Баг-трекинг: локализация и оформление дефектов

Ольга Назина Санкт-Петербург «БХВ-Петербург» 2024 БАГ-ТРЕКИНГ: локализация и оформление дефектов

ISBN 978-5-9775-1915-1 © Назина О. Е., 2024 © Оформление. ООО «БХВ-Петербург», ООО «БХВ», 2024 УДК 004.415.53 ББК 32.973.26-018.2 Н19 Назина О. Е. Н19 Баг-трекинг: локализация и оформление дефектов. — СПб.: БХВ-Петербург, 2024. — 352 с.: ил. ISBN 978-5-9775-1915-1 Подробно раскрываются темы о локализации дефектов, освещаются правила и приемы оформления описаний выявленных ошибок и исправлений. Приведены паттерны и антипаттерны обоснования задач. Описаны инструменты баг-трекинга и процесс отслеживания ошибок. Рассказано о методах ретроспективного анализа ошибок. Рассмотрен жизненный цикл (Workfl ow) задач. Приведено множество примеров локализации ошибок, оформления дефектов и задач, даны рекомендации по составлению описаний. Для тестировщиков ПО и специалистов технической поддержки УДК 004.415.53 ББК 32.973.26-018.2 Группа подготовки издания: Руководитель проекта Павел Шалин Зав. редакцией Людмила Гауль Редактор Григорий Добин Компьютерная верстка Людмилы Гауль Корректор Светлана Крутоярова Оформление обложки Зои Канторович «БХВ-Петербург», 191036, Санкт-Петербург, Гончарная ул., 20.

Спасибо всем моим ученикам за активное участие в создании материалов для книги. Она существует благодаря вам :-) Отдельное спасибо моим учителям, которые вдохновляли меня — Алексею Баранцеву и Павлу Абдюшеву. И всем моим коллегам, советы которых помогают мне доносить правильные мысли до студентов. И, конечно, большое спасибо моей семье за поддержку в этом нелегком деле — мужу Александру, мамочке Светлане и сыну Владиславу. Куда же я без вас?

1. Тестировщик находит баг — О, неведомая хрень! — О, ошибка, надо локализовать и оформить Кевин Катя 2. Оформляет его — Как-то так я шел, че-то нажимал... — Обойти дерево с дуплом индюшки, пройти вдоль реки, повернуть направо... Кевин делает тяп-ляп Катя локализует, ищет причину

3. Разработчик пытается воспроизвести... — И что? И где? — Не знаю, где-то тут было... — И что? И где? — Да вот же, смотрите! 4. Получилось только с грамотно оформленным багом! — Ты что, дебил? Тут ничего нет! — Правда, баг! Спасибо!

От автора Привет! Меня зовут Оля, и я — тестировщик. Возможно, мы с вами одной крови профессии, а возможно, и нет. Но раз вы держите эту книгу в руках — значит, вы хотите научиться оформлять баги так, чтобы их исправляли. А улучшения — чтобы их делали. Почему баги не исправляют, а улучшения не делают? Причины бывают разные: › задача плохо описана — из нее вообще не понятно, почему это баг; › задача не воспроизводится по шагам — ну, увы, тогда закрываем; › задачу решили не делать (слишком много других задач / слишком дорого исправлять / нет ресурсов). С последним пунктом мы мало что можем сделать, разве что убедить менеджера в том, что исправление стоит трудозатрат. Но иногда и это не помогает. Да, баг, но пусть живет — это суровая реальность. ОЖИДАНИЕ РЕАЛЬНОСТЬ Исправляются все-все-все баги Это не так :-) А вот на первые пункты можно и нужно влиять! И именно в этом поможет книга — уменьшить количество отклоненных из-за плохого описания задач.

10 От автора Персонажи Мне проще усваивать материал, когда сухой текст разбавлен картинками. Поэтому сама я пишу в таком же стиле — в книге вас ждет очень много картинок! Давайте познакомимся с главными героями. Это Кевин — белка-истеричка. Всем привет! Я — Кевин. Белка-истеричка. При виде бага впадаю в панику, бегаю вокруг компа разработчика и кричу: «Ужас, ужас, исправляй скорее!» А когда разработчик просит воспроизвести, у меня не всегда получается. Я ведь не знаю причины ошибки, увидел и сразу сообщил. Его реакция на баг выглядит примерно так: КОШМАР!!! ГОВНОКОДЕРЫ!!! ВСЁ ПЛОХО!!! КАК ЭТО ВЫШЛО В PROD?! Мы все умрем... ВСЁ СЛОМАЛОСЬ!

От автора 11 А это Катька — тестировщик, и она идеально оформляет баги. Ну, или пытается =) А я — Катька. Тестировщик. При виде бага изучаю его, ищу корень зла и понятно оформляю! Будут встречаться и другие персонажи: разработчик, начальник… Но основные два — это Катька и Кевин. Разумеется, Кевин — доведенный до абсурда персонаж. В реальной жизни тестировщики обычно более спокойно реагируют на найденные ошибки. Но иногда кажется, что все действительно пропало. По крайней мере, такое бывает у меня. Причем не только на первой работе, но и на второй, и на третьей. Вроде уже 5+ лет опыта, 10... А всё равно иногда видишь баг и сразу: «А-а-а-а-а, кошмар, кошмар, всё плохо, чини скорее!!!!» Бедный разработчик при этом выглядит вот так: Ну что пристала?

12 От автора А потом начинаем разбираться и выясняется, что баг вовсе не такой страшный. Его легко обойти или он встречается редко (плохо локализовала), поэтому не так критичен. Или я неправильно написала автотест и развела панику, что функциональность не работает. А на самом деле проблема в тесте... Так что даже опытных тестировщиков не обходит судьба Кевина. Конечно, я сужу по себе, но встречала похожие случаи среди опытных тестировщиков. Так что бывает, бывает! И с новичками бывает, и с матёрыми специалистами. Наша с вами задача — перейти от белки-истерички к спокойному и умному специалисту, который анализирует баги, локализует ошибки, понимает приоритет... В общем, к Катьке! Белка-истеричка Идеальный тестировщик И тогда уже совсем неважно, кто вы: › тестировщик; › разработчик; › аналитик; › сотрудник техподдержки › да и просто заказчик. Главное, что ваши задачи исправляют! А ведь это очень приятно, да? ;-) Так давайте разбираться, как же грамотно заводить задачи.

Часть I Часть I ВВОДНАЯ ВВОДНАЯ

ГЛАВА 1 Что такое баг? Баг Так что же я такое? В этой главе разберемся с определениями. Ведь перед тем, как баг заводить, нужно сначала понять, что же он такое. И когда баг — это не баг… Это позволит не ставить лишних задач, которые никогда не будут исправлены.

16 Часть I. Вводная 1.1. Определение бага Я могла бы сейчас просто выписать несколько определений бага из разных источников и сказать: «Мне больше нравится вот это!» Вот только насколько это будет полезно? Раньше все мои курсы для начинающих начинались с беседы в чате «А что же такое баг?» Как думаете, сколько времени она занимала? =) Кажется, что это легко — быстренько погуглил и пришел с ответом. Что такое баг? Я погуглила! Вот только самый распространенный ответ очень легко опровергается… И ой! Дальше уже сложнее становится. Вывод определения обычно занимает полдня и 50–200 сообщений в чате. А то и больше, если активные участники чата берут перерыв. Но при этом он о-о-о-о-чень полезен. Готовый ответ не запоминается. А если размышлять, как переформулировать, чтобы «дурацкий пример тренера» перебить — в подкорке сохранится! Те, кто участвовал в обсуждениях, сами потом признавали: «Прям чувствую, как шестеренки в мозгу завертелись, спасибо». Поэтому я предлагаю вам пройти этот путь вместе. Не просто прочитать «что тренер думает на эту тему», а поразмышлять над вопросами, которые я сейчас буду задавать. Обещаете думать, а не просто читать? =) Итак, начинаем размышлять! — Что же такое баг?

Глава 1. Что такое баг? 17 Давайте я угадаю, что вы ответите. Если вы хоть что-то пытались поискать по теме тестирования или читали книгу Романа Савина1 , ответ будет такой: — Отличие фактического результата от ожидаемого! Что такое баг? Отличие фактического результата от ожидаемого! Далее диалог развивается примерно так: — Окей, Гугл, поставь баг в Скайп, я ожидаю при каждом сообщении в этот чат перевод 1000 долларов на мой счет. — Не, ну это не баг! — Почему? Фактический результат расходится с ожидаемым. — А где написано, что Скайп должен переводить деньги? Он нигде не обещал! Значит, не должен! — Э-э-э-э, а где в определении выше было что-то про публичные обещания? 1 «Тестирование dot com» Окей, Гугл, поставь баг в Скайп, я ожидаю при каждом сообщении в этот чат перевод 1000 долларов на мой счет Это не баг! Скайп этого нигде не обещает! А где в твоем определении было про обещания?

32 Часть I. Вводная Особенно, если речь про иностранное ПО, которое локализовали под русский язык. «Ошибка» — это и будет баг. Ничего страшного в этом нет. Ведь чаще всего баг — это и правда какая-то ошибка, вылезающая на экран. Или ошибочное поведение программы. Так что чаще всего «ошибка», «сбой», «баг» — применяются именно как синонимы. Но историю с платьем запомните. Пригодится при сдаче экзамена ISTQB или на собеседовании, если вас попросят указать разницу. 1.4. Вопросы для самопроверки 1. Чем плохо определение бага из Савина: «Отличие фактического результата от ожидаемого»? 2. Что такое баг? 3. Ошибка, дефект и сбой — чем различаются? 4. Чем баг отличается от ошибки? А от улучшения? Или просто задачи? 1.5. Ответы на вопросы для самопроверки 1. Чем плохо определение бага из Савина: «Отличие фактического результата от ожидаемого»? Оно работает только тогда, когда есть четкое ТЗ. Тогда да, отклонение от ТЗ является багом. В системе или самом ТЗ. 2. Что такое баг? Баг — это проблема для лиц, чье мнение имеет для нас значение. 3. Ошибка, дефект и сбой — чем различаются? См. разд. 1.3: Ошибка — это действие разработчика, в результате которого в программе появляется дефект. Когда дефект срабатывает, в системе происходит сбой. 4. Чем баг отличается от ошибки? А от улучшения? Или просто задачи? Баг — это и есть ошибка. В английской версии обычно тип задачи Bug, в русифицированной Jira — «Ошибка». В других системах может быть как-то иначе. Баг — это проблема, которая уже есть в программе. Улучшение — то, какой мы хотим видеть программу в будущем. Задача — ни то ни другое (например, «написать автотесты или документацию»)

ГЛАВА 2 Как заводить задачи в баг-трекер? Переходим к главной теме книги — тому, как заводить задачи. В этой главе мы обсудим сам процесс кратенько, с высоты птичьего полета. Это тот чек-лист, который вы сможете применять потом, после прочтения книги. Напоминалкой будет =)

34 Часть I. Вводная 2.1. Процесс баг-трекинга Баг-трекинг — это заимствованное из английского языка от «bug tracking» — процесс слежения за багом. Вы ведь хотите, чтобы ваши баги исправлялись? Тогда за ними надо следить! Если в компании не используется система отслеживания ошибок, то процесс выглядит примерно так: тестировщик нашел ошибку, сообщил разработчику. Тот быстренько исправил и отдал новую версию на тестирование. Такое вполне возможно в небольших компаниях, почему нет? Тут ошибка при регистрации через Твиттер... Ага, ok, сейчас исправлю! Подход хорош... Но есть и минусы: 1. Каждое отвлечение — потеря времени. Идеальное рабочее состояние — состояние потока1 . Но если отвлечь человека, когда он продумывает сложный алгоритм, он потеряет мысль. И бывает такое, что тебя отвлекли на одну минуту, а вернуться к коду, вспомнить, что делал, на чем остановился, занимает полчаса. Особенно обидно, если отвлекли по мелочи: спросили про обед или задали вопрос, который могли бы и сами погуглить. При этом не все разработчики осознают всю ценность работы в тишине. Некоторым нравится открытый диалог, они сами призывают к тому, чтобы вы сразу говорили о том, что нашли. Хотя такое обычно бывает на начальных стадиях развития продукта. Когда или разработчик молодой неопытный, или ему просто хочется фидбек побыстрее получить. 1 См. книги Михая Чиксентмихайи про поток.

Глава 2. Как заводить задачи в баг-трекер? 35 Как решается такая ситуация? Очень просто. Заранее договоритесь о правилах: y Разработчик сделал новую сборку? Полчаса тестируем! Разработ чик в это время занимается чем-то простым, чтобы можно было прерваться без потери концентрации, а тестировщик проверяет. Если что-то нашел, сразу говорит разработчику. Все довольны, но это длится оговоренное время. Сеанс тестирования 30 мин y В офисе часто используется предмет-сигнал: «Не трогайте меня, я занят». Обычно это надетые наушники. Если разработчик сидит в наушниках — он ушел в глубины кода, отвлекать его не стоит, пишите на почту, чтобы не забыть. Если он снял наушники — можно подходить с вопросами. Он в наушниках — его трогать не надо. Запишу пока вопрос, потом задам

36 Часть I. Вводная Для удаленщиков можно использовать статусы: если занят — красный сигнал, чтобы пока не отвлекали или писали отложенное сообщение. Впрочем, иногда разработчик просто ограничивает время выхода в сеть. Скажем, утром часик, после обеда часик... В остальное время он отключает мессенджер и погружается в задачу. 2. Ой, я забыл исправить! Разработчик сказал: «Да, это баг, сейчас исправлю», — но... Забыл. Да, такое тоже бывает. Возможно, он решил доделать то, чем занимался, а баг исправить уже потом. Но увлекся работой и просто забыл о новой задаче. Или его отвлекли более критичным багом, и про ваш мелкий он совсем забыл. Или его просто отвлекли... В итоге получается так, что все знали о баге, но никто его не починил. В хорошем раскладе тестировщик просто напомнит о нем в следующем сеансе тестирования. В плохом — этот баг попадет на prod2 , и его найдет пользователь. А потом к тестировщику придет начальник с вопросом: — Почему вы не нашли этот баг?? — Нашли! Я вчера Васе (разработчику) его показывал... И разработчик такой: — Блин, точно! Приходил, но меня потом отвлекли, и я совсем забыл... Почему вы не нашли баг? Нашли! Вась, я же тебе его вчера показывала, помнишь? Блин, точно! Показывала, но меня потом отвлекли, и я совсем забыл... 2 Prod, он же Production, — «боевая» среда, то есть та, с которой работают реальные пользователи (обычно отдельно есть тестовая, отдельно — prod, ну и разные вариации между ними).

Глава 2. Как заводить задачи в баг-трекер? 41 3. Придумайте короткий и ёмкий заголовок Упоротый менеджер в 12 но чи просматривает багтрекер, и он должен по заголовку понять, насколько критично исправить проблему. Если он пропустит серьезную ошибку из-за непонятного названия, утром полетят головы. Если он поднимет панику из-за несерьезной задачи, выставит себя дураком. И сильно обидится на того, кто ставил задачу. Если он не поймет из названия, в чем проблема, задачу закроют, даже если там реальный косяк. Соизмеряйте важность проблемы и название задачи. Не будьте Кевином! Не будьте Кевином! А-А-А-А-А-А-А, КОШМАР, ВСЁ ПРОПАЛО, НИЧЕГО НЕ РАБОТАЕТ! Авторизация через Твиттер падает с HTTP 500 Так ПЛОХО Так ХОРОШО Менеджер ночью смотрит задачи. Поймет ли он, о чем речь?

42 Часть I. Вводная Нет Да А-А-А-А-А-А-А, КОШМАР, ВСЁ ПРОПАЛО, НИЧЕГО НЕ РАБОТАЕТ! Авторизация через Твиттер падает с HTTP 500 В исследуемой системе при вводе в поле «Имя» символов русского алфавита, английского алфавита, спецсимволов и символов в неправильной кодировке поведение программы неверное Падает отправка письма в кодировке UTF-08 Двойные имена Нет подсказок по двойным именам в ФИО Если в заголовке появились слова «Ошибка», «Неправильный», «Некор ректный», «Неверно» — перепишите заголовок. Вы заводите задачу с типом «Ошибка» — уже понятно, что что-то работает не так. Объясните проблему: «Можно зарегистрироваться с именем Ктулху». Но если вы заводите улучшение, заголовок должен предлагать, а не ставить перед фактом: «Запретить регистрацию с именем Ктулху». Баг Улучшение Можно зарегистрироваться с именем Ктулху Запретить регистрацию с именем Ктулху Сообщение об ошибке указывает на неверный пароль при вводе недопустимого имени Выводить в сообщение об ошибке детальную информацию по причине Нет подсказок по двойным именам в ФИО Выводить подсказки по двойным именам в ФИО Можно зарегистрироваться с паролем 123 При регистрации добавить проверку небезопасных распространенных паролей Нельзя загружать несколько файлов сразу Обрабатывать загрузку нескольких файлов 4. Приложите скриншот Первое, что цепляет взгляд — это картинка. Иногда разработчику достаточно названия и картинки, чтобы понять, где проблема. Даже если вам кажется, что и без скриншота всё понятно, не поленитесь, добавьте его. Баги не всегда исправляются сразу. Спустя месяц изменится интерфейс, и без скриншота может быть непонятно, о чем речь в задаче. Картинка поможет тестировщику увидеть «как было до», чтобы сопоставить с настоящим. На картинке не должно быть ничего лишнего. Если нужна только маленькая часть экрана — прикладывайте ее, а не весь рабочий стол. Если скриншот получается большим, выделите в нем область, на которую надо смотреть, — например, нарисуйте стрелочку.

ГЛАВА 3 Как локализовывать ошибки? Ошибка? Сейчас локализуем! В этой главе мы разберемся подробнее с тем, что такое локализация, и зачем она нужна. А ещё обсудим, что такое: › принцип лопаты; › эффект лентяя. И зачем нужно опровергать свои теории.

58 Часть II. Локализация ошибок 3.1. Что такое локализация? Локализация — это поиск первопричины. У одной причины может быть десяток следствий. Например, не работает загрузка фотографий в альбом. А кнопка загрузки есть в нескольких местах: › на главной странице сайта; › в личном кабинете в разделе фотоальбомов. И там, и там, если нажать «Загрузить», вылетит ошибка. Но не надо ставить два разных бага, ведь по сути он один: не работает функциональность. Если заводить разные задачи, вы усложняете жизнь разработчику. Ему придется при исправлении одного бага менять статус 2–4–6 задач. При этом надо будет открыть список из 20–50 задач, которые висят на нем, и самому искать дубликаты. Конечно, он это делать не станет — закроет только ту задачу, которую увидел первой и по которой нашел проблему в коде. В итоге менеджер будет смотреть на статистику задач и думать, что разработчику еще пять багов чинить. А они уже все давно исправлены. Нехорошо! Готово В работе Не готово Готовы в рамках Задачи 1 Готовы в рамках Задачи 2 Реально не готовы всего 3 задачи Из-за дублей не видно реальной статистики Поэтому перед постановкой задачи ее стоит локализовать. Это первый вариант локализации — когда мы нашли баг и хотим убедиться в том, что наша теория о том, что именно сломалось, верна. Явно хочется понять, где будет второй...

Глава 3. Как локализовывать ошибки? 59 3.2. Как локализовывать ошибки? Для локализации проблемы: › поисследуйте область рядом (а если не только «А», но и «Б» ввести?); › стройте догадки (вводить можно все, что захочешь)... › и опровергайте их! Последний пункт может показаться немного странным. Но только на первый взгляд. Видите ли, есть такая ментальная ловушка: если мы уже что-то придумали, нам сложно отказаться от этой идеи. Поэтому Кевин и поднимает панику. Если что-то не работает — о ужас, о кошмар, всё не работает, остановите prod! Хотя если копнуть чуть глубже, понимаешь, что это не так. Но даже если не брать в расчет белку-истеричку, бывает такое, что ты провел тест — ого, не работает! Провел второй, чтобы подтвердить локализацию — ну точно, не работает!! И кажется, что всё не работает. А на самом деле мы просто подбираем примеры, подходящие под выдуманный нами образ причины проблемы. Не очень понятно, да? Сейчас разберемся подробнее. Копаем рядом (принцип лопаты) Когда вы находите баг, нужно покопаться рядышком. Вдруг вы нашли всего одно проявление, а их сильно больше? Посмотрим на примере. Кто у нас не умеет локализовывать баги? Правильно, Кевин! И вот он тестирует форму ввода. В поле «Доход» по ТЗ можно вводить только числа. Он вводит символ «а» и... Символ вводится! Доход а вводить можно только цифры

60 Часть II. Локализация ошибок Кевин рад, он нашел баг! Для него баг — это орешек (вспомнили же «Ледниковый период» сейчас, да?). Ух ты, баг! Кевин не любитель локализовывать, копать рядом. Ему пофигу, что рядом с одним орешком еще десяток, вон там, под листвой лежат. Он ведь нашел баг!!! Надо срочно всем рассказать! Что он и делает — бежит к команде и хвастается багом: — Смотрите, что я нашел! У нас баг в системе!! Зацените!!! Вот дурак... Ого, какой орешек... Некоторые коллеги думают: — Ух ты, как круто! И правда, баг, а я его и не замечал... Но опытный разработчик знает, что нельзя сразу ставить баг, надо покопать рядом.

ГЛАВА 7 Примеры локализации Ха! А правду Васька говорил, надо искать на границах! Можно учиться на собственных ошибках, а можно на чужих. Но ведь это не только ошибок касается! Локализация не так проста, как кажется, а насмотренность многое дает. Поэтому в этой главе на примерах из реальной жизни мы посмотрим, как находится корень зла.

128 Часть II. Локализация ошибок 7.1. Примеры локализации бага, найденного тестировщиком 1. «Вы используете устаревший браузер» в поддерживаемом браузере при переходе на сайт из документов Office Если в приложении есть проверка на устаревший браузер, то мы получаем любопытный кейс при работе с MS Office: любая ссылка из него ведет на страницу «Вы используете устаревший браузер». Даже если сам браузер поддерживаемый. Когда я узнала о причине бага, специально себе такой же внедрила. Вот вам ссылка: http://buggy.bugred.ru/. А теперь попробуйте: 1. Скопировать ее интернет-адрес (URL) и открыть в браузере — она открывается, пишет о том, куда вы попали. 2. Вставить ее в Word и открыть из него (в том же самом браузере) — откроется страница «Вы используете устаревший браузер». Узнали про эту особенность случайно — на моем курсе, когда студенты тестировали другой сайт. В одном из ДЗ они писали тест-кейсы. Сдавали обычно в ворде или экселе — курс был не про инструменты, а про саму технику составления кейсов. Как проверить, что тест-кейс вообще выполним, никакой шаг не забыт? Правильно. Написали тест-кейс, а потом попробовали сами по нему пройтись. Тыкнули на свою же ссылочку, увидели страшную страницу, перепугались... Потом задумались... Браузер-то нормальный, пять минут назад всё работало. Открыли в новой вкладке — работает! И вот тут начинается локализация бага. Если сразу оформлять, то это будет реакцией Кевина: «Но мы исследуем область рядышком: это только в ворде так? Или в экселе тоже? А в других приложениях офиса? У нас возникла теория, что баг касается приложений MS Office. Стоит ли бежать и тестировать вообще все приложения офиса?» Нет, не стоит. Наша задача — предоставить информацию. Информация должна быть значимой: › для понимания масштаба проблемы; › для ее исправления. Что мы нашли? Какую теорию вывели? Что ссылки из офиса не открываются. Хм. Тут же возникает вопрос — а как вообще используют ссылки и где? Ну не открывается из ворда, и что? Может, ну его?

Глава 7. Примеры локализации 129 Из ворда открывается... КАК ЭТО ВЫШЛО В PROD?! ВСЁ ПЛОХО! Мы все умрем... ГОВНОКОДЕРЫ!!! КОШМАР!!! Значимое для: y понимания масштаба y исправления Как используют ссылки и где? Какие из MS приложений важно проверить, какие — нет?

130 Часть II. Локализация ошибок Какие из MS приложений важно проверить, какие — нет? Думаем о сценарии использования. Ссылки задействуются в промома териалах. Например, когда мы делаем рассылку и вставляем туда ссылку на сайт. Если наша аудитория — офисные работники, велик шанс, что они будут просматривать почту через Outlook. Значит, проверить почтовый сервис — действительно важно. Про ве ряем в первую очередь его, а дальше уже смотрим по обстоятельствам. Воспроизвелось? › ДА — ставим блокер-баг, потому что это важно: рассылка уже ходит, а если из маркетинговых материалов ссылка не откроется, это fail; › НЕТ — думаем дальше, что будет значимо? Воспроизвелось? ДА Ставим блокер НЕТ Что значимо? Начну с важного — Outlook

ГЛАВА 12 Как правильно вложить аттач в задачу? Куда тут смотреть? ПЛОХО Тут понятно куда ХОРОШО Красное платье Состав: хлопок 100% Синее платье Состав: хлопок 100% Редкий баг обходится без дополнительных вложений. Обычно у нас есть название, описание + некий аттач (от английского слова attachment, «вложенный файл»). Чаще всего это картинка, скриншот экрана. В идеале разработчику достаточно прочитать название задачи и посмотреть на скриншот, чтобы понять, в чем дело. Но так ли легко вложить скриншот правильно? Давайте разбираться, какие бывают типовые ошибки вложений и какие есть правила хорошего тона.

214 Часть III. Оформление задач 12.1. Общее правило вложений: говорящее название Люди обычно не заморачиваются: «на чем воспроизвел, то и приложу». Если это скриншот экрана, то как его система сохранила — с названием «Скриншот» или «20000809» — так и аттачим1 . Дайте файлу говорящее название, чтобы его проще было найти. Ведь обычно в задаче не один вложенный файл, а несколько. И тогда вы просто запутаетесь среди десятка одинаковых вложений «Рисунок» или «Тест». Что значит 111, о чем эта картинка? Названия аттачей должны быть говорящими! Что файл олицетворяет? Какой-то шаг или ошибку? Об этом и пишите: См. рис. 8453659846.jpg См. рис. «Кривая статистика». См. рис. «Мертвый демон». См. рис. «Автобус парит в воздухе». См. рис. «Борода у женского персонажа». См. рис. «Ул. Адмирала Лазарева, данные ФИАС». См. рис. «Шаг 1. Регистрация». См. рис. «Ошибка авторизации». 1 Жаргонное слово. Аттачим = прикладываем файл к задаче.

Глава 12. Как правильно вложить аттач в задачу? 215 Это касается не только скриншотов, но и вообще всего! См. файл «Тест.xls». См. файл «Много колонок.xls». См. файл «Одна ячейка.xls». См. файл «20_mb.xls». 12.2. Общая ошибка: нет отсылки на аттач по тексту Допустим, мы дали скриншоту хорошее название и вложили его в задачу. А потом... В теле задачи пишем: «Результат: отчет падает с ошибкой, см. скриншот». За такое мы на курсах ругаемся: — На какой скриншот мне смотреть? — Он там один, зачем уточнять? Объясняю. Реальная жизнь выглядит так — на примере бага: — Вася заводит баг, в нем один скриншот. — Тестировщица Маша комментирует баг: «Воспроизвелся на моей ветке тоже», — и прикладывает новый скриншот. — Разработчик Петя не понимает, что творится в логах, прикладывает скриншот, логи и просит разработчика Мишу посмотреть. — Разработчик Миша смотрит логи, объясняет Пете, в чем дело, прикладывает аттач с серверными логами, соответствующими клиентским. — .... Там ошибка, смотри аттач! На какой из них мне смотреть?!

216 Часть III. Оформление задач В результате вы имеете баг, в котором аттачей полтора десятка. И если в описании задачи написано «см. аттач», то автора начинают тихо ненавидеть. Потому что непонятно, а на какой смотреть-то? Да, на момент постановки задачи вложение могло быть одно. Ну и что? Учитывайте сразу будущую жизнь вашей задачи. Конечно, студенты любят привести аргумент: «У нас такого не будет, ведь баг правлю только я после комментария тренера. Давайте, вы так зачтете, а я потом, на настоящей работе, буду правильно заводить». Ага-ага, сейчас лень, а потом сразу правильно буду =) Сразу вспоминается, как я на курсы макияжа ходила. Там тренер учила накладывать тон долго, прорабатывая каждый участок. А потом, когда перешли к следующей теме, и она сказала: «Наложите пока тон», — все справились за пару минут. Думаете, это успех? Нет! — А как это вы так быстро справились? Учитесь сразу делать хорошо. А тактика: «Я сейчас быстренько и тяп-ляп, а вот пото-о-ом, с реальными клиентами буду уже аккуратно всё делать», — не работает. Как сейчас приучитесь делать быстро, так потом и продолжите. Поэтому учитесь сразу делать хорошо, я лучше подожду еще немного. Я на обучении тяп-ляп быстренько сделаю, но ты не обращай внимания. В реальной жизни всё правильно делать буду Ну да, как же! Делайте сразу хорошо. И поверьте, это окупится. Иначе будет вечное «авось новых аттачей не добавят» или «авось все запомнят, что я имел в виду вон тот». А потом читаете свою же задачу спустя полгода и тихонько материтесь, ища среди аттачей тот, который имелся в виду.

ГЛАВА 13 Дополнительные поля Названия и описания в баге недостаточно для дальнейшего анализа! Версия Исполнитель Приоритет Здесь и сейчас, чтобы воспроизвести ошибку, достаточно названия и описания. Но чтобы потом ее найти и проанализировать, нужны дополнительные сведения. Какие? Давайте обсудим! Какие бывают поля в баг-трекере? Кто и как их заполняет?

226 Часть III. Оформление задач 13.1. Что можно встретить в баг-трекере? Название Приоритет Исправить в версии Появилось в версии Исполнитель Комментарий Автор Описание Watchers Бизнес-обоснование Менеджер Срок исполнения Да всё, что угодно! Приоритет, ис пол нитель, автор, бизнес-обос но вание, к какому сроку выполнить, мене джер, отвечающий за поставку... Я не могу привести здесь все-все-все возможные варианты, потому что это нереально, — баг-трекинговые системы разрешают добавлять не только стандартные поля, но и какие-то свои. Так что какой комплект будет у вас на работе — там и узнаете. А в этой главе я расскажу про некоторые типовые поля. 13.2. Приоритет / важность (Priority / Severity) Приоритет показывает, насколько критично исправить проблему. Просто представьте, что разработчик сделал новую функциональность, а тестировщик сходу нашел там 20 багов. С какого начать исправление? Что можно отложить на потом? Подскажут приоритеты: › Critical — очень критично, начинаем с нее! › Normal — обычная задача; › Minor — некритично, можно и отложить. Градаций может быть не три, а больше. Например, можно добавить Bloker — «еще важнее, чем Critical, всё бросаем и исправляем». Или увеличить градацию неважных задач, добавив «trivial» или «text» (опечатка в тексте). Все зависит от фантазии вашей команды и необходимости в работе.

ГЛАВА 15 Примеры оформления задач Примеры помогают понять, что мне делать Мы много говорили о том, как правильно оформлять задачи. Теперь осталось собрать всё вместе и применить. В этой главе я покажу несколько примеров оформления багов и улучшений — с комментариями, на что при этом обращать внимание. А вы читайте и проверяйте себя — всё ли знакомо и запомнилось из предыдущих глав?

272 Часть III. Оформление задач 15.1. Nginx error при просмотре программы лояльности Обнаружила баг чисто случайно: заинтересовало название кнопки на сайте, вот и попробовала туда ткнуть. Шаги для воспроизведения 1. Открыть главную страницу: http://www.cinemapark.ru/. 2. Нажать на кнопку Программа лояльности (рис. 1. Нажать на кнопку). Результат Открывается страница http://www.cinemapark.ru/bonus/, но Nginx ее режет. В итоге видим ошибку (рис. 2. Nginx error): «Nginx error! Something has triggered missing webpage on your website. This is the default 404 error page for nginx that is distributed with EPEL. It is located /usr/share/nginx/html/404.html You should customize this error page for your own site or edit the error_page directive in the nginx confi guration fi le /etc/nginx/nginx.conf.»

Глава 15. Примеры оформления задач 273 Ожидаемый результат Открытие программы лояльности. Программа должна открываться не только внутри корпоративной сети — ведь на нее идет ссылка с главной страницы сайта. То есть это не внутренняя документация. На что обратить внимание: 1. Шаги отображают реальный сценарий. Можно, конечно, сразу в шагах дать прямую ссылку: Открываем http://www.cinemapark.ru/bonus/, и всё падает! Но такой баг могут закрыть, потому что не видно проблемы. Откуда у пользователя прямая ссылка? Может, ему кто-то скинул информацию, которая и должна быть доступна только внутри корпоративной сети... И всё ok — неча лезть, куда не просят. А так мы показываем, что вот у тебя на главной странице большая призывная кнопка, — и когда она не работает, это фейл ))) 2. Названия скриншотов говорящие, а не просто: «рис. 1», «рис. 2»... Специально обращаю на это ваше внимание, потому что не указать название скриншотов — типичная ошибка у моих студентов. 3. Вложены логи (текстом, не скрином). Недостаточно приложить скриншот ошибки — лучше выписать ее текст. Потому что по тексту можно искать, а по картинке — нет. А еще бывает, что ты забыл вложить аттач, и сиди потом гадай при проверке, что за ошибка такая выскакивала. 15.2. Не загружаются файлы с большим количеством (более 165 тыс.) строк Внимание: не пытайтесь воспроизвести этот баг сами! Во-первых, он исходно был найден на тестовом стенде и давно исправлен. Во-вторых, он про нагрузку на сервер, а нагрузочное тестирование мы ради своей прихоти на чужом сайте не проводим — только с разрешения хозяина. У нас разрешение на тестовом стенде было, и вот баг от студента: Ш а г и 1. Открыть форму стандартизации данных: https://example.ru/clean/#process-fi le (почта: [email protected], пароль 1234). 2. Загрузить файл эксель с большим количеством (например, 168 тыс.) строк (см. аттач «Эксель с 168 тысяч строк»). Фактический результат Файл не загружается, показывает прогресс-бар на 100% загрузки и при этом висит более 30 минут — не понятно, почему файл при показанной 100% загрузке не грузится 30 минут (см. рис. «Скрин загрузки экселя с 168 тысяч строк»,)

274 Часть III. Оформление задач Ожидаемый результат Файл загружается, так как в описании примера файла для загрузки нет ограничений на допустимое количество строк в загружаемом файле (см. аттач «Скрин требований по формату загруж.файла.jpg»), а загружаемый файл имеет размер менее 20 Мбайт. Для файлов менее чем с 168 тыс. строк при 100% заполненном прогресс-баре: • для файла с 50 тыс. строк висит секунд 15; • для файла с 100 тыс. строк висит секунд 30; • для файла с 150 тыс. строк висит 1 мин; • для файла с 162 тыс. строк висит 3 мин. Для файла 168 тыс. строк при 100% заполненном прогресс-баре зависает больше чем на полчаса (см. аттач «Скрин загрузки экселя при 168 тысяч строк»).

ГЛАВА 18 Инструменты баг-трекинга Мы только что обсудили преимущества специализированных инструментов. А какие они вообще бывают? Где и как можно оформлять баги? Я расскажу вам, как было во времена «динозавров», чтобы вы еще раз прочувствовали всю прелесть современных инструментов! На самом деле в качестве инструментов баг-трекинга можно использовать все, что угодно: › Гуглодоку; › ворд; › Скайп; › почту; › ... И я абсолютно серьезно это говорю. Про Гуглодоку слышала, а ворд и почту сама использовала.

300 Часть IV. Процессы и инструменты 18.1. Самодельные инструменты Почта На первой моей работе мы тестировали игрушки для мобильных приложений. Это было в далеком 2006 году. Если мы видели ошибки, то создавали письмо в почте, туда прикладывали шаги, скриншоты (ну какие скриншоты... фоточки! Те телефоны еще не поддерживали функцию снимков экрана, и у нас был специальный фотоаппарат для этого) и отправляли разработчику. Почта — не самый удобный инструмент баг-трекинга, но и такое бывает Разработчик отвечал на каждое письмо, где подписывал у каждой ошибки статус: починил или отклонил (не баг). Тестировщик получал письмо и должен был сразу проверить исправление, — иначе можно было легко забыть, что правилось. Ну или настраивать как-то специально почту: «Вот это письмо прочитано, но не проверено», но таким мы не заморачивались. Новички обновлять версии не умели, поэтому шли к начальнику с телефоном. Тот обновлял сборку, мы проверяли фикс1 и писали ответ на письмо разработчика: всё проверено, ок. Или: «Вот это и это до сих пор не работает, вот новые скрины». Конечно, это не самый удобный инструмент, — разработчик периодически получал дубли... Но тем не менее оно работало! Уж не знаю, почему 1 Фикс — исправление ошибки (жаргон).

Глава 18. Инструменты баг-трекинга 301 Ворд — инструмент баг-трекинга??? не было «нормального» инструмента. Возможно, о них тогда просто не знали. Это сейчас про Jira каждый в курсе, а раньше было не так. А может, что-то уже существовало, но не захотели платить или заморачиваться с настройкой. И так ведь работает! Ворд Потом я работала в небольшом стартапе. Я уже знала о существовании джиры и всячески уговаривала ее подключить и настроить. Ребята были против: › Jira — платная, но на небольшую компанию до 10 человек это стоило всего 10 долларов в месяц, на что и был упор в моих доводах; › настраивать неохота, времени тратить жаль, но тут я готова была ее настроить сама. Тем не менее какое-то время мы жили с багами в ворде. Да-да, в простом ворде! Мне разработчица отдавала функциональность на тестирование. Я ее проверяла, все баги описывала в ворде. Потом скидывала файлик ей через Скайп (даже дропбокс для версионности не использовали). Она в нем размечала всё, что исправила, возвращала мне. Я проверяла по файлу. Потом или дополняла его, или создавала новый файл, куда писала новые проблемы + копировала недоисправленные. Очень неудобно было, хочу вам сказать =) Но жили же как-то... Однако я рекомендую использовать нормальные, специализированные инструменты. Тем более, что сейчас вариантов стало много, — есть и бесплатные, и дешевые... Так что завязываем с байками из жизни, переходим к тому, «как надо»! Просто знайте, что бывало… 18.2. Специализированные инструменты Сначала список удобных и «красивых» инструментов2 (2023 год): › Jira — платная, но крутая; › Redmine — основной конкурент, бесплатный; › YouTrack — чем-то похож на Jira, но менее распространен; 2 Разумеется, это ИМХО (мое мнение). Все люди разные, для меня удобно одно, для вас другое.

302 Часть IV. Процессы и инструменты Менее удобные, но относительно популярные (2023 год): › Mantis — в целом не так уж плох, но не сравнится с Jira или Redmine; › Bugzilla — она вообще не конкурент, но если не верите… Тут даже отредактировать задачу нельзя, только новый комментарий написать; › Trac — как по мне, так вообще убожество, там надо писать в HTMLразметке, а зачем заморачиваться, если даже в Гуглодоке и то про это думать не надо? Если у вас еще нет никакого инструмента на работе, предложите установить какой-нибудь. Лично я фанатка Jira, она мне кажется простой и удобной. Тем более, что в облачной версии всё можно создать/настроить в пару кликов и работать почти «из коробки». А вот с редмайном — чтобы он стал удобным — надо повозиться администратору... В любом случае вы можете попробовать парочку разных инструментов, чтобы сделать выбор. Какой понравится, тот и ставьте. Обычно у инструментов есть trial-версия («попробуй бесплатно один месяц»), используйте ее. Круто! А триал-версия есть? Ну или тестовые площадки, находящиеся в открытом доступе. Например, у меня на портале «Testbase» есть такие3 . Мне всё равно нужны были инструменты для моего курса — дать студентам пощупать. Почему 3 См. http://testbase.ru/test-it.

ГЛАВА 21 Ретроспективный анализ ошибки Так, чему меня это научило... Как анализировать пропущенные баги? Да-да, даже когда у вас 5–10– 15 лет опыта в тестировании, вы всё равно будете пропускать ошибки. Найти всё невозможно. А вот сделать правильные выводы и научиться чему-то на собственной ошибке — это можно и нужно! Я расскажу вам про свой способ в этой главе.

320 Часть IV. Процессы и инструменты 21.1. Зачем анализировать? Нельзя найти все баги. Вы все равно что-то упустите. И в продакшене всплывет ошибка, которую вы не заметили. Найдут ее уже пользователь или клиент. Что делать в такой ситуации? Как я могла пропустить этот баг... Самобичевание бесполезно. Поиск виноватых тоже. Окей, виноваты не вы, проверку не выполнил Вася. Дали втык, отобрали зарплату. Полегчало? Через месяц Маша допустит ту же ошибку. Повторяем наказание. Ничего не меняется. Ребята ходят по граблям, на которые уже наступали. Но ведь важен не сам факт допущения ошибки. Важно, какой урок из нее вынес человек. Почему мы не любим новичков? Потому что у ребят со стажем есть опыт. Не только хороший, но и плохой. Они знают, что бывает, когда забываешь проверить поле на пустоту. Они видели, отчего может развалиться сервер. Помнят по горькому опыту, что значит ошибка ORA-54032. Они уже наступили на грабли и не повторят ошибку. Именно поэтому важно анализировать пропущенную ошибку и извлекать из этого пользу, для чего надо понять: › почему мы её пропустили? Требования неполные, в чек-листе не учли, что-то ещё? › как сделать так, чтобы не пропускать ее в дальнейшем? Может, стоит сделать стандартный чек-лист проверок именно для вашего приложения?

ГЛАВА 22 Послесловие Пожалуй, я рассказала вам всё, что хотела! Вот наша книга и заканчивается. Надеюсь, вам это было полезно ;-) Кажется, что понятно сформулировать свои мысли очень просто, но это не так. Кратко, но емко и понятно всё описать, — сложная задача. Но я уверена: при должном старании у вас будет получаться. Да, иногда лень локализовывать, лень красиво описывать задачи... Что же, заставить я вас не могу. Но надеюсь, что вы проработаете на текущей работе хотя бы годик и потом сможете вернуться к своим старым задачам. Обычно именно это помогает осознать, насколько важно писать понятно.

332 Часть IV. Процессы и инструменты Ведь главная ценность хорошего описания — то, что к задаче можно вернуться в любой момент и быстро оценить ситуацию. Что тогда было? Как починили? Как проверили? Ну и дополнительный бонус — благодарность разработчиков, которым больше не надо ходить в личку и спрашивать: «Что именно ты имел тут в виду?» Поэтому давайте делать мир чуточку лучше и начнем с описания багов! А я в конце книги подкину вам несколько приложений, которые в этом помогут ;-).