- Краткое описание проблемы
- Продукт
- Платформа
- Статус
- Приоритет
- Серьезность
- Предусловия
- Шаги воспроизведения
- Фактический результат
- Ожидаемый результат
- Прикрепленные файлы
Среди всех вещей, связанных с тестированием, есть кое-что, с чем тестировщик сталкивается ежедневно. Это баг-репорт: документ, описывающий баг, его серьезность и приоритет, а также шаги, позволяющие его воспроизвести. Опираясь на баг-репорты, разработчики могут быстро определить, какая часть кода работает неправильно, и исправить ее.
Хорошо написанный баг-репорт гарантирует эффективное сотрудничество между командами разработчиков и тестировщиков. Поэтому умение писать баг-репорты — один из самых важных навыков тестировщика.
Как же писать баг-репорты, чтобы разработчики были ими довольны? В этой статье вы найдете несколько советов.
Как написать хороший баг-репорт
Когда дело касается написания документации, есть одно универсальное правило: пишите попроще. Чем проще, тем лучше.
Но «попроще» не значит «покороче». Баг-репорты должны содержать подробности, позволяющие читателю понять природу бага. То есть в них должно быть достаточно сведений, чтобы понять, почему описываемое поведение — баг, и как его воспроизвести. Вместе с тем нужно стараться не включать в баг-репорт лишнего и не повторяться.
Что же мы подразумеваем под «хорошим» баг-репортом? Мы можем сказать, что баг-репорт эффективен, если:
- багу присвоен уникальный номер
- баг можно воспроизвести, это не единичная случайность
- описание бага конкретное и касается только одной проблемы.
Не пытайтесь использовать баг-репорт как доказательство того, что кто-то совершил ошибку. Указывайте только значимую информацию и придерживайтесь нейтрального тона. Всегда перечитывайте то, что написали, прежде чем отправить.
Непременно воспроизведите баг два-три раза, прежде чем начать его документировать. Не включайте в репорт больше одного дефекта. Наконец, прежде чем написать репорт о новом баге, убедитесь, что его нет в списке уже известных багов (чтобы избежать дублирования).
Структура баг-репорта
1. Краткое описание
В идеале, описание бага должно раскрывать ответы на три вопроса: что, где и когда. Например: «(что?) Появляется Console Error (где?) во вкладке Статистика (когда?) после того, как пользователь нажимает на кнопку Скачать». Иногда часть «где» можно опустить. Например: «Приложение падает после того, как пользователь нажимает на кнопку Войти». Можно указать страницу, на которой это происходит. Но если у вас есть единственное место, где пользователь может найти эту форму, то и так очевидно, где он нажимает на кнопку.
2. Продукт
В этой части обычно пишется версия сборки, которая тестируется. Тестировщик указывает эту информацию, чтобы разработчик мог сравнить последнюю, тестируемую версию продукта с предыдущей и посмотреть, что изменилось. Благодаря этому куда легче найти причину поломки.
3. Платформа
Тестировщик должен указать, на какой платформе проявляется баг. Для десктопных проектов укажите операционную систему. Для веб-проектов — самые важные сведения о браузере. Что касается мобильных проектов, для них нужно указать модель девайса и его операционную систему.
4. Статус
Указание статуса бага помогает держать всю команду в курсе процесса исправления. Статус может сообщать о том, что разработчик принял баг в работу, вернул на повторное тестирование, исправил и закрыл и т. п. Количество возможных статусов зависит от принятого в команде рабочего процесса.
5. Приоритет
Приоритет бага показывает, насколько критичен дефект для бизнеса, и определяет очередность исправления. Обычно приоритет устанавливают менеджер продукта, собственник продукта или тимлид.
6. Серьезность
В отличие от приоритета, серьезность определяется тестировщиком. Устанавливая уровень серьезности, он исходит из того, насколько опасен баг для всей системы, в какой степени он затрагивает самый важный функционал и т. п.О серьезности и приоритетности багов можно почитать в статье «Серьезность и приоритет багов — в чем разница?»
7. Предусловия
В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка.
8. Шаги воспроизведения
Наилучший способ описать эти шаги — составить пронумерованный список с последовательностью действий пользователя, приводящих к проявлению бага. Используйте простые предложения.
Например:
- Пользователь открывает вкладку Статистика.
- Нажимает на кнопку Сохранить.
- Обновляет страницу.
- и т. д.
9. Фактический результат
Фактический результат — это проблема, появляющаяся, когда пользователь выполняет шаги, указанные выше.
Опишите результат, придерживаясь того же правила, что и для краткого описания бага. Обозначьте, что происходит, где и когда. Это поможет разработчику понять, в чем проблема. Лаконичное и четкое описание пригодится и QA-команде в будущем.
10. Ожидаемый результат
В этом разделе опишите ожидаемый результат шагов, описанных в п.8. То есть изложите, как приложение должно было бы себя вести.
Ошибка тоже может быть ожидаемым результатом — если тестировщик проверяет негативный сценарий. Например, если пользователь вводит неправильные учетные данные, он не должен войти в систему, вместо этого он должен увидеть сообщение об ошибке.
11. Прикрепленные файлы
Это дополнительные материалы, которые можно добавить к баг-репорту. Часто с визуальными руководствами бывает проще воспроизвести баг. Особенно, если баг сложно описать словами.
Добавление скриншотов или коротких видео поможет избежать недопонимания. Только не забывайте, что визуальные материалы должны быть релевантными и понятными.
Итоги
Документацию нужно создавать так, чтобы она была легкой в использовании и понятной другим членам команды. Такая документация сэкономит вам много времени в будущем, когда проект разрастется, а в команде появятся новички.
Теперь вы знаете, как написать баг-репорт. Более того: вы знаете, как написать его так, чтобы разработчики были довольны. Сохраните себе этот план и пользуйтесь им в работе!
