Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
- Недоделки. Это ошибки, которые допустили разработчики, пока пилили новый функционал. Такие ошибки находят при исследовательском или приемочном тестировании новых фич на девелоперских стендах команд.
- Баги в регрессе. Это дефекты, которые находят ручные регрессионные тесты или автоматические UI и API тесты на стенде для интеграции кода.
- Баги с прода. Это проблемы, которые нашли сотрудники или клиенты и обратились в службу технической поддержки.
С чего мы начинали, или Jira
Два года назад у нас была выделенная команда тестировщиков, которые вручную тестировали продукт после интеграции кода всех команд. До этого момента код проверялся разработчиками на девелоперских стендах. Ошибки которые находили тестировщики заносились в бэклог в Jira. Баги хранились в общем бэклоге и переезжали из спринта в спринт с другими задачами. Каждый спринт два-три бага доставались и чинились, но большинство оставалось на дне бэклога:
- Одна из причин, по которой баги копятся в бэклоге? – они не мешают пользователям. У таких багов низкий приоритет и их не будут чинить.
- Также, если в компании нет чётких и понятных правил заведения багов, тестировщики могут добавлять одну и ту же проблему несколько раз, потому что не смогли найти в этом списке уже добавленный баг-репорт.
- Ещё одной причиной может послужить то, что на проекте задействованы неопытные тестировщики. Ошибка начинающих тестировщиков, заносить в баг-трекинг все баги найденные во время работы. Неопытные тестировщики считают целью тестирования? – поиск багов, а не предоставление информации о качестве продукта и предотвращение появления дефектов.
Приведу простой пример. При построении отчётов в полях ввода даты по умолчанию подставляется сегодняшний день. При изменении даты в попапе можно снова выбрать сегодняшний день и поле ввода даты очистится.
У меня есть подозрения, что за все время работы нашей сети, никто, кроме тестировщиков не воспроизводил эту ошибку. Такого рода ошибки и составляют большинство багов, которые не исправляются.
При таком подходе, когда заносятся все найденные баги, некоторые из них дублируются и большинство из этих багов не чинится возникают проблемы:
- Тестировщики демотивируются, так как ошибки которые они находят не исправляются разработчиками. Складывается ощущение, что работа не имеет смысла.
- Владельцу продукта сложно управлять бэклогом с большим количеством багов.
Прощай Jira, да здравствует Kaiten
Весной 2018 года мы отказались от Jira и перешли в Kaiten. Смена инструментов была вызвана причинами, о которых Андрей Арефьев написал в статье «Почему Додо Пицца стала использовать Kaiten вместо связки Trello и Jira». После перехода в Kaiten наш подход к работе с багами не изменился:
- Недоделки заносились на командные доски и разработчики самостоятельно решали чинить их или нет.
- Баги, которые нашли в регрессе (его проводила выделенная команда тестировщиков), чинили в релизной ветке и не релизили код, пока все проблемы не были исправлены. Мы решили, что логичнее вести и собирать информацию об этих проблемах в канале тестировщиков в Slack. Тестировщики писали сообщение, которое содержало легенду, список багов с логами и имена разработчиков, которые взяли задачу в работу. С помощью эмоджи меняли статус, а в трэдах обсуждали, прикладывали скрины, синхронизировались. Тестировщиков этот формат устраивал. Некоторым разработчикам не нравился такой способ, потому что в чате параллельно шла другая переписка и это сообщение уходило наверх и его не было видно. Мы его закрепляли, но это не сильно упрощало жизнь.
- Баги которые нашли на проде заносились в бэклог, Product Owner, расставлял приоритеты и выбирал те, которые будем чинить.
Время экспериментов, или нет
Мы решили поэкспериментировать с форматами и создали отдельную доску в Kaiten, на которой хранили баги и меняли статусы. Мы упростили заведение баг-репорта, чтобы тратить меньше времени. При добавлении карточки в Kaiten тестировщики помечали разработчиков. Об этом им на почту отправлялось уведомление. Мы вывели эту доску на монитор, который висел в проходе рядом с нашим рабочим местом, чтобы разработчики видели прогресс и процесс тестирования стал прозрачным. Эта практика тоже не прижилась, потому что основной канал общения? – Slack. Наши разработчики не проверяют почту часто. Поэтому это решение быстро перестало работать и мы снова вернулись к Slack.
Верните муравьишек
После неудачного эксперимента с доской в Kaiten, некоторые разработчики всё ещё были против формата с сообщением в Slack. И мы стали думать как трекать баги в слаке и решить проблемы, которые мешали разработчикам. В результате поисков наткнулись на приложение для Slack, Workast, которое помогает организовать работу с тудушками прямо в мессенджере. Мы подумали, что это приложение позволит управлять процессом работы с багами более гибко. У этого приложения были свои плюсы: смена статусов и назначение на разработчиков по одному нажатию кнопки, завершенные задачи скрывались и сообщение не разрасталось до огромных размеров.
Так выглядели решенные задачи в приложении Todo и просьбы вернуть «муравьишек». После окончания пробного периода приложения Workast мы решили от него отказаться. Потому что пользуясь этим приложением, мы пришли к тому же, что было во время, когда мы пользовались Jira. Оставались некоторые баги, которые кочевали в этом списке из регресса в регресс. И с каждой итерацией их становилось больше. Возможно, стоило доработать процесс работы с этим расширением, купить его и пользоваться, но мы этого не сделали.
Наш идеальный способ по работе с багами сейчас
В конце 2018?-?начале 2019 года у нас в компании произошли ряд изменений, которые повлияли на процесс работы с багами.
Во-первых, у нас не стало выделенной команды тестировщиков. Все тестировщики разошлись в команды разработчиков, для усиления компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.
Во-вторых, мы отказались от ручного регрессионного тестирования в пользу автоматического.
В-третьих, мы приняли «zero bug policy». В статье "#zerobugpolicy или как мы баги чиним" bevzuk подробно рассказывает как мы выбираем баги, которые чиним.
Сегодня процесс работы с багами выглядит следующим образом:
- Недоделки. Тестировщики сообщают о проблеме аналитикам или продакт менеджерам. Идут ногами, показывают, воспроизводят, объясняют как это повлияет на клиентов и решают нужно ли это починить до релиза или можно починить позже, а может даже и не стоит чинить совсем.
- Баги в регрессе, которые нашли автотесты, чинит команда, которая трогала этот участок системы и мы не релизим этот код, пока не решим проблему. Тестировщики фиксируют эти баги в произвольном формате в канале релиза в Slack.
- Баги с прода. Такие баги попадают напрямую к владельцам задач. Аналитики прогоняют ошибки по Матрице приоритетов бага и добавляют в бэклог либо фиксируют у себя, накапливая статистику обращений по этой проблеме.
Итоги
Коротко говоря, мы отказались в принципе от баг-трекинговой системы. С помощью такого подхода работы с багами мы решили несколько болей:
- Тестировщики не расстраиваются из-за того, что ошибки, которые они находят и заводят в баг-трэкинг не исправляются.
- Тестировщики не тратят время на заведение и полное описание багов, которые даже никто не прочтёт.
- PO проще управлять бэклогом, в котором нет мёртвого груза.
Я не хочу сказать, что трэкинг багов бесполезен. Баги которые мы берём в работу трэкаются как и любые другие задач. Но баг-трэкинговая система это не обязательный атрибут тестирования. Её не нужно использовать только потому, что используют большинство компаний и так принято в индустрии. Нужно «думать головой» и примерять инструменты к своим процессам и потребностям. Для нас идеально работать без баг-трекинговой системы сейчас. За пол года такой работы, мы ни разу не подумали о том, чтобы вернуться к ней и снова заводить все баги туда.
А как в вашей компании устроен процесс работы с багами?
Комментарии (7)
Flaminestone
15.05.2019 11:38+1Спасибо за статью, очень полезно почитать про путь, который проделали команды, чтобы найти свой удобный способ эффективно работать.
Я может что-то упустил, но я не совсем понял где вы сейчас ведёте описание багов?
Баг найден, и будет поправлен через неделю, но во что описать сценарий и где его эту неделю хранить? Или это просто еще одна таска, которые каждый как хочет организует?(стикеры, блокноты, google keep, excel)
e-ivanchenko Автор
15.05.2019 11:55Баги, которые найдены и будут поправлены через неделю складываем в Кайтен. У нас есть общая доска для всех команд, там и держим их. А команды когда затягивают эту багу уже хранят как им удобно, у моей команды физическая доска.
tuslo
15.05.2019 13:39+1Все тестировщики разошлись в команды разработчиков, для усиление компетенции тестирования команд.
Поясните, пожалуйста, более развернуто эти изменения.
Что для тестировщика изменилось во взаимодействии с разработчиком?
Теперь есть команды тестровщиков, которые работают только со своей командой разработчиков?
Возможна ротация между командами?e-ivanchenko Автор
15.05.2019 14:14По сути изменилось время начала взаимодействия. Раньше взаимодействие тестирощика и разработчика начиналось когда код разработчика попадал в релизную ветку и сводилось к тому, что тестировщик приносил баг, найденный на стейдже и потом перепроверял его, теперь тестировщик участвует в командных активностях, в командном планировании или груминге, выполняет приемочное тестирование до того, как код сольется в дев ветку. Может показать сценарии по которым он будет тестировать фичу, чтобы разработчик сразу учел различные моменты и стало меньше возвратов задачи на доработку.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.TheGodfather
16.05.2019 21:10В целом вроде довольно очевидно, что выделенный QA инженер на команду это куда эффективнее, чем «выкидывание продукта за забор тестировщикам». Однако:
— Компонентый QA и final validation это все-таки разные вещи, и обе одинаково нужны. QA плотно общается с девелоперами, участвует в планировании, может посмотреть код и заапруивить код ревью, final validation тестировщик делает аля acceptance\integration тестирование для всего продукта в целом (где уже собрались компоненты из всех команд вместе), обычно со стороны black box. Говорить «мы перевели всех финальных тестировщиков в QA и зажили счастливо» — ну, такое.
— Не поощрять ротацию — тоже сомнительно. По крайней мере, именно так я читаю «нужно согласие отпускающей команды». Ротация полезна как и для тестировщиков (попробовать себя в немножко разных ролях, увидеть продукт с разных сторон), так и для component team (свежий незамыленный взгляд, подсветка проблем, к которым «старички» уже привыкли). Понятно, что не каждый месяц прыгать, но есть смысл некой «минимальной планки», после которой компания должна или поощрять или хотя бы не мешать человеку поменять команду. Условные 18 месяцев как в гугле или поменьше, если у вас за полгода все с ног на голову переворачивается
TheGodfather
16.05.2019 20:41+1Disclaimer: /me QA Engineer
В корне не согласен с утверждением «если баг мелкий, незаметный и не особо мешает, то заводить не надо». Любая проблема в продукте, замеченная тестировщиком, должна быть задокументирована или исправлена (если разработчик свободен, можно «сходить ногами» и он может это пофиксить «прямо сейчас»). Бэклог\не бэклог — мне, как тестировщику, в принципе все равно (если поинт был «пустой беклог», но «пофигу, что в основном трекере»). Мне важно, чтобы PO\разработчики знали, что есть проблема. Когда будет пофикшена — пусть PO решает, но определенно должна быть исправлена рано или поздно.
Не говоря уж о том, что приходит к вам новый тестировщик с незамутненными глазами, в первый день exploratory сессии с продуктом натыкается на десяток таких «мелких» косяков, а вы ему что? «Ой, да, мы знаем, но никто и не собирается фиксить, не заводи багу»? И что вы про мотивацию-то говорите? Видишь баг -> потыкай и попробуй понять причину\воспроизвести несколько раз -> заводи баг. По крайней мере, у вас уже будет артефакт, который будет доступен в поиске по баг-трекеру, в котором будут комментарии, видна история, видны ответственные лица. А не сакральное знание «да, это первый баг, который находят новые сотрудники уже пару лет, но мы его не фиксим, ибо неважно», передающееся из уст в уста от одного тестировщика к другому.
Также, если в компании нет чётких и понятных правил заведения багов, тестировщики могут добавлять одну и ту же проблему несколько раз, потому что не смогли найти в этом списке уже добавленный баг-репорт.
Так, может, стоило эту проблему решить? Или провести какой-нибудь мастер-класс тестировщикам (вдруг вы наняли вчерашних студентов, которые про JQL не слышали?), или сделать «правила хорошего тона при отправке багов» или разобраться, почему такая текучка (обычно если тестировщик работает с девелоперами над одним компонентом\продуктом\частью продукта, то после пары месяцев он знает список багов в своем продукте хотя бы на уровне «да-да, была такая проблема, сабмитили уже месяц назад» — ведь именно QA играет значительную роль в качестве своего компонента)
Ошибка начинающих тестировщиков, заносить в баг-трекинг все баги найденные во время работы. Неопытные тестировщики считают целью тестирования? – поиск багов, а не предоставление информации о качестве продукта и предотвращение появления дефектов.
Я далеко не «начинающий тестировщик», но да, заносить в багтрекер\уточнять у девелоперов\проверять, было ли засабмичено раньше лучше все баги, найденные в процессе.
Поиск багов не самоцель, конечно, тут согласен, но если есть проблема в продукте — это именно что «предоставление информации о качестве». Пусть проблема воспроизводится только в полнолуние в пятницу 13-го, но это проблема.
P.S. А пример со скриншота так вообще вопиющий — «error 500» — это какой-то крэш на сервере, любой крэш\exception в продакшне — это как минимум Medium, как по мне. По вашей же матрице — Inconvenient|All/Some -> должно быть или 1 или 2.
saipr
Спасибо, хорошая и полезная статья.
Пожалуй очень верное решение.