フェーズ、レベル、タイプ、技法

機能テスト、制御フローパステスト、システム統合テスト、ビルド検証テスト.....

これらは、用語の最後に全部「テスト」がつくので同じ類いのことを指しているように聞こえますが全く違う概念です。

ソフトウェアテストがわからないとか、やっていてわけがわからなくなるという人がいますが、この全く違う概念の区別がつかないのが大きな原因なのではないかと思っています。

この件をわざわざnoteに書こうと思ったきっかけは、このにしさんツイートがとっても的確で素晴らしかったからです。

このツイートのきっかけは、シナリオテストが技法なのかテストタイプなのか？という問いかけでした。

「シナリオテスト」って、JSTQBの定義では技法です。けど、実際の現場では、テストタイプとして使われる時もあれば、テストレベル、またはテストフェーズとして使われることがあります。これは「機能テスト」にも言えることです。つまり全く違うことを同じ用語で話すのがテストの混乱するところなのです。

フェーズ、レベル、タイプ、技法の定義

〜テストは大抵以下の概念のどれかをさした用語として使われます。

テストフェーズ

テスト実行の日程をグルーピングした単位です。管理をする上では、「◯月◯日からXXテストを開始します。△月△日に終了予定で、その後から□□テストをします。」と言った感じにWBSを書いて進捗を追うと言ったことをしたくなるし、それが実際やりやすいです。

テストレベル

テストレベルは、Vモデルでいう開発の段階的詳細化と対になるテストの段階的詳細化です。と言ってもテストは詳細なものから大きなものになっていくので、段階的統合とでも言った方がよいかもしれません。いわゆる、ユニットテスト、インテグレーションテスト、システムテスト、システムインテグレーションテストと言ったものです。テストレベルは、テストベースが異なります。ユニットテストはメソッドレベルの設計書であり、システムインテグレーションテストは業務レベルの記載がある要件定義書になります。ただ、これはプロジェクトの開発の仕方に依存します。

それぞれのテストレベルは、似ていることと似ていないことがあります。テスト実行のやり方、テスト環境、テストデータのどれかが一緒になることもある、といった感じです。

テストレベルを分ける際に明確に区別すべきはテストアイテムです。ユニットテストは関数やメソッド、機能単体テストであれば画面やバッチ、統合テストであればI/F、システムテストで言えばフィーチャや業務フローといった感じで、テスト対象をどういう切り口で見てるかを明確に分けるべきです。なぜならこれが網羅の母数になるからです。

テストタイプとテスト技法

これはにしさんが書いた通りです。強いていうと、テストレベルの中には複数のテストタイプが含まれます。システムテストでは、機能テストも行うが性能テストも行うと言ったように複数のテストタイプが入ることがあり得ます。

技法は、テストタイプに複数入ることがあります。

なぜ違う概念で同じ言葉を使うのか

それこそウオーターフォールの開発のように、ユニットレベルのテストが全て完了し、終了基準をクリアしてからインテグレーションテストをするという日程でテストを進める場合、テストレベルとテストフェーズはイコールになります。違うことを同じ言葉で話しても問題になりません。これが同じ言葉を使う理由です。同様に機能テストは一般的にはテストタイプですが、テストフェーズとして機能テストだけをやる期間をスケジュールすればそれはテストフェーズになってしまいます。

何が問題なのか？

テストレベルとテストフェーズを例にします。イメージして欲しいのは、ある程度大きな規模のテストです。自分たちで開発しているシステムは外部の5つのシステムとインテグレーションして動くシステムであり、システムテストの際には、全部を繋いでいるとします。バッチもジョブフローに組み込まれていて、その通りに動きます。そこでシステムテストのテスト担当者は30人ほどいます。システムテストではこれらがつながった状態で業務シナリオが期待通りに遂行できることをテストしていることを想像してください。

システムテストになってから、テスト漏れが見つかった場合、そのテストケースを追加してテストをします。しかし、そのテスト漏れが、例えば、ある画面のフィールドのバリデーションチェックだった時は、そのテストは機能単体テストなのです。システムテストとはテストレベルが違います。ただ、フェーズの名前もシステムテストだとすると、確かにこの時期はシステムテストです。

ここで2つの概念は違うのですが言葉が一緒なため一緒に考えてしまう可能性が出てきます。

テストの網羅性が管理できなくなる問題

まずテストケースがシステムテストのテストケースとして扱われてしまう場合があります。そうなると、システムテストの本来の目的とは違うテストをやることになってきて、「全部テストする」話が収集つかなくなります。なんでもシステムテストでやりだすとシステムテストが終わらなくなります。色々気になる人たちは良かれと思い、「このテストはしたか？あのテストはしたか？」と言ってテストを追加しようとします。これを目的が異なると言って突っぱねられないとテストがどんどん増えていきます。突っぱねるのもなんなんですが、少なくとも単体テストの延長としてやってもらうとか、分けないといけません。分けないでテストしていると今度は細かいことを知らないエライ人が数字だけ見て全部終わったかどうか？とか話をしてきて、なんでテストが増えるんだとか言ってきたりすると、その数字をちゃんと整理するのが大変になって来て更に混乱します。

テスト実行遅延の問題

次にテスト環境の問題もあります。システムテストはシステムテストをするために最適化された環境を用意しています。そこで、細かいことをテストしだしていると、テストデータが想定とは違う状況になってしまいます。またテスト実行のスケジュールにも悪影響が出ます。スケジュールが遅れたりすると、またしてもPMOのような人たちが来て、日程と進捗だけでその改善を迫って来ます。またその対策とか言ってマイクロマネジメントしてくると、更に面倒になります。

本来はどうすべきか

テストフェーズはシステムテストだとしてもテストレベルがシステムテストではない場合は、テストケースは単機能テストとして管理して、テスト実行も単機能テストができる環境でテストを行い、テストされたモジュールをシステムテスト環境にデプロイするのが本来の姿なのですが、これがわからなくなってしまう、これが問題なのです。

たかが用語されど用語

なので、なんて言葉を使うかは関わる人たちが共通の認識でテストをするのが大事なのですが、違う概念に同じ言葉を使うとそれがすごく難しくなるのが問題です。

なので用語の定義はちゃんとしようという話でした。JSTQBは役に立ちますよ！（宣伝ww）