Привет! Меня зовут Лёша и я работаю в команде, которая тестирует веб в 2ГИС. Как часто бывает в тестировании, мы попали в неприятную ситуацию: бэклог с багами постоянно растёт (да уж скорее пухнет), а бюджет команды на исправления — ограничен.
Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из‑за которой больше не приходится спорить.
Мы в тестировании используем метод бюджетирования багов. Условно говоря, у нас есть Х баллов, которые мы можем потратить на исправление, при этом каждый баг весит от 0,1 до 1 балла. Чем больше времени нужно на исправление, тем «дороже» баг.
Когда у тебя горят 100 багов сразу, очень сложно расставить приоритеты.
В стрессовой ситуации выбор приоритетов может быть довольно неочевидным и даже контр‑интуитивным. К примеру, можно схватиться за заметный баг, который не особо‑то и мешает — и упустить бажину, которая бьёт по критическим метрикам. И подобные флуктуации приоритетов бывают не только с багами — Эля Снежкова писала о похожих задачах в тестировании фич.
Как мы выбирали баги раньше
Общий подход был такой:
Критические и блокирующие баги берутся на доску вне бюджета.
Баги, найденные в процессе тестирования фичи — фиксятся сразу, пока фича на доске.
Если баг найден на бою или на завершающих стадиях разработки, он попадает в бэклог с другими багами.
Раз в неделю мы собирались командой тестирования и пытались выбрать наиболее критичные баги. Но выбор превращался в холивар: какой же баг — самый противный, какой должен попасть на доску первым? Иногда мы не брали из бэклога никаких задач вовсе. Например, баг очень большой и не влезает в текущий бюджет — мы «копили» бюджет для него к следующей неделе.
В таком подходе мы отметили ряд недостатков:
Критичность бага — понятие относительное, если нет метрик для измерения этой самой критичности. Из этого вытекают споры и долгие обсуждения.
Самые дорогие в реализации задачи — далеко не всегда самые важные.
Самые дешевые в реализации задачи не обязательно должны правиться здесь и сейчас.
На первый взгляд, критичные баги могут никогда никому не встретиться в жизни. Может, они не такие уж и критичные?
Спустя некоторое время мы сформулировали ряд метрик по которым начали оценивать не только стоимость задачи, но и её вес. Чем больше у бага вес — тем приоритетнее проблема относительно других багов.
Метрики багов
На вес бага влияют такие параметры как массовость, критичность и блокирование. Мы решили добавить градацию для каждого пункта. Всё еще не очень точно, но можно примерно оценить масштабность ситуации.
Массовость — насколько часто пользователи могут встречаться с ошибкой. Оцениваем массовость в 1 или 3 (2 убрали сознательно, чтобы не проваливаться в «средний вариант» и сделать оценку биполярной). При 1-й баг затрагивает только небольшую часть аудитории (например, ошибка воспроизводится только на iOS 8 и старше). А баг на «троечку» может воспроизводиться например на всех устройствах Apple.
Критичность — насколько критична для бизнеса область приложения, в которой возникла ошибка. Критичность 1 терпит без проблем (например, поехала вёрстка в описании памятников). А при 3 сломался показ рекламы — нужно срочно тушить.
Блокирование — сильно ли ошибка блокирует пользователя. Аналогично: при 1 баг не блокирует, можно пользоваться 2ГИС. А при 3 — блокирует без обходного решения, доступа к фиче нет.
Частота воспроизведения. Учитываем также то, что баги, которые возникают часто, должны быть исправлены до багов, которые возникают редко.
Оценив каждый пункт по отдельности, оцениваем общий вес ошибки по формуле:
Массовость × Критичность × Блокирование |
Давайте посмотрим на примере. У нас есть два бага:
Бажина 1. Пользователь не может изменить аватарку. | Бажина 2. Пользователь не может изменить почту | |
Цена | 0,3 балла | 0,7 баллов |
Массовость | 3 — Касается всех пользователей. | 1 — Большая часть наших пользователей регистрируются через социальные сети. Мы давно отключили возможность регистрации по почте по некоторым причинам. |
Критичность | 1 — Пользователь может и со старой аватаркой пожить, на функциональность сервиса баг не влияет. | 1 — Критически важных фич, вроде двухфакторной аутентификации с подтверждением логина через почту, у нас нет. Авторизация доступна через соцсети. |
Блокирование | 3 — Фича недоступна, пользователь не может самовыражаться и грустит. | 3 — Фича недоступна. |
Итог (М×К×Б) | 9 баллов | 3 балла |
Чтобы легче запомнить формулу и критерии подсчёта, мы создали плагин для Chrome, в который подставляем параметры. Качайте и используйте у себя!
Как вводили новый процесс
Создавать встречу и всей командой оценивать каждый тикет — дорого, потому мы взяли список всех открытых дефектов и разделили поровну на всех QA в команде.
Каждый оценил задачи из своего списка так, по своему мнению. Затем его оценки уходили на ревью двоим коллегам. Так у нас появилась возможность актуализировать бэклог на наличие неактуальных багов.
После того, как все старые дефекты были оценены, мы создали еженедельную встречу, на которой оценивали новые ошибки.
Как изменилась наша работа
Время. На оценку багов мы стали тратить примерно в 3-4 раза меньше времени. Раньше встречи на эту тему занимали до часа в неделю. Сейчас у нас уходит на это 5–15 минут в неделю.
Оценка. Разногласия в оценках остались, но их стало очень мало. Например, часто спорили о критичности области, но в один момент просто синхронизировали список критичных для приложения областей.
Коллеги. Наш подход подхватили другие команды. Одни взяли формулу для расчетов без изменений, другие изменили ее в соответствии с нюансами своего проекта и процессами. Коллеги отмечают, что работать стало удобнее, а процессы стали более прозрачными.
Опыт команды 2ГИС Про
Раньше мы в Про приоритезировали баги без использования весов, по ощущениям, так сказать. Потом перешли сразу на фреймворк. Стало ли удобнее? Стало. Прозрачнее ли приоритезация? Точно да!
Есть и дополнительные плюсы. Например, начали использовать все приоритеты в JIRA, а не только традиционный мажор — для этого есть табличка соответствия веса и приоритета. Это помогает не только приоритезировать баги в бэклоге, но и в рамках спринта раскидывать по приоритету, внутри приоритета по весу.
Раньше на каждой встрече всей командой решали, куда ж отправить баг, теперь сразу кладем в бэклог (кроме очевидных блокеров, конечно). Потом, не тратя время всей команды, при планировании спринта вытаскиваем баги по приоритетам.
Формулу для расчета меняли, так как у нас — b2b‑сегмент и много своих нюансов. Например, массовость к нам вообще не относится, потому что если у одного крупного клиента что‑то «вылезет» — это уже критично.
В конечном итоге, важно иметь хорошую организацию и планирование для управления багами, чтобы можно было оценить их срочность, важность и сложность исправления, и определить приоритеты. Это поможет команде быть более эффективной в решении проблем и улучшении качества продукта.
***
А прямо сейчас у нас открыты вакансии для тестировщиков в разные команды и на разные платформы.