筆者は、テスターが創造性を発揮するやり方が望ましいと考えている。テストの目的がテストケースで最も重要な側面であると思うからだ。テストデータを具体的に指定する理由があるのでなければ、すべてのテストデータを可変要素として指定する方法を筆者は好む。テスターが新たなアイデアを思いつき、異なるテストデータでテストすることが望ましいと考えているからだ。

　テストケースを指定通りに実施する必要がある場合と、テスターに創造性を発揮してもらいたい場合を明確化すること。つまり、添付したテストデータが指定通りに使用される必要がある場合と、テスターが異なる値を試すことができる場合を明確化するということだ。筆者はテストデータが可変要素であることを明確に示すために、変更可能なテストデータをカラーで強調したことがある。

　コンテンツも考慮すべき事柄の1つである。誰がテストケースを使用するかが分かれば、テストケースの説明のトーンや詳細を決めやすい。では、コンテンツの詳細はどのように決めればいいのだろうか。規制を受けた環境の中でテストを行い、テストする製品が監査の対象になるのであれば、選択の余地はない。指針となる手順に従い、要求された事項を順守しなければならないのである。規制を受けず、急速に変化する環境の中でテストを行うのであれば、詳細な手順を示したテストケースは融通が利かないので、更新しにくかったり実用性に欠けるなどして、使い捨てになってしまう恐れがある。テスト環境の状況およびテスト対象となる製品も、考慮すべきファクターなのだ。また、テスト実施経験および対象となる製品に関する経験の両面において、テストチームの経験レベルを考慮する必要もある。

　フォーマットも考慮すべき事柄の1つである。ただし筆者は個人的には、フォーマットはそれほど重要ではないと考えている。テストケースの要はコンテンツであり、フォーマットではないからだ。しかしテストケースを保存するツールを購入し、そのツールを使わざるを得ない人もいるかもしれない。あるいは、テストケースはWordやExcelまたはTestDirectorで記述しなければならないといった指針を定めている企業もあるだろう。筆者は、フォーマットがテスターにとって実用的であることが望ましく、テスターの仕事を増やしたり、ソフトウェアをテストするという最終的な目標を見失わせたりするものであってはならないと考えている。

　最後に考慮すべき事柄として、テストケースのランク付けが挙げられる。テストケースが多くなってくれば、テストケースのメンテナンスも重要な要素となる。テストケースの作成を重ねる中で、製品およびテストケースが時とともに進化するということが理解でき、テストケースをランク付けしようと考えるようになるだろう。ここで言うランク付けとは、必ず実施しなければならないテストケースと、比較的重要度が低いテストケースを決めることを意味する。テストケースが各リリースのリグレッションテスト用に設計されており、そのテストケースが重要な機能をカバーしているのであれば、そのテストケースのランク付けを検討することが望ましい。

　筆者は以前、各テストケースを1～3のレベルに分類することによってランク付け問題を解決した。レベル1のテストケースは基本的な機能をチェックするものであるため、各ビルドごとに実施する必要がある。レベル2のテストケースは製品の機能変更に基づいて選択し、レベル3のテストケースはリグレッションテストスイートをすべて実行するときに使用するようにした。一般的には、各製品リリースごとにすべてのテストケースを評価し、実施の優先順位を見直すことになるだろうが、テストケースの開発を重ねていけば、現在のリリースだけにフォーカスするよりも、製品全体に対して各テストケースがどの程度重要であるか考えるようになるだろう。

　以上を要約すれば、まず、実用性と再利用性を重視することである。また、利用者に応じて、テストケースを詳細に記述する必要がある。各テストケースの目的を明確化するとともに、添付されたテストデータは「そのまま」使用するのか、それともサンプルとしてテストデータを示しているだけなのかを明記する。そしてメンテナンス可能なフォーマットを使用すること。