回答。

リリース段階での手動テストの組織は、リリース予定の製品バージョン内の欠陥を迅速かつ効果的に見つけるための一連の手段であり、最も重要でよく使用される機能に焦点を当てています。

背景: 以前は、リリースはしばしば「夜間の駆け込み」で行われ、テスターはすべてを急いで確認したため、テストの質が損なわれ、バグがプロダクションに飛び込み、リソースが非効率的に浪費されました。優先事項を明確に体系化することで、より多くの成果をより短時間で得ることができることが徐々にわかるようになりました。

問題: リリース前のテストに制限された時間しかないため、すべてを確認することはできません。また、人間の要因—疲労、急ぎ、ストレスが増します。しばしば、クリティカルなバグはリリース後にしか浮上せず、製品の評判を損ない、チーム内に混乱を引き起こします。

解決策:

ビジネス、アナリスト、開発者と共に、重要かつビジネス上重要なシナリオを評価します。
よく使われるかリスクの高い「クリティカル」シナリオを含むリリースチェックリストを作成します。
最終的なスモークテストおよびサニティテストを手動で実施します：システムの起動、ログインプロセス、注文処理、支払いなどを確認します。
誰がテストデータに責任を持つか、誰が発見された欠陥の報告に責任を持つか、誰が開発者とのコミュニケーションを担当するかを明確に分けます。

重要な特徴:

バグの優先順位付け：クリティカルなものをまず見つけてエスカレーションします。
簡潔で迅速に実行可能なテストケースおよびチェックリストの使用。
開発チームとの迅速なコミュニケーションを実現し、迅速な修正を行います。

騙し質問。

リリース前にアプリ全体を手動で確認して「過剰確認」することは可能ですか？

いいえ、通常、完全な手動テストにかける時間はありません。重要なシナリオに焦点を当てたバランスの取れたアプローチが、より良い結果をもたらします。

リリース前に「小さな」バグを開示すべきですか？

いいえ、リリースモードでは、重要でブロッキングな欠陥のみをエスカレーションし、重要でないものは既知の問題として整理し、リリース後に処理します。

リリース段階で詳細なテストケースを必ず手動で作成する必要がありますか？

いいえ、しばしばチェックリストやテストケースから引き出したミニスクリプトを使う方が簡単で迅速であり、関連するシナリオを迅速に確認することができます。

一般的な間違いとアンチパターン

最後の数時間までテストを遅らせる—これによりすべてが急いで行われ、質が損なわれます。
重要なシナリオを犠牲にして、まれに使用されるシナリオや重要でないシナリオを確認する。
リリース直前に最終的なスモーク/サニティテストが欠如する。

実生活の例

ネガティブケース

リリーステストは夜間に行われ、ドキュメントをざっと確認しながら、重要な支払いフローを忘れます。翌日、ユーザーが多数注文を支払えなくなります。

利点:

高速な確認。

欠点:

重要なバグを見逃した。
深夜のストレスリスク、開発者とのコミュニケーションの逸失。

ポジティブケース

リリース前に、クリティカルなシナリオ（ログイン、支払い、注文の保存、パートナーとの統合）のみに焦点を当てます。チェックリストに従って結果を確認し、バグは即座にエスカレーションされます。