Как разрушить барьеры между разработкой и QA в гибком проекте?
Я применяю Agile уже несколько месяцев в своем проекте. Однако мы видим постоянную проблему с нашими итерациями. Мы не достигаем нуля на каждой итерации.
Оставшиеся задачи являются задачами QA. Такие вещи, как написание тестов, тестирование и т. Д.
В настоящее время существует организационное сопротивление идее гибкой "кросс-функциональной команды". Dev разрабатывается для отдельных проектов, но тестеры используются для нескольких проектов. Что совершенно противоречит гибкой идее совместной работы Dev и QA.
Тот факт, что время моего тестировщика распределено по многим другим проектам, является причиной нашего замедления. Разработчики тестируют, чтобы набрать как можно больше слабины, но некоторые задачи все еще не выполнены.
Из того, что я вижу, я могу сделать две вещи:
- Убедить организацию двигаться в направлении "каждого проекта, имеющего отдельного специалиста по обеспечению качества"
- Измените мое определение "Готово", чтобы оно не включало работу по обеспечению качества и тестированию. Вещи все еще будут проверены, хотя.
Я бы предпочел не заниматься #2, так как я ценю сотрудничество в области тестирования, которое мы делаем.
Какой совет вы имеете для моего затруднительного положения?
6 ответов
Это сложная ситуация, и, к сожалению, довольно много компаний, которые пытаются следовать Agile, не признают это. Вам не нужно иметь специального сотрудника по контролю качества - даже если Agile ресурсы могут быть распределены между различными задачами. Вам НЕОБХОДИМО включить свой QA в отслеживание прогресса.
Да, ваш прогресс будет медленнее. Для этого есть веская причина (у вас недостаточно ресурсов QA), и вы должны объяснить это руководству вашей организации с цифрами в руках. Это поможет вам убедить их, что некоторые изменения должны произойти.
Также вы можете перейти к более автоматизированному тестированию и использовать своих разработчиков, чтобы помочь тестировщикам в автоматизации тестирования. Это распределит нагрузку более равномерно и улучшит качество контроля качества в вашем проекте.
Я не думаю, что вы можете назвать то, что вы делаете, гибким, если все не вовлечены в это. Заставьте тестера сидеть физически близко к разработчикам (по крайней мере, в течение времени, когда тестер работает над задачами для своего проекта, такими как создание планов тестирования), это может улучшить коммуникацию и заставить QA покупать в ней.
Я думаю, что QA может предложить намного больше в Agile-среде, чем просто тестирование. Если QA достаточно хорошо осведомлен о рабочем процессе и различных его ветвях, можно быть на месте водителя, чтобы управлять остальной частью процесса схватки. QA может быть связан с разработчиками для разработки логических рабочих процессов, которые в конечном итоге будут стимулировать тестовые случаи. Таким образом можно устранить множество ошибок, связанных с проектированием и рабочим процессом, в процессе разработки, прежде чем они попадут в среду контроля качества.
Чтобы это работало, вы должны получить QA, чтобы уделить достаточно времени проекту. Возможно, вам придется поработать с их руководством, чтобы выделить определенное количество времени для работы над вашим проектом. Таким образом, вы сможете планировать свое время и точно знать, сколько работы ваши разработчики могут выполнить, чтобы команда QA успела протестировать. Это может потребовать от вас сокращения разработки, чтобы компенсировать снижение поддержки со стороны QA.
Вы не упоминаете, какая часть вашего тестирования автоматизирована. Возможно, вы сможете улучшить автоматизацию тестирования, чтобы сократить время, необходимое команде QA для сертификации проекта. Вы можете потратить часть времени на разработку тестов QA для запуска команды QA. Не оптимально, но это может помочь.
Вы можете рассматривать QA как клиентов для разработчиков. Поэтому, когда Devs выпускают в конце итерации в QA, итерация завершается.
Отзывы клиентов (ошибки, требующие исправления) могут перейти к работе, которую необходимо выполнить для следующей итерации.
В краткосрочной перспективе прекратите использовать ресурсы QA, которые не вписываются в ваш процесс, и возьмите на себя эти задачи с теми, которые могут быть выделены по мере необходимости. Я понимаю, что это не идеально, но есть неоптимальная ситуация, когда у вас организационная структура, которая не соответствует вашим процессам. Вы можете просто обнаружить, что это будет хорошо работать (и узнать о тестировании в процессе).
В долгосрочной перспективе ваши варианты
- найти способ для этого работать с данной организационной структурой / процессом
- изменить организационную структуру, чтобы соответствовать процессу
- шаг процесса разработки, чтобы быть подходящим для организации