четверг, 19 февраля 2015 г.

Как заводить задачи в баг-трекер

У тестировщика миллион способов завести баг так, чтобы разработчики на него забили. Учитесь ставить такие задачи, которые будут исправлять.

1. Выберите тип


Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.

Какие бывают типы задач:
  • Баг — ошибка в программе.
  • Улучшение — все ок, но хотим с перламутровыми пуговицами.
  • Новая разработка — такой возможности нет, а очень хочется.

Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!

Баг
Улучшение
Новая разработка
Ошибка 500 при загрузке xlxs файла
Загружать файлы драг-н-дропом
Возможность грузить сразу несколько файлов
Город “Москва” исправляется на “Масква”
Выводить код ФИАС в результатах разбора адреса
Обработка иностранных адресов
Нет подсказок по букве "Б" на английской раскладке
Распознавать не переключенную раскладку в подсказках для email
Транслитерация в подсказках
При загрузке файла большого размера сообщение об ошибке “некорректный тип”
Увеличить ограничение на размер загружаемого файла до 30Мб
Загрузка файлов формата .djvu

Осторожнее с ошибками. Разработчик не любит слышать, что в его детище что-то не так. Он будет топать ногами и кричать “Это не баг и исправлять его не надо”. Финт ушами — ставьте улучшения вместо некритичных ошибок.


brannye-slova2.jpg
Системный архитектор реагирует на появление ошибки

2. Локализуйте проблему


Локализация — это поиск первопричины.

Не торопитесь заводить конкретную проблему, это ниточка. Потяните за нее и распутайте весь клубок. Если этого не сделать, разработчики исправят последствия, а исходная проблема останется.


Когда мы тестировали систему Дадата, обнаружили, что “Гунько Александр” женского рода. Первая реакция — бегом ставить баг! Хотя нет, постойте...

В чем тут проблема?
Система всех “Гунько” считает женщинами?
Или “Гунько Марина” тоже сменит пол?
А “Иванов Петр” — мужчина?

funny-homer-simpson-chasing-spider-box-animated-gif-pics.gif
Младший разработчик локализует свой первый баг


См также:


3. Придумайте короткий и емкий заголовок


Упоротый менеджер в 12 ночи просматривает баг-трекер, и он должен по заголовку понять, насколько критично исправить проблему.

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

Соизмеряйте важность проблемы и название задачи.

Нет
Да
ААААААА, КОШМАР, ВСЕ ПРОПАЛО, НИЧЕГО НЕ РАБОТАЕТ!
Авторизация через твиттер падает с HTTP 500
В исследуемой системе при вводе в поле “Имя” символов русского алфавита, английского алфавита, спецсимволов и символов в неправильной кодировке поведение программы неверное
Падает отправка письма в кодировке UTF-08
Двойные имена
Нет подсказок по двойным именам в ФИО

Если в заголовке появились слова  "Ошибка", "Неправильный", "Некорректный", "Неверно" — перепишите заголовок. Вы заводите задачу с типом "Ошибка" — уже понятно, что что-то работает не так. Объясните проблему: “Можно зарегистрироваться с именем Ктулху”.


Но если вы заводите улучшение, заголовок должен предлагать, а не ставить перед фактом: “Запретить регистрацию с именем Ктулху”.

Баг
Улучшение
Можно зарегистрироваться с именем Ктулху
Запретить регистрацию с именем Ктулху
Сообщение об ошибке указывает на неверный пароль при вводе недопустимого имени
Выводить в сообщение об ошибке детальную информацию по причине
Нет подсказок по двойным именам в ФИО
Выводить подсказки по двойным именам в ФИО
Можно зарегистрироваться с паролем 123
При регистрации добавить проверку небезопасных распространенных паролей
Нельзя загружать несколько файлов сразу
Обрабатывать загрузку нескольких файлов


3. Приложите скриншот


Первое, что цепляет взгляд — это картинка.
Иногда разработчику достаточно названия и картинки, чтобы понять, где проблема.

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

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

Плохо.jpg
Хорошо.jpg


4. Опишите шаги воспроизведения и результат


Если названия и скриншота недостаточно, разработчик читает шаги воспроизведения. Что ему нужно сделать, чтобы увидеть проблему?

Шаги — короткие, емкие и последовательные. Разработчик должен выполнить их, а не задумываться над тем, что и в каком порядке ему делать.

Если шаги непонятные, разработчик не станет в них разбираться. Ему это не нужно. он закроет задачу: “не воспроизводится”. Увы, на баг забили!

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

Слишком кратко → когда нужно тратить время, чтобы понять, о чем речь. Студенты думают, что у разработчика уже открыт сайт на нужной странице, поэтому пишут просто “Сделай так!”. Но разработчик может вести сразу несколько проектов и такие шаги ставят в ступор. Где сделай? Что за проект? В каком месте системы этот раздел находится? Где ссылки, в конце то концов??

Слишком длинно → когда поленились локализовать. Бродишь по сайту, отчаявшись найти проблему, и вдруг… ОШИБКА! Первое стремление — скорее, скорее ее завести. Кажется, что все действия крайне важны. Даже если они не имеют реального отношения к проблеме. Ведь так воспроизводится? Заводим!

НЕТ
ДА
Загрузить файл с опечатками в email-ах
  1. Авторизоваться в системе — https://dadata.ru/#authorization_popup (логин abc, пароль 1)
  2. Загрузить файл с опечатками в email-ах (см пример в аттаче — emails.xlxs)
  3. Нажать “Просмотреть результат”
  1. Открыть сайт Дадата
  2. Авторизоваться в системе
  3. Открыть раздел “Подсказки”
  4. Открыть раздел “ФИО”
  5. Ввести “Киселева Ольга Евгеньевна”
  6. Присесть 20 раз
  7. Поплясать с бубном
  8. Переключиться на вкладку “Организации”
  9. Ввести “ОАО Ромашка”
  1. Открыть подсказки по организациям https://dadata.ru/suggestions/#party
  2. Ввести “ОАО Ромашка"


IMG_2334.jpg
Как для разработчика выглядят шаги воспроизведения бага

См также:
Как получить прямую ссылку на всплывающее окно
Шаблон бага → бери да юзай!
Шаблон улучшения → бери да юзай!
Не пишите в баге «Ввести 6,9»! → это плохо кончится

5. Обоснуйте ожидаемый результат


Раз вы ставите баг → вы считаете, что в системе есть проблема. Но почему это проблема? И для кого? Насколько она реальна?

Недостаточно сказать “поле email должно быть 23 символа” — а с чего вы взяли? Вспомните, что такое баг и обоснуйте свои ожидания.

У разработчика и тестировщика разные взгляды на проблемы. То, что мешает тестировщику, разработчик считает нормальным поведением. И если его просто ставить перед фактом: “Это баг, исправляй!”, пощады не ждите. Разработчик не станет бегать за автором с вопросом “А почему это проблема? Объясни, пожалуйста”. Он просто закроет баг.

Опишите сценарий использования, в котором возникает ошибка. Покажите, что в другом похожем месте система ведет себя по-другому (неединообразно → плохо!). Дайте пруфлинки.

НЕТ
ДА
Увеличить поле “Имя” до 30 символов.
Увеличить поле “Имя” до 50 символов, так как туда часто вводят ФИО целиком и оно обрезается.
Исправлять непереключенную раскладку в подсказках по ФИО
Исправлять непереключенную раскладку в подсказках по ФИО, как это уже сделано в подсказках по адресам и организациям. Сейчас система работает неединообразно
Адрес “Россия, Москва, Большая Пироговская улица, 37-43кб” разбирается корректно.
Адрес “Россия, Москва, Большая Пироговская улица, 37-43кб” разбирается корректно, потому что такой вариант записи диапазонных домов нормален. И этот адрес существует, см http://maps.yandex.ru/-/CVGIMR3g

См также:
Как небаг стал багом — после обоснования на реальном примере!
При оформлении бага критикуйте проблему, не людей!— обоснование «или исправляете, или вы чмо» вызовет только агрессию.

---------------------------------------------------------------------------------------------


Тотальная паранойя — друг тестировщика!

Конечно, даже идеально поставленную задачу не всегда исправят. Но лучше поставить задачу, чем не ставить. Пусть хранится для истории.

Позвольте рассказать историю, после которой я записываю все баги, даже те, которые мне приснились.

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

Как-то раз нашла я проблему и пришла к главному разработчику — баг? Он отмахался от меня: "Нет нет, все ок, это не баг. Так и должно работать". А через две недели прибежал к тестировщикам с выпученными глазами и начал кричать "Тестировщики лентяи, такую багу пропустили!!!". Пропущенным багом оказалась… Та самая проблема.

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

И не докажешь уже, что не индюк, не записано Wink ;)

PS — статья написана в помощь студентам моих курсов: НЛО и для начинающих тестировщиков, и добавлена на портал Testbase, в навык описания баг-репортов.

8 комментариев:

  1. В блоггере нет табличек, а вставленные из гуглодоки он вытаскивает за края экрана — увы, не могу с этим ничего сделать. Может разве что в коде HTML попробовать ширину ограничить?

    ОтветитьУдалить
  2. Позанудствую. Что еще полезно указывать, мои 5 копеек:

    1. Характеристики системы на которой баг найден (ОС, ее битность, сервис пак, версии вспомогательных продуктов (SQL, например). Эти характеристики тоже хорошо бы локализовать. Бывает так что баг проявляется на 32-х битной системе, а на 64 битной нет. Или на 2008 он есть, а на 2012 уже нет.

    2. У тестера есть такой инструмент как Severity - это индикация критичности бага для PM'а.

    3. Полезно писать название фичи\истории при тестировании которой найден баг. В некоторых багтрекерах для этого есть специальное поле. Потом очень удобно делать выборку багов по конкретной фиче\истории.

    4. Если есть дампы падения, то ссылку на шару с ними. Логи приложения тоже надо. Сообщения из eventlog'а.

    5. Номер билда на котором найдена проблема.

    6. Иногда баги заводятся по результатам претензии от клиента, тогда хорошо бы указать номер саппорт кейса, или любую связанную с этим информацию.

    7. Текст ошибки в теме бага очень полезен для последующего поиска. Ведь чтобы не плодить дубликатов надо смотреть не заводил ли кто-нибудь уже CR по эту проблему.

    ОтветитьУдалить
    Ответы
    1. Василий, спасибо за полезные пункты :)

      Со всеми согласна, но тоже позанудствую :)
      Пункт 6 входит в обоснование бага.
      С седьмым согласна, полезно :)

      А остальное все некритично. В разных компаниях самый разный набор входных полей — версия, где нашли, версия, где поправили, OS, ссылка на требования, компоненты, метки и прочая, прочая.

      Я выписала все, что считаю основным и что должно быть в любой системе баг-трекинга с любым списком заполняемых тестировщиком полей

      Удалить
  3. Нет, серьёзно?
    Я думал в разных компаниях тестировщики заполняют разные поля.
    То есть половина статьи бесполезна для множества компаний.
    Далее: сам процесс описания бага расписан некорректно.
    "Короткое, но ёмкое название"??? Это разве как-то критеризируется?
    Я лучше потом напишу как заводить баги, а потом дам тебе ссылку.
    И, да. Разве локализация не должна стоять перед "выберите тип".
    Таблички и картинки как всегда красивые, но даже у Савина описано как-то получше.

    ОтветитьУдалить
    Ответы
    1. Да, серьезно.
      Еще до публикации поста, на этапе ревью, несколько человек сказали спасибо за него — то есть он кому-то полезен.
      Вся статья полезна для любой компании. Это как раз всякие версии можно научиться быстро расставлять. Но у всех свое мнение, с удовольствием почитаю твою статью

      Удалить
  4. Первое: "сначала новые функции, потом ошибки, потом все остальное" покажите мне разработку, которая сначала делает новые фичи, а потом правит баги в текущих, и я радостно раздам ей по ушам. правда перед этим оборву руки их пмам и тестерам.
    И второе: "Финт ушами — ставьте улучшения вместо некритичных ошибок." а теперь приведите пример улучшения вместо некритичной ошибки? С учётом того что ошибка - это отклонение от требований.

    ОтветитьУдалить
    Ответы
    1. Баги бывают разные и "впереди планеты всей" надо исправлять только блокеры + то, что всплыло у Заказчика.
      "Баг = отклонение от требований" → ужасная формулировка, сплошной Савин. А потом джуниоры ходят и говорят "у вас обязательно должны быть горы документаций, без них мы тестить не умеем, как же баги то найдем"?

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

      Хотя это пример улучшения, которое никто не сделает. Другой пример — какой-нибудь бантик на систему добавить. Не "сообщение об ошибке плохое", а "Улучшить сообщение об ошибке".

      Мне сложно сейчас дать примеры, потому что под носом примеры моих студентов, а спойлерить я не хочу :)
      Требования есть не всегда и не на все. Не надо сломя голову ставить "баги", которые никто исправлять не будет

      Удалить
    2. Как-то у меня много наезда получилось, извините)

      Ну требования в любом случае есть, в каком бы то ни было виде (eg заказчик сказал, заказчик обычно хочет/привык к виду (если опыта с конкретным заказчиком достаточное количество), так принято, так безопасно, так не уплывёт и т.д., и т.п.), т.е. не обязательно гора документации, документации из разряда "тз" полтора года в глаза не видел)
      А баги сломя голову никогда не надо ставить, это да. Только я, например, и многие мои знакомые/коллеги делают что-нибудь типа trivial, который естественно если и будет будет поправлен, то когда рак на горе не то что свистнет, а песенку споёт)

      Удалить