17 правил написания баг-репортов

Автор: Aleksey GL 16.05.2016

После нескольких лет обучения студентов в Portnov Computer School были сформулированы эти правила

Cмотреть с 55 минуты

1. В разных компаниях правила, требования, форма сообщения об ошибках могут отличаться.

Даже не могут, а точно будут отличаться. Процесс “привыкания” к новым стандартам при переходе в другую организацию похож на смену собственного автомобиля с одной модели на другую.

2. Чтобы баг репорт был достаточно информативен, он должен удовлетворять привило трёх W

  • What happens?
  • Where happens?
  • Under Which circumstances?

По русски звучит как Что? Где? Когда?

  • Что случилось?
  • Где это случилось?
  • При каких обстоятельствах, Когда?

Имея ответы на эти вопросы можно:

  • Понять суть бага
  • Воспроизвести баг
  • Починить баг

3. Два типа сообщений об ошибке:

  1. Проблема
  2. Решение

Тонкая вещь, если коротко:

  • Пишите сообщение о наличии проблемы. Констатация факта и всё.
  • Пишите сообщение об ошибке, уже содержащее в себе решение проблемы. Это экономит время разработчика.

Как лучше поступить?

Баг репорт с решением лучше, но предложенное решение не должно быть ошибочным. Не стоит говорить о вещах, которые не понимаешь.

4. Сообщение об ошибке - не сочинение об ошибке. Требования к английскому минимальны.

Зная 200 слов английского языка, владея терминологией (действия пользователя с интерфейсом, элементы интерфейса) уже можно писать баг-репорты.

5. Убедитесь, что ошибка найдена в правильной версии продукта и в правильной “среде обитания”

Под средой обитания понимаем платформу, версию программного продукта, браузеры и т.д. - всё то, что влияет на функциональность продукта. Будь на одной волне с разработчиком в техническом плане.

6. Сообщение об ошибке пишется немедленно после обнаружения, не откладывая.

Убедившись, что вы нашли ошибку, сразу же её фиксируйте.

7. Убедись, что ошибка воспроизводится не только на твоём, но на других компьютерах перед тем, как о ней сообщать

Это экономит время вовлеченных в процесс. Не стоит плодить баг-репорты.

8. Минимизируй количество шагов по воспроизведению ошибки.

Поищите вариант с меньшим количеством шагов воспроизведения бага. Опять-таки это экономит время разработчика.

9. Отправляй одно сообщение об ошибке на одну обнаруженную проблему - не две, не три и не десять.

Если проблема повторяется в других элементах, стоит обобщить и таки написать один баг-репорт. Со временем это превратится в навык.

10. Расхождение между реальным поведением программного продукта и его требуемым поведением должно быть хорошо понятно.

В баг-репорте показать разницу между ожидаемым и реальным поведением продукта.

11. Не нужно “оправдываться”, цитируя нарушаемые правила. Просто сообщайте об их нарушениях.

Нарушенное правило - не часть баг-репорта

12. Исходите из того, что программист хорошо знает продукт. Не нужно писать о том, какую кнопку нажать, чтобы открыть окно и т.п.

Типичная ошибка начинающих.

13. Сообщение об ошибке должно быть предельно кратким (не за счет информативности), без “воды”

“Продайте” свой баг-репорт разработчику, чтобы он его выбрал из большого количества друг баг-репортов по продукту и исправил первым.

14. Сообщение об ошибке должно содержать предельно полную информацию по проблеме

Пишите лаконично, но включайте всю важную информацию.

15. Прикрепляйте скриншоты, файлы данных, логи к сообщению об ошибке, чтобы сделать его более полным и понятным.

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

16. Проблема может иметь предысторию. Спросите, прежде чем сообщать об этой проблеме.

Вам расскажут почему так. Или посоветуют написать баг-репорт.

17. Сообщение об ошибке должно быть написано техническим языком с использованием принятой терминологии.

Следует овладеть терминологией предметной области. Пример: названия элементов веб-страницы.

Категории: qa-testing

Теги: for-brain