テストとは何か
テストって何ですか？
これが意外と難しい．「自動テストでユニットテストをやったり，リリース前にQAをやったりするよ．」とかいう人も多いと思います．
じゃあ，**「ユニットテストと結合テストの区別は何？」「計算結果をファイルに保存する機能だけどこれってユニットテスト？結合テスト？」**みたいなことが往々にしてあります．このあたりをチームで話をしてても，全然かみ合わず，「俺のテストの定義」「今までチームでやってきたテストの定義」みたいなものがあり，じゃあ，それが本当にプロダクトの品質を上げるテストなんだっけ？というところも懐疑的です．
ということで，いろいろな「テストの定義・分類」を複数の書籍・リンクから引用し，「どんなテストの定義・分類があるのか？」を一覧にしてみようという試みです．
それにより，**自分のチームやプロダクトで行っている"テスト"がどれに近いか，抜けているものはないか．というものを振り返ることができるのではないか．**と考えています．
構造化手法からオブジェクト指向まで 図解でわかるソフトウェア開発のすべて
出版年：2000年
| 分類 | 説明 |
|---|---|
| 単体テスト | 単体テストはモジュールを単体で動かし，主に内部ロジックを検証すためのテストで，ユニットテストとも呼ばれます． |
| 結合テスト | モジュールを結合して動かし，全体として正しい機能を備えていることを検証します．ここで結合するモジュールは単体テストが前提になります． |
| システムテスト | システムテストは出来上がったシステム全体の機能・性能を検証するテストです．本番環境にできるだけ近いテスト環境を作り，実務に則したテストケースを作ってテストします． |
| 運用テスト | 運用テストは，顧客が実際に運用してみるテストです．検収テストや受入テストとも呼ばれます． |
自分が学生時代に大学で買った本です．出版年が2000年と古いため，かなりウォーターフォール型を意識した内容になっています．しかし，このテストの定義自体はそれほど違和感のあるものとはなっていません．ただ「システムテスト」と「結合テスト」の境目が分かりにくい．といった問題があります．したがって，「ユーザーをDBに登録する機能を検証する」といった項目があった時，「システムテスト」と「結合テスト」のどっちでやる？といった議論になります．私もこの分類での境目はよくわからないです．
実践アジャイルテスト テスターとアジャイルチームのための実践ガイド
出版年：2008年
出展：http://jasst.jp/archives/jasst10n/pdf/S2.pdf
本自体を読もうと思って読めていないので，細かいことは議論できませんが，かなりまとまった内容になっていると思います．「第1象限」と「第4象限」のテストは割と技術者にはなじみのある部分だと思います．「第1象限」はいわゆる「機能要件」を扱っており，「仕様通り機能が実装されているか？」です．対して，「第4象限」は「非機能要件」です．例えば，サーバーへの同時接続数など，そのプロダクトの限界性能のようなものを扱っています．「第2象限」と「第3象限」は，本読んでからまた書きます(
実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる
出版年：2009年
| 分類 | 説明 |
|---|---|
| 受け入れテスト | システム全体が機能するか？ |
| インテグレーションテスト | 私たちが変更できないコードに対して，書いたコードが機能するか？ |
| ユニットテスト | オブジェクトは正しく振舞っているか？また，オブジェクトは扱いやすいか？ |
一番最近読んだ本です．このテストの分類は非常に分かりやすい形になっています．「ユニットテスト」が担当する範囲は，「自分が書いたクラスのみ」．「インテグレーションテスト」が担当する範囲は，「ライブラリと結合したクラス」．「受け入れテスト」は「システムが全部結合した状態で行うテスト」です．
「ユニットテスト」は例えば，「UserRegisterUseCase」といったドメインレイヤーのクラスに対し，モックを用いたようなテストになります．「インテグレーションテスト」は，「UserDbRepositoty」といったクラスが対象で，実際のDBと結合し，データを保存しているようなテストです．「受け入れテスト」は「POST /usersでユーザーをテストする」といった内容で，APIレイヤーからドメインレイヤー．DBレイヤーまで全て結合したテストになります．
Test Sizes
https://testing.googleblog.com/2010/12/test-sizes.html
公開年：2010年
Googleによるテストの定義です．small, medium, largeといった分類をしています．一番秀逸だと思うのは，この表ですね．文章で説明してしまうと，人によって解釈のぶれが発生してしまい，「結合テストでやるのかシステムテストでやるのか」問題が発生していますが，これにいたっては，そのような遊びが非常に少なく認識の齟齬が発生しにくいです．
感想
あまりこういうことは言いたくはありませんが．「答えはない」ですね．どれが正しいか？というものは，ちょっと聞いただけでは判断できない．という気がします．例えば，規模の小さいソフトウェアで，内容をよく知っているおり，受託開発．といったユースケースの場合，旧来の，「図解 ソフトウェア開発のすべて」の区分で十分だと思います．しかし，一方で．仕様が曖昧で，仕様を理解しながら作る形だと，「実践テスト駆動」の形式が良いと思います．また，それ以上にビジネスとして成功するか？まで広いスコープを取り入れると「実践アジャイルテスト」の区分まで手を広げたほうが良いと思います．ありがちではありますが，「ChaosMonkey流行ってるから入れようぜ！」みたいなことを考えずにやると，品質が低い部分が出てきてしまい，全体として整合性がとれず，結局捨てられることになったりします．ひとつひとつのテスト技法やその内容について知ることも大事ですが，「ユニットテスト」はどの範囲を担当し，「結合テスト」はどこを補填しているのか．といった，品質に対するテストの役割と分類を追うのが大事だと思いました．