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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

НТН

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Почему:

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

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

Ответ 9

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

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

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

Ответ 10

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