はじめに

皆さんこんにちは。GC編集部です。Webサービス系の企業に務められている方は単体テスト、結合テスト、受け入れテスト、等一度は聞いたことがあるかと思います。ただ、「テストレベル」という言葉だといかがでしょうか。テストレベルとは、まさに単体テスト、統合テスト、システムテスト、受け入れテストを意味しますが、この関係性を正しく認識出来ているでしょうか。また、QAチームという組織が社内に存在した場合、QAチームはどのテストレベルまでを担当とすべきでしょうか。本コラム記事では、テストレベルとはなにか、と組織におけるテストレベルの分担に関して記載させていただきます。ソフトウェアテストに対して何らかの関心がある方、ソフトウェア/システムの品質に思うところがある方はぜひご一読ください。

テストレベルのすゝめ

ソフトウェアテストは本当に色々な種類があります。そのため、ソフトウェアテストについて勉強しよう、と本を買っても、自分がほしいソフトウェアテストの情報までたどり着けないということはソフトウェアテスト初学者のあるあるです。

ソフトウェアテストについて知りたい方の属性は大きく分けて2つの分類が出来ると思います。1つめはソフトウェアテストの設計技法が知りたい方です。この場合、シチュエーションとしては、実際に自分がソフトウェアテストを行うことになったとき、さて、どのようにソフトウェアテストを設計したらよいか、そう考えて本屋に出向く、職場でいきなりホワイトボックステストやって、と言われてAmazonでホワイトボックステストの本を調べる、そんなシチュエーションが考えられます。

次に、ソフトウェアテストの全体的なイメージが知りたいという方が一部いらっしゃるのではと思います。将来を考えたときの一つの選択肢として、ひょんなことからソフトウェアテスト業界に足を踏み入れられた方、知らず知らずの内にソフトウェアテスト関連の業務にアサインされてしまった方などなど。まずはソフトウェアテストの全体を知りたい、そんなふうに思う方がいらっしゃるのではと思います。

今回お話させていただくテストレベルの話は特に後者、つまりソフトウェアテストの全体を知りたい方にまずは学習いただきたい内容です。

なぜなら、テストレベルとはソフトウェアテストをある観点のもと整理したものだからです。分野横断的に議論が行われるソフトウェアテストを1つの切り口として理解できるようにサポートしてくれる考え方こそがテストレベルなのです。もちろん、テストレベルの考え方を学ぶことはソフトウェアテストの全体像を学びたい方だけではなく、ソフトウェアテストの設計技法を学習されようとしている方向けにもおすすめな内容です。自分がどのテストレベルの設計技法を知りたいのか理解することはソフトウェアテスト設計技法を理解するためのはじめの一歩とも言えます。なにより、ソフトウェアテストの設計技法の説明は多くの場合、テストレベルによる分類をベースとした説明となっているので、実際はテストレベルについて理解していないままでソフトウェアテストの設計技法を習得することは至難の技です。

長々とお話してしまいましたが、まとめると、テストレベルを理解することは、ソフトウェアテストにこれから関わろうとする方すべてに対しておすすめの第一歩ということです。

テストレベルとは

さて、本題のテストレベルの説明に進みます。テストレベルとは、系統的にまとめ、マネジメントしていくテストの活動のグループである、とISTQBのシラバスに定義されています（JSTQBによる翻訳版から引用［1］に記載）

この定義だけでは意味を理解しにくいので、具体的なテストレベルをみていきたいと思います。

具体的なテストレベルとして最もよく知られているのが、単体テスト、統合テスト、システムテスト、受け入れテスト、の4つです。

※以下のそれぞれ語句の説明はソフトウェア品質知識体系ガイド (第 3 版) －SQuBOK Guide V3－の説明から引用し、記載しています（[2]に記載）。一部改編のものも含みます。

まず単体テストは英語ではUnit Testと言われ、頭文字を取ってUTとも表現されます。単体テストではモジュールやクラスなどが独立してテストが実施可能な部分をテストされます。プログラムを対象として行われるテストです。つまり、単体テストは開発者（プログラマ、エンジニア）が行うテストと言い換えることもできます。

統合テストはIntegration Testと言われ、頭文字を取ってITとも表現されます。単体テストでは検証できないモジュールやクラス間のインターフェースをテストします。統合テストも対象はプログラムを含んでおり、加えてデータベースやシステム要件にも踏み込んだようなテストになっているとご理解いただけたら良いと思います。そのため、統合テストも開発者（プログラマ、エンジニア）が行うテストであるとご理解いただけたらと思います。

そしてシステムテストは文字通りSystem Testの頭文字でSTと表現され、システム全体のテストを行います。このテストレベルでは、機能の組み合わせに着目したテストやパフォーマンスなどの非機能要件に対するテスト、ビジネスプロセスやユースケースへのテストも含まれてきます。

さて、ここで少し専門用語が多く出てきたので解説させていただきます。 特に重要なものは「機能」、「非機能」です。

「機能」と「非機能」とは

「機能」とは、実際にそのソフトウェアで成し遂げようとしているものを意味します。言い換えると、ビジネス仕様と言われたりもします。決済アプリを例にすると、そのアプリで決済出来ることは「機能」の1つであると言えます。

「非機能」とは、あるソフトウェアを成り立たせるための「機能」以外の部分です。決済アプリを例にすると、そのアプリで決済出来ること、はプログラムによって成り立ちます。ただ、裏のサーバーの動作、データベースの保存容量は「機能」とは明らかに異なるもののデータベースの保存可能容量が充分でないと正しく決済を行うことが出来なくなるため、ソフトウェアを成立させるために重要です。こうした、「機能」ではないが、そのソフトウェアの動作に必要不可欠な要素として「非機能」が存在するのです。

「機能」と「非機能」から考えるテストレベル

さて、テストレベルに話を戻します。

システムテストはシステム全体のテストです。これは、システムの「機能」、「非機能」全体のテストをするという意味合いです。決済アプリの例でいうとその決済が出来るという機能をサーバやデータベースなどの動作も込みでテストするということです。

次のテストレベルは受け入れテストです。受け入れテストはAcceptance Testといわれ、頭文字を取ってATと表現されます。顧客やユーザーによってシステム全体や一部、および非機能要件に対するテストを実施します。受け入れテストには、ユーザー受け入れテスト、運用受け入れテスト、αテストやベータテストなどの種類があります。

受け入れテストの特徴は主体がユーザー（顧客）であるということです。これまでの単体テスト、統合テスト、システムテスト、3つのレベルはいずれも主体は開発者です。ただ、受け入れテストはその主体がユーザーで、ユーザー目線でそのシステム、ソフトウェアが正しく動いているかを検証します。言い換えると、ビジネス仕様が正しく満たされているかユーザー目線で正しく動いているかを確かめているものが受け入れテストと言えます。

さて、それぞれのテストレベルを特徴とともにご紹介させていただきました。

皆様のイメージとしていかがでしょうか。「機能」、「非機能」の話等多少複雑なところがありましたが、大きな枠組としてはまさにレベルとして4つのソフトウェアテストのレベルが存在するということをご理解いただけたかと思います。

単体テストと言われると、どうやら開発現場のプログラムレベルの話をしていることがわかり、受け入れテストと言われると、ユーザーが実際に使用するレベルでのテストの話であることが想像出来ます。

※なお、実際はテストレベルと機能、非機能テストの関係はもう少し複雑です。単体テスト、統合テストレベルで非機能テストが行われることもあることがJSTQB Foundation 第4版シラバス2018対応に記載されています[3]。

では実際にテストとして実行される場合、どのようなプロセスのもとでそれぞれのテストレベルのテストは行われるのでしょうか。

テストレベルの実行プロセスとテストアクティビティ

テストレベルはそれぞれのテストレベルの中で計画、設計、実行、修正が存在します。例えば、単体テストの中でも単体テストの計画、設計、実行、修正が存在し、統合テストは統合テストで統合テストの中で計画、設計、実行、修正が存在するという意味合いです。

最初のテストレベルの定義に戻ります（ISTQBの定義のJSTQB翻訳版より記載[1]）。

“テストレベルとは、系統的にまとめ、マネジメントしていくテストの活動のグループ

つまり、テストレベルは、それぞれのテストレベル1つ1つに計画、設計、実行のプロセスがそれぞれ存在するということです。

最初にテストの設計を学びたい方もまずテストレベルから勉強したほうがよいとお伝えした理由はここにあります。 単体テストにおいても設計が存在し、システムテスト、受け入れテストにおいても設計が存在するため、テストの設計を学びたい場合も自分がどのテストレベルの設計を行いたいかきちんと理解する必要があるのです。

この前提は中々自分一人で学習する中ではたどり着けないのではと思います。

テストレベルにおけるQAへの期待範囲

では、次にもう一段階議論を進めたいと思います。

テストレベルはどこまでがQAへの期待範囲でしょうか（QAに関してはこちらの記事をご覧ください）。

QAチームは開発者が担当するような単体テスト、統合テストも実施すべきでしょうか。それとも、システムテストから実施すべきでしょうか。いやいや、QAチームは受け入れテストのみ実施すべきでしょうか。

結論、明確な定義は難しいです。

会社や組織によって期待範囲が異なるというのが説明となります（実際WEBサービス大手企業にヒアリングを行っても回答はそれぞれの組織によって異なります）。

ただ、多くの場合受け入れテストはQAのスコープであり、システムテスト（ST）まで足を踏み入れているケースがほとんどで、組織によっては単体テストの一部を担っている場合もあります。

とりわけ、プログラムコードを書けるほどの技術・知識・経験を持ちながら品質保証の考え方を理解しているSoftware Engineer in Test （SET）の重要性は最近話題となっていますね。

※SETに求められる要件の議論は本記事では割愛させていただきます。

実際QAのスコープを広げることはそのままQAチームの専門性を拡大することなので、理想を掲げることは出来ても現実問題継続的なリソースの確保は多くの組織で難しいのではないでしょうか。

QAチームのスコープの定義がテストレベルの範囲において不明確であるボトルネックは意外と専門性の拡充かもしれない、というのは独り言でありながら、この議論における本質ではとも思っています。

さて、少し含みを残した状態ではありますが、テストレベルの説明は以上とさせていただきます。

これからソフトウェアテストについて学習される方、ソフトウェアテストについて学習している方の学習の一助となることを願っております。

まとめ

※文中にも記載させていただいておりますが、本コラム記事の用語・考え方はISTQB-FL 2018、JSTQB Foundation 第4版 シラバス2018対応、SQuBOK Guide v3から引用しております。

[1] ISTQB（2018）『テスト技術者資格制度 Foundation Level シラバスVersion 2018V3.1.J03』ISTQB. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf（閲覧日：2022年2月10日）

[2] SQuBOK策定部会ほか（2020）『ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3』オーム社.

[3]大西 建児ほか（2019）『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』翔泳社.