小説なんかでいわれる「緻密なプロット」の何がすごいって、「情報に関する情報」のコントロールだと思うんですよね。
- 人物Xは、事実Fを知らない。
- 人物Yは、事実Fを知っている。
これなら単純なのですが、一階層上がって
- 人物Zは、「人物Xが事実Fを知らない」ことを知っている。
- 人物Zは、「人物Yが事実Fを知っている」ことを知っている。
でもすでに複雑ですし、さらにもう一階層上がって
- 人物Yは、「「自分が事実Fを知っている」ことを、人物Zが知っている」ことを知らない。
となってしまうと、もうかなりややこしいですよね。そしてこの状況は、物語が進むにつれて変化していくわけです。
このような条件が入り組めば入り組むほど、文章の些細な修正がプロットを破綻させるリスクが高まります。「あれ？ この時点でこの人たちは面識なかったはずなのに・・」みたいな。
ということで、JSTQBの用語集で、「リグレッションテスト」の定義を見てみましょう。
リグレッションテスト（regression testing）
バージョン 3
ソフトウェアの変更されていない領域で欠陥が混入している、もしくは露呈していることを検出するための、変更関連のテストの一種。
この定義には暗黙の前提として、「ソフトウェアが変更された」ことが含意されていますが、それはいいでしょう。
次に気になるのは、「変更されていない領域」という表現です。ソフトウェアのある部分を変更したとき、「変更された領域」と「変更されていない領域」に二分できることが含意されているわけです。これって自明なことでしょうか？
物語のアナロジーで考えてみます。
ある単語を入れ替えたときに、「変更された領域」はどこでしょうか。単語か、文か、文章か、段落か、章か、物語全体か・・。
「物語全体」って言わざるを得ないんじゃないかなと思います。
もちろん多くの場合、変更部分から「遠い」部分ほど、影響が小さくなる傾向はあるでしょう。ただそれはあくまでもグラデーションだし、特に叙述トリック界隈では「序盤のこの何気ない文章が、ここにつながってたのかー！」みたいな（意図した）「影響」が生まれるわけですね。
ソフトウェアの話に戻りましょう。
ソフトウェアって、原則として前から後ろに流れていく小説と比べて、「変更による影響の及ぶ範囲」が人間には見極めづらいですよね。だからこそ、「変更によって意図せぬ副作用が生まれていないか」を検証する必要があり、そのための道具の一つがリグレッションテストなんだと思います。
なので、リグレッションテストのわたしなりの定義は、以下です。
ソフトウェアの変更によって、意図しない領域で欠陥が混入している、もしくは露呈していることを検出するための、変更関連のテストの一種。
「意図」という言葉に、人間の主観と限界を込めています。
・・・とここまで書いて、JSTQB Foundationシラバスを覗いてみると、「2.3.4 変更関連のテスト」に以下のような記述があります。
リグレッションテスト：
修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。変更には、オペレーティングシステムやデータベース管理システムの新しいバージョンなど、環境の変更も含まれる。そのような意図しない副作用をリグレッションと呼ぶ。リグレッションテストでは、テストを実行して、そのような意図しない副作用を検出する。
いや、「わたしなりの定義」とかいらんかったわ！ ちゃんとシラバスに書いてある！
この文章を定義に流用すればいいんじゃないかな・・・？
おまけ1
変更の影響の特定の難しさについては、以下のまとめが秀逸です。
非プログラマの方に「どうしてそんなに変更するの難しいんですか？」って聞かれたら、「六法全書を思い出して欲しい、条項の中から一文探し出して、それが他と矛盾しないかもチェックして欲しい、もちろんその変えるべき条項文は依頼側は分からないので、そっちで全て調べてください」って伝えてる
おまけ2
リグレッションテストと関係の深い用語「デグレ」ですが、この言葉は和製英語らしいぜという話は以下の記事で。
おまけ3
「プログレッションテスト」という言葉を教えてもらいました。
プログレッションテスト以外のところは
— Fumikazu Fujiwara (@freddiefujiwara) 2023年8月15日
リグレッションテスト？
とか単純すぎですかね
プログレッションテストは新しい機能のテストに焦点を当て、
リグレッションテストは既存の機能が新しい変更によって壊れていないことを確認
この2つのテストをうまく組み合わせる
この記事で簡単な説明があります。
プログレッションテスト
顧客の新たな要望に応える新機能を市場に素早く投入する。なのでテストをシフトレフトする。 それには、SeleniumやAppium、BDD (Behavia Driven Development: 振る舞い駆動開発)と言ったスクリプトベースな技術でテストを行うとアジリティが良いそうです。
この記事（と講演）でいう「リグレッションテスト」「プログレッションテスト」の切り口は、わたしの考えているものとはちょっと違いますが、なるほどーと思いました。
