QA к dev [закрытому] отношению

Начните с 1 QA для 5 или 6 разработчиков. Затем начните настраивать его в зависимости от того, сколько работы, по вашему мнению, QA должны сделать или им нечего делать.

По правде говоря, это просто основано на моем собственном опыте, потому что здесь задействовано слишком много факторов. Насколько развита или стабильна ваша кодовая база? Насколько оно большое? Насколько комплексным должно быть тестирование? Какие инструменты тестирования и анализа задействованы? Как часто выпускаются промежуточные релизы? Какой у вас процесс разработки? Сколько ручного тестирования и сколько автоматизированного?

Есть еще много вопросов. Так что просто начните с произвольного числа и продолжайте оттуда.

Рациональное соотношение QA и Dev может быть получено только в зависимости от сложности рассматриваемого приложения.

Очевидно, что uberdeveloper, вероятно, может создать сложное приложение, в котором только 3 QA полностью время можно эффективно протестировать из-за сложности рабочего процесса; в свою очередь, может быть 1 QA для 3 младших разработчиков, которые собирают относительно простое приложение для создания отчетов о вводе-выводе.

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

Многое зависит от того, что делает система и каковы последствия дефектов? Вы пишете финансовое программное обеспечение? Или социальные сети? Вероятная стоимость одного отказа больше, чем другого, поэтому усилия по обеспечению качества варьируются. Точно так же, если это продукт (с несколькими установленными пользовательскими базами, которые может быть сложнее исправить), вам нужно, чтобы он был более стабильным, чем если бы он был внутренним.

Вы также должны спросить, ожидаете ли вы, что они проведут базовое тестирование системы или объем и нагрузочное тестирование тоже. Похоже, вы смотрите на комбинацию тестирования пользовательского интерфейса и тестирования API.

Дайте вам отправную точку, предполагая, что вы говорите об «нормальном» типе системы, а мы говорим о базовом тестировании системы, метрике Я бы согласился с тем, что 33% всех усилий должно приходиться на тестирование. Теоретически это дает вам соотношение 1: 2, но предположим, что ваши разработчики проводят модульное тестирование, возможно, увеличьте его до 1: 3. Конечно, сейчас я использую от 1 до 4, и этого недостаточно (я исправлю это, как только бизнес позволяет мне).

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

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

Это, вероятно, зависит от насколько задействована база кода (есть ли много интегрирующих модулей) и насколько задействован пользовательский опыт (если есть много визуальных элементов и элементов управления вводом для тестирования).

Если это довольно сложная система, вы можете захотеть рассматривать 2-3 QA-инженера на каждые 5 разработчиков. Если, однако, функции на самом деле не сильно меняются или задействованы меньше,

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

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

Опять же, если ваша система не меняется так часто, редко обновляется, зачем вам много разработчиков для начала? ? Мне удалось убедить себя, что 1: 2 - идеальное соотношение практически во всех ситуациях. :)

2 тестировщика на 3 разработчика - неплохое начало. Если во многих тестовых примерах используются вещи, которые нельзя автоматизировать (физическое подключение / отключение, визуальная проверка рендеринга пользовательского интерфейса), добавьте 1 тестировщика на 2 инженеров по тестированию.