Всем привет! На связи Андрей – 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 на проекте, при котором у нас получается создавать устойчивые команды, способные эффективно работать с высоким качеством.
Если тебе тоже интересно развиваться в тестировании, разработке или других направлениях ИТ, смотри актуальные вакансии на сайте Совкомбанк Технологий.