この記事はNishi Grover Gargによるゲスト投稿です。

新人テスターが基礎を学ぶとき、とても大切なことを忘れがちです。新人がテストケース設計を重視するよう教えられることはめったにありません。結果として、テスターはほとんどテストについて考えることなく、いきなりテストにとりかかります。必要最小限の概略だけを書きつけて、すぐさまテストに進んだあげく、せっせとアプリケーションをクリックすることに大半の時間を費やします。

テストケースの作成は、有効なテスト設計技法と合わせて、経験、創造性、枠を超える思考を要求する技術です。

以下に、テストを始める前に、よりよく有効なテストケースを考え、作成するためのヒントを挙げます。

テスト設計技法

もちろん、私たちは境界値分析や同値クラス分割を知っています。テストでエッジケース（稀に起こる問題）を考慮したこともあったかもしれません。しかし、実際のプロジェクトにおいて、どれだけこういったテスト設計技法について考えてきたでしょうか? 

デシジョンテーブルは、要件をよりわかりやすく表現したり、コードのアーキテクチャを設計したり、可能性のあるすべてのシナリオをテストする計画を立てたりするのによい方法です。アプリケーションの中で、デシジョンテーブルを作成できるような領域を探しだすと、自分のためだけでなく、プロダクトマネージャーや開発者のためにも役立ちます。

テスト対象のアプリケーション全体、または特定の複雑な部分について、状態遷移図を作成するのもよいでしょう。すると、潜在的な問題や、到達できない状態や、処理されていない領域を見つけられる可能性があります。

テストを設計するとき、システムが何を期待し、何を受け入れないかについて、UI オプション以外にも目を向けるようにしましょう。より広く考えましょう。まず全体を見渡してから、個々の詳細を調べましょう。実証済みの確立された技法をテスト設計に活かしましょう。

履歴と経験

ソフトウェアに関する経験を新しいテストの設計に活かします。ある程度長く関わっているソフトウェアであれば、よく問題の原因になるものや、どんなエラーが起こるかについて身をもって学んでいるでしょう。

プロジェクトに後から参加した場合は、バグトラッキングシステムで過去のバグとその解決策を見ることで、ソフトウェアの履歴を学びます。そうすると、問題になりやすい領域や、バグ密度の高い機能や、よくある問題のタイプを把握できます。 

新機能や機能拡張のテストケースを設計する前に、機能に関連する問題を調べ、履歴を考慮することを習慣にします。そうして作成されたテストケースは、テスト実行時にバグを特定するのに役立つことが多いものです。

関連領域

特定の機能をテストするときは、機能自体に集中しがちで、既存の他の機能との統合に重点が置かれることはほとんどありません。

たとえば、以前はアプリケーションにただ表示するだけだったところに、実行レポートを Excel ファイルとしてダウンロードする機能を新たに追加したとします。この新機能のテストでは、レポートをダウンロードし、開き、任意の場所に保存できることが確認されました。

しかし、レポート設定を変更し、別のパラメーターでレポートをダウンロードした場合はどうなるでしょうか? 以前は、レポートには行数などの制限はありませんでした。しかし、Excel にダウンロードするようになった今、Excel の最大行数を超えるレポートを生成し、ダウンロードしようと試みた場合、どうなるでしょうか?

製品に新機能を追加するたびに、他の既存領域との統合について検討する必要があります。可能なテストをもれなく作成し、新機能が他の機能を損なわずに正しく動作することを検証できるようにします。検証を容易にする方法として、新機能を設計するとき、関連する領域や影響を受ける領域の一覧も作成すると、よりよいテストを設計するための参考資料として利用できます。

創造性

最後に、テストの一部はただテスターの思考と創造性に委ねられます。アプリケーションの探索に時間を費やす中で、既存の枠を超えるテストシナリオを思いつくこともあるかもしれませんが、より早期に枠を超えた思考をめぐらすことで、テスト設計時からより創造性の高いテストケースを作成できる可能性があります。

たとえば、ユーザーがファイルをアップロードする機能をテストするとします。正しいタイプのファイルをアップロードする、サポート対象外のファイルタイプを却下する、サイズが大きすぎるファイルに対して警告する、等のテストは必ず行うでしょう。

読み取り専用のファイル、書き込み禁止のファイル、あるいは読み取り禁止のファイルをアップロードしようとした場合はどうなるでしょう? 空のファイル (0 MB) または隠しファイルをアップロードしようとした場合は? このようなシナリオで、システムはどのように動作するでしょうか? ファイルは受け入れられるでしょうか、それとも予期しないエラーが発生するでしょうか?

こういったテストケースによって、普通より一段上のテストが可能になります。このような思考をめぐらすことで、システムとその弱点および内部的な動作に関する認識がより明確になります。

まとめ

テストの設計に時間をかけましょう。テストにより多くの思考を注げば、それぞれのテストの価値が高くなります。そうして作成されたテストケースは、非常にまれなバグを発見するでしょう。また、テスターの経験を広げるとともに、ソフトウェアの品質を向上させるでしょう。

Nishiは企業トレーナー、アジャイルの信奉者、そして根っからのテスターです。業界で13年以上の経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニングヘッドとして働いています。トレーニングに情熱を注ぎ、テストコミュニティイベントやミートアップの主催、多数のテストイベントやカンファレンスで講演を行ったりしています。アジャイルおよびテスト分野での最近のトピックを取り上げたブログをご覧ください。

（この記事は、開発元Gurock社の Blog 「Tips for Writing Effective Test Cases」2021年9月15日の翻訳記事です。）