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

Question

Какое отношение [старших] разработчиков к тестировщикам люди считают лучшим?

Очевидно, что это будет частично зависеть от производительности разработки / сопровождения, но есть ли эмпирическое правило, из которого может работать новая компания / проект?

Кроме того, вы бы использовали «чистых» тестеров или совмещали бы тестирование с другими ролями (например, документация, обучение пользователей и т. Д.)?

Очевидно, что ответы могут зависеть от используемой стратегии компании / моделей развития, поэтому, пожалуйста, укажите, отвечаете ли вы в целом, или для определенного стиля продукта / выпуска и т. Д.

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

2) Сколько нужно времени для проверки каждого?

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

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

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

Answer 4

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

Answer 5

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

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

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

НТН

Answer 6

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

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

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

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

Answer 7

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

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

Также рассмотрим:

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

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

Answer 8

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

Answer 9

Кроме того, вы бы использовали «чистые» тестеры, или Вы бы совместить тестирование с другими роли (например, документация, пользователь обучение и т. д.)?

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

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

Answer 10

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

Почему:

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

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