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

Для кого эта статья?

Если коротко, то форматы комментариев - это уже процессы Quality Assurance, поэтому статья будет полезна для всех, кто хочет улучшать качество на своем проекте, и для тех, кому есть, что улучшать. Это важно! Есть проекты, где уже все процессы настроены и ваши нововведения никому не нужны.

Тестирование, как инженерное искусство

Многие работают в своих компаниях в должностях: Инженер по тестированию, Инженер по качеству, QA Engineer и т.п. Но по факту, это просто тестировщики, которые к слову "инженер" не имеют никакого отношения. Я предлагаю поменять мышление по отношению к этой работе.

Что такое "инженерное" мышление? Это мышление с четкой структурой, аналитикой, логикой и полнотой. То есть комментарий "все проверено, все ок" - это совсем далеко от этого.

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

Начало

Я работал в многих компаниях, и видел много разных вариантов. Есть компании, в которых тестировщики под задачей пишут "ок/готово/done" и переводят в статус Завершен.

Поэтому как бы это банально не звучало, но грамотный комментарий должен начинаться со статуса тестирования:

Протестировано/Не протестировано - тут могут быть и другие варианты, например, деплой прошел, фича отключена и т.п.

Следующий момент, это указание стенда, на котором было проведено действие:

на Тестовом окружении/на Динамическом окружении и т.д. Да, это важно. Даже если у Вас на доске, есть максимально подробные колонки, которые указывают на стенд, то это все равно важно указывать. Мы пишем отчеты для того, чтобы со временем, если находится какой-то баг, можно было по таким комментариям понять, когда эта ошибка была упущена, кем была упущена и т.п.

Тело

Чек-лист - это следующий этап нашего комментария. Да, его стоит прикреплять. Это можно делать по-разному: можно написать проверки в самом комментарии (не обязательно идеально подробный, но хотя бы с логическими делениями), но обязательно со статусами проверок; можно прикреплять excel-файл с чек-листами; можно прикреплять ссылку на тест-ран запущенный на специальной платформе (какое-то время я крепил pdf-файл выгруженный из qase после прохождения тест-рана - он был достаточно информативный и читабельный) - подойдут разные варианты, но важно, чтобы любой разработчик или менеджер мог всегда просмотреть проверки, которые были проведены, даже через несколько лет после вашего ухода из компании.

Обнаруженные дефекты (список багов в формате что? где? когда?). Если во время тестирования были обнаружены дефекты, то они обязательно должны быть отображены в комментариях. Недостаточно просто написать, что они есть. Нужно хотя бы тезисно их перечислить. Идеальный формат, по моему мнению, что тезисы должны отвечать на вопросы "что? где? когда?". Например, Не работает кнопка Отправить(что происходит?) в модальном окне Новое сообщение (где?) при нажатии (когда?). Такие баги будут понятные даже без шагов воспроизведения, ожидаемых результатов и прочего. Если по багу заведен баг-репорт, в таком случае, можно указать ссылку на тикет с дефектом.

Вопросы. Это могут быть вопросы по документации, по реализации - вообще по всему. Особенно этот пункт важен на этапе анализа задачи перед тем, как ее начнут разрабатывать. Это должен быть четкий список (не обязательно развернутой формы). Вы можете все моменты обсуждать в переписках, но само озвучивание вопросов в задаче обязательно.

После того, как мы получаем ответы. Если они обсуждались где-то в другом месте, а не в самой задаче, то их нужно вынести в отдельный раздел Ответы. Можно это сделать отдельным комментарием, можно отредактировать ранее написанный комментарий. Желательно также отмечать тех, кто эти ответы давал, чтобы можно было к ним обратиться за уточнением.

Артефакты. Не обязательный, но все же важный пункт в нашем комментарии. Это могут быть скрины, скринкасты, логи. Все, что подтверждает, что задача работает/не работает. Также это могут быть файлы, которые мы используем для тестирования (например, когда мы тестируем загрузку документов).

Результат

В зависимости от действий задачи, стоит озаглавить результат соответственно:

Результат тестирования/Результат анализа/Результат изучения/Результат обсуждения

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

Результат тестирования:
При тестировании были выявлены баги. Одобрено к релизу на Прод-окружение.

Нет логики в таком описании результата. Хороший пример:

Результат тестирования:
При тестировании были выявлены баги, минорного значения, которые не блокируют дальнейший релиз. Сами дефекты были вынесены на доработку в отдельные задачи. Одобрено к релизу на Прод-окружение.

Дополнительные советы:

Тут еще пару советов о том, как сделать свои комментарии более читабельными и понятными для других:

• Используйте форматирование. Минимальное выделение жирным шрифтом ключевых слов помогает лучшему восприятию комментария.

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

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

• Используйте технический язык. Помню, как в одном чате со специалистами, один тестировщик прислал пример баг-репорта с его проекта. Там было написано "на маленьких экранах скукоживается текст" - это до сих пор у нас локальный мем. Не должно быть такого в технической документации!

• Будьте рациональными. Если задача, изменение кнопки в одном месте с "Отмена" на "Отменить" и ее проверять 1 минуту, то не стоит тратить 20 минут, чтобы написать супер красивый комментарий. Но тем не менее используйте хотя бы техническое начало и результат.

• Всегда работайте над тем, чтобы что-то улучшать. Комментарий такого вида - это не предел совершенства. Всегда есть, что добавить и что улучшить.

Вместо вывода - пример:

Задача "Добавление поля с вводом 1 или 0"

Протестировано на Тестовом окружении.

Чек-лист:
-Проверка с вводом 1 - passed
- Проверка с вводом 0 - passed
- Проверка с вводом нескольких 1/0 - passed
- Проверка с вводом букв - passed
- Проверка с вводом других цифр - passed
- Проверка с вводом спец.символов - failed (вынесено в Дефект 1.)
- Сверка поля с макетом - skipped (вынесено в Вопрос 1.)

Обнаруженные дефекты:
1. Не работает валидация на спец.символы в поле "Введите 0 или 1"

Вопросы:
1. Отсутствует макет для мобильной версии приложения. По реализации сейчас поле отличается от десктопной версии. С чем сравнивать?

Результат тестирования:
- При тестировании были выявлены дефекты.
- Ожидается ответ на вопрос от <лида>.
- Задача отправлена на доработку.