VSTS: テスト

そもそも最近は、旧来の「テスト」という言葉からあいまいさを取り除き、より効率的に、より管理しやすくするために、言葉を再定義する流れがある。漫然と「テスト」とだけ言ってしまうと、以下のような意味のどれだかわからないわけである。

• テストケース
  • どのような機能を、どのような観点で、どうやって実行するか、結果をどう判定するのか、などの内容。
  • 手作業でおこなう場合は手順書などで表現する。自動化したものは、まさにJUnitやNUnitのテストケースであったりする。
  • VSTSではテストプロジェクトの構成要素となる。

• テスト実施
  • テストケースを実際に実行して結果を得ること。いくつかのテストケースをまとめて一度に実行することも多い。
  • テストを実施したときの日時や、対象のバージョン・ビルド番号、実施した人・環境、などの情報を持つ。
  • テスト結果を産み出す。
  • VSTSでは、テストの実行が相当する。手作業のものも自動実行のものもまとめて。

• テスト結果
  • テストを実施したときの、テストの実行結果。単純にはOK/NGだったり、画面やらログやらダンプやらのエビデンスがついていたりもする。
  • どのテスト実施の結果であるかが重要。
  • 複数のテスト実施からサマリを取ると、QAな人が喜ぶ統計情報が得られたりもする。
  • VSTSでは Test Result である。

これらの言葉を使ってテストプロセスを考えると、ざっと以下のようになる。ウォーターフォール的な書き方になっているが、このプロセスをミクロに回せばTDDっぽくなるかもしれない。

1. テスト全体の計画を立てる。
2. テストケースを設計・作成する。
3. テストを実施する。
4. テスト結果をもとに、計画にフィードバックする。

いま回帰テストはあたりまえになっているので、テストケースとテスト実施を分離して作業・管理できないような計画なり手法なりは、致命的に時代遅れであり、プロジェクトの成功という目的に対して無責任である。