Всем привет! Меня зовут Наташа Бакалдина, и я QA Lead в HiFi-стриминге Звук. В этой статье я хочу поделиться опытом и рассказать о проведенном в нашей команде эксперименте, в ходе которого одна из метрик статистики по багам внезапно помогла планировать спринты лучше. 

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

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

Причины возникновения  дефекта

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

1. Дубликат. Потому что всегда есть человеческий фактор. Можно «загнаться» и завести дубль существующего бага.

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

3. Недоработка требований системной аналитики или продуктовой аналитики.

4. Некачественное дизайн‑ревью.

5. Ошибка разработки.

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

7. Неактуальные тест-кейсы.

Детали эксперимента

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

Затем мы описали сам процесс, а именно кто и когда заполняет это поле. В первую очередь, конечно, это были QA на этапах тестирования и актуализации багов. Далее PM и PO (они могли проставить только «Дубликат», «Не воспроизводится» и «Неактуальные тест‑кейсы») на этапе отмены или закрытия дефекта. И, наконец, причины возникновения дефектов проставляла вся команда на ретро или отдельной встрече.

А что выходило по срокам? Сначала мы хотели понаблюдать за процессом всего два спринта, но после первого фидбэка и полученных результатов продлили эксперимент до трех месяцев. К слову, эти три месяца истекли в августе.

Сложности и обратная связь

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

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

Еще одной сложностью стало то, что часто причина возникновения дефекта определялась неверно. Вот один из ярких примеров — «Неактуальные тест‑кейсы» проставлялись у тех багов, в которых была явная недоработка требований, и именно поэтому тест‑кейсы на такие сценарии просто не могли быть корректными или вообще написанными.

В процессе работы и обсуждений мы поняли, что причина возникновения дефекта напрямую зависит от того этапа, на котором был заведен баг. Например, дефект на какую‑то визуальную недоработку на пофичном тестировании получит или «Ошибку разработки», или «Недоработку требований», а вот если такой баг попадет на прод, то это может быть и «Некачественное дизайн‑ревью», и «Неактуальные тест‑кейсы».

Еще сложность была у QA. Ребята могли не видеть разницы в «Ошибке разработки» и «Проблеме из‑за техдолга», потому что она не всегда очевидна без знания кода. Такие дефекты, конечно, по умолчанию отправлялись на обсуждение с командой. 

Итоги эксперимента 

На протяжении всего нашего эксперимента команда на встречах строила догадки, какая причина все же окажется ведущей. Разработчики активно выступали за версию «Проблема из‑за техдолга», QA за «Недоработку требований».

В обоих стримах на первом месте была ошибка разработки, а на втором — недоработка требований. «Проблема из‑за техдолга» заняла почетные третье и четвертое место в разных стримах.

Что же мы решили с этим делать? Делюсь шагами, которые мы вывели в процессе работы над задачей:

1. Ввели техспринты в конце каждого квартала, чтобы все участники команды смогли привести в порядок свой код и документацию.

2. Стали фиксировать любые, даже минимальные требования, а фичи обсуждать со всеми участниками процесса.

3. Ввели ревью требований среди аналитиков (а в некоторых командах и среди членов групп, которые будут заниматься разработкой и тестированием фичи).

4. Ввели обязательные unit‑тесты для новых фичей. Раньше их заводили в техдолг (и забывали), но теперь без пройденного рана разработчик просто не сможет влить ветку в мастер.

Мы рассчитываем, что эта практика успешно внедрится во всех командах и поможет победить максимум старых багов и предотвратить новые. Кстати, на сегодня наша команда добилась следующих результатов по закрытым багам: в одном стриме закрыто 200 багов из 213 с начала эксперимента, а во втором — 133 из 178.

Спасибо, что прочитали статью. Буду рада ответить на все возникшие вопросы и обсудить ваш опыт борьбы с багами в комментариях!