Баланс между разработчиками и тестировщиками в команде — это вопрос не столько цифр и соотношений, как стратегическое решение, влияющее на качество, эффективность и коммерческий успех программного продукта.
В данной статье рассматривается важность присутствия тестировщиков в команде разработки программного обеспечения, также рассматриваются различные соотношения между тестировщиками и разработчиками в различных сценариях и ситуациях, а в заключение приводятся соображения по поводу участия разработчиков непосредственно в тестировании.
О ролях
Распространенным заблуждением является то, что единственной обязанностью тестировщиков является поиск багов. На самом деле их роль гораздо более важная, эта роль является неотъемлемой частью самого процесса разработки.
Тестировщики смотрят на ситуацию «с другой стороны», со стороны пользователя (по крайней мере должны смотреть), обращая внимание на пользовательский опыт, возможные/вероятные сбои в системе и проблемы с производительностью, которые не всегда могут быть очевидны разработчикам на начальном этапе. QA следят за тем, чтобы программное обеспечение не только отвечало техническим требованиям, но и как можно полнее соответствовало ожиданиям и потребностям пользователей.
В Agile-среде тестировщики плотно сотрудничают с разработчиками, участвуя в ежедневных митингах и планированиях спринтов.
Такое сотрудничество способствует более глубокому пониманию функциональности продукта с точки зрения конечного пользователя, что позволяет разрабатывать сложные и эффективные стратегии тестирования.
Тестировщики также играют важную роль в автоматизации регрессионных тестов, участвуют в процессах непрерывной интеграции и развертывания и тем самым вносят свой вклад — повышают общее качество и стабильность программного обеспечения.
Соотношение тестировщиков и разработчиков «в целом»
Идеальное соотношение количества тестировщиков и разработчиков не бывает универсальным для любого проекта. Оно зависит от сложности проекта, его масштаба, размера команды (и количества отдельных команд), и требований к разрабатываемому продукту.
Обычно соотношение варьируется от 1:1 в очень сложных проектах до 1:3 или 1:5 и более, в простых «быстрых» проектах.
В проектах с высокой степенью риска, например, связанных с финансовыми операциями или конфиденциальными данными, соотношение dev/QA вплоть до 1:1 обеспечивает тщательное тестирование и минимизирует риск критических ошибок. И наоборот, в менее сложных проектах или в проектах, где нужна быстрая разработка прежде всего, может быть достаточно и намного меньшего количества тестировщиков.
В стартап-проектах или небольших командах соотношение вполне может быть в пользу меньшего числа тестировщиков, но с акцентом на многофункциональность ролей в команде. В таких командах разработчики могут также брать на себя некоторые элементарные задачи тестирования, а более сложные сценарии тестирования выполняются небольшой группой специализированных тестировщиков. Такой подход вполне может быть эффективным, если в команде сохраняют нацеленность на качество и совместное решение проблем (проджект-менеджером культивируется хорошая коллаборация).
Понимание важности соотношения количества тестировщиков и разработчиков может дать ПМ-у реальное представление о том, как различные конфигурации проектных команд работают в сложившихся условиях. Приведем несколько примеров, иллюстрирующих применение этих соотношений в различных проектах.
Соотношение 1:3 — большие корпоративные проекты
В крупном, многолетнем, масштабном проекте разработки корпоративного ПО сложность проекта требует тщательного тестирования. Однако из-за необходимости поддерживать большую команду квалифицированных разработчиков поддерживать (теоретически желательное) соотношение 1:1 зачастую нецелесообразно. Поэтому в таких проектах чаще бывает примерное соотношение 1 тестировщик к 3 разработчикам.
При таком соотношении тестировщики могут быть (и часто бывают) перегружены задачами, что может приводить к задержкам в цикле тестирования или пропуску ошибок на уровень конечных пользователей, что для корпораций, разумеется, недопустимо. Чтобы смягчить эту опасность, такие проектные команды часто вкладывают значительные средства в автоматизированное тестирование, что позволяет снизить ручную нагрузку на тестировщиков.
Также полезными могут быть регулярные тренинг-сессии для разработчиков по основным методологиям тестирования.
Соотношение 1:5 — Agile-стартапы
В быстрорастущем подающем надежды стартапе, работающем например над мобильным приложением, где акцент делается на сверхбыстрой разработке и частых итерациях, обычным является соотношение разработчиков и тестировщиков примерно 5 к 1.
Такое соотношение, однако, может приводить к повышенному риску пропуска багов, особенно в сложных «фичах». Стартапы в такой ситуации используют хорошо отлаженные пайплайны непрерывной интеграции и развертывания (CI/CD) с большим количеством автоматизированных модульных и интеграционных тестов, которые просто не пропускают бОльшую часть багов на верхние уровни пирамиды, то есть к конечным пользователям.
А в некоторых критических ситуациях эффективными могут быть так называемые «баг-баши», когда практически вся проектная команда концентрируется на тестировании.
Соотношение 1:1 — Финтех
В проектах, связанных с областями повышенного риска (таких как финансовое ПО), в которых ошибки могут иметь значительные последствия, часто бывает оправдано соотношение dev/QA даже 1:1.
Это, разумеется, может привести к повышению общих затрат в проекте и увеличению продолжительности цикла разработки. Однако, плотное и частое общение и продуктивная коллаборация между тестировщиками и разработчиками дает результаты. Тестировщики участвуют в процессе разработки с самого начала, способствуя лучшему пониманию разработчиками функциональности программного обеспечения и требований к нему.
Соотношение 1:? — Опенсорсные проекты
А вот в проектах с открытым исходным кодом это соотношение может очень сильно варьироваться. В одних проектах большое число участников сосредоточено на разработке, а в других — на тестировании. Это зависит от проекта. Сугубо и исключительно добровольный характер работы тестировщиков может привести (и часто таки приводит) к несоответствию качества тестирования изначальным целям проекта.
Установление более четких изначальных рекомендаций по контрибуциям в проект, и поддержка культуры тестирования в сообществе проекта — должны поддерживать стандарты на приемлемом уровне.
Проблемы
Достижение идеального соотношения тестировщиков и разработчиков может оказаться непростой задачей для менеджера, особенно для небольших организаций и стартапов с ограниченными ресурсами. В таких случаях нужно выработать стратегию, позволяющую максимально эффективно использовать имеющиеся QA-ресурсы.
Один из подходов заключается в определении приоритетов тестирования на основе оценки рисков. Области приложения с высоким уровнем риска, такие как работа с пользовательскими данными и основными функциями, должны получать больше внимания и времени QA-инженеров.
Эффективная коллаборация между тестировщиками и разработчиками также является ключевым моментом в условиях ограниченных ресурсов.
Поощрение разработчиков к участию в основных видах тестирования, таких как модульное тестирование и дымовое тестирование, поможет снизить нагрузку на тестировщиков и повысить культуру разработки, ориентировать ее на качество.
Вовлечение разработчиков в процесс тестирования — не просто необходимость для команд с ограниченными ресурсами тестирования, это лучшая практика, которая повышает общее качество проектов в компании. Вовлечение разработчиков в процесс тестирования позволяет им глубже понять опыт конечного пользователя и свои потенциальные ошибки в коде. Это приведет к созданию более надежных и удобных программных решений.
Эффективным способом интеграции тестирования в процесс разработки является парное программирование или, вернее в данном случае, парное тестирование, когда разработчик и тестировщик совместно работают над фрагментом кода. Такая практика не только повышает качество кода, но и способствует обмену знаниями и улучшает сплоченность коллектива.
Кроме того, вовлечение разработчиков в процесс разработки и анализа тест-кейсов может дать им новые точки зрения и понимание нюансов, что приведет к более надежному тестовому покрытию.
Адаптация
Важнейшим аспектом управления соотношением количества тестировщиков и разработчиков является способность адаптироваться к изменяющимся ситуациям в проекте. На начальных этапах разработки, когда быстро создаются новые функции, может требоваться большое количество разработчиков. Затем, когда проект становится зрелым и стабильным, акцент смещается в сторону поиска и исправления ошибок и «полировки фич», что увеличит потребность в большем количестве тестировщиков.
Такая динамика требует гибкого и оперативного подхода к составу команды. Эффективной стратегией может быть обучение наиболее перспективных членов команды, с расчетом на их более широкую функциональность, и дальнейшее продвижение.
Обучение разработчиков базовым навыкам тестирования, а тестировщиков — пониманию процессов разработки позволит создать более адаптируемую, гибкую, устойчивую команду, способную эффективно работать на любых этапах жизненного цикла разработки.
Если внутренних ресурсов проекта все-таки недостаточно для достижения нужного соотношения dev/QA, целесообразным решением может стать аутсорсинг или привлечение/консалтинг внешних QA-команд. Такой подход позволяет внутренним QA-командам получить знакомство с более специализированным опытом тестирования, а менеджерам масштабировать проект без долгосрочных обязательств по найму дополнительных штатных QA-сотрудников.
При этом необходимо убедиться, что «внешние» тестировщики хорошо интегрируются со сложившейся проектной командой, правильно понимают требования конкретного проекта, и будут придерживаться утвержденных стандартов качества. Эффективная коммуникация и четкое определение ролей и обязанностей являются залогом успешного сотрудничества с внешними QA-командами.
