Каково хорошее соотношение разработчиков и тестировщиков?

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

На мой взгляд, хорошим показателем для определения количества необходимых тестировщиков является сложность требований, а не количество разработчиков. Если бы я нанимал тестировщиков, я бы взглянул на список требований (или, если необходимо, разбил бы проектный документ на список требований), и подумал бы, сколько времени на тестирование потребуется для каждого требования, чтобы убедиться, что оно работает правильно. Я бы использовал этот первоначальный анализ, чтобы нанять базу тестировщиков, а затем добавить тестировщиков позже, если рабочая нагрузка окажется слишком высокой для моей первоначальной базы.

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

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

Редактировать: Если вам повезло, что у вас есть набор приемочных испытаний на раннем этапе, пожалуйста, замените «приемочные тесты» на «список требований» выше. :-)

Я бы сказал (в зависимости от скорости, с которой вам нужно тестировать) с автоматизацией у вас может быть 1 или 2 тестировщика на каждые 5 разработчиков.

Почему:

• С автоматизацией им просто нужно беспокоиться о тестировании новых модулей.
• Регрессионные тесты позаботятся о более старых.
• 1 или 2 тестировщика могут легко покрыть всю работу, которую будут выполнять 5 разработчиков, например, неделю / неделю
• Хорошее соотношение, которого меня учили, заключалось в том, что на каждые 10 часов разработки команде по обеспечению качества потребуется около 3 или 4 часов, чтобы отследить большинство дефектов, которые возникли за эти 10 часов.

Надеюсь, это поможет :)

Джоэл приводит хороший аргумент для 1 тестировщика на каждых 2 инженеров, а также объяснение причин, по которым люди не имеют этих тестировщиков.

Also, would you use 'pure' testers, or would you combine testing with other roles (e.g. documentation, user training, etc)?

Это зависит от типа тестирования, но я бы не стал обременять тестировщиков другими ролями. Компетентные инженеры-тестировщики на вес золота (как и грамотные инженеры-программисты). Если вы поручаете им задачи, выходящие за рамки их компетенции, вы их замедлите и рассердите. Любят ли инженеры-программисты заниматься документацией или обучать пользователей? Обычно нет. И тестеры тоже.

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

Я однажды писал об этом в блоге здесь. Наиболее актуальный отрывок приведен ниже.

«Я видел высококачественные продукты, произведенные в соотношении разработка: тест 10: 1, и ужасные продукты, созданные в соотношении 1: 1. Разница заключается во внимании и заботе о качестве. Если все (включая руководство) в команде глубоко заботится о качестве продукта, это может произойти независимо от соотношения. Но если качество - это то, что должно быть проверено в продукте, непременно имейте по крайней мере 1 тестировщика на каждого разработчика - больше, если вы можете получить их."

Не существует обобщенного соотношения «хорошо».

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

Также учтите:

• что считается развитием?
• что считается тестированием?
• Если бы мы все равно собирались проводить регрессионное тестирование, будет ли это считаться «нулевым» дополнительным временем тестирования?

см .: http://www.sqablogs.com/jstrazzere/150/What+is+the+%22Correct%22+Ratio+of+Development+Time+to+Test+Time%3F.html

Прежде всего, от разработчиков до тестировщиков - это хороший практическое правило, но это Плохоправило.

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

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

Хотя это общие максимы, практический совет будет заключаться в использовании какой-то приблизительной формулы, основанной на этих факторах.

1) Сколько существует (разделенных) вариантов использования?

Я говорю о разделенных вариантах использования, потому что, если вы включаете изменения состояния и постоянные переменные, то кажущиеся несвязанными части программы могут оказаться связанными. I.E. 2 + 2 = 4 (1 вариант использования) 2 * 2 = 4 (2-й вариант использования). Это два простых оператора, значит, два класса вариантов использования. Однако, если вы можете add, а затем multiply, тогда вы не сможете проверить ТОЛЬКО add и multiply по отдельности, вы должны проверить их во всех возможных вариантах.

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

2) Сколько времени нужно, чтобы проверить каждую из них?

Это не означает (расширяя метафору калькулятора) только прибавление 2 + 2 и рассмотрение ответа. Вы должны указать время, необходимое для восстановления после сбоя. Если ответ неверен, вы ожидаете, что тестировщик зарегистрирует ошибку со снимком экрана и конкретными инструкциями о том, как воссоздать ошибку. Если вы не даете им времени на такую ​​административную работу, то вы вплетаете в свой план предположение, что у вас нет ошибок. И если мы так предполагаем, то зачем вообще нужны тестеры;)

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

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

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

1). Вопрос о соотношении разработчика и тестировщика актуален, поскольку чем сложнее требования, тем больше требуется разработчиков и, следовательно, больше тестировщиков. Многие из ответов, казалось, опровергли это.

2). Независимо от областей применения, хорошее соотношение, которое работает в реальном мире для «высококачественного» программного обеспечения, составляет 2: 1. Вы можете жить с соотношением 4: 1, но это действительно растянуть его. Конечно, в этой оценке есть много переменных, не только сложность требований, системы / среды для развертывания, но также то, насколько продуктивны разработчики и насколько плотный график доставки.

HTH

Одно можно сказать наверняка. Количество тестировщиков должно быть больше, чем количество разработчиков. Для каждой функции, созданной разработчиком, тестировщик должен проверить эту функцию в различных типах тестов: функциональность, удобство использования, границы, стресс и т. д. Хотя точное соотношение будет больше зависеть от количества тестовых примеров и продолжительности цикла тестирования. быть (1 неделя, 3 дня, 1 день или полдня), один разработчик будет генерировать достаточно активности тестирования для нескольких тестировщиков. Кроме того, могут быть сценарии, требующие, чтобы несколько тестировщиков имитировали двух или более пользователей, одновременно работающих в системе.