メニュー

探索的テストとスクリプトテスト：誰が勝つか？

exploratory testing vs scripted testing

問題を排除するために楽器を試してください

探索的テストの実際の利点：

従来、ソフトウェアテストは非常に厳格な活動でしたが、近年、スクリプトベースのテストからの移行が進んでいます。 探索的テスト よりコンテキスト主導型の、が前面に出てきました。これは、テスターが自分のスキルと知識を活用するためのより多くの自由を与え、自分の仕事の価値を最適化する責任をテスターに​​与えるためです。

探索的テストとスクリプトテスト

誰もが探索的テストの価値で売られているわけではありません。知覚された形式の欠如と個人的な責任の強調は、警鐘を鳴らす可能性があります。しかし、その懸念は主に探索的テストの誤解に基づいています。 ルールをウィンドウから外してランダムにテストすることではなく、実際には非常に構造化され、体系化されています。そしてそれはまた非常に効果的です。

懐疑論者は、それがテスターの士気を向上させる以上のことをするという具体的な証拠を求めています。そのため、コンテキストベースの探索的テストをスクリプトベースのテストアプローチと直接比較する調査を実施することにしました。あなたが見つけようとしているので、結果は非常に興味深いものでした。

学習内容：

何でjsonファイルを開くか

コンテキストベース（探索的テスト）とスクリプト化されたテストチーム

2つのチーム、2つのアプローチ：

まず、テスターを3人ずつの2つのチームに分けました。各チームのテスターは、同じ同等のアプリケーション知識を持っていました。の同じ定義 欠陥の重大度 （メジャー、マイナー）は両方のチームのために設立されました。両方のチームに同じアプリケーションビルドが提供されました。一方のチーム（「スクリプト」）は従来のスクリプトベースのテストアプローチを適用し、もう一方のチーム（「探索的」）はコンテキスト駆動型のテストアプローチを採用します。テスト活動は、それぞれ3日間の2つのフェーズに分けられます。

スクリプトベースのチーム テストする5つのビジネスワークフローを特定し、15のテストケースを生成しました。テストケースの範囲は限られていたため、テスターはスクリプトの範囲外を探索する自由がありませんでした。

探索チーム 2つ作成しました 視覚的なマインドマップ 、1つはテストカバレッジとテストチャーターを識別し、もう1つは製品コンポーネント/モジュールをカバーします。このプロセスにより、合計24のテストチャーターが作成されました。定義された憲章は高レベルであり、文脈の解釈を可能にし、テスターのテストセッションの範囲を拡大しました。

フェーズ1：

スクリプトチームは、割り当てられた3日間で6つのテストケースを完了することができました。彼らは当時6つの大きな欠陥を報告しました。

探索チームは、それぞれ30分から180分の範囲の13のテストセッションを完了することができました。彼らは10の大きな欠陥と5つの小さな欠陥を報告しました。

スクリプト化されたテストと探索的テスト1

興味深いことに、探索チームは、スクリプトチームが報告したすべての欠陥を報告しました。

フェーズ2：

スクリプト化されたチームはなんとか完了しました 9つのテストケース 今回。彼らは報告した 10の主要な欠陥 そして 8つの小さな欠陥 。

探索チームは18セッションを完了しました。彼らは報告した 14の主要な欠陥 そして 5つの小さな欠陥。

スクリプト化されたテストと探索的テスト2

フェーズ2では、スクリプトチームは、探索チームが検出しなかった2つのメジャー欠陥と1つのマイナー欠陥を報告しましたが、探索チームは、スクリプトチームが報告しなかった3つのメジャー欠陥と1つのマイナー欠陥を報告しました。

これは、これらのセッションおよびテストケース内でテスターに​​よって選択された可能性のあるワークフローの相対的な複雑さを考慮していませんが、それでもいくつかの興味深い結論を引き出すことができます。

どういう意味ですか？

探索的アプローチ、およびそれが生み出す責任と柔軟性は、より効果的な形式のテストをもたらすように思われます。状況に応じて、テストセッションの進行に合わせてテスト憲章を作成および適合させることで、より多くの分野をカバーできる可能性があります。この自由はスクリプトベースのテストに欠けており、欠陥の発見を妨げる可能性があります。

qtpインタビューの質問と回答pdf

スクリプトに固執することで、使い古されたパスが作成されます。これらのパスから逸脱することによってのみ、すべての欠陥を明らかにすることができます。テストコミュニティ内のソートリーダーが何度か言及したように、「製品を地雷のフィールドとして想像し、各地雷が欠陥である場合、同じ道を何度も踏むことがそれらを見つける方法ではないことはかなり明らかです。すべて。'

結局、どちらのアプローチも完璧ではありませんでした。なぜなら、探索チームが全体としてもっと報告したとしても、各チームが他のチームが特定しなかった欠陥を報告したからです。

現実的には、これは、「最小限の」欠陥に可能な限り近づくことに関して、正しいアプローチが2つの混合になることを意味する場合があります。しかし、には多くの利点があります コンテキスト主導のアプローチ それはその賛成で話します。 準備時間と文書化が少なくて済み、問題を早期に特定し、テスターに​​分析スキルと演繹的推論を使用するように要求します。 彼らは製品をより深く、より完全に理解し、実際にエンドユーザーの支持者として行動します。

結論

最終結果は、探索的テストが稼働前により多くの欠陥の報告につながり、チームによって提供されるより良い製品をもたらし、最終的には より満足した/満たされたテスター あなたがそれをどのように見ても、それはすべて望ましい結果です。

著者について

Mush Hondaは、のQAディレクターです。 KMSテクノロジー 、ジョージア州アトランタとベトナムのホーチミン市にオフィスを構える、ソフトウェア開発ライフサイクル全体にわたるITサービスのプロバイダー。彼は以前、Ernst＆Young、Nexidia、Colibrium Partners、Connectureでテスターを務めていました。 KMSサービスには、アプリケーション管理、テスト、サポート、プロフェッショナルサービス、およびスタッフの増強が含まれます。

同意しますか？以下にコメントや質問を投稿してください。

前のチュートリアル |次のチュートリアル＃4： HPSprinterを使用した探索的テスト

推奨読書

^