Хороший баг-репорт – понятный, прозрачный, содержит в себе все, что потребуется для решения проблемы в проекте. Написать такой нетрудно. При составлении важно выложить всю необходимую информацию из своей головы в тикет в Jira, и тогда вопросы разработчики не будут спрашивать “очевидные вещи”.
Баг-репорты составлять — тоже навык, который нужно развивать. Уметь донести свою мысль до другого человека - полезный навык не только для тестировщиков, но и разработчиков тоже. Проектные менеджеры — разработчикам, фронтендеры — бэкендерам, тестировщики — всем. Если junior-разработчик хочет перейти на следующую ступень карьеры, то он ему пригодится этот навык. Для сеньоров он must-have.
За время работы на проектах разной степени сложности я понял, что хороший баг-репорт несложно оформить, в нем достаточно двух вещей: шаги для воспроизведения и Expected/Actual результаты. Остальная информация опциональна.
Чтобы создать баг-репорт, который быстро пофиксят, нужно:
- Описать шаги воспроизведения. Начиная от начала авторизации в тестируемом портале и до получения ошибки. Данные для авторизации, Переход по ссылкам, клик по кнопке, ввод таких-то данных, вот это вот все должно быть упомянуто.
- Написать “Ожидаемый результат / Expected”.
- Написать “Текущий результат / Actual”
- Убедиться, что ни один шаг не был пропущен и не нужно будет никому пояснять что-либо.
- Очевидные вещи надо проговаривать/прописывать. Что очевидно для одного, не очевидно для другого. И наоборот.
- Если кажется, что “ну вот это они точно и так знают как делать”, то перечитай пункты 4 и 5
В итоге, если баг-репорт был оформлен верно, то:
- Сокращается время на фикс. Твои коллеги не тратят свое время и мыслетопливо на прояснение деталей.
- Автору баг-репорта не задают уточняющие вопросы в личку. Особенно неприятно получать вопросы поле окончания рабочего дня, не так ли?
- Автор не становится блокером для коллег.
- Автору не приходится объяснять что-либо второй раз.
А если уточняющие вопросы все же появились, то необходимо записать эту информацию в баг-репорт. Тогда обсуждение не потеряется из виду и будет сохранено в общей проектной документации.
Таким образом, хороший баг-репорт будет выглядеть примерно так:
Title: There is no password security requirement error on the register page
Steps to reproduce:
1. Go to https://example.com/regitster
2. Type login: 'Vasya', password: 'qwerty'
3. Click on the Submit button
Expected: Backend validation error, 400 http status response. Message is "Your password must contain at least 1 capital char and 1 digit"
Actual: The user account is being created. No backend errors appear
Таким образом, любой разработчик команды может взять задачу в разработку, даже если не он писал формы авторизации. Понятен ожидаемый результат и нет необходимости обращаться за разъяснением к оригинальной задаче разработки формы регистрации, автору или бизнес-аналитику. Может показаться, что я хочу переложить работу по прояснению деталей с плечей разработчиков на тестировщиков, ведь ожидаемый результат разработчик сам может посмотреть в требованиях. Однако автор баг-репорта уже знает, как нужно, и может сразу написать об этом, а потом на ретроспективе уже команда обсудит, как не допускать повторений таких случаев.