こんにちは、yassanです。
今回は「【SE】テスト工程の道しるべ」を紹介します。
新人エンジニアの方がシステム開発のキャリアを歩む上で、最初に担当する工程として最も多いのがテスト工程かと思います。
テスト工程は、V字モデルではおなじみの右側の領域をがっつり占領している工程です。
テストというからには、作ったシステムがちゃんと動くかどうかを確かめる工程であることは、だいたい予想はつくかと思います。
しかし、いざ蓋を挙げてみると、単体テストに結合テスト、 UATやSITなどよくわからない単語がうじゃうじゃ出てきて困りますよね。
（私も大変苦労しました...）
そんなわけで、
「テスト工程について全体像を深すぎず浅すぎずざっくりと知りたい」
このように感じる方も多いのではないでしょうか。
今回は、そのような方に向けて、システム開発のテスト工程の全体像を紹介します。
この記事を読むことで、テスト工程の実践的テクニックが身につく！わけではありませんが、少し情報の整理ができると思います。
V字モデルのおさらい
おなじみのV字モデル。とは言ったものの、やはりさらっとだけおさらいしておきましょう。
V字モデルとは、システム開発に置ける工程（フェーズ）をV字で表現したものです。
コンテンツとしては、その時々に微妙に違いはするのですが、
要件定義→基本設計→詳細設計→開発→単体テスト→結合テスト→ユーザー受け入れテストと言った流れになります。
なぜV字にしているかというと、それぞれの工程が対になっているからです。
例えば、要件定義で決まったことはユーザー受け入れテストでテストされます。
詳細設計で決まったものは単体テストでテストされます。
V字モデルは、このように作り出すものと各テストが対になっています。
対になることで、ドキュメント作成・受け渡しがやりやすく、各メンバーの担当領域もわかりやすくなります。
単体テスト(Unit Test)
V字の最も谷の部分に位置する工程です。
単体テストは、
わざわざ単体テストをする人を用意する場合もありますし、開発者がそのまま単体テストをするケースもあります。
単体テストは、各モジュールが詳細設計で決められた通りに動作することを確認します。
単体テストは、いわゆるホワイトボックステストです。
具体的には、制御フローテストによって、条件を網羅できているかのチェックがされます。
静的解析ツールなども使うと効果的に進められます。
他に、データフローテストも実施します。
定義された変数が、どのように変遷して消滅（出力や解放）するのかをテストします。
当たり前のことですが、ここのテストをちゃんとやっておかないと次にその次にと待っているテストで大きな問題になり手戻り地獄になります。
結合テスト(Interface Test)
結合テストは、モジュール間のデータの受け渡しを実施します。
それにより、基本設計書に書かれた内容が実現できているかの確認をします。
この「モジュール」をどこまでと捉えるのかがしばしば議論になります。
結局のところ、明確な線引きがされていません。
なので、結合テストでどこまでの範囲をテストするのかは、そのプロジェクトによります。
私の体感としては、一つのサブシステムと考えて良いと思っています（なので、後述の機能テストとほぼ同義では...と感じている）
そんな結合テストですが、単体テストと異なり、いわゆるブラックボックステストになります。
モジュール内でどのような処理をしているのかはともかく、入力値と出力値だけを確認します。
入力値と出力値を用意するだけとはいえ、テストケースの洗い出しがなかなかに難しい工程です。
何故ならば、効率良く適切にテストケースを網羅するために、基本設計書だけでなく要件定義の内容から詳細設計書まで目を通しておく必要があるからです。
機能テスト(Functional Test)
システムに求めらている機能が満たせているかのテストになります。
こちらも、結合テスト同様に、ブラックボックステストです。
V字モデルについて知っているならば、機能要件・非機能要件についてもなんとなく知っているかと思います。
機能要件とは、まさにシステムで実現したいことそのものです。
どのようなことを実現したいかは、要件定義で明らかになっていますし、
システムでどのようなことができれば要件が満たされるかは、基本設計書に記載されています。
それらを適切に汲み取り、ユーザーの立場に立って機能が実現できているかをテストします。
非機能テスト(Non-Functional Test)
システムに求められている機能ではありませんが、満たさなければならない要件を満たせているかのテストになります。
回りくどい言い方をしてしまいましたが、そもそも非機能要件について知らない人はささっとgoogle先生に聞いてみてください。
非機能テストは、サーバーを複数用意して一台をわざと落としたり、非常に素早い操作や放置など、異常系と呼ばれるテストが多いため、実施するのはなかなか大変です。
（クラウドにのってるシステムとかなら比較的楽ではあるんですけど、オンプレならなおのこと大変かと）
また、非機能要件はプロジェクトによっては正解が決まっていない（あるいはお客さんは勝手に思い込みをしていたりする）ので、今一度どのような非機能要件にするのか話し合う必要も出て来るかもしれません。
ただ、なんにせよ非機能要件ですので、機能とは切り離して考えることはできます。
システム結合テスト(System Interface Test)
いわゆるSITと呼ばれるものです。
中規模以上のシステムになると、1つのアプリケーション（システム）でシステムが完成することは少ないです。
複数のシステムと連携しあって1つの大きなシステムとなります。
（複数の会社が関わっている程度の規模になると、このようなテストが発生しますね）
ここでのテストもブラックボックステストです。
データの受け渡しの際に、インターフェースがきちんとできているかをテストします。
ここまで来ると、システム開発もいよいよ本当に終わりが見えてきたという感じがします。
ユーザー受け入れテスト(User Acceptance Tset)
いわゆるUATと呼ばれるものです。
ここは読んで字のごとく、ユーザーに実際にシステムを使ってもらうテストです。
ユーザーにとっては、求めていたものが出来上がったを確認することはもちろんですが、
実際の運用をどうするのか？マニュアルはどのように作るのか？などの課題は残っています。
そのためにも、きちんとUATを行う必要があります。
また、ベンダー側にとっても、ここで不具合や要望を洗い出しておかなければ、
保守や（ベンダー側の）運用にコストがかかってしまいます。
まとめ
いかがでしたでしょうか。
システム開発のテスト工程の全体像を少しでも理解頂けますと幸いです。
ここまで読んでいただき、ありがとうございました。
