Должны ли тестеры утверждать релизы или просто сообщать о тестах?

Имеет ли смысл давать полномочия на подпись тестерам? Если тестовая команда

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

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

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

В конечном счете, QA! = Бизнес и бизнес должны решить, в порядке ли они при развертывании кода в текущем состоянии, или перевес перевешивает недостатки или что-то еще. Это часто делается клиентами или заинтересованными сторонами непосредственно перед развертыванием и часто называется принятием пользователем.

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

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

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

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

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

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

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

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

Решение «освободить» или «не выпускать» является в конце дня деловым решением, где необходимо провести тщательный анализ рисков / выгод.

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

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

Как отметили другие, _ кому-то _ (и я считаю, что это физическое лицо) действительно необходимы полномочия для принятия решения "освободить" или "не выпускать". Это же лицо может делегировать это решение при определенных условиях (т.е. без ошибок P1 или P2)

Я работал с той же ситуацией, когда тестировщики преодолевали и изобретали все более креативные способы взлома системы, которые при оценке риска невероятно маловероятны в производстве.

Хотя я понимаю и одобряю группу тестирования за то, что она не желает рассылать несовершенные версии, для определения «приемлемого риска» требуется сильное владение продуктом.

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

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