Самоорганизующаяся команда продуктовой разработки вынуждена расти на собственных ошибках. Регламенты, шаблоны и готовые процессы — даже если они хороши и работают для соседа — не приживаются. Чужие «законы» сложно правильно понять и ещё сложнее развивать и улучшать.

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

Попробую сформулировать такие принципы и привести практические примеры их применения в конкретной области — написании багрепортов.

Содержательность

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

Локализация бага — сложная умственная задача. Чтобы сэкономить время и силы коллег, укажите в багрепорте, чем представлена реальность, а чем её описание:

• На какой инсталляции проводилась проверка (пререлиз, стейдж, прод, какая-то ветка на CI)
• Ссылки на документацию, если в ней описано поведение. Если не описано, то где оно должно было быть описано
• Если документации нет, то описать бизнес-сценарий или проблему, которую решит починка бага
• Если возможно, указать версию кода (commit hash, JIRA version)
• Если применимо, описать локальное окружение: версию ОС и браузера, разрешение экрана и т. п

Воспроизводимость

Воспроизвести баг потребуется ещё как минимум 3 раза после написания исходного багрепорта: разработчику в процессе починки, девлиду/ревьюеру для проверки, тестировщику (причем, не обязательно автору багрепорта) для закрытия задачи. Сэкономить время коллег позволит подробное и точное описание последовательности действий:

• Перечислены последовательные шаги воспроизведения
• Приведены логин/пароль, если от них зависит сценарий (если пароли не от прода)
• Для дефектов на веб-страницах указана точная ссылка на страницу
• Для запросов в API указаны все детали (метод, тело, адрес, ...), например в формате curl.

Иногда воспроизводить баг оказывается сложно или дорого (например, баг замечен на проде, или воспроизводится «через раз», или текстовое описание проблемы сложно воспринять). Чтобы повысить вероятность и скорость починки такого бага полезно:

• Приложить скриншоты с выделенной «проблемной» областью
• Достать логи, относящиеся к проблеме (если логов много, то приложить файлом)
• Указать время последнего воспроизведения
• Если известно, указать идентификатор транзакции (x-request-id, краш из sentry и т. п.)

Единообразие

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

• Всегда явно указывать фактическое и ожидаемое поведение, даже если они кажутся очевидными
• Иметь единый «шаблон» багрепорта для конкретного продукта/направления

Полнота

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

• Что именно могло поломаться, в каком сервисе, каким коммитом
• Какие похожие кейсы могут быть сломаны, но их ещё не проверяли
• Когда в прошлом бывали похожие проблемы, и как они решались (дать ссылку на таск)
• Кто может иметь больше подробностей о воспроизведении бага или о работе сервиса

Локальность

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

• Одна задача — один дефект
• В описании и сценарии указывать конкретное дефективное поведение, а не абстрактную проблему

Поток

Разработку продукта можно рассматривать как поток. Каждая бизнес-задача «течёт» по своему жизненному циклу (… — аналитика — разработка — тестирование — ...), а все задачи вместе образуют непрерывный «поток», в котором на каждом участке (например, «в тестировании») в любой момент находится несколько задач. Такое представление полезно, например, для выявления бутылочных горлышек в процессах и понимания степени их влияния на общий результат. Чтобы тестирование как можно реже становилось бутылочным горлышком, полезно следовать рекомендациям:

• Если баг блокирует тестирование или не позволяет проверить happy path, то его надо помечать как критичный и «трубить» об этой проблеме
• Если в процессе тестирования обнаружен дефект, не относящийся к тестируемой истории или не блокирующий деплой этой истории в прод, то такой баг можно оформить особым образом, например:
  
  • упомянуть о некритичности в джире/багтрекере
  • превратить в отдельную историю
  
  

Другой способ навредить «потоку» — встроить новую задачу не в начало, а в середину. В ходе тестирования появляются идеи об улучшении продукта, которыми необходимо делиться с командой. Формулировка такого улучшения/фичи в виде багрепорта создаёт риск пропуска важных шагов процесса (например, приоритезации или аналитики). Поэтому стоит:

• Задачи, содержащие предложения по улучшению сервиса, формулировать в виде новых историй