Home

Всем привет! На связи Андрей – QA-лид из Совкомбанк Технологий.

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

В этой статье разберем сколько QA-инженеров нужно проекту, от чего это зависит и есть ли корреляция количества тестировщиков с количеством разработчиков. 

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

В статье рассмотрим:

• Оптимальное соотношение QA-инженеров и разработчиков

• Соотношения, которые существуют в реальных проектах и их особенности

• Параметры, которые нужно учитывать, чтобы вывести оптимальное соотношение

• Вывод идеальной формулы

Цель статьи – найти идеальный баланс количества людей в команде, отталкиваясь от сути проекта. 

Идеальное соотношение – это когда состав команды сбалансирован настолько, что на проекте не возникает никаких «бутылочных горлышек». Тестирование является последним этапом жизненного цикла производства ПО и отвечает за качество произведенного ПО. 

Нужно создать такой баланс, чтобы тестирование было очень качественным «фильтром-горлышком» и успевало за всеми процессами разработки ПО: анализом, проектированием и разработкой. 

Я провел опрос по соотношению тестировщиков и разработчиков в проектах других ИТ-специалистов.

Чаще всего в проектах на 1 тестировщика приходится 3 разработчика. Есть и такие, где соотношение составляет 1 к 1. Отчего же это зависит? И какое оно – идеальное соотношение?

В некоторых ИТ-проектах вообще не предусмотрены тестировщики. Там тестированием занимаются аналитики, проджект-менеджеры или пользователи, такие мы даже рассматривать не будем.

Один из процессов тестирования — это проверка функционала, реализованного разработчиками. Конечно, разработчики и сами пишут тесты на свой код, но почему-то всегда находятся баги — для этого и существует профессия тестировщика. 

При создании таких соотношений в команде, учитываются разные аспекты. Перечислю основные: 

Аспект №1 – тип приложения

От количества программных составляющих проекта зависит степень сложности проекта.

Рассмотрим виды и их ключевые особенности:

1. Веб-приложение. Чаще всего оно состоит из бэкенда, фронтенда и базы данных. Данное приложение может быть архитектурно как и монолитным, так и микросервисным.

2. Мобильное приложение. Разновидностей таких приложений очень много, но чаще всего у них есть бэкенд, база данных и сама «визуальная часть». Приложение может быть нативным, прогрессивным или веб.

3. Чистый бэкенд. Это может быть интеграция или просто обработка данных. 

Исходя из этого уже можно понять количество будущих проверок в зависимости от количества устройств.

Аспект №2 –этапы разработки

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

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

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

4.* Этап, когда у разработчиков не горят сроки. Они начинают писать unit-тесты, которые тоже могут ловить ошибки. Да-да, это отсылка к пирамиде тестирования, не стоит о ней забывать.

Аспект №3 – сложность

Под сложностью я имею ввиду количество возможных аффилированных объектов и общей логики.

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

Почему именно кратное? Допустим, в карточке клиента есть 3 поля, каждое из которых принимает по 3 возможных значения — это 9 возможных комбинаций. Добавим четвёртое поле с аналогичной бизнес-логикой. Для разработчика это влечет увеличение трудозатрат на 33%. Но в тестировании количество комбинаций увеличивается с 9 до 27. Следовательно, рост затрат не на 33%, а на все 200%.

Аспект №4 – требования к тестированию или критичность

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

Если тестировщиков будет мало, то количество непокрытого функционала будет расти, скорость тестирования будет падать, а качество снижаться. Сами тестировщики будут ходить уставшие.

Из личного опыта

Мы с коллегами сталкивались с различными проектами. Расскажу о трёх наиболее интересных, в которых соотношение тестировщиков и разработчиков было разным.

Проект №1

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

В этом проекте участвуют 2 тестировщика и 11 разработчиков. Интересное соотношение! Вы спросите, а как они успевают с соотношением ~1/5?

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

Проект №2

Веб-приложение, в котором соотношение тестировщиков и разработчиков составляет 1 к 6 соответственно. Почти тоже самое, что и в примере выше, но тут есть фронт (UI/визуал/картинка, чтобы было понятнее).

А тут как тестировщики успевают? Особенность кроется не в автоматизации, как в примере выше, а в небольшом функционале, который можно проверять совместно. Связку фронт-бэк-база данных тестируется со стороны фронта и проверяет методы бэка. В таком проекте один тестировщик может выстроить процессы так, как ему удобно или усовершенствовать способы проверки, провести регресс при выпуске новой версии – протестировать и убедиться, что ничего не сломалось. 

Проект №3

Расскажу о собственном проекте, над которым работаю сейчас. 

Речь об огромном веб-приложении для обслуживания клиентов банка, в котором много микросервисов и интересного функционала. 

Так какое там соотношение? 21 ручной тестировщик, 7 автотестировщиков и 26 Front-end и Back-end разработчиков. То есть даже больше, чем 1 к 1, почему так?

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

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

Таким образом, количество тестировщиков зависит в основном от:

• типа проекта

• этапа разработки

• сложности проекта

• требований к тестированию

Важно понимать и анализировать каждый из параметров, чтобы найти идеальное соотношение.

Подведем итоги 

Универсального ответа на вопрос «какое должно быть соотношение тестировщиков и разработчиков?» нет, все зависит от проекта, окружающих факторов и даже опыта членов команды. 

Но попробуем все-таки вывести усредненную формулу.

Как пользоваться коэффициентами

Рассмотрим пример: приложение на чистом бэке, которое находится на фазе разработки и поддержки, количество логики среднее, допускаются минорные баги:

1.5*1.5* 1.5 1.5 = 5.0625 – в таком приложении будет оптимальным отношение QA к разработчикам 1 к 5 соответственно.

Другой пример: веб-приложение, где много логики, активная фаза развития и допускаются минорные баги:

1*1*1*1.5 = 1.5 – в таком ПО допускается соотношение 2 тестировщика на 3 разработчика.

Самое важное в этом деле — это участие каждого члена команды в процессах и качество исходного продукта.

Тестированию в компании «Совкомбанк Технологии» отводится большое внимания – мы используем максимальный гибкий подход к количеству QA на проекте, при котором у нас получается создавать устойчивые команды, способные эффективно работать с высоким качеством.

Если тебе тоже интересно развиваться в тестировании, разработке или других направлениях ИТ, смотри актуальные вакансии на сайте Совкомбанк Технологий.

Обсудить в форуме