Каково хорошее соотношение разработчиков и тестировщиков?
какое отношение [старших] разработчиков к тестировщикам люди считают лучшим?
очевидно, что это будет частично зависеть от пропускной способности разработки/обслуживания, но есть ли эмпирическое правило, из которого может работать новая компания/проект?
кроме того, вы бы использовали "чистые" тестеры или объединили тестирование с другими ролями (например, документация, обучение пользователей и т. д.)?
очевидно, что ответы могут зависеть от используемой стратегии компании / моделей развития, поэтому, пожалуйста, укажите если вы отвечаете вообще, или если для определенного стиля продукта/выпуска и т. д.
10 ответов
прежде всего, разработчики для тестеров-это хорошо правило, но это плохо правила.
что вам нужно учитывать, так это сколько вариантов использования вашего приложения. Приложения, с которыми пользователи будут взаимодействовать неконтролируемым образом (например, веб-приложения или настольные приложения), потребуют больше тестировщиков, чем аналогичное консольное приложение.
приложение, которое принимает один файл и обнаруживает регулярное выражение шаблоны в нем потребуют меньше тестеров, чем новая ОС.
хотя это общие Максимы, практическим советом было бы использовать какую-то приблизительную формулу, основанную на этих факторах
1) сколько (разделенных) вариантов использования есть?
Я говорю разделенные случаи использования, потому что если вы включаете изменения состояния и постоянные переменные, то, казалось бы, несвязанные части программы могут оказаться связанными.
И. Е. 2 + 2 = 4 (1 Использование case) 2 * 2 = 4 (2-й случай использования). Это два простых оператора, два класса вариантов использования. Однако, если вы можете add затем multiply, тогда вы не можете проверить только add и multiply индивидуально, вы должны проверить их во всех их возможных перестановок.
при рассмотрении количества вариантов использования убедитесь, что вы включаете варианты использования, которые включают цепочку команд.
2) сколько времени требуется, чтобы проверить каждый из них?
это не означает (для расширьте метафору калькулятора) только добавляя 2 + 2 и глядя на ответ. Необходимо указать время, необходимое для восстановления после аварии. Если ответ неверен, вы ожидаете, что тестер зарегистрирует ошибку со скриншотом и конкретными инструкциями о том, как воссоздать ошибку. Если вы не дадите им времени на такого рода административная работа, тогда вы печете в план предположение, что у вас нет ошибок. И если мы предполагаем, что, то зачем вообще тестеры;)
A сложный проект будет иметь как большое количество вариантов использования, так и большое количество разработчиков, но они не являются гарантированной корреляцией. Вам лучше тщательно изучить свои варианты использования и принять обоснованное решение о том, сколько тестеров потребуется.
Дополнительный Бонус. После того, как вы разбили приложение так тщательно, вы можете найти некоторые варианты использования, которые никогда не рассматривались на этапе проектирования, и исправить их, прежде чем тестер найдет их.
Джоэл делает хороший аргумент для 1 тестера для каждых 2 инженеров, так же, как покрывать оправдания люди используют для не иметь те тестеры.
Я однажды написал об этом в блоге здесь. Наиболее уместная выдержка приведена ниже.
" Я видел высококачественные продукты, произведенные в соотношении 10:1 dev:test, и ужасные продукты, созданные с соотношением 1: 1. Разница заключается во внимании и заботе о качестве. Если все (включая руководство) в команде глубоко заботятся о качестве продукта, это имеет хорошие шансы произойти независимо от соотношения. Но если качество это то, что должно быть испытано в продукт, безусловно, есть по крайней мере 1 тестер для каждого разработчика - больше, если вы можете их получить."
недавно была соответствующая статья о InfoQ что вы можете найти интересным.
эта строка, по-видимому, довольно старая. Но мне казалось, что все ответы не имеют смысла.
1). Вопрос соотношения разработчика и тестировщика является актуальным, так как чем сложнее требования, тем больше требуется разработчиков и, следовательно, тем больше тестировщиков. Многие из ответов, казалось, отвергали это.
2). Независимо от областей применения, хорошим соотношением, которое работает в реальном мире для обеспечения высокого качества является 2:1. Вы можете видео с 4:1, но это действительно растянуть его. Конечно, в этой оценке есть много переменных, не только сложность требований, систем / сред для развертывания, но и насколько продуктивны разработчики и насколько плотен график доставки.
HTH
на мой взгляд, хорошей метрикой для определения необходимого количества тестировщиков является сложность требований, а не количество разработчиков. Если бы я нанимал тестировщиков, я бы посмотрел на список требований (или разбил бы проектный документ на список требований, если это необходимо) и подумал о том, сколько времени тестирования каждого требования потребуется, чтобы убедиться, что оно работает правильно. Я бы использовал этот первоначальный анализ, чтобы нанять базу тестировщиков, а затем добавить тестировщиков позже если рабочая нагрузка окажется слишком высокой для моей первоначальной базы.
Если вы собираете бюджет и нанимаете тестировщиков позже, это не вариант, вы можете захотеть бюджетировать немного больше ресурсов тестирования, чем указывает ваш анализ. Слишком много всегда лучше чем мало.
использовать ли" чистые " тестеры-это еще один вопрос, который действительно зависит от того, сколько ресурсов тестирования вам нужно. Я обнаружил, что хороший компромисс-нанять тестировщиков, которые способны другие работы, и используют их в других емкостях временами когда нагрузка испытания светла.
Edit: Если вам посчастливилось иметь набор приемочных тестов на раннем этапе, пожалуйста, замените "приемочные тесты" на "список требований" выше. :-)
нет обобщенного" хорошего " отношения.
очевидно, что время, необходимое для тестирования чего - либо, является контекстуальным-это зависит от факторов, которые могут иметь мало или ничего общего с тем, сколько времени потребовалось для разработки этой функции.
также считают:
- что считать развитием?
- что входит в тестирование?
- если бы мы все равно собирались выполнить регрессионное тестирование, это считается" нулевым " дополнительным тестированием часов?
Я бы сказал (в зависимости от скорости, которую вам нужно протестировать), с автоматизацией вы можете иметь 1 или 2 тестера для каждых 5 разработчиков.
Почему:
- с автоматизацией им просто нужно беспокоиться о тестировании новых модулей
- регрессионные тесты позаботятся о более старых.
- 1 или 2 тестера могут легко покрыть всю работу, которую разработчики 5 сделают, например, неделю / неделю
- хорошее соотношение, которому меня учили, было для каждого 10 часов превращаться, команда проверки качества примет arround 3 или 4 часа для того чтобы отслеживать большой часть из дефектов те 10 часов произведенных.
надеюсь, это поможет:)
кроме того, вы бы использовали "чистые" тестеры или вы бы объединили тестирование с другими роли (например, документация, пользователь обучение и т. д.)?
Это зависит от типа тестирования, но я бы не стал обременять тестировщиков другими ролями. Компетентные инженеры-испытатели стоят своего веса в золоте (так же, как компетентные инженеры-программисты). Если вы дадите им задания, выходящие за рамки их компетенции, вы замедлите их и отключите. У инженеров программного обеспечения, как ведение документации или обучение пользователей? Обычно нет. Не тестеры.
тем не менее, нет ничего плохого в дополнении вашей тестовой команды людьми из других областей, особенно для тестирования юзабилити, приемочного тестирования, быстрых обзоров и т. д.
одно можно сказать наверняка. Количество тестеров должно быть больше, чем количество разработчиков. Для каждой функции, созданной разработчиком, тестер должен использовать эту функцию в различных типах тестов: функциональность, удобство использования, граница, стресс и т. д. Хотя точное соотношение будет больше зависеть от количества тестовых случаев и продолжительности цикла тестирования (1 неделя, 3 дня, 1 день или полдня), один разработчик будет генерировать достаточную активность тестирования для нескольких тестировщиков. В кроме того, могут быть сценарии, требующие нескольких тестеров для имитации двух или более пользователей, работающих одновременно в системе.