QA против коэффициента развития

Ответ 1

Ответ очень субъективен, но вот мой опыт.

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

Эта смесь будет варьироваться в зависимости от нескольких критериев:

• Сколько тестирования модулей разработчики делают. Чем больше они делают, тем меньше тестов нужно делать.
• Насколько разработчики пишут с нуля и используют существующие библиотеки. Если существует много ранее существовавшего кода, и тестировщикам необходимо также проверить эту функциональность, необходимо учитывать эту стоимость разработки для отображения 1:1.
• Как динамично развивается. Если вы пишете пользовательский интерфейс, где относительно небольшие настройки разработчика приводят к большому изменению тестируемой поверхности, вам потребуется больше тестеров, которые были бы обработаны.
• Насколько важна эта функция. Чтобы написать что-то вроде GMail, где он используется случайно, и ошибки могут быть допущены и исправлены в поле, требуется меньшее количество тестеров. С другой стороны, если вы работаете над медицинскими устройствами для визуализации, вам нужно намного больше тестирования, потому что ошибки трудно исправить в поле и очень плохо, когда они происходят.

Ответ 2

Для большинства проектов в компании я работаю в соотношении 1:1. Но это может варьироваться в зависимости от нескольких факторов:

• Выход Dev. Я видел одного разработчика, у которого было большое количество выходных данных, и 3 QA работали над его функциями.
• Качественный бар для продукта. Критически важная система с высокой степенью надежности должна иметь более высокий бар QA, чем внутренний веб-сайт отчетности, и ему потребуется больше людей с QA.
• Некоторые проекты должны быть протестированы с большим количеством конфигураций и сценариев. Devs может оставаться постоянным, но вам, очевидно, потребуется больше QA для покрытия полной тестовой матрицы.
• Как автоматизируется тестирование. Если тестирование не может быть легко автоматизировано, вам потребуется больше людей для выполнения ручных проходов.

Ответ 3

По моему опыту, есть два основных типа персонала QA: те, кто просто следуют за письменным script и взаимодействуют с приложением, стремясь найти случаи с краями, и те, кто может на самом деле писать сам код автоматического тестирования, и искать новые и инновационные способы (fuzzing, Selenium, писать клиенты API), чтобы разорвать код команды разработчиков.

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

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

Ответ 4

Мое место работы в настоящее время составляет около 8: 1 dev: qa. Причина этого в том, что мы очень серьезно относимся к автоматизированному тестированию. Требуется полная работа с полным охватом unit test. Мы также участвуем в функциональном тестировании с помощью Fitnesse (все истории пользователей должны иметь тест на пригодность), проверки запускают полные тестовые прогоны с сервером CI, часто проверяют разработчиков, часто выпускаем.

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

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

Ответ 5

Есть много факторов, которые отвечают на это.

• У вас есть автоматическое тестирование?
• Как структурируются ваши периоды выпуска?
• Каков ваш unit test охват%?
• Насколько хороши ваши люди (как QA, так и Dev)?
• Включаете ли вы QA в течение всего жизненного цикла проекта или вы сбрасываете их в конце?
• Вы делаете добавочные релизы в QA?

Я работал там, где он варьировался от 3: 1 (QA/DEV) до 0,5: 1 (QA/DEV). Это сводится к тому, сколько ресурсов QA требуется для адекватного тестирования продукта, и нет никакого ответного ответа на этот вопрос.

Ответ 6

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

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

Ответ 7

Количество сотрудников QA не должно зависеть от количества разработчиков. Это должно зависеть от желаемого качества продукта, но не от чего-либо еще.

Многие говорят, что "для QA" работа хорошего разработчика - это более простая задача, чем "для QA" - работа хуже разработчика. Черт, почему это правда? "Обеспечить качество" - и QA - это "обеспечение качества" - означает разработать процесс, который маркирует продукт с "QA прошел" и "QA failed". Я знаю только два процесса, которые зависят от самого кода: статическая проверка кода и экспертная оценка. В то время как первый несколько используется, и иногда ему нужны парни QA, чтобы поддерживать его, то, что называется "качество" кода, не имеет значения для бездушной машины. И экспертная оценка проводится программистами, а не QA. Надеюсь, это убедит вас, что количество QA не зависит от разработчиков, не так ли?

В домене, в котором работает наша компания, конкуренции нет, и рынок очень узкий. Поэтому мы получаем всю необходимую информацию из отчетов об ошибках и у нас нет QA, поэтому отношение равно нулю. Все испытания выполняются разработчиками. Тем не менее, мы живем, потому что требуемое качество не нуждается в hirind любых ребята QA.

Ответ 8

В нашей организации отношение dev: QA равно 5: 2, и для этого нам нужно понять больше сценариев, таких как

• который работает над модульным тестированием. В нашем случае один человек полностью посвящен написанию плана unit test, а команда из 5 членов выполняет unit test случаи и исправляет ошибки наш PL вовсе не участвует в кодировании, он делает только ориентированные на процесс/обзорные вещи.

• функциональное тестирование выполняется тестерами времени, которые вы можете сказать о половине ресурса и одном цикле функционального тестирования, выполненного разработчиками

Таким образом, это зависит от размера проекта, ресурсов LOC и ресурсов компании на основе их уровня CMM.

Ответ 9

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

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

Ответ 10

Это зависит от организации и веб-приложения, которое разрабатывается. Все компании имеют собственный коэффициент качества: QA в соответствии с их требованиями.

Короче говоря, это зависит от размера проекта и ресурсов, доступных в организации.

Ответ 11

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

Ответ 12

Хорошо, это зависит от качества персонала в конце дня. Если один программист выполняет такую ​​же работу, как два QA, то соотношение равно 1: 2 и наоборот. Качество персонала здесь будет # 1.