«Когда я впервые занял должность лида, меня постоянно беспокоила одна и та же проблема. Каждый раз, когда QA-команда начинала тестировать новую фичу, её просто заваливало базовыми, очевидными, даже в «счастливых» сценариях багами. Багами, которые должны были быть отловлены ещё до того, как story получала статус «готова к тестированию».
Вместо того чтобы искать edge cases и потенциальные сбои, наши тестировщики тратили время на то, чтобы заставить фичу хоть как-то работать. Это расстраивало не только из-за потраченного впустую времени, но и потому, что показывало более глубокую проблему — у нас не было настоящей культуры качества.
Разработчики торопились закрыть задачи, переводя их в статус «Готово». Требования понимались неправильно или просто пропускались. Ляпы в дизайне проходили незамеченными.
И команда тестирования, вместо того чтобы быть последним уровнем защиты, становилась первой, кто находил фундаментальные проблемы, которые нужно было исправить намного раньше.
Это была не просто проблема у рарзаботчиков. Это была проблема процесса.
Мы хотели это исправить — не ища виноватых, а делая видимыми пробелы в нашем процессе.
Что такое анализ первопричин дефектов
Лично я начал с очень простой, но очень эффективной вещи — мы добавили специальную обязательную метку для первопричины каждого дефекта.
Идея была такова: когда тестировщики сообщали о баге, им нужно было выбрать метку, которая лучше всего объясняла, почему этот баг появился, а не просто описывала его:
Вот какие варианты у нас тогда были:
- Функциональный баг — пропущенная или неправильно понятая часть критериев приёмки. Обычно это означало, что разработчик не до конца разобрался в пользовательской истории или не проверил результат перед передачей.
- Проблема UX — баг в юзабилити, который нужно было выявить или уточнить ещё на этапе проектирования.
- Проблема UI — визуальное несоответствие, которое исходило от самого дизайна — либо что-то не так в макете, либо не было учтено в дизайн-системе.
- Проблема с UI (фронтенд) — правильный дизайн, который был некорректно реализован фронтенд-разработчиком. Эта метка покавала нам важность дизайн-ревью после реализации.
- Пропущенный сценарий — баг, который вся команда (разработчики, тестировщики и продуктологи) упустила на этапе планирования.
- Пропущенное требование — баг, где требование было чётко указано в истории, но почему-то не учтено при разработке.
- Производительность — баги, указывающие на глубокие проблемы в архитектуре и/или масштабируемости.
- Безопасность — уязвимости или небезопасные решения, которые говорят об отсутствии понимания основ безопасного программирования.
- Совместимость и адаптивность — баги, возникающие из-за невнимания к поведению приложения на разных устройствах или в разных браузерах.
Превращаем дефекты в инсайты
Когда мы начали последовательно маркировать баги, мы стали генерировать подробные отчёты каждый спринт и квартал, а также простой дашборд, который показывал распределение первопричин.
Мы чётко увидели тенденции:
- Резкий рост числа функциональных багов? Нужно было улучшить процесс написания, проверки и валидации пользовательских историй перед реализацией, вместо «они и так понятны».
- Слишком много проблем с UI (на фронтенде)? Это заставило нас добавить этап дизайн-ревью после имплементации и привлекать дизайнеров к процессу QA, когда это было нужно.
- Повторяющиеся баги с «пропущенными сценариями»? Наши сессии планирования были недостаточно тщательными. Мы упускали краевые случаи и некоторые особенности поведения пользователей. Это заставило нас проводить более подробный кросс-функциональный анализ историй и внедрить «сдвиг тестирования влево».
- Рост числа багов, связанных с UX. Это был сигнал, что нам нужно сотрудничество между продуктовой командой, UX-дизайнерами, разработчиками и QA на ранних этапах жизненного цикла продукта.
- Несколько багов, связанных с безопасностью, хотя они были редкими. Это был тревожный признак, что о безопасном коде думают мало. Мы ввели простейшее моделирование угроз и добавили этапы проверки безопасности для критически важных фич.
Таким образом, вместо расплывчатых жалоб типа «разработчикам нужно тестировать больше», мы получили инсайты, которые показывали, где и как улучшать процесс.
Строим культуру качества, метками
Метки первопричин оказались чем-то большим, чем просто способ отслеживать дефекты. Они создали ответственность без обвинений.
- Разработчики стали лучше видеть свои баги, что помогло им расти.
- Тестировщики почувствовали, что их обратная связь не игнорируется, а становится ценным инструментом для улучшения процесса.
- Продуктовые и дизайн-команды заметили, к чему приводят упущенные сценарии или неясные требования.
Со временем мы сместили фокус с исправления багов на улучшение процесса, который позволял этим багам возникать. В тот момент я понял, что мы начали строить настоящую культуру качества.
И еще
Баги — это часть нашей работы, мы все это знаем. Но когда одни и те же баги повторяются спринт за спринтом, это говорит о более глубокой проблеме, на которую нужно обратить внимание. Дело не в том, кто совершил ошибку. Дело в том, почему это произошло, и как мы можем это предотвратить в следующий раз.
Вам не нужен сложный фреймворк, чтобы начать анализировать первопричины. Просто начните с малого: добавьте метку. Почаще спрашивайте «почему». Ищите закономерности. Открыто обсуждайте их на ретроспективах — не для того, чтобы кого-то обвинить, а чтобы показать, где есть пробелы.
Наша цель — не избавиться от всех багов. Наша цель — перестать тратить время на поиск и исправление тех багов, которых можно было избежать, чтобы команда могла сосредоточиться на том, что действительно важно — на создании классных фич, на поиске неочевидных сценариев, и на реальной ценности.
Если вы занимаете должность лида, попробуйте это. Поощряйте маркировку дефектов. Делитесь инсайтами. И тогда на встречах вы будете искать не виноватых, а решения.»