技術的負債にならないテストケース

とりあえず、取り留めのない文章ですが、自分の思っていることに対して人の意見をききたいのでポエム的に書いちゃいます。

技術的負債

「技術的負債はよくないのでなんとかしないと！」ってよく言いますよね。

Wikipediaだとこう書いてあります。

技術的負債とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。

PublicKeyの記事はわかりやすくまとまってます。

「技術的負債」とは何か。原典とその対応策を探る

技術的負債ってソースコードに対してよく使われるんですが、テストケースそのものに対しても技術的負債って言葉が当てはまるんじゃないかって思うようになりました。なので、テストケース自身に対する技術的負債についてどっか書いてないかと思って、Webでちょっと調べたのですが、テストケースの技術的負債について書かれた記事を見つけられませんでした。（テストコードの技術的負債って話はありましたが。）あまり、テストケースに対して、「このテストケースには技術的負債がたまってる！」って言う人はいないのかもしれません。

テストケースの技術的負債

テストケースを作ったが、テスト実行中に仕様が変わったり、もしくは仕様の内容を勘違いしてたことに気づいたけど、忙しいしテストケースをそのまましておくってことはよくあると思います。

その後、ちゃんとメンテナンスしないで、とりあえず保管しといたままのテストケースって、実は技術的負債が積まれていってるのかもしれません。

テストケースをちゃんとメンテナンスをして、次に同一箇所のテストをするときや、リグレッションテストをするときにテストケースを使いまわせるようにすることが、テストケースの技術的負債を返済していることになるのではないかなと思うわけです。

そもそも「使い捨て」前提でテストケースを書いてる？

誰でも実行しやすいように実行手順をしっかり書いたテストケースは、実はメンテナンスが難しいと思っています。本当のリグレッションテスト以外でそのテストケースをがそのままで「また使える」ってことが考えずらいからです。だって全く仕様変更がなくそのままのところに対して、わざわざメンバーをアサインしてQAして欲しいってならないですよね？

そうであれば、（リグレッションテスト以外は）テストケースを再利用する必要があるのでしょうか？

テスト設計をする時間がそれほど潤沢にあるってことはあまりなく、開発のスピードに合わせてテストをしっかり行うってなると、その場凌ぎのテストケースを猛スピードで作ったほうが効率よいかもしれないです。テストケースを作らなくてもひらめきでテストしたほうが早いかもしれないです。

けど、そうやって用意したテストケースは「使い捨て」かも。

「使い捨てのテスト」なのに、さも資産化できてるようなふりをして、再利用するかの如く保存しておくのは無駄なのではないか？って思います。

まぁ全く無駄ではないかもしれない。細かく読めば何をテストしてたかはわかるので。記録として大事かも。

どっちにしろ、実際は過去のテストを再利用するより、作り直したほうが早い」って考えてる人は多いと思います。私もそう思っているフシがあります。

テストケース再利用が開発のボトルネックになっている？

けど、「それらの過去のテストを再利用すれば工数かからないだろ？」的なことを言われたら嫌じゃないですか？

もしくは、「いったいなんでこのテストをするのだろう？」と思われるけど、とりあえず実行しておけば文句も言われないし、って考え方で過去に使ったテストケースを何度もテストするっていうのもあるかもしれません。けど、それって意味ありますか？再利用なんですかね？

これも「実行されないコードだけど消すとなんかあった時にまずいから」っていって残ってるソースコードと一緒で負債のようなものです。負債となってるテストケースは再利用しても効果ないどころか害になります。

ソースコードの技術的負債は返済するがテストケースの技術的負債は返済しないとすれば、それは開発スピードの妨げにになってると思っていいかもしれないです。本当は必要かどうかわからないテストをとりあえずやっているからです。

技術的負債を溜めないためにも構造やアーキテクチャーがテストに必要、けど、それだけかな？

再利用をするには、事前条件、P-V、実行手順、期待結果がセットになった教科書通りのテストケースのような細かい内容よりも、もっとハイレベルな、テスト条件とか、そういうレベルでテストを表現すべきです。テストの階層構造です。そしてP-Vなど、テストに登場する要素が明確になるようにしておき、テスト条件に属するP-Vが全てグルーピングされていて、実際にテストで使う時にはその時に相応しいP-Vだけ選んでテストする、これが再利用できる方法だと私は思っています。

また、テスト条件のようなハイレベルなものだとしても、その数がたくさんになってくると収集つかなくなるので、それらの関係を整理し見通しが良いようにカテゴライズしたりグルーピングしてマネジメントできるようにすると思います。これ、つまりテスト設計コンテストとかで主題になるテストアーキテクチャーです。

ソースコードの技術的負債に対処するためにもソフトウェアアーキテクチャーを設計して、見通しをよくして、変更する箇所をわかりやすくすると思います。テストにも同じことが言えます。テストケースの見通しをよくなるようなテストアーキテクチャーを設計して、変更する箇所をわかりやすくする品質が求められるかもしれません。

けど、「アーキテクチャーがどうだ」とか「やれ、テストケースの階層構造だ」とかいう前にもっと大事なことがあるってことに気付きました。正確にいうと「なんとなく気付いてたけど、点と点が繋がった感じ」がしました。（ここからが一番言いたいところ）

カンニガム氏の負債の説明の動画では以下の言葉が述べられてます。

アプリケーションを開発していく過程で得られた学びを蓄積するためにプログラムに手を入れる

テストであれば、テストアーキテクチャーを設計し、テスト条件を識別し、テストケースを設計し、テストケースを実行します。そしてバグが出たら直してもらい再度テストます。そういった一連の過程で得られた「学び」をテストに蓄積していくため、テストケースに「手を入れる」必要があるんだなってしみじみ痛感してます。

つまり、「手を入れなくてよい」テストケースなんて無いってこと。

最初に作ったテストアーキテクチャーとか識別したテスト条件とかテストケースとかが完成状態ではなく、私たちはその後のテスト実行からのフィードバックを受けてテストをよくしていかなければならないってこと。

昨今のアプリケーションは一度テストしたら終わりではなく、そこからが始まりで、お客さんの声でアプリケーションが進化していくのと一緒でテストケースも進化しなければ足並み揃えた開発ができないはず。

テストケースも追加していかなきゃいけない、けど、ひたすら追加だけ続けていればよいわけではなく、常に見通し良い状態をキープして適正量に収め続けていかないと。それが負債を返済すること。

テストケースの技術的負債を返済することは、単なるメンテナンスの「余計な作業」ではなく、開発スピードを高速にしていく時の対になるものとして、必須なんだろうな。