Comments 12
Спасибо, хорошая и полезная статья.
Все тестировщики разошлись в команды разработчиков, для усиление компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.
Пожалуй очень верное решение.
Спасибо за статью, очень полезно почитать про путь, который проделали команды, чтобы найти свой удобный способ эффективно работать.
Я может что-то упустил, но я не совсем понял где вы сейчас ведёте описание багов?
Баг найден, и будет поправлен через неделю, но во что описать сценарий и где его эту неделю хранить? Или это просто еще одна таска, которые каждый как хочет организует?(стикеры, блокноты, google keep, excel)
Я может что-то упустил, но я не совсем понял где вы сейчас ведёте описание багов?
Баг найден, и будет поправлен через неделю, но во что описать сценарий и где его эту неделю хранить? Или это просто еще одна таска, которые каждый как хочет организует?(стикеры, блокноты, google keep, excel)
Все тестировщики разошлись в команды разработчиков, для усиление компетенции тестирования команд.
Поясните, пожалуйста, более развернуто эти изменения.
Что для тестировщика изменилось во взаимодействии с разработчиком?
Теперь есть команды тестровщиков, которые работают только со своей командой разработчиков?
Возможна ротация между командами?
По сути изменилось время начала взаимодействия. Раньше взаимодействие тестирощика и разработчика начиналось когда код разработчика попадал в релизную ветку и сводилось к тому, что тестировщик приносил баг, найденный на стейдже и потом перепроверял его, теперь тестировщик участвует в командных активностях, в командном планировании или груминге, выполняет приемочное тестирование до того, как код сольется в дев ветку. Может показать сценарии по которым он будет тестировать фичу, чтобы разработчик сразу учел различные моменты и стало меньше возвратов задачи на доработку.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.
В целом вроде довольно очевидно, что выделенный QA инженер на команду это куда эффективнее, чем «выкидывание продукта за забор тестировщикам». Однако:
— Компонентый QA и final validation это все-таки разные вещи, и обе одинаково нужны. QA плотно общается с девелоперами, участвует в планировании, может посмотреть код и заапруивить код ревью, final validation тестировщик делает аля acceptance\integration тестирование для всего продукта в целом (где уже собрались компоненты из всех команд вместе), обычно со стороны black box. Говорить «мы перевели всех финальных тестировщиков в QA и зажили счастливо» — ну, такое.
— Не поощрять ротацию — тоже сомнительно. По крайней мере, именно так я читаю «нужно согласие отпускающей команды». Ротация полезна как и для тестировщиков (попробовать себя в немножко разных ролях, увидеть продукт с разных сторон), так и для component team (свежий незамыленный взгляд, подсветка проблем, к которым «старички» уже привыкли). Понятно, что не каждый месяц прыгать, но есть смысл некой «минимальной планки», после которой компания должна или поощрять или хотя бы не мешать человеку поменять команду. Условные 18 месяцев как в гугле или поменьше, если у вас за полгода все с ног на голову переворачивается
— Компонентый QA и final validation это все-таки разные вещи, и обе одинаково нужны. QA плотно общается с девелоперами, участвует в планировании, может посмотреть код и заапруивить код ревью, final validation тестировщик делает аля acceptance\integration тестирование для всего продукта в целом (где уже собрались компоненты из всех команд вместе), обычно со стороны black box. Говорить «мы перевели всех финальных тестировщиков в QA и зажили счастливо» — ну, такое.
— Не поощрять ротацию — тоже сомнительно. По крайней мере, именно так я читаю «нужно согласие отпускающей команды». Ротация полезна как и для тестировщиков (попробовать себя в немножко разных ролях, увидеть продукт с разных сторон), так и для component team (свежий незамыленный взгляд, подсветка проблем, к которым «старички» уже привыкли). Понятно, что не каждый месяц прыгать, но есть смысл некой «минимальной планки», после которой компания должна или поощрять или хотя бы не мешать человеку поменять команду. Условные 18 месяцев как в гугле или поменьше, если у вас за полгода все с ног на голову переворачивается
Финальная валидация интеграции кода всех команд у нас выполняется автотестами.
Прежде чем разойтись по командам мы провели эксперимент. Двух тестировщиков оставили заниматься финальной валидацией продукта, после прохождения автотестов. Команды знали об этом экспермиенте. Баги найденные тестировщиками на этом этапе приравнивались к багам которые мы выпустили в прод. Команды стали внимательнее относится к коду, который сливали в дев. Мы смотрели сколько багов найдут тестировщики руками после прохождения автотестов и сравнивали с количеством багов найденных во время регресса до начала эксперимента. Количество багов не изменилось и критичность пропущенных багов осталась на том же уровне. Увидев что нет разницы мы решили вообще не проводить ручную финальну валидацию. Тут вопрос в потенциальных убытках, которые компания может понести от пропущенных багов и затратах на поиск этих багов. Мы приняли риски и сократили время выпуска продукта, в других ситуациях такой подход не допустим и это нормально.
Про ротацию. “Нужно согласие отпускающей команды” я имел ввиду что нельзя просто так взять и уйти ничего не сказав команде, не обсудив с ней это. И мы ни в коем случае не мешаем переходу.
Прежде чем разойтись по командам мы провели эксперимент. Двух тестировщиков оставили заниматься финальной валидацией продукта, после прохождения автотестов. Команды знали об этом экспермиенте. Баги найденные тестировщиками на этом этапе приравнивались к багам которые мы выпустили в прод. Команды стали внимательнее относится к коду, который сливали в дев. Мы смотрели сколько багов найдут тестировщики руками после прохождения автотестов и сравнивали с количеством багов найденных во время регресса до начала эксперимента. Количество багов не изменилось и критичность пропущенных багов осталась на том же уровне. Увидев что нет разницы мы решили вообще не проводить ручную финальну валидацию. Тут вопрос в потенциальных убытках, которые компания может понести от пропущенных багов и затратах на поиск этих багов. Мы приняли риски и сократили время выпуска продукта, в других ситуациях такой подход не допустим и это нормально.
Про ротацию. “Нужно согласие отпускающей команды” я имел ввиду что нельзя просто так взять и уйти ничего не сказав команде, не обсудив с ней это. И мы ни в коем случае не мешаем переходу.
Disclaimer: /me QA Engineer
В корне не согласен с утверждением «если баг мелкий, незаметный и не особо мешает, то заводить не надо». Любая проблема в продукте, замеченная тестировщиком, должна быть задокументирована или исправлена (если разработчик свободен, можно «сходить ногами» и он может это пофиксить «прямо сейчас»). Бэклог\не бэклог — мне, как тестировщику, в принципе все равно (если поинт был «пустой беклог», но «пофигу, что в основном трекере»). Мне важно, чтобы PO\разработчики знали, что есть проблема. Когда будет пофикшена — пусть PO решает, но определенно должна быть исправлена рано или поздно.
Не говоря уж о том, что приходит к вам новый тестировщик с незамутненными глазами, в первый день exploratory сессии с продуктом натыкается на десяток таких «мелких» косяков, а вы ему что? «Ой, да, мы знаем, но никто и не собирается фиксить, не заводи багу»? И что вы про мотивацию-то говорите? Видишь баг -> потыкай и попробуй понять причину\воспроизвести несколько раз -> заводи баг. По крайней мере, у вас уже будет артефакт, который будет доступен в поиске по баг-трекеру, в котором будут комментарии, видна история, видны ответственные лица. А не сакральное знание «да, это первый баг, который находят новые сотрудники уже пару лет, но мы его не фиксим, ибо неважно», передающееся из уст в уста от одного тестировщика к другому.
Так, может, стоило эту проблему решить? Или провести какой-нибудь мастер-класс тестировщикам (вдруг вы наняли вчерашних студентов, которые про JQL не слышали?), или сделать «правила хорошего тона при отправке багов» или разобраться, почему такая текучка (обычно если тестировщик работает с девелоперами над одним компонентом\продуктом\частью продукта, то после пары месяцев он знает список багов в своем продукте хотя бы на уровне «да-да, была такая проблема, сабмитили уже месяц назад» — ведь именно QA играет значительную роль в качестве своего компонента)
Я далеко не «начинающий тестировщик», но да, заносить в багтрекер\уточнять у девелоперов\проверять, было ли засабмичено раньше лучше все баги, найденные в процессе.
Поиск багов не самоцель, конечно, тут согласен, но если есть проблема в продукте — это именно что «предоставление информации о качестве». Пусть проблема воспроизводится только в полнолуние в пятницу 13-го, но это проблема.
P.S. А пример со скриншота так вообще вопиющий — «error 500» — это какой-то крэш на сервере, любой крэш\exception в продакшне — это как минимум Medium, как по мне. По вашей же матрице — Inconvenient|All/Some -> должно быть или 1 или 2.
В корне не согласен с утверждением «если баг мелкий, незаметный и не особо мешает, то заводить не надо». Любая проблема в продукте, замеченная тестировщиком, должна быть задокументирована или исправлена (если разработчик свободен, можно «сходить ногами» и он может это пофиксить «прямо сейчас»). Бэклог\не бэклог — мне, как тестировщику, в принципе все равно (если поинт был «пустой беклог», но «пофигу, что в основном трекере»). Мне важно, чтобы PO\разработчики знали, что есть проблема. Когда будет пофикшена — пусть PO решает, но определенно должна быть исправлена рано или поздно.
Не говоря уж о том, что приходит к вам новый тестировщик с незамутненными глазами, в первый день exploratory сессии с продуктом натыкается на десяток таких «мелких» косяков, а вы ему что? «Ой, да, мы знаем, но никто и не собирается фиксить, не заводи багу»? И что вы про мотивацию-то говорите? Видишь баг -> потыкай и попробуй понять причину\воспроизвести несколько раз -> заводи баг. По крайней мере, у вас уже будет артефакт, который будет доступен в поиске по баг-трекеру, в котором будут комментарии, видна история, видны ответственные лица. А не сакральное знание «да, это первый баг, который находят новые сотрудники уже пару лет, но мы его не фиксим, ибо неважно», передающееся из уст в уста от одного тестировщика к другому.
Также, если в компании нет чётких и понятных правил заведения багов, тестировщики могут добавлять одну и ту же проблему несколько раз, потому что не смогли найти в этом списке уже добавленный баг-репорт.
Так, может, стоило эту проблему решить? Или провести какой-нибудь мастер-класс тестировщикам (вдруг вы наняли вчерашних студентов, которые про JQL не слышали?), или сделать «правила хорошего тона при отправке багов» или разобраться, почему такая текучка (обычно если тестировщик работает с девелоперами над одним компонентом\продуктом\частью продукта, то после пары месяцев он знает список багов в своем продукте хотя бы на уровне «да-да, была такая проблема, сабмитили уже месяц назад» — ведь именно QA играет значительную роль в качестве своего компонента)
Ошибка начинающих тестировщиков, заносить в баг-трекинг все баги найденные во время работы. Неопытные тестировщики считают целью тестирования – поиск багов, а не предоставление информации о качестве продукта и предотвращение появления дефектов.
Я далеко не «начинающий тестировщик», но да, заносить в багтрекер\уточнять у девелоперов\проверять, было ли засабмичено раньше лучше все баги, найденные в процессе.
Поиск багов не самоцель, конечно, тут согласен, но если есть проблема в продукте — это именно что «предоставление информации о качестве». Пусть проблема воспроизводится только в полнолуние в пятницу 13-го, но это проблема.
P.S. А пример со скриншота так вообще вопиющий — «error 500» — это какой-то крэш на сервере, любой крэш\exception в продакшне — это как минимум Medium, как по мне. По вашей же матрице — Inconvenient|All/Some -> должно быть или 1 или 2.
«Заводить багу на всё» — это прямой путь для разбухания бэклога и собирания безнадёжного кладбища.
И единственный проект, где бэклог не рос за счёт такой безнадёги с минимальным приоритетом был тот, где было сформулиировано правило, какие баги НЕ заводить, а озвучивать на стендапах. РП примерно отслеживал статистику и оочень иногда включал в план работ таски по таким местам.
В большинстве случаев эта мелочь умирала в более приоритетных задачах и подбиралась совсем по остаточному принципу.
И единственный проект, где бэклог не рос за счёт такой безнадёги с минимальным приоритетом был тот, где было сформулиировано правило, какие баги НЕ заводить, а озвучивать на стендапах. РП примерно отслеживал статистику и оочень иногда включал в план работ таски по таким местам.
В большинстве случаев эта мелочь умирала в более приоритетных задачах и подбиралась совсем по остаточному принципу.
Тестировщики не тратят время на заведение и полное описание багов, которые даже никто не прочтёт.
По мне так это звучит, как не грамотно настроенные процессы работы тестирования и взаимодействия с тестированием. Мне совершенно не понятно, как можно не читать дефекты
Но баг-трэкинговая система это не обязательный атрибут тестирования. Её не нужно использовать только потому, что используют большинство компаний и так принято в индустрии.
Гибкое решение, но это только потому-что бизнес позволяет и рабочая методология
Вкратце
Выбираем подходящий баг-трекинг.
Коротко говоря, мы отказались в принципе от баг-трекинговой системы.
Спасибо за статью, всегда интересно знать как устроены подобные процессы в других компаниях.
Sign up to leave a comment.
Выбираем подходящий баг-трекинг