この記事はNishi Grover Gargによるゲスト投稿です。
テスターである私たちは、すべてを批評的な目で検討します。何かテストの対象が出てくると、私たちは本能的に調査にとりかかり、問題領域を探し始めます。新人テスターは、ドキュメント化されたテストスクリプトを入手したら、ただちに実行したいという誘惑にかられるでしょう。
しかし、まず立ち止まってどんなテストが可能か考えをまとめるほうが賢いアプローチであり、より良くまんべんなくテスト対象をカバーできるでしょう。ただし、いつもシナリオやさまざまなパスを想定する十分な時間があるとはかぎりません。幸運なことに、どんな場合でもあらかじめ計画を立てておくことができます。以下は、時間に余裕がないときでもテストのアイデアを生み出すための4つのヒントです。
古典的なテスト技術を再考する
境界値分析、同値クラス分割、デシジョンテーブル、ステートフローダイアグラムなどの古典的なテスト設計技術は、テストケースを考える際に常に役立ちます。これらの技術の大半はテスターの思考プロセスに組み込まれており、ほとんど常識となっていますが、簡単にでも改めて検討すれば、さらにテストのアイデアを得られるかもしれません。
たとえば、2つまたはそれ以上の変数の相互作用について簡単なデシジョンテーブルを作成し、システムの動作を確認すると、見逃していたかもしれない特殊な組み合わせを発見できる可能性があります。あるいは、フォームの年齢フィールドに対して簡単な境界値分析を行うと、見逃していた可能性がある特別なケースが見つかるかもしれません。
同様に、エンドツーエンドのフローを状態遷移図にすると、テスターだけでなく、開発者がシステム全体のフローを頭に描き、問題領域を明らかにするのに役立つ可能性があります。
履歴を見る
プロジェクトまたはシステムの履歴は、テスト対象について、一般的な欠陥クラスターが存在する場所について、また最も問題が多いコンポーネントについて多くの洞察を与えてくれます。
テストチームに入ったばかりの場合、過去のスプリントまたはリリースの欠陥追跡記録を見ることから始めましょう。そうすると、過去の欠陥や最も欠陥が多かったコンポーネントに基づいて、より多くのテストケースを考え出すことができます。
以前からチームに所属している場合、おそらく直感的にそういった領域に注目しているでしょう。それでも、経験に基づいて、最もよく発生したバグのタイプや最も問題が多かった領域を意識的にリスト化するのは有益です。そうした作業は、自分だけでなくチームの新しいメンバーや経験が少ないメンバーにも役に立ちます。
欠陥分類を利用する
ログインフィールドやEコマースのショッピングカートなどの一般的なコンポーネント、あるいは単純なクライアントサーバー連携などは、多数のシステムに組み込まれています。結果として、そういったコンポーネントは世界中で何度も設計・開発・テストされているため、すでに出来上がった欠陥分類やチェックリストが存在し、同様のシステムコンポーネントを初めて開発するチームにとっても有益である可能性があります。他の人たちがオンラインでシェアしている経験を利用するのは賢いことです。
そのような欠陥分類は構築中のコンポーネントの機能的あるいは非機能的側面に関する一般的な問題を知るのに役立ちます。欠陥分類を利用してより多くのテストアイデアを生み出しましょう。時間が経つにつれて、自身のプロジェクトの欠陥分類を作成してチーム内部で共有することもできるかもしれません。
探索を広げる
システムを検証する方法を見つけるのに、実際にやってみるより良い方法はありません。システムを動かし、探索を広げることで、システムが何をしているか、さまざまなパスでどのように動作するかを理解し、特殊なフローを試してみましょう。多くの場合、以前のテスト設計では見逃されていた可能性のあるシナリオやフローに行き当たるでしょう。さらに問題や新規の動作の探索を続け、テストケースに加えましょう。
時間に追われる状況になったとき、上記のヒントを試してより良いテスト間をすばやく生み出しましょう。
Nishiは企業トレーナー、アジャイルの信奉者、そして根っからのテスターです。業界で13年以上の経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニングヘッドとして働いています。トレーニングに情熱を注ぎ、テストコミュニティイベントやミートアップを主催したり、多数のテストイベントやカンファレンスで講演を行っています。アジャイルおよびテスト分野での最近のトピックを取り上げたブログをご覧ください。
（この記事は、開発元Gurock社の Blog 「4 Ways to Generate Quick Test Ideas」2021年1月21日の翻訳記事です。）
