testing - いつ検査をやめますか？

Question

実際に、アプリケーションのテストを停止して本番環境に移行する時期を知るために、どのような手段を使用していますか?

Answer 1

私の組織のプロジェクトでは、私が通常使用する手段は次のとおりです。

• 重大度 1 (ショー ストッパー) の問題なし
• 重大度 2 (主要な機能の障害) の問題なし
• 重大度 3 (マイナーな機能) の問題の許容数

「許容数」は、アプリケーションのサイズなどによっては、当然非常にフワフワした数です。

これらの前提条件が満たされたら、すべての利害関係者 (QA リード、開発リード、アプリ サポート リードなど) とのミーティングを開き、未解決の問題のリストを調べて、割り当てられた重大度について合意があることを確認します。未解決の問題。重大度 1 および重大度 2 の問題が未解決であることを確認したら、各利害関係者から「Go/No Go」の電話を受けます。全員が「Go」と言えば、私は安心して本番環境に移動できます。少なくとも 1 人の利害関係者が「No Go」と言う場合、「No Go」の理由を調べ、必要に応じて、その背後にある問題を解決するための措置を講じます。

小規模なプロジェクトでは、プロセスはより合理化される可能性があり、それが 1 人だけの操作である場合、前提条件のセットははるかに単純になる可能性があります。つまり、「(明らかに) 許容できる数のバグがありながら、アプリケーションは妥当な利益を提供します -そこに出しましょう！」. アプリケーションによって提供される利点がバグの煩わしさに勝る限り、特に「早期に頻繁にリリースする」というガイドラインに従っている場合は、それでうまくいくかもしれません。

Answer 2

まず、テストをやめることはありません。テストが完了してリリースすると、ユーザーが代わりにテストすることになります。

第 2 に、包括的なテスト スクリプトが許容レベルの失敗で合格すると、次に進む準備ができたことになります。

最後に、これはあなたのケースに非常に固有のものです。一部のプロジェクトでは、3 週間のベータ テスト期間が設けられており、最小の変更がロールアウトされる前に多くの人がシステムをハックします。他の領域 (それほど重要ではありません) では、別の開発者がうなずくだけで小さな変更を移すことができます。

Answer 3

私がずっと試してみたいと思っていた興味深いテスト方法の 1 つは、「エラー シード」です。アイデアは、さまざまなカテゴリに分類される意図的なバグをシステムに挿入するというものです。

例えば：

• 装飾、スペルミスなど
• 重大ではないエラー
• 重大なエラーとクラッシュ
• データの問題。エラーは発生しませんが、結果にさらに深刻な問題があります。
• 等

「シーダー」は、これらのバグを挿入するために何が変更されたかを正確に文書化するため、迅速に元に戻すことができます。テスト チームがシードされたバグを見つけると、実際のバグも見つけますが、違いはわかりません。理論的には、テスト チームがシードされた重大なエラーの 90% を検出した場合、実際の重大なエラーの比例した数を検出した可能性があります。

これらの統計から、いつリリースを許可するかについて判断を下すことができます。もちろん、発見されるバグのランダムな性質 (実際のバグまたはシードされたバグ) のため、これは絶対確実とは言えませんが、リリースするバグの数がまったくわからないよりはましです。

Answer 4

私の職場で時々使用される指標の 1 つは、製品の過去数バージョンに存在していた古くて報告されていないバグを見つけ始めたときに、十分にテストしたということです。これらがテスト中に発見されたバグであり、それらのバグが何年にもわたって存在し、顧客からの苦情がなければ、おそらく安全に出荷できるという考えです。

もちろん、手動テスト、自動テスト、開発者に製品を使用させること、ベータ版、継続的なテストなどもすべてありますが、過去のバージョンに存在しているが報告されていない、現在発見されているバグの数を使用しています。最初に聞いたときは新しいアイデアでした。

Answer 5

主要なショーストッパーがすべてなくなったとき。

真剣に、ユーザー受け入れテストを行い、ユーザーにシステムを使用させて、すべてがユーザーに適しているかどうかを確認する必要があります。これが現実的でない場合は、ターゲット ユーザーに似た選択したユーザーでクローズド ベータを行います。

システム内のすべてのバグを実際に見つけることは不可能であるため、唯一の本当のルールは出荷することです。

Answer 6

「showstopper」または主要な機能のバグの間に製品に費やされたテスト時間を測定することで、ほぼそこにいることを知ることができます。新しい機能が導入された製品が急速に変化するとき、テストチームは、報告しているバグのほとんどが重大な機能のバグであることに気付くのが一般的です。それらが扱われるにつれて、相互作用の滑らかさと明快さを改善することを目的とした、マイナー、フィット、フィニッシュタイプの問題が大量に発生することがよくあります。全体として、それらは製品の品​​質に大きな違いをもたらしますが、それぞれがそれほど重要ではありません。それらが修正されてテストが続行されると、テスターがエラーケースや異常な使用パターンにプッシュするときに、おそらくバグレポートを取得し続けるでしょう。