2月に「リグレッションテストと他のテストを分けるものは何？」という、哲学的な問いが現れていたので、その疑問には全然答えない記事を書いてみます。
リグレッションテストとその他のテストを分けるのってつまるところ実行回数なのかな？2回目以降のテストはリグレッションテスト？
— tsuemura (@tsueeemura) 2020年2月6日
I/JSTQBによると、リグレッションテストの定義は以下の通りです。
リグレッションテスト（regression testing）
ソフトウェアの変更されていない領域で欠陥が混入している、もしくは露呈していることを検出するための、変更関連のテストの一種。
目的は「欠陥の検出」なのですが、期待している結果は「成功」だと考えてよいですよね。
言い換えると、リグレッションテストでは、「前回成功したテストが、今回も成功する」ことを期待しているわけです。*1
テストに対する期待結果のマトリクス
ここで、「前回」「今回」をパラメタ、「成功」「失敗」をその値と考えると、リグレッションテストを次のようなマトリクス上に位置付けることができます*2。
このマトリクスは、「前回のテストに結果に対し、今回はどういう結果を期待しているか」を表しています。よって、リグレッションテストは 成功→成功 のセルに入っています。
成功を期待するテストには何があるか
グラフを見たら、網羅せよ（Boris Beizer）。もちろん表も、網羅せよ。これぞテスターの心意気。 さあ、どこから埋めましょうか。
わかりやすいのは、失敗→成功。これは、不良を修正した後のテストです。
I/JSTQBではこのテストを、「再テスト」「確認テスト」というかなり一般的な（テクニカルタームとは思えないような）名称で呼んでいます。定義は以下の通りです。
再テスト（re-testing）
変更関連テストの一種。欠陥を修正した後に実行し、それらの欠陥により引き起こされていた故障が発生しなくなっていることを確認する。
この「変更関連のテスト」というのは、リグレッションテストの定義でも出てきましたね。
再テストとリグレッションテストの二つが、変更関連のテストに属します。
「成功」列を埋めてしまいましょう。
前回は「なし」で、今回「成功」を期待するのは、「はじめてのテスト」 ですね。特に名前はありません。
ちなみに、「テスト実行」に関する秋山さんの記事で、Myersの言葉が引用されていました。
58号：テスト実行｜Kouichi Akiyama｜notenote.com
「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 （1979年） by G.J. Myers
テストの目的（の一つ）は「バグを見つけること」なのですが、そうはいってもテスト対象は「正しく動く」前提でテストに流れてくるので、ここでは「成功を期待する」としてマッピングしています。
失敗を期待するテストには何があるか
さあ問題は、「失敗を期待するテスト」の方です。失敗することを期待して行うテストなんてあるでしょうか。
その一つは、実は再テストとペアになるものです。
再テストにおいては、「修正前のバージョンで、バグに起因する現象が再現すること」をまず確認したうえで、バージョン以外の条件を維持したまま、「修正後のバージョンでは、バグに起因する現象が発生しないこと」を確認するのが基本です。
すでにわかっている現象をなぜ、あらためて再現させるのでしょうか。
バグの内容によっては、現象を発生させる条件が難しかったり、複雑だったりします。「修正後」の確認だけだと、「バグは正しく直っていないのに、発生条件が整っていないせいで、現象が出ない」ことがありえます。これをもって、「バグは直った」と誤解するリスクがあるのです。
ですから、必ず再現させたうえで、修正後のバージョンでもう一度同じテストを行うことが大切です。
次に左上のセル、なし→失敗 です。
最初から失敗を期待する、そんな奇特なことを目的としてテストなんてある・・・？
・・・あるぞ・・・これは・・・TDDの説明でよく見るやつ・・・。
最初に、失敗するテストコードを記述します。また、テストを実行可能にするために、テスト対象コードはテストを失敗させるように仮実装します。
この、「TDDで一番初めに書くテスト」、これは「最初から失敗を期待する」テストだ！
同じように、成功→失敗 も、TDDにおける「RED」のためのテストコードですね！
なお「GREEN」は、失敗→成功 のところに入るでしょう。
マトリクスを網羅した！
色でグルーピングしてみました。
いやあ、表を埋めると仕事した気分になりますね！
他にもこのセルに入るテストはあるでしょうか？
