テスターはリリースを承認するべきですか、それともテストについて報告するだけですか？

20

テスターにサインオフ権限を与えることは理にかなっていますか？テストチームが

機能、問題などをテストし、合格/不合格ベースで報告するだけで、それらの結果に基づいて行動することができます。
それらの結果に基づいて、リリース自体を保持する権限がありますか？

つまり、テスターは実際にリリースを承認する必要がありますか？私が取り組んでいるテストチームは、彼らがそうしていると感じており、「スコープクリープのテスト」が原因でこれに問題があります。

testing release-management process

— アーネスト・フリードマン・ヒル
ソース

2

アンケートではないように質問を書き直してください。解決しようとしている問題は何ですか？

— M.ダドリー

5

「すべき」は、企業の組織構造に大きく依存します。本番環境で見つかったバグを測定する場合、バグのあるリリースを保持できることが不可欠なツールです。

素晴らしい点、@ MichaelT。私の組織では、テストは職務内容ではなく役割であり、評価はより場当たり的であり、定量的ではありません。展開の成功は肯定的なレビューにつながりますが、実稼働環境のバグは特定の否定的なものではなく、チームの他の誰よりも多くなります。

— アーネストフリードマンヒル

5

テスターが対処する予定のない問題に基づいてリリースの承認を拒否する問題がある場合は、コミュニケーションの問題（対処する予定のない問題を知らない）または人の問題（自分自身を重要にしているかどうか）リリースすることは最終的にビジネス上の決定です）。

— Jan Hudec

27

私がQAを担当したほとんどの場所には、何らかのサインオフ手順がありますが、リリースが進行するかどうかについての最終的な権限はありません。彼らのサインオフは、彼らがリリース計画に期待されるテストを完了したことを表しており、リリースに問題がないことを表しています。

最終的にQA！=ビジネスとビジネスは、現在の状態でコードを展開しても問題ないか、メリットがマイナス面を上回るかどうかを判断する必要があります。これは多くの場合、展開の直前にクライアントまたは利害関係者によって行われ、多くの場合、ユーザー受け入れと呼ばれます。

QAがユーザー受け入れグループでもある場合、リリース候補を受け入れられないものとして定義する権限を持っている可能性がありますが、バグ修正/反復/スプリント/変更の範囲外の問題についてこれを取得している場合リクエスト/時間を何に費やしても、プロジェクトマネージャーまたはビジネスラインの利害関係者は、QAチームとイエスミーティングに来る必要があります。

既存の欠陥または新しい要件の意図しない結果について報告することは問題ありませんが、範囲外であり、壊滅的でない場合、一般的にそれをブロッキング問題としてラベル付けすることは受け入れられません。製品所有者が他のすべてと同様に優先順位を付けることは、バックログに含まれます。

— ビル
ソース

ビルド1234で受け入れテストを実行するように顧客を招待するか、受け入れテストに十分ではないかを決めるのは誰ですか？

— バートヴァンインゲンシェナウ

3

@BartvanIngenSchenau：製品所有者/プロジェクトマネージャーは、これらについて最後の言葉を話す必要があります。受け入れテストでさえ、必要に応じて膨らむことが多いため（機能Yを使用できなくても機能Xが必要ですか、それとも修正するまであと2か月待ちますか？）交渉中です。

— Jan Hudec

Janが言ったことに加えて、多くの方法論では、ここにスケジュールまたはリズムがあります。最初のスモークテストで残ったすべての候補をUATにデプロイする人もいれば、候補ブランチにチェックインしたものを自動デプロイした人、メインにチェックインしたものをすべて導入した人もいます。理想的には、何らかの形で進むにつれて利害関係者の進歩を示しているので、最後に驚くことはあまりないはずです。これらのケースのいくつかでは、QAの人々があなたを石炭の中に引きずり込んでいるものを利害関係者に見せることになり、彼らは単に「誰が気にかけている」と言って終わりました。

— ビル

継続的な展開を伴う最新のSaaSでは、コード（サービス）の展開サイクルを機能（ビジネス）のリリースサイクルとは別にすることができます。この機能リリースサイクルは、機能フラグまたはトグルを使用して実装できます。たとえば、アルファ版（内部）からベータ版（オプトイン）から一般公開まで。これは、特定のコードやサービスのデプロイ可能性とは別に、より正式なビジネスサインオフを行う1つの方法です。反対に、機能リリースをサービス展開に結び付けて、プロセスにカップリングとリスクを導入しますが、これは機能フラグ技術で回避できます。

— ウィル

@私は同意しませんが、それらの隠された機能が初期展開でベータチーム以外のユーザーに気付かれず、最終的に私が使用した場所でシーケンスプレイに隠れている場合、誰かがまだ判断を求めています多かれ少なかれ同じですが、可動部分のラベルが異なり、リスクが少しシフトしました。私はあなたが説明する状況を好みますが、QAチームが既存のものを見つけたり、プロダクトマネージャーがとにかく先に進むことを決定したりすることは、このモデルでは他の経験と同じくらい重要です。

— ビル

6

誰かがその権限を必要としています。それがテスター、テスターのチーム、テスターのチームのリーダー、または開発組織のリーダーであるかどうかは、やや無関係です。または、おそらくより正確には、組織に依存します。

最終的に、ソフトウェアをリリースする選択はビジネス機能です。ビジネスは品質が適切かどうかを判断する必要があります。おそらく、品質保証の責任者はその決定を下すか、その決定を適切なビジネスユニットに提供する必要があります。それはすべて、会社の規模、品質の相対的重要性などに依存します。

言われていることはすべて、決定に使用される情報はテスターから始まります。リリースを停止する権限があるかどうかに関係なく、リリースの遅延を引き起こすと思われる何かを見たときに意思決定者に通知する責任を感じる必要があります。

— ブライアン・オークリー
ソース

6

テスターへのリリースにサインオフ権限（つまり拒否権）を与えることは、開発者にその権利を与えることと同じくらい意味があります。

テスターと開発者は主に技術者であるため、主に技術的な理由で決定を下す可能性があります。しかし、リリースを行う際に検討する必要がある懸念は、技術的およびビジネス上の懸念です。明らかに、バグの多い製品を提供した場合、顧客は満足しませんが、製品に未解決の問題があるため、リリースを延期し続けると、顧客も同様に不満になります。

誰かが良い製品と顧客に約束されたスケジュールを守ることとの間の適切なバランスを見つける必要があります。これを行うには、あなたがすべきではない純粋に技術的な役割ではなく、むしろプロジェクトマネージャーや製品の所有者のようなより多くのビジネス/経営指向の役割にプロジェクトに参加し、テスターと開発者からあなたの入力を取ること。

— バートファンインゲンシェナウ
ソース

1

私はあなたがしているいくつかのポイントと仮定に根本的に同意しないので、これを採決しました。多くのQAグループもユーザー受け入れの役割で活動しているため、QAにリリースを拒否する権限を与えてはならないことに同意しません。さらに、テスターが技術者であるという仮定には同意しません。常にそうであるとは限らず、ソフトウェアをリリースするすべてのグループが完全なQAチームを確保できるわけではないため、その役割は、まったく技術的ではないビジネスアナリストに任せることができます。

— maple_shaft

1

maple_shaftのポイントに加えて、ひどい何かが特定されない限り、顧客の役割にいる人にこの左の最後の呼び出しを見ることもよくあります。最終的には成果物であり、正確な情報を提供することを前提として、リスクに関して正しい観点を持っている可能性が最も高くなります。

— ビル

5

「リリースする」または「リリースしない」という決定は、最終的にはビジネス上の決定であり、厳密なリスク/報酬分析を実行する必要があります。

組織がこの責任を引き受けるようテストチームに依頼したり、テストチームがこの責任に同意したりするのは正気ではありません。

テストチームの役割は、ソフトウェアの品質、リリースの準備状況、およびリリースするかどうかのビジネス決定への入力として識別されるリスクの分析を提供することです。

他の人が指摘したように、_ 誰か _（そして私はそれが個人だと思う）は、「リリース」または「リリースしない」決定を行う権限を必要とします。その同じ人は、特定の条件下でその決定を委任することができます（つまり、P1またはP2のバグはありません）

— ヨルダン
ソース

3

私は同じ状況でテスターが働きすぎて、システムを破るより創造的な方法を発明し、リスクを評価したときに本番環境では信じられないほど起こりそうにありません。

テストチームが不完全なリリースを送りたくないことを理解し、称賛する一方で、「許容できるリスク」を定義するには強力な製品所有権が必要です。

私の経験では、テストチームにはソフトウェアのリリースに関する拒否権が与えられるべきですが、この拒否権は製品所有者によって無効にされるべきですが、リードテスターとの議論の後でなければなりません。

ソフトウェアが完璧になることはありません。テストクリープに苦しんでいる場合、主要な生産上の問題（正しくテストされない）が発生して急いでしまうまで、何もリリースされません。

— マイケル
ソース

1

それは本当の問題ですが、それが必ずしもOPの問題であるかどうかはわかりません。私の解釈では、テスターは元々定義されていなかった新しい要件を何らかの形で解釈しています。

— maple_shaft

2

テストチームでの私の経験は、この反対側に陥ることにつながりました。私にとって、QAは、チームの他のメンバーに主張したり、所有者にチームをオーバーライドさせたりせずに、デプロイをブロックできることを期待してはなりません。

— ビル

1

確かに-私はおそらく十分に明示的ではなかった、テスターが欠陥を提起するときに同じ問題が発生し、同じ問題につながる「物語の核心」で引用する-何もリリースされない。

— マイケル

私の場合、@ maple_shaftの解釈のほうが多くなっています。明示的にサポートされていないケースの処理の失敗を報告するように、ソフトウェアを破壊する方法を見つけるのにそれほど巧妙ではありません。

— アーネストフリードマンヒル

1

@ ErnestFriedman-Hill 負の要件を説明しているように聞こえますが、これらは機能要件ドキュメントに欠けているものです。ネガティブ要件は、システムが実行しないことに関する明示的なステートメントであり、通常の要件と同じくらい受け入れられる場合があります。これらが宣言されている場合、ネガティブ要件に対するテストケースは無効です。

— maple_shaft