7 principles software testing
ソフトウェアテストの7つの原則:欠陥のクラスタリング、パレートの法則、農薬のパラドックスに関する詳細を含みます。
誰もが「 ソフトウェアテストの7つの原則 」。
これらの基本的なテスト原則は、テストチームが時間と労力を活用してテストプロセスを効果的なものにするのに役立ちます。 この記事では、2つの原則について詳しく学びます。 欠陥のクラスタリング、パレートの法則、農薬のパラドックス 。
学習内容:
ソフトウェアテストの7つの原則
これらの2つの原則を詳しく説明する前に、ソフトウェアテストの7つの原則を簡単に理解しましょう。
探検しよう!
#1)テストは欠陥の存在を示します
すべてのアプリケーションまたは製品は、さまざまなチームによる十分な量のテストの後に本番環境にリリースされるか、システム統合テスト、ユーザー受け入れテスト、ベータテストなどのさまざまなフェーズを通過します。
そう テストチームがソフトウェアを完全にテストし、ソフトウェアに欠陥がないことを確認または聞いたことがありますか。 ?その代わりに、すべてのテストチームは、ソフトウェアがすべてのビジネス要件を満たし、エンドユーザーのニーズに従って機能していることを確認します。
ソフトウェアテスト業界では、誰もがあると言うことはありません 欠陥なし テストでは、ソフトウェアにエラーや欠陥がないことを証明できないため、ソフトウェアではこれは非常に真実です。
ただし、テストの目的は、さまざまな手法と方法を使用して、ますます多くの隠れた欠陥を見つけることです。テストにより、未発見の欠陥が明らかになる可能性があります。欠陥が見つからない場合でも、ソフトウェアに欠陥がないことを意味するわけではありません。
例1 :
銀行のアプリケーションについて考えてみましょう。このアプリケーションは徹底的にテストされ、SIT、UATなどのさまざまなテスト段階を経ており、現在、システムに欠陥は確認されていません。
ただし、実稼働環境では、実際の顧客が銀行システムではめったに使用されない機能を試し、テスターがその機能を見落としていたため、これまで欠陥が見つからなかったか、開発者がコードに触れたことがない可能性があります。 。
例2:
テレビで石鹸、歯磨き粉、手洗い、消毒スプレーなどの広告を見てきました。
その特定の手洗いを使用すれば99%の細菌を取り除くことができるとテレビで言っている手洗い広告を考えてみてください。これは、製品が100%無菌ではないことを明確に証明しています。したがって、私たちのテストコンセプトでは、欠陥のないソフトウェアはないと言えます。
#2)早期テスト
テスターは、ソフトウェア開発ライフサイクル(SDLC)の初期段階で関与する必要があります。したがって、要件分析フェーズ中の欠陥またはドキュメントの欠陥を特定できます。このような欠陥の修正に伴うコストは、テストの後の段階で見つかったものと比較すると非常に低くなります。
テストが実稼働に移行するにつれて、欠陥修正のコストがどのように増加するかを示す以下の画像を検討してください。
[画像 ソース ]
上の画像は、要件分析中に見つかった欠陥を修正するために必要なコストが少なく、テストまたはメンテナンスフェーズに進むにつれてコストが増加し続けることを示しています。
今の質問は テストはどのくらい早く開始する必要がありますか ?
要件が確定したら、テスターはテストに参加する必要があります。要件が正しく定義されていない場合、開発段階で修正するのではなく、すぐに修正できるように、要件ドキュメント、仕様、またはその他のタイプのドキュメントに対してテストを実行する必要があります。
#3)徹底的なテストは不可能
実際のテスト中に、入力データのすべての有効な組み合わせと無効な組み合わせですべての機能をテストすることはできません。このアプローチの代わりに、いくつかの組み合わせのテストは、さまざまな手法を使用した優先順位に基づいて検討されます。
徹底的なテストには無制限の努力が必要であり、それらの努力のほとんどは効果がありません。また、プロジェクトのタイムラインでは、これほど多くの組み合わせをテストすることはできません。したがって、等価分割や境界値分析などのさまざまな方法を使用して入力データをテストすることをお勧めします。
例えば 、アルファベット、特殊文字、および0〜1000の数字のみを受け入れる入力フィールドがあるとします。テスト用にいくつの組み合わせが表示されるか想像してみてください。各入力タイプのすべての組み合わせをテストすることはできません。
テストに必要なテスト作業は膨大であり、プロジェクトのタイムラインとコストにも影響します。したがって、徹底的なテストは事実上不可能であると常に言われています。
#4)テストはコンテキストに依存します
銀行、保険、医療、旅行、広告などの市場で利用可能ないくつかのドメインがあり、各ドメインには多くのアプリケーションがあります。また、ドメインごとに、アプリケーションにはさまざまな要件、機能、さまざまなテスト目的、リスク、手法などがあります。
異なるドメインは異なる方法でテストされるため、テストは純粋にドメインまたはアプリケーションのコンテキストに基づいています。
例えば 、銀行のアプリケーションのテストは、eコマースや広告のアプリケーションのテストとは異なります。アプリケーションの種類ごとに関連するリスクは異なるため、同じ方法、手法、およびテストの種類を使用してすべての種類のアプリケーションをテストすることは効果的ではありません。
#5)欠陥クラスタリング
テスト中に、見つかった欠陥のほとんどが少数のモジュールに関連している場合があります。モジュールが複雑である、そのようなモジュールに関連するコーディングが複雑であるなど、これには複数の理由が考えられます。
これはソフトウェアテストのパレートの法則であり、問題の80%がモジュールの20%で見つかります。欠陥クラスタリングとパレートの法則については、この記事の後半で詳しく説明します。
#6)農薬のパラドックス
農薬パラドックスの原則によると、同じ一連のテストケースが一定期間にわたって何度も実行された場合、これらの一連のテストでは、システムの新しい欠陥を特定するのに十分な能力がありません。
この「農薬のパラドックス」を克服するために、一連のテストケースを定期的にレビューして改訂する必要があります。必要に応じて、新しいテストケースのセットを追加し、システムからそれ以上の欠陥を見つけることができない場合は、既存のテストケースを削除できます。
#7)エラーがない
ソフトウェアが完全にテストされ、リリース前に欠陥が見つからなかった場合、ソフトウェアには99%の欠陥がないと言えます。しかし、このソフトウェアが間違った要件に対してテストされた場合はどうなりますか?このような場合、エンドユーザーのニーズに合わない誤った要件でテストが実行されるため、欠陥を見つけて時間どおりに修正しても役に立ちません。
例えば、 アプリケーションがeコマースサイトに関連しており、「ショッピングカートまたはショッピングバスケット」機能に対する要件が誤って解釈およびテストされているとします。ここでは、さらに多くの欠陥を見つけても、アプリケーションを次のフェーズまたは実稼働環境に移行するのに役立ちません。
これらは、ソフトウェアテストの7つの原則です。
では、調べてみましょう 欠陥のクラスタリング、パレートの法則、および農薬のパラドックス 詳細 。
欠陥クラスタリング
ソフトウェアをテストしているときに、テスターはほとんどの場合、見つかった欠陥のほとんどが特定の機能に関連していて、残りの機能の欠陥の数が少ないという状況に遭遇します。
欠陥クラスタリングとは、ほとんどの欠陥を含む少数のモジュールを意味します。基本的に、欠陥はアプリケーション全体に均一に分散されるのではなく、欠陥が2つまたは3つの機能に集中または集中化されます。
アプリケーションの複雑さのために、コーディングが複雑またはトリッキーになる場合があります。開発者がミスを犯して、特定の機能またはモジュールにのみ影響を与える可能性があります。
欠陥クラスタリングは「 パレートの法則 」とも呼ばれます 80-20の法則 。これは、検出された欠陥の80%が、アプリケーション内のモジュールの20%に起因することを意味します。パレートの法則の概念は、当初、イタリアの経済学者によって定義されました -Vilfrodo Pareto 。
テスターが100個の欠陥を調べた場合、それらの100個の欠陥に対して根本的な意味があるかどうかは明確ではありません。しかし、これらの100個の欠陥が特定の基準で分類されている場合、テスターは、多数の欠陥がごく少数の特定のモジュールにのみ属していることを理解できる可能性があります。
例えば 、銀行のアプリケーションの1つでテストされた以下の画像を考えてみましょう。これは、ほとんどの欠陥が「当座貸越」機能に関連していることを示しています。アカウントの概要、資金移動、自動振込などのその他の機能には、限られた数の欠陥があります。
[画像 ソース ]
上の図は、合計32個の欠陥のうち18個の欠陥が当座貸越機能の周囲にあることを示しています。これは、欠陥の60%が「当座貸越」モジュールで見つかったことを意味します。
したがって、テスターは主に実行中にこの領域に集中して、ますます多くの欠陥を見つけます。テスターは、テスト中に他のモジュールにも同様の焦点を当てることをお勧めします。
最初の反復時よりも一連のテストケースを使用して同じコードまたはモジュールを何度もテストすると、欠陥の数は多くなりますが、何度か繰り返すと、欠陥の数は大幅に減少します。欠陥クラスタリングは、欠陥が発生しやすい領域を回帰テスト中に徹底的にテストする必要があることを示します。
農薬のパラドックス
モジュールの1つにさらに欠陥があることが判明した場合、テスターはそのモジュールをテストするためにいくつかの追加の努力をします。
テストを数回繰り返した後、開発者はテスターがより多くの欠陥を見つけた特定のモジュールをコーディングする際にも注意を払うため、開発チームによってほとんどの欠陥が修正されるため、コードの品質が向上し、欠陥数が減少し始めます。
したがって、ある時点で、ほとんどの欠陥が発見および修正され、そのモジュールで新しい欠陥が検出されなくなります。
ただし、特定の1つのモジュール(この場合は「」でコーディングする際に特に注意が必要な場合があります。 当座貸越 」モジュール)、開発者は他のモジュールを無視して適切にコーディングしたり、その特定のモジュールで行われた変更がアカウントの概要、資金移動、自動振込などの他の機能に悪影響を与える可能性があります。
テスターが同じテストケースのセットを使用して、ほとんどの欠陥が見つかったモジュール(当座貸越モジュール)を実行すると、開発者がそれらの欠陥を修正した後、それらのテストケースは新しい欠陥を見つけるのにあまり効果的ではありません。当座貸越のエンドツーエンドのフローとして、モジュールは徹底的にテストされ、開発者もそのモジュールのコードを慎重に作成しました。
これらのテストケースを改訂および更新する必要があります。また、新しいテストケースを追加して、ソフトウェアまたはアプリケーションのさまざまな領域で新しい欠陥や欠陥を見つけることができるようにすることもお勧めします。
農薬パラドックスの予防方法
以下に示すように、農薬のパラドックスを防ぐための2つのオプションがあります。
に) さまざまな領域またはモジュール(以前の欠陥が発生しやすいモジュールを除く)に焦点を当てた新しいテストケースのセットを作成します。 例: ソフトウェアの「当座貸越」)。
b) 新しいテストケースを準備し、既存のテストケースに追加します。
の中に ' 方法A 」、テスターは、以前のテスト中に焦点が当てられなかった、または開発者がコーディング中に特に慎重でなかった他のモジュールで、より多くの欠陥を見つけることができます。
上記の例では、テスターは、新しいテストケースのセットを使用して、アカウントの概要、資金移動、または自動振込のモジュールでさらに多くの欠陥を見つけることができます。
しかし、テスターが以前のモジュールを無視する可能性があります( 例: 「当座貸越」)ほとんどの欠陥が以前の反復で発見され、このモジュール(当座貸越)が他のモジュールのコーディング後に新しい欠陥を注入された可能性があるため、これはリスクとなる可能性があります。
の中に ' 方法B 」、モジュールの残りの部分で新しい潜在的な欠陥を見つけることができるように、新しいテストケースが準備されます。
この例では、新しく作成されたテストケースは、アカウントの概要、資金移動、自動振込などのモジュールの欠陥を特定するのに役立ちます。ただし、テスターは以前の欠陥が発生しやすいモジュールを無視することはできません( 例: これらの新しいテストケースは既存のテストケースとマージされるため、「当座貸越」)。
既存のテストケースは「当座貸越」モジュールに重点を置き、新しいテストケースは他のモジュールに重点を置いていました。したがって、テストケースのすべてのセットは、コードの変更がいずれかのモジュールで発生した場合でも、少なくとも1回は実行されます。これにより、適切なリグレッションが実行され、このコード変更による欠陥を特定できるようになります。
2番目のアプローチを使用すると、テストケースの総数が大幅に増加し、実行に必要な労力と時間が増えます。これは明らかにプロジェクトのタイムラインに影響を与え、最も重要なのはプロジェクトの予算にも影響を与えます。
したがって、この問題を克服するために、冗長なテストケースを確認してから削除することができます。新しいテストケースを追加し、既存のテストケースを変更すると、役に立たなくなるテストケースがたくさんあります。
最後の5回の反復(5回の反復を想定)の欠陥を特定するために、どのテストケースが失敗したか、およびどのテストケースがそれほど重要ではないかを確認する必要があります。また、いくつかのテストケースでカバーされている単一のフローを別のエンドツーエンドのテストケースでカバーでき、単一のフローを持つテストケースを削除できる場合もあります。
これにより、テストケースの総数が減ります。
例えば 、1つの特定のモジュールをカバーする50のテストケースがあり、これらの50のテストケースのうち、20のテストケースが最後の数回のテスト反復で新しい欠陥を検出できなかったことがわかりました(5回の反復を想定します)。したがって、これらの20のテストケースを徹底的にレビューする必要があり、これらのテストケースの重要性を確認し、それに応じて20のテストケースを保持するか削除するかを決定できます。
テストケースを削除する前に、それらのテストケースでカバーされている機能フローが別のテストケースでカバーされていることを確認してください。テストケースの総数を大幅に減らすために、このプロセスをすべてのモジュールで実行する必要があります。これにより、テストケースの総数が減りますが、要件は100%カバーされます。
これは、残りのすべてのテストケースがすべてのビジネス要件をカバーしているため、品質に妥協がないことを意味します。
結論
ソフトウェアテストは、ソフトウェアがエンドユーザーごとに必要なとおりに機能しているかどうかを確認するため、SDLCの重要なステップです。
テストでは、可能な限り多くの欠陥を特定します。したがって、テストを効果的かつ効率的に実行するために、誰もがソフトウェアテストの7つの原則を認識し、実際に理解する必要があります。また、それらはテストの柱として知られています。
ほとんどのテスターは、実際のテスト中にこれらの原則を実装して経験しました。
Android用の最高の無料音楽ダウンローダーアプリ
一般に、原則という用語は、従う必要のある規則または法律を意味します。したがって、ソフトウェアテスト業界のすべての人がこれらの7つの原則に従う必要があり、誰かがこれらの原則のいずれかを無視すると、プロジェクトに莫大な費用がかかる可能性があります。
幸せな読書!!
推奨読書
- 最高のソフトウェアテストツール2021 [QAテスト自動化ツール]
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストコース:どのソフトウェアテスト機関に参加する必要がありますか?
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- 欠陥ベースのテスト手法とは何ですか?
- いくつかの興味深いソフトウェアテストのインタビューの質問
- ソフトウェアテストコースのフィードバックとレビュー