Как мне устранить барьеры между разработкой и контролем качества в гибком проекте?[закрыто]

Question

Я подавал заявление проворный вот уже несколько месяцев работаю над своим проектом.Однако мы наблюдаем постоянную проблему с перегрузкой наших итераций.Мы не достигаем нуля на каждой итерации.

Остальные задачи - это задачи контроля качества.Такие вещи, как написание тестов, тестирование и т.д.

Сейчас существует некоторое организационное сопротивление идее agile о "кросс-функциональной команде".Разработчики разрабатывают для отдельных проектов, но тестировщики используются совместно для нескольких проектов.Что совершенно противоречит гибкой идее совместной работы разработчиков и отдела контроля качества.

Тот факт, что время моего тестировщика распределено между таким количеством других проектов, является причиной наших замедлений.Разработчики проводят тестирование, чтобы устранить как можно больше недостатков, но некоторые задачи по-прежнему не выполняются.

Судя по тому, что я вижу, я могу сделать две вещи:

1. Убедите организацию двигаться в направлении "наличия в каждом проекте выделенного специалиста по контролю качества"
2. Измените мое определение "Сделано" на не включает работу по контролю качества / тестированию.Вещи все равно будут проходить модульное тестирование.

Я бы предпочел не делать # 2, поскольку ценю сотрудничество в тестировании, которым мы занимаемся.

Какой совет у вас есть по поводу моего затруднительного положения?

Answer 1

Это сложная ситуация, и, к сожалению, довольно много компаний, которые пытаются следовать Agile, не осознают этого.Вам не обязательно иметь специального специалиста по контролю качества - даже при использовании Agile ресурсы могут быть распределены между разными задачами.Вам действительно необходимо включить свой контроль качества в отслеживание прогресса.

Да, ваш прогресс будет медленнее.Для этого есть веская причина (у вас недостаточно ресурсов для контроля качества), и вы должны объяснить это руководству вашей организации с цифрами в руках.Это поможет вам убедить их в том, что должны произойти какие-то перемены.

Также вы могли бы перейти к более автоматизированному тестированию и использовать своих разработчиков, чтобы помочь тестировщикам с автоматизацией тестирования.Это позволит распределить нагрузку более равномерно и улучшит качество контроля качества вашего проекта

Answer 2

Я не думаю, что вы можете назвать то, что вы делаете, гибким, если в этом не участвуют все.Попросите тестировщика физически находиться рядом с разработчиками (по крайней мере, на то время, пока тестировщик работает над задачами для своего проекта, такими как создание планов тестирования), это может улучшить коммуникацию и заставить QAs поверить в это.

Answer 3

Чтобы это сработало, вы должны заставить QAs посвятить проекту достаточное количество времени.Возможно, вам придется поработать с их руководством, чтобы выделить им определенное количество времени для работы над вашим проектом.Таким образом, вы сможете планировать их время и точно знать, какой объем работы могут выполнить ваши разработчики, который команда контроля качества успеет протестировать.Это может потребовать от вас сокращения сроков разработки, чтобы компенсировать сокращение поддержки со стороны QA.

Вы не упоминаете, насколько автоматизировано ваше тестирование.Возможно, вам удастся повысить уровень автоматизации тестирования, чтобы сократить время, необходимое команде контроля качества для сертификации проекта.Вы могли бы использовать часть своего времени на разработку для подготовки тестов контроля качества для запуска командой контроля качества.Не оптимально, но это могло бы помочь.

Answer 4

Я думаю, что QA может предложить гораздо больше в гибкой среде, чем просто работу по тестированию.Если QA достаточно хорошо осведомлен о рабочем процессе и различных его ветвях, можно оказаться на месте водителя, чтобы управлять остальной частью процесса scrum.QA может быть передан разработчикам для разработки логических рабочих процессов, которые в конечном итоге будут определять тестовые случаи.Таким образом, можно устранить множество ошибок, связанных с дизайном и рабочим процессом, в процессе разработки, прежде чем они попадут в среду контроля качества.

Answer 5

Вы могли бы рассматривать отдел контроля качества как клиентов для разработчиков.Таким образом, когда разработчики выпускают в конце итерации QA, итерация завершается.

Обратная связь от заказчика (ошибки, которые необходимо исправить) может быть использована при выполнении следующей итерации.

Answer 6

В краткосрочной перспективе прекратите использовать ресурсы контроля качества, которые не могут вписаться в ваш процесс, и выполняйте эти задачи с теми, которые могут быть выделены по мере необходимости.Я понимаю, что это не идеально, но существует неоптимальная ситуация, когда у вас организационная структура, которая не соответствует вашим процессам.Возможно, вы просто обнаружите, что все будет работать нормально (и узнаете о тестировании в процессе).

В долгосрочной перспективе у вас есть следующие варианты

• найдите способ, чтобы это работало с данной организационной структурой / процессом
• измените организационную структуру, чтобы она соответствовала данному процессу
• убедитесь, что процесс разработки подходит для организации