Home

Оригинальная публикация

Автор: Наталья Руколь

Многие руководители проектов ищут универсальный ответ на вопрос: «Каким должно быть соотношение тестировщиков и разработчиков»? В некоторых компаниях дело доходит до утверждения нормативов: например, численность тестировщиков должна составлять 40% от команды разработки, или на каждого разработчика должен приходиться один тестировщик. Для обоснования этого соотношения нередко подбирается некая универсальная статистика по отрасли. Существует ли оптимальный рецепт?

Правильного соотношения не существует

Универсальные ответы всегда чреваты неточностью. Представьте: вы приходите к врачу и начинаете ему жаловаться на свою проблему. Он, не дослушав, выписывает лекарство:

— Какой у Вас вес? 80? Значит, по нормативу Вам надо пить 2 таблетки в день.
— Но подождите, доктор, у меня не простуда, а перелом ноги!
— Не отвлекайте, у нас норматив. Следующий!

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

Когда экономия обходится дорого

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

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

Допустим, свою работу не успевает сделать команда тестировщиков. Что тогда делает с оставшимся избытком ресурсов команда разработки? Как правило, она частично компенсирует нехватку тестирования! В итоге, разработчикам приходится тратить много сил на дополнительные активности. Мы можем столкнуться с несколькими вариантами таких трудозатрат:

• если тестировщики заводят ошибки слишком поздно (через неделю или более после готовности сборки), исправление занимает значительно больше времени;

• если тестировщики заводят ошибки недостаточно понятно, разработчики сами тратят время на выяснения и локализацию проблем;

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

Получается, что задачи тестирования тормозят весь процесс. Экономя на тестировании, которое является более дешёвым по сравнению с разработкой процессом, мы теряем продуктивность разработки!

Больше – не значит лучше

Многие руководители проектов все еще свято верят в проектный треугольник:

«Хотите сделать что-то лучше, больше? Либо наймите больше людей, либо расширьте сроки». К счастью, эта модель неполноценна. Она не учитывает ни квалификацию команды, ни специфику процесса работ. Когда вы необдуманно добавляете ресурсы в проект, теряется контроль, и добавляется избыточный «белый шум».

Я лично участвовала в проекте по спасению крупной компании-разработчика ПО с мировым именем. Проблема на входе звучала как катастрофа: «Мы сорвали сроки выпуска продукта НА ПОЛТОРА ГОДА. В команде уже более 100 человек, но с каждым днём мы находим всё больше проблем, а сроки релиза откладываются всё дальше». В первый месяц мы уменьшили проектную команду до 40 человек, ещё через два месяца вышел успешный релиз.

Как найти собственное «правильное» соотношение?

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

Шаг 1-й. Сначала строим процесс, потом расширяем команду.
Прежде чем пополнить команду, убедитесь, что ваши сотрудники работают достаточно продуктивно. В этом вам поможет техника 5M из Kaizen и «Дерево текущей реальности» из Теории Ограничений. Сначала вы должны оценить оптимальность текущих процессов и только после этого принять решение о расширении команды, если таковое необходимо. Иногда вы можете получить и совершенно противоположный результат – число работников нужно сокращать!

Шаг 2-й. Учитываем критичность программного продукта.
Соотношение тестировщиков и разработчиков во многом зависит от важности разрабатываемых вами продуктов. Глубина тестирования браузерной игрушки и ПО в авионике существенно отличается: растёт цена ошибки – следовательно, растёт и цена её обнаружения. Становится недостаточным находить только очевидные проблемы. Необходимо проверять все мыслимые и немыслимые ситуации, создавая модели и убеждаясь в полноте их покрытия.

В некритичном ПО мелкие ошибки зачастую вообще не исправляются, а потому их поиск и регистрация не имеют смысла. Чем выше степень ответственности проекта, тем большее внимание уделяется мелочам: «мелких» ошибок в таких задачах не бывает.

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

Шаг 3-й. Учитываем поддерживаемые окружения.

Требования к поддерживаемым окружениям существенно влияют на стоимость тестирования, и в меньшей степени – на разработку. Наглядный пример такой зависимости мы наблюдаем в разработке Android-приложений. Огромное количество производителей телефонов, разные версии Android, альтернативные прошивки, оболочки и настройки самой системы в совокупности дают бесконечное количество комбинаций. Теоретически, разработка под них ведётся в соответствии с общим гайдлайном. На практике в конкретных условиях возможны неожиданные дефекты. Узнать о них можно только эмпирическим путём через тестирование. Для обнаружения ошибки, связанной с определённой прошивкой конкретного «железа», может потребоваться проверить сотню других валидных комбинаций. Разработка будет задействована только в случае обнаружения проблемы, а тестирование – в любом случае.

Шаг 4-й. Учитываем сложность продукта.
Затраты на тестирование растут по экспоненте в зависимости от его сложности. Нам важно проверить не только работу отдельных операций или обработку конкретных данных, но и связи с другими сценариями или объектами нашей системы. В дело вступает комбинаторика в тестировании. Допустим, в карточке клиента есть 3 поля, каждое из которых принимает по 3 возможных значения — это 9 возможных комбинаций. Добавим четвёртое поле с аналогичной бизнес-логикой. Для разработчика это повлечет увеличение трудозатрат на 33%. Но в тестировании мы получаем уже 27 комбинаций вместо 9 – а следовательно, рост затрат не на 33%, а на 200%.

Не стоит упускать из анализа и такое явление, как регрессионное тестирование. Допустим, мы имеем зрелый непростой продукт, кодовая база которого содержит полтора миллиона строк кода. Разработчик вносит маленькое изменение, и… Что проверять? Как узнать, что эти правки ничего не сломали?

В качестве примера приведу ещё один случай из своей практики. Когда-то я подрабатывала тестировщиком в веб-компании, разрабатывающей достаточно простые сайты, не содержащие серьёзной функциональности (90% разработок – обычные «визитки»). Моей неполной занятости хватало на то, чтобы проверять результаты работы 30 разработчиков и верстальщиков, не пропуская при этом ни одной серьёзной ошибки. Простые продукты и тестировать очень просто.

Шаг 5-й. Учитываем связи с внешними продуктами.
Чем больше в системе интеграций, тем больше требуется тестировщиков. Ошибки могут содержаться как в сторонних библиотеках, так и в неправильном формате данных, полученных от поставщика. Разработчикам не нужно забивать этим голову до тех пор, пока тестировщики не подтвердят наличие проблемы. Наконец, бывают ситуации, когда ошибки не находятся, но для полной уверенности в этом всё равно необходимо проводить полное тестирование интеграции.

Однажды мне на тестирование передали доработку, выполненную программистом меньше, чем за день. В ней было от силы 100 строчек кода, обеспечивающих передачу данных во внешнюю систему управления задачами через её API. За 3 (три!) дня тестирования я завела около 40 серьёзных функциональных дефектов. Все они были вызваны некорректной работой внешнего API или его неактуальной документацией. Разработчику пришлось обходить эти ошибки «костылями» с нашей стороны.

Выводы

Придумать какое-то универсальное число и следовать ему – очень просто. Выбрать лучшее соотношение для своего проекта – значительно сложнее. Если вы хотите, чтобы проект был не просто «в норме», а по-настоящему успешен – вам придётся потрудиться! Лучшие результаты будут достигнуты в том случае, если вы для начала проанализируете текущие задачи, внедрите оптимальный процесс, а уж потом примете решение по количеству тестировщиков и разработчиков. Всевозможные «единственно правильные» установки и нормативы могут только увести вас от эффективного решения.

Если вас заинтересовали идеи и методики, упомянутые в статье, и вы хотели бы узнать о них больше, или даже попробовать применить их на своём проекте - приглашаем вас на тренинг Натальи Руколь "Школа  тест-менеджеров".

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