Так сколько же тестировщиков нужно?

Привет, Друзья! Тема заголовка, как мне кажется, не перестаёт болеть ни у одного тестировщика на протяжении всей его жизни. Кто-то для себя уже нашел простой ответ об идеальном соотношении разработчиков к тестировщикам, кто-то только на пути. А кто-то нашел какое-то своё просветление, о котором мы сегодня в общем-то и поговорим. Проходите опросик и добро пожаловать под кат. Время прочтения около 7 минут.

Я надеюсь, вы уже прошли опрос выше. Если да, тогда можно глянуть на результаты такого же опроса у меня в телеграм-канале. Интересно будет сравнить.

Ну да, ну да. Опрос провокационный. Кто-то скажет мне (точнее, уже говорил): «Кирилл, это какой-то неправильный опрос, тут нет многих пунктов». Я осознанно убрал некоторые соотношения и вариант «угодить всем», от части, потому что хотел бы посмотреть именно на те цифры, которые зачастую обсуждаются на кухнях, в коридорах или на созвонах с топ-менеджерами; а от части потому, что именно вариант «угодить всем» я хотел обсудить в этой статье.

Ну что ж, затянувшаяся преамбула закончилась, погнали к рассуждениям.

Для начала я хотел бы кое в чем признаться. Дело в том, что если меня выдернуть на улице (или во сне) и спросить «Какое оптимальное соотношение тестировщиков к разработчикам?», я, не моргнув глазом, отвечу: «Ну наверное 1 к 3». Мой опыт работы в тестировании до 2019 года говорил мне, что 1 к 3 — это плюс-минус нормальное соотношение. Да, иногда где-то тестировщиков чуть больше, где-то чуть меньше, но медиана проходит где-то возле 1/3.

Я уже задавался этим вопросом ранее и, как ни странно, нашел только одну более-менее нормальную статью по теме. Статья, по-моему, значительно старше, чем 2017 г. Мне кажется я читал её в далёком 2011. Тем не менее ссылку дам на издание расширенное и дополненное.

Для тех, кому лень читать ещё одну статью, коротко скажу вывод: волшебной таблетки нет, каждому проекту своё количество тестировщиков; где-то 1qa к 20dev это слишком много, а где-то 5qa к 1dev это слишком мало.

Вывод кажется очевидным, спорить с ним не готов и не собираюсь, более того, всячески его придерживаюсь.

Своей же статьёй я бы, пожалуй, рискнул чуть расширить алгоритм, выдаваемый в статье Натальи Руколь, на примере своих проектов в Exante.

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

Опять же, для тех, кому английский не мил – перескажу главные мысли.

Во-первых, автор подчеркивает те же принципы, проговоренные в статье выше: количество тестировщиков на проекте зависит от сложности проекта, количества поддерживаемых платформ и навыков тестировщиков.

Во-вторых, в статье приводится интересный график, основанный на статистике компании, которая и опубликовала статью. Компания занимается тестированием в режиме аутсорс. И по их личной статистике (которая, в свою очередь, довольно обширна) получается, что соотношение в районе 60% (6 тестировщиков к 10 разработчикам) будет оптимальным с точки зрения соотношения цена/качество. Тем не менее, если готовы переплачивать, то при достижении соотношения равного 90% (9 qa/10dev) уровень качества достигает плато и дальнейшее добавление новых тестировщиков не будет приводить к повышению качества.

Какие бы выводы можно было сделать? Ну, самый главный вывод – «оранжевая» зона у каждой компании на самом деле своя. Посчитать её очень тяжело, если только не менять количество тестировщиков (с зафиксированной командой разработки) и не смотреть, что происходит на проекте. Тем не менее кажется, что 6 или 5 тестировщиков на 10 разработчиков (то есть примерно 1 к 2) – действительно довольно продуктивное и комфортное соотношение (на этом месте я снова полез посмотреть на результаты своего опроса. А вы?).

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

Что ещё не учитывается? Возможно, кто-то из вас уже нашел ответ на этот вопрос и горит желанием написать о нём в комментариях. Не спешите – обсудим. Не учитывается автоматизация тестирования. Вне зависимости от того, есть ли у вас выделенный автоматизатор или у вас T-shaped тестировщики-автоматизаторы, программирование тестов (и поддержание тестового фреймворка) отнимает время, а значит количество тестировщиков в команде должно быть больше.

А теперь, кажется пора поделиться историей про то, как мы работали и работаем в Exante.

Конечно, подсчёт тестировщиков по головам не обошел стороной и нашу компанию. В своё время тестировщиков и разработчиков действительно считали штуками и делили одно число на другое. Получали некое соотношение, а потом говорили «должно быть 1/3».

Какие были проблемы в связи с этим? Ну, думаю и так понятно. В команде разработки могло быть три синьористых синьора с опытом работы в компании более четырёх лет, а в команде тестировщиков – три джуна с опытом меньше года. Я сейчас утрирую, но вы понимаете, что получалось соотношение 1 к 1, а качество продукта и скорость тестирования не увеличивались.

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

Фултайм автоматизаторы, которые автоматизировали регресс и, по сути, облегчали жизнь ручным тестировщикам, тоже попадали под раздачу. Их считали как «целого одного тестировщика», однако такой тестировщик не вносил свой вклад в тестирование новых фич, он занимался другими делами. Кстати, тест-менеджеры тоже порой считались за боевую единицу, а их в нашей компании было 3 (из 11 сотрудников QA отдела, в своё время).

Напоследок добавлю, что можно было даже жонглировать проектами. То есть, допустим на одном проекте соотношение было 1 к 2 (и всё равно не хватало), а на другом 1 к 4 и всё было супер. Но при усреднении получалось, что соотношение 1 к 3 и «куда ещё столько тестировщиков?»

Могу сказать только одно, ребят – здорово, что эти времена в далёком-далёком прошлом. Сейчас мы используем друге подходы.

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

Дальше – мы не учитываем автоматизацию в этих расчётах. Автоматизаторы занимаются своими делами, от них ожидаются свои результаты, но если мы хотим ускорять разработку проектов (а значит и тестирование) мы должны ориентироваться на релизное тестирование в рамках скоупа спринта.

Там, где как таковых спринтов нет – важно смотреть на количество задач в тестировании.

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

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

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

Что касается тех проектов, где работа идёт по спринтам с жестким скоупом релиза – там мы просто хотим успевать разбирать этот скоуп. Для этого, конечно, мы стараемся автоматизировать регресс, чтобы уменьшить время ручного регресса и высвободить тестировщикам время на задачи и исследовательское тестирование. Тем не менее, если тестинг забивается, то мы туда добавляем тестировщика.

Ну и последнее. У нас есть проекты, в которых и один тестировщик справляется с четырьмя-пятью разработчиками и всё успевает. В этом значимая доля успеха того, что вся продуктовая команда работает как один организм и разработчики активно вовлечены в процессы по обеспечению качества. Тем не менее, мы и туда добавляем тестировщиков. Зачем? Всё просто – мы хотим уменьшить (или точнее увеличить) bus-factor. Потому что потерять одного тестировщика из пяти на проекте совсем не то же самое, что потерять одного единственного тестировщика на проекте. И я сейчас говорю не сколько об увольнениях (хотя и о них тоже), но и об отпусках, болезнях или других непредвиденных обстоятельствах.

Вы уже поняли, что мы набираем себе в команду большое количество QA инженеров, да? Тогда воспользуюсь случаем и скажу, что мы ждём к себе в команду тестировщиков и не только (можно найти на нашем сайте Exante).

Минутка саморекламы окончена. Давайте к выводам.

Что ж! Выводы с одной стороны банальные, с другой стороны, приправлены несколько иным соусом.

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

Со своей стороны я сделал вывод, что считать такое соотношение вообще контрпродуктивно. Надо считать напрямую количество работы, которое делают тестировщики и смотреть – справляются они или нет (да, Кэп!). В некоторых проектах мы упростили этот подход и свели всё к формуле: одна критичная сложная задача в тестировании на одного тестировщика, плюс один тестировщик на миноры и багофиксы.

Вот так вот. Спасибо, что дочитали этот лонгрид. Надеюсь, вам было интересно. Уверен, что описанные мною выше подходы (как свои так и чужие) – не единственные варианты справится с вопросом количества тестировщиков на проекте. Поэтому я буду очень рад комментариям под этим постом.

До связи!