前回、テストをDeveloper Testing、Customer Testing、QA Testingの3つに分類しました。ここまでで何か質問はありませんか？

担当からの質問

「受け入れテスト」というのはCustomer Testなんですか？

はい、そうです。

テストというと、よく「○○テスト」という言葉を聞くと思います。たとえば「受け入れテスト」以外にも、「⁠ユニットテスト」「⁠単体テスト」「⁠機能テスト」「⁠結合テスト」など、いろんな何々テストという言葉があります。質問にお答えする前に、まずテストの分類に対する視点を整理しましょう。

テストの分類に対する視点

「ユニットテスト」「⁠単体テスト」「⁠機能テスト」「⁠結合テスト⁠」⁠。

これらテスト対象の範囲を基準にしたテストの分類は、狭間の領域、グレーゾーンができてしまいます。実際には何なのか、何を示すのかわかりにくい場合があると考えています。

ですから私がこの連載で説明しているテストの分類法は簡単に言うと、テスト範囲での分類ではなくて、目的別の分類なんです。何のためのテストかという視点によって、Developer Testing、Customer Testing、QA Testingの3つに分けましょうということです。より正確にいうと、目的と、実行者と、受益者です。「⁠誰が、何のために、誰のために」行うのかという視点で、錯綜してしまったテスト分類を見直してみましょうということです。

受け入れテスト

さて、質問のあった「受け入れテスト」です。

受け入れテストというのは、たとえばそのテストが通ったことによってお客さまに検収印をいただくとか、そのテストが通ったことによって実際に望んだ機能が達成されています、もしくはこのプロジェクトは完了ですということが証明されるようなテストのことをいいます。

言うなれば受け入れテストとは進捗管理のためのテスト。プロジェクトのためのテストです。だから私は受け入れテストをCustomer Testingのカテゴリに入れています。

単体テスト、ユニットテスト

次に「単体テスト」「⁠ユニットテスト」について考えてみましょう。

単体テストという言葉が指し示すものは非常に揺らいでいるので難しいところではありますが、単体テストだとかユニットテストと私たちが呼んでいたものは、基本的にはDeveloper Testingにカテゴライズされます。

単体テストとかユニットテストは、私たちがプログラムを書く際に、自分たちが書いているプログラムに対するテストのことを指します。テストの対象は、1クラスのテストや、もしくは1メソッドのテストです。私たちは日々そういう狭い領域に対するテストをユニットテストもしくは単体テストの形でやってます。テストを実行するのは開発者自身であり、受益者も開発者自身ですので、これは明らかにDeveloper Testingに入ります。

結合テスト、機能テスト

「機能テスト」では、ある機能がきちんと動作するかどうかをテストします。その機能を達成するためには複数のクラスの強調動作が必要であることが多いため、テストのスコープはユニットテストより広くなります。

「結合テスト」では、よりスコープを広くとり、サブシステム間の連携まで含めてテストします。たとえば、ステムがクライアントとサーバに分かれているときにサーバから返ってくる結果をクライアントが描画するところなども含めてテストを行います。

では、「⁠結合テスト」「⁠機能テスト」はどこにカテゴライズされるのでしょうか。

結合テストや機能テストは開発者のためのテストだという視点を私は持っていますので、Developer Testingに入ると考えています。たとえば、インフラレベルを先にテストするという状況を考えてみましょう。テストに使うデータはテスト用に開発者が自分で作成したものを使い、クライアントとサーバの通信機能だけをテストする目的で行うテストを考えます。この場合、実行者は開発者、そして受益者も開発者ですね。

なぜCustomer Testingにカテゴライズされないのかというと、お客さまの望むものは、その結合テストが通った上で、お客さまに提供する機能にあると考えているからです。結合テストが通ることと、お客様の望むシステムになるかどうかは別の話です。お客さまに対して望む機能を提供できるかという視点のテストが「受け入れテスト」と呼ばれると考えていますし、その視点が、Customer Testingにカテゴライズされる条件だと思っています。

Developer TestingとCustomer Testingは機能要件に対するテスト

ここまでを整理しましょう。

今説明してきた「○○テスト」は、いずれもDeveloper TestingやCustomer Testingに分類されました。

Developer TestingやCustomer Testingは「機能要件に対するテスト」です。お客さまがやりたいもの、もしくは私たちプログラマがお客さまの機能を満たすためにはどういうものを作らなきゃいけないか、そのような視点に基づいて書いていくテストです。

その際に、テストを進捗管理の入力情報とするのがCustomer Testingですし、開発を促進していく際にテストを自分たちへのフィードバックとして回していくのがDeveloper Testingです。

QA Testingは非機能要件に対するテスト

Developer Testing、Customer Testingとはまたぜんぜん別の視点のテストがQA Testingです。

QA Testingは「品質保証のためのテスト」「⁠非機能要件に対するテスト」です。非機能要件とは、たとえばレスポンスは1秒以内になされなければならないとか（パフォーマンスですね⁠）⁠、連続で30日間以上動き続けなきゃならないとか（堅牢性ですね）です。

ではそういった非機能要件はDeveloper TestingやCustomer Testingの視点でテストできるのかというと、できないものが多いと考えてよいと思います。望んだとおりの答えを返すけれど、動作スピードがすごく遅いというのでは、お客さまは満足しないこともあるからです。Customer TestやDeveloper Testは「こういうことをしたいね」とか「こういう機能が欲しい」といった視点からのテストなんです。

対照的にQA Testingは、「⁠システムがかくあらねばならない」とか「こうあってはならない」という視点です。たとえば、レスポンスが遅くてはならないですとか、セキュリティ上の弱みがあってはいけないですとか、そういった、あえて言うなら「もっとシステムをいじめる視点」です。

QA Testingとは、それに合格しなければ、たとえ機能を満たしていたとしても、そのソフトウェアはソフトウェアとしてお客さまにお渡しするわけにはいかないというような視点を持ったテストのことです。

QA Testingはこれまで説明したような特徴を持っているため、開発者本人ではなく品質保証専門のチームが行うこともあります。大きめのプロジェクトでは品質保証の専門のチームが編成されていて、その品質保証のチームが開発チームが書いたコードに対して、どんどん品質保証の側面からテストを行っていきます。たとえば、大量のリクエストをサーバに送るようなテストを行うかもしれませんし、セキュリティ上の攻撃を行うかもしれません。