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

20

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

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

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

Эрнест Фридман-Хилл
источник
2
Пожалуйста, перефразируйте свой вопрос, чтобы это не опрос. Какую проблему вы пытаетесь решить?
М. Дадли
5
«Должен» во многом зависит от организационной структуры компании. Если они измеряются на наличие ошибок, обнаруженных в производстве, то наличие возможности держать версию с ошибками является важным инструментом.
Отличная мысль, @MichaelT. В моей организации тестирование - это скорее роль, а не описание работы, а оценка более специальная, а не количественная. Успешные развертывания будут положительными отзывами, но ошибки в работе не будут являться конкретными минусами, равно как и для других в команде.
Эрнест Фридман-Хилл
5
Если у вас есть проблема с тем, что тестировщики отказываются утверждать выпуски на основе проблем, не запланированных для решения, то у вас есть проблема со связью (они не знают, что проблемы не планируется решать) или проблемы с людьми (они делают себя важными; выпуск в конечном итоге делового решения).
Ян Худек

Ответы:

27

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

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

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

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

Билл
источник
Кто решает, пригласите ли вы клиента выполнить приемочные испытания на сборке 1234 или что он недостаточно хорош для приемочных испытаний?
Барт ван Инген Шенау
3
@BartvanIngenSchenau: Владелец продукта / менеджер проекта должен иметь последнее слово по этому поводу. Потому что даже приемочные испытания часто будет деформироваться , если это будет необходимо (вы хотите функция X теперь даже если мы не можем получить Y для работы с ним, или вы хотите , чтобы ждать еще 2 месяца , пока мы это исправить?) И владелец продукта ведет переговоры об этом.
Ян Худек
в дополнение к тому, что сказал Ян, во многих методологиях здесь будет график или каденция. некоторые люди развертывают каждого кандидата, прошедшего первоначальный дымовой тест, в UAT, некоторые автоматически внедряют все, что проверено в ветке кандидата, а некоторые все, что проверяется в основном. в идеале вы демонстрируете прогресс заинтересованных сторон по мере того, как вы идете, поэтому в конце не должно быть большого сюрприза. в некоторых из этих случаев вы заканчиваете тем, что показываете заинтересованным сторонам, на что люди QA тянули вас через угли, и они просто говорят «кого это волнует», и все кончено.
Билл
В современном SaaS с непрерывным развертыванием цикл развертывания кода (службы) может быть отделен от цикла выпуска компонента (бизнеса). Этот цикл выпуска функций может быть реализован с использованием флагов или переключателей функций, например, от альфа (внутренняя) до бета (дополнительная подписка) до общей доступности. Это один из способов более формального выхода из бизнеса отдельно и независимо от возможности развертывания конкретного кода или сервисов. Напротив, привязка функций к развертыванию сервисов привносит сопряжение и риск в процесс, которого можно избежать с помощью метода флагов функций.
Будет
@ Я не согласен, но кто-то все еще выносит суждение, если эти скрытые функции достаточно скрыты, чтобы их не заметили другие пользователи, кроме бета-группы, при первоначальном развертывании и, в конечном счете, везде, где я использовал этот подход. более или менее одинаково, но с разными метками на движущихся частях и риск немного сместился. Я предпочитаю ситуацию, которую вы описываете, но команда QA, обнаружившая что-то уже существующее, или менеджер по продукту, решивший продолжить, так же важны в этой модели, как и любая другая в моем опыте.
Билл
6

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

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

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

Брайан Оукли
источник
6

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

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

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

Барт ван Инген Шенау
источник
1
Я отказался от этого, потому что я принципиально не согласен с некоторыми пунктами и предположениями, которые вы делаете. Я не согласен с тем, что QA не должно иметь права налагать вето на релиз, потому что многие группы QA также работают в роли User Acceptance. Кроме того, я не согласен с предположением, что тестеры - технические люди. Не всегда так, не каждая группа, которая выпускает программное обеспечение, может позволить себе полноценную команду контроля качества, так что эта роль может упасть на бизнес-аналитиков, которые могут вообще не быть техническими.
maple_shaft
1
в дополнение к пункту maple_shaft, я часто вижу последний вызов слева от того, кто играет роль клиента, если не будет выявлено что-то ужасное. это в конечном итоге их результат, и они, скорее всего, будут иметь правильную точку зрения на риск, если вы предоставите им точную информацию.
Билл
5

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

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

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

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

Иордания
источник
3

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

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

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

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

Майкл
источник
1
Это реальная проблема, но я не уверен, что это обязательно проблема ОП. Моя интерпретация заключается в том, что тестеры каким-то образом интерпретируют новые требования, которые изначально не были определены.
maple_shaft
2
мой опыт работы с командами тестирования привел меня к тому, что я оказался на другой стороне. Для меня QA не должно ожидать, что сможет заблокировать развертывание, не доводя дело до остальной части команды или не заставляя владельца переопределить команду.
Билл
1
Верно - я, вероятно, не был достаточно явным, те же самые проблемы возникают, когда тестеры поднимают дефекты, и я цитирую «в духе истории», которая приводит к тем же проблемам - ничего не выпускается.
Майкл
В моем случае это больше интерпретация @maple_shaft; не столько лукавство в поиске способов взлома программного обеспечения, сколько сообщение об отказе обрабатывать явно неподдерживаемые случаи.
Эрнест Фридман-Хилл
1
@ ErnestFriedman-Hill Похоже, вы описываете Отрицательные требования, а этого нет в ваших документах с функциональными требованиями. Отрицательное требование - это явное утверждение о том, что система НЕ будет делать, и может быть таким же приемлемым, как и обычные требования. Если они объявлены, то их контрольные примеры с отрицательными требованиями недействительны.
maple_shaft