メニュー

コンテキスト駆動型テスト：例を含む7つの基本原則

context driven testing

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

例を使用したコンテキスト駆動型テストの7つの基本原則：

アニメをオンラインで無料で視聴するのに最適なサイト

私が空港に車で行くとき、私は通常、最短時間でそこに着くことができ、通行料を回避する高速道路を利用します。しかし、その日、私は通行料のかかるより長い地方道路ルートを取りました。週末を家族と過ごすために非常に長い距離を旅した友人とドライブで数分余分に過ごしたかったからです。この場合、通常の最悪の選択が最良の選択であることが判明しました。

しかし、これを考慮してください。

ガスが不足している場合はどうなりますか？

現金が不足している場合はどうなりますか？

別のオプションを選択します。どうして？コンテキスト。

コンテキスト駆動型テストとは

(画像 クレジット )

に基づいて決定を下す場合、以下はコンテキスト主導の決定です。

  • 関係者
  • 状況
  • 目標
  • 利用可能なオプション
  • 感情など

では、コンテキスト駆動型テストとは何ですか？

コンテキスト駆動型テストは、Cem Kaner、James Bach、Bret Pettichordによって開発された考え方の転換（またはテストの学校）です。それについての詳細は彼らの有名な本で見つけることができます： ソフトウェアテストで学んだ教訓 。

それには7つの基本原則があります。以下は彼らの本から直接選ばれています：

＃1） 実践の価値は、その文脈によって異なります。

＃二） コンテキストには優れたプラクティスがありますが、ベストプラクティスはありません。

＃3） 一緒に働く人々は、プロジェクトのコンテキストの最も重要な部分です。

＃4） プロジェクトは、多くの場合予測できない方法で時間の経過とともに展開します。

＃5） 製品はソリューションです。問題が解決しない場合、製品は機能しません。

＃6） 優れたソフトウェアテストは、やりがいのある知的プロセスです。

＃ 7） プロジェクト全体を通して協力して行使される判断力とスキルによってのみ、適切なタイミングで適切なことを行い、製品を効果的にテストすることができます。

それは私たちのために行われているので、私はそれらのそれぞれを説明するつもりはありません ここに専門家自身 。

コンテキスト駆動型テストに関する私の見解について、シナリオベースの説明を行うだけです。

コンテキスト駆動型テストの例：

私がテストプロジェクトを開始しているとしましょう–プロジェクトAには、Webベースのアプリケーションのエンドツーエンドのテストが含まれています。

私の戦略は何でしょうか？

標準プロセスによると、これは一連のイベントになります。

  • 要件を収集し、アプリケーションを理解する
  • テスト計画を作成する
  • テストドキュメントの作成-テストシナリオ、テストケース、トレーサビリティマトリックスなど。
  • すべてのドキュメントを確認して承認してもらいます
  • QA環境とテストデータを設定します
  • テスト実行を実行します
  • バグレポートを作成する
  • テスト実行状況レポートなどを生成して共有します。

「これが私がしなければならないことだとどうやって決めたのか」と自問する場合。私の答えは、ベストプラクティス、QA基準、業界ガイドライン、過去の経験ベースラインなどですよね？

GPU温度を監視するための最良のプログラム

私は自分がするように教えられたこと、または他の人がするのを見たことを繰り返しています。

さて、何か問題がありますか？どういたしまして。このアプローチには一定の再現性と実績があるため、これも機能する可能性があります。しかし、それは最適な結果への道を開くのでしょうか？

疑わしい。どうして？

すべてのプロジェクトで、さまざまな状況に対処するためです。

  • 文書化された要件と文書化されていない要件
  • 緊密に連携しているチームと地理的に分散しているチーム
  • 同じ会社に属する開発チームとテストチームと競合他社
  • 十分な時間対。 タイトなスケジュール
  • チームの構成 –新規参入者と経験者。訓練されたものと訓練されていないもの。
  • ツールの可用性-手動とテスト管理ツールの使用法
  • プロジェクトの種類-ルール（FDAまたは銀行）と実験的（ソーシャルメディアなど）を厳密に順守する必要があります
  • プロジェクトの技術。例えば：WebとWindowsアプリを同じ方法でテストすることはありません
  • クライアントの要件（毎日の詳細なレポートが必要な場合もあれば、ハイライトのみが必要な場合もあります）
  • 従ったプロセス（アジャイルと従来のテスト、スクリプトテストと探索テスト）

このリストは網羅的なものではなく、私と同じように、各プロジェクトには多くの変数があることをご存知でしょう。

コンテキスト駆動型テストとは、業界で認識されている標準的な「テスト」ではなく、これらの状況でテストの実践、手法、さらには定義を決定することです。 ベストプラクティス' 。

さて、これらが私がプロジェクトAのために取り組んでいる詳細であるとしましょう：

  • 私は5〜4人の新参者と1人の経験豊富なテスターのチームと協力しています。
  • 文書化された要件はありません。
  • 私のチームはインドにあり、開発チームは米国にいるので、反対のタイムゾーンで作業します。
  • クライアントは毎日の詳細なステータスレポートを望んでいます
  • MantisやBugzillaなどのWebベースのバグ追跡ツールを使用しています。これですべてです。
  • テストの文書化のために、10日間で2ラウンドのテストを3日間行う必要があります

大まかなゲームプランは次のとおりです。

1） チームにはたくさんの新参者がいるので、たくさんのピアレビューが必要です。

2） また、BAおよび開発チームとの要件ディスカッションミーティングが少なくとも2回必要です。チームは他の場所にあり、質問をしてチームに近づく余地がほとんどないため、これは正式なものでなければなりません。

3） これは、ドキュメントの積極的なテストタイムラインです。私たちが書くドキュメントが多ければ多いほど、必要なレビューも多くなり、これはより多くの時間に相当します。したがって、最小限のドキュメントを保持する必要があります。メインだけを文書化するつもりです エンドツーエンドのTC 残りは 探索的にテスト済み 。

4） テスト実行中の毎日のステータスレポートが作成され、毎日EODが送信されます。

5） ほとんどのテストは探索的であるため、実行されるすべてのテストの概要を簡単に説明するように時間をアドバイスしてください。このようにして、何がテストされ、何がテストされていないかがわかります。

6） 欠陥はMantisにリアルタイムで報告されます。チームは別のタイムゾーンで作業しているため、説明が必要な場合に備えて、QAチームから連絡が来るまで1日待たなければならない場合があります。したがって、便利なチームで毎日電話をかけ、QAチームがバグの再現を実演します。そうすれば、待ったりフォローアップしたりする必要がなくなります。

等々。

全体的な戦略が決まったら、これらのポイントを説明する基本的なテスト計画を作成します。これで、慎重に検討し、成功のための戦略をカスタム作成した後、テストプロジェクトに取り掛かる準備が整いました。

要約すれば：

これは コンテキスト駆動型テスト。あなたの状況（標準ではない）をあなたのテスト戦略の主要なインプットとインフルエンサーにします。 それは私たちに周りを見回してあなたの周りのすべてを考慮に入れるように促します。

個人的には、この概念が大好きです。なぜなら、テストの実践は厳格で模倣に基づいていると見なされることが多すぎるからです。誰かがそれをして成功したので、私もそれをするつもりです。これは、人々がテストのキャリアに挑戦し続けることを怖がらせるようなイメージです。

しかし、創造的思考、分析スキル、および意思決定には十分な余地があります。詳細については、上記のリンクでトピックを読んでください。

幸せなコンテキスト駆動型テスト

推奨読書

^