У прочитавших пост о группе управлении разработкой закономерно возникнет вопрос — почему я не упомянул о команде тестировщиков и QA лидере?
К сожалению, автор не имеет серьёзного опыта управления тестированием и может судить лишь на основании наблюдений за работой неподконтрольных ему подразделений.
Тестировщик является важнейшей фигурой процесса разработки. Он, и только он может принять решение о готовности доработки к вливанию. Только глава QA может дать добро на релиз данного билда, когда будет уверен в том, что все критичные дефекты исправлены.
Тестировщика обязательно нужно подключать к обсуждению на этапе написания требований. Дело в том, что эта категория специалистов обладает специфическим «разрушительным» мышлением и находит ошибки в требованиях намного эффективнее коллеги-аналитика с «созидательным» мышлением, выступающего в роли рецензента.
Возможны три подхода к организации группы тестирования:
- Выделенный департамент тестирования, обслуживающий все продукты.
- Тестировщики как части универсальных кросспродуктовых команд.
- Тестировщики как части микрокоманд.
Выделенный департамент тестирования.
Все тестировщики выделены в обособленное подразделение, которое проводит тестирование всех программных продуктов, выпускаемых компанией.
Данный подход оправдан для организации тестирования в компании, выпускающей обширную продуктовую линейку. Тестировщиков в этом контексте «натаскивают» на все продукты линейки, что позволяет балансировать ресурсы в зависимости от нагрузки.
Схема имеет существенный недостаток — как бы гладко ни был построен процесс планирования работ, при старте доработки QA лидер не может определённо сказать, кто именно будет тестировать. Тестировщик будет поставлен перед фактом по готовности доработки и не будет иметь достаточно времени для полноценного вникания в требования. Знакомить всю тестировочную группу с требованиями ко всем доработкам всех продуктов нецелесообразно — сотрудник будет внимательно слушать только если есть гарантия, что проверять данную доработку придётся именно ему.
Тестировщики как части универсальных кросспродуктовых команд.
Имеется выделенная команда — несколько аналитиков, несколько разработчиков, несколько тестировщиков. В ряде случаев данная команда работает над одним продуктом, иногда — с несколькими. В этом случае круг возможных доработок, которые придётся тестировать конкретному сотруднику значительно сужается, что позволяет вникать в требования раньше (по сравнению с подходом, описанным в предыдущем разделе).
Тестировщики как части микрокоманд.
Почти идеальный подход. При старте доработки формируется микрокоманда из аналитика, нескольких разработчиков и тестировщика. Микрокоманда ведёт производство на всех этапах, от сбора требований, до финальной сдачи заказчику (вливания в релизный билд в случае продуктовой разработки). Тестировщик микрокоманды находится в курсе требований с самого начала и готовит план тестирования с момента передачи требований разработчику, а не по готовности доработки, что позволяет тестировать комфортно, оперативно и эффективно.
