В своей практики я встречал различные виды организации работы QA специалистов по командам, но обычно это все сводится к нескольким способам, вне зависимости от того, как организованны команды разработки в компании (мультифункциональные, специализированные и т.п.).
QA специалист внутри команды
В больших компаниях, когда есть много примерно одинаковых команд разработки (ведь мы знаем, что больше 7-8 человек в одной команде уже плохо работает), очень часто в команду добавляют 1-2 QA специалиста (не будем разделять ручные, автоматизаторы, sdet), которые занимаются полностью вопросами тестирования задач этой команды. Рассмотрим плюсы и минусы:
Плюсы
- qa становятся центром знаний и хорошо знают свою часть проекта
- команда знает к кому обращаться по поводу тестирования
Минусы
- bus factor очень высокий, ведь в небольшйо команде больше 1-2 qa нет
- не масштабируется, из-за чего qa может быть узким горлышком
- qa становятся носителями уникальных знаний
- qa начинает уставать, если команда разрабатывает функционал в одной области и становится узколобым
- в каждой команде свои правила тестирования
Внешняя QA команда
Бывает так, что весь QA выносится в отдел, который просто получает задачи от команд разработки, распределяет их между собой и выполняет.
Плюсы
- масштабируемость - во внешней команде больше людей может подключиться к проблеме и протестировать, могут подменить если человек ушел
- распределение знаний по всем частям проекта равномерно распределяется между всеми qa (при условии, что задачи всегда делают разные люди)
- всегда можно сменить фокус задач для какого-то конкретного специалиста, что может снять усталость от рутины
- единые правила тестирования
Минусы
- qa менее глубоко разбираются в узких деталях каждой команды разработки
- ответственность за тестирование размазывается на всех (усложняется коммуникация при проблемах)
Гибрид
Оба классических способа организации QA в командах имеют право на жизнь, но всегда необходимо быть гибкими и улучшать свои процессы. В компании с более чем 10 командами разработки (в продуктовой компании), мы со временем пришли к гибридной моделе.
У нас была отдельная команда QA, где специалистов было меньше, чем команд разработки, но за каждым специалистом было закреплено несколько команд разработки, куда необходимо было ходить на планирования и груминги, чтобы быть в курсе дел. Раз в 2 спринта, специалисты менялись (ротировались), это позволяло не уставать, расширять кругозор и налаживать связь с различными командами. При этом задачи приходили все равно в общий пул (в jira просто переводились в QA Pending), где свободный QA мог взять и тестировать, не обращая внимания от кого это.
Такое решение позволило решить проблемы с передачей опыта между специалистами (все знали продукт в той или иной степени), проблем с bus factor (если кто-то уходил в отпуск, то тестирование в какой-либо команде не останавливалось) и у ребят всегда были новые и интересные задачи. Также, за счет того, что задачи были всегда, нагрузка распределялась равномерно между всеми и не могло быть ситуации, когда один зашивается, а другой (в другой команде) бездельничает и не может помочь (плохая междкомандная связь, ничего не понимает в задача другой команды).
Сменив место работы, с нуля построил подобный процесс и на протяжении 3-х лет при 50 разработчиках (и 7 QA) этот подход еще раз показал себя очень жизнеспособным.