Сначала фактический результат в баге, потом ожидаемый

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

Шаги
Делаем то, делаем се 

Ожидаемый результат
Все работает круто!    ---  о_О 

Фактический результат
Все плохо :(

Погодите, погодите, то есть я выполняю шаги, получаю результат... Да он же классный, что в нем не так? И только потом я вчитываюсь в заголовки и понимаю, что это ожидания. Но ведь рано про ожидания говорить, я еще проблему не осознала.

Логичнее сначала описать проблему, а потом ваши ожидания. Если у вас еще нет шаблона бага — используйте мой, хотя бы на первых порах.

В баге есть фактический и ожидаемый результаты

Иногда кажется, что ожидаемый результат в баге писать вообще не нужно. Например, когда в системе краш — все развалилось. Казалось бы, зачем тут ОР? И если ОР — «Система не должна падать», то он действительно выглядит лишним. Текст ради текста, от которого мы хотим избавиться.

НО!

Никто и не просит писать «система не упала». Напишите, что именно она должна была сделать. Открыть главную страницу? Вернуться назад? Выдать какое-то сообщение об ошибке?

Да, это бывает очевидным. Если мы грузим главную страницу и тут БАХ, эксепшен. А должна открыться главная. Л — логика. Но такие баги возникают редко и обычно на проектах с начинающими разработчиками, которые легко «ломают» странички, забыв поставить точку с запятой в коде.

Опиши и приложи (правила оформления бага)

На что обращаться внимание, когда вы пишете шаги бага? Есть несколько разных правил, одно из которых — «опиши и приложи». Не забывайте про скриншоты и примеры!

Скриншоты

Почему в моей книге столько картинок? Потому что они привлекают внимание! Это первое, за что цепляется взгляд.

Хорошо оформленный баг — это когда разработчик прочитал название, посмотрел на скриншот и все. Ему больше ничего не нужно, он понял, где ошибка. А шаги... Шаги остаются тестировщику для перепроверки задачи.

Примеры

Пример — это не только какое-то значение, которые мы вводим в строку: «Например, 6,9»

Нужна авторизация? Дай данные

Нашли ошибку, заводим задачу. Вроде все делаем по фен-шую... Ссылка на забагованное место есть, описание есть, но... Разработчик переходит по ссылке и видит окно авторизации. Что ему делать? Какие данные вводить? Это важно вообще, что будет за пользователь? И где взять тестовые данные?

Иногда тестировщики не пишут данные потому что «их и так все знают». Потому что есть пачка тестовых пользователей, на которых они гоняют все тесты. И они даже где-то описаны.

Это все здорово и хорошо. Но если ваш баг читает разработчик или менеджер проекта, он может про тестовых пользователей не знать. И придется ему тратить время на регистрацию. Или бегать к тестировщику узнавать, под кем можно войти. Сохраните команде время, укажите данные для входа.

Пусть любой, кто хочет воспроизвести баг, сделает это быстро и без дополнительных телодвижений. Прошел по ссылке, ввел что сказали — профит! А все дополнительные действия сделайте вы, заранее. В том числе создайте пользователя.

Воспроизводится ли баг по твоим шагам? Проверь!

Оформили баг? Пройдите по собственным шагам, словно видите их впервые. Если ошибка в вебе, откройте новое окно в режиме инкогнито. Это поможет увидеть, что вы забыли указать.

Может, ссылку не дали, просто «Открой страницу полетов». Что? Каких полетов? На каком стенде? По какой ссылке?

Может, данные для входа указать забыли, так как у себя на машине авторизованы и не приходится этого делать. Режим инкогнито подскажет, что «дальше не пройдешь, пока данные не назовешь».

Может, пропустили какой-то шаг. Поэтому очень важно идти ЧЕТКО ПО СВОИМ ШАГАМ. Не по тому, что у вас в голове хранится, а четко по шагам. Иначе получается примерно такая картина:

Воспроизводится ли баг по твоим шагам?

— Я делаю, как вы сказали. Вот я ввела эти данные сюда, эти сюда. Но почему-то никакого результата не вижу.

— А что видите?

— Все ту же форму, просто заполненную.

— Ну так там же надо нажать «далее»!

— А где это в баге?

— Ой, ну очевидно же.

Вот чтобы было без «ой», пройдите по своим шагам и заполните пробелы.

Эмоций в баге быть не должно!

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

Поэтому если уж очень хочется — выскажите все устно. Обсудите с разработчиком задачу в курилке, яро отстаивая свою поцизию. Но как только дошли до компьютера — эмоции убираем, пишем лишь факты. Без «если да кабы» и без «а ВЫ! Потеряли клиента!»

Когда я только начинала работать в HFLabs, в моем личном KPI появился пункт «не ругаться и не наезжать» :-) 

Краткая шпаргалка от Павла по заведению бага

Эту шпаргалку написал мой коллега Павел Абдюшев в помощь моим студентам еще года 3-4 назад (во времена недельного интенсива).

С тех пор так и используется активно ребятами! Ведь по оформлению бага столько разных статей, ну разве удержишь это все в голове? А тут единый списочек. Так сказать, чек-лист заведения бага!

Решила, что пора поделиться им со всеми. Студенты до сих пор помнят ее именно как «Краткая шпаргалка от Павла», так что заголовок сохранила знакомый. А вот и чек-лист:

Плакат НЛО (найти, локализовать и оформить ошибку)

Плакат НЛО

Скачать PDF (500 мб)

Скачать в zip-архиве (вместо 500мб будет 350)

План действий:

1. Скачиваем плакат
2. Отдаем в типографию, печатаем на цветном принтере формата А1
3. Вешаем в отдел своих тестировщиков!

Исходно плакат делался для студентов курса «Техники и инструменты» (пока там не появилось 5 новых лекций про логи, панель разработчика и т.д., курс назывался как плакат, НЛО). Но на прошлой неделе я выступала на конференции КоТэ и там как раз рассказывала теорию по плакату. А потом подумала, а почему бы его не расшарить? ツ

Он же клевый! Если повесить в коридоре, можно встречаться там и обсуждать! И разрисовывать его 

Примеры оформления багов с КоТэ

Всем привет! Сегодня выступала на КоТэ, конференции для тестировщиков с мастер-классом по заведению дефектов. Перед мастер-классом я дала домашнее задание — потестировать 4 разных сайта.

Ребята справились с ДЗ на «УРА»! Целых 130 ответов!!! Честно говоря, я столько не ожидала ツ

Гуглодока ответов — https://docs.google.com/spreadsheets/d/1ew8qXDZnODDLWxukfLkxYcxIJ6f6PAmHaWJ76dXaEjQ/edit#gid=558356532

Зачем я ее показываю публично? А затем, что, когда мы видим хорошо оформленный баг, мы считаем, что это само собой разумеется и вы бы сами сделали точно также. А вот видя баг, который можно улучшить, не всегда находишь проблемы. Попробуйте найти проблемы в этих багах и расскажите, как их можно улучшить.

На докладе я дала некоторые номера строк гуглодоки как образцы. Вот они: