手動テストだけのソフトウェアは腐っていく

1990年代までのソフトウェアテスト

1990年代までのソフトウェア開発におけるテストは、手作業で目視確認が主流でした。今日のようにテスト駆動開発で、自動テストを書くという習慣はありませんでした。いくつかの書籍から、本当でそうであったかを引用すると次の通りです。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

• 出版社/メーカー: オーム社
• 発売日: 2014/07/26
• メディア: 単行本（ソフトカバー）

著者のMartin Flowerは、この本の中で次のように述べています。

テストの実行は確かに簡単になりました。しかしテストの実行は簡単になってもテストは依然として極めて退屈なものでした。これは、コンソールに出力されるテスト結果を私がチェックしなければならないためです。

Clean Code　アジャイルソフトウェア達人の技 (アスキードワンゴ)

• 出版社/メーカー: ドワンゴ
• 発売日: 2017/12/28
• メディア: Kindle版

この本で、著者のRobert Martinも、次のように述べています。

この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。

Coders at Work プログラミングの技をめぐる探求

• 出版社/メーカー: オーム社
• 発売日: 2011/05/25
• メディア: 単行本（ソフトカバー）

『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。

「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」
それに対して、Joshua Blochは、

「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」

という話をしています。

1週間半費やしてその原因が何であったかというと、彼が書いたコードではなくて彼が書いたコードが使っていたミューテックスのライブラリにバグがあったっていうことです。それに対してインタビュアーが、

「そのミューテックスの作者がテストを書いていればバグは見つかったはずで自分が1週間半デバッグすることはなかったのにと思いますか？」

と聞いています。

インタビュアーの質問に対するJoshua Blochの回答は次の通りです。

頭に入れておく必要があるのはこれが90年代初期の話だということです。十分なユニットテストを書いていないということで、そのエンジニアを非難しようという気は全く起きませんでした。

1990年代は、このような時代だったのです。実際、私自身も、テスト駆動開発を行うようになったのは、2003年からです。

手動テストだけのソフトウェアは腐っていく

私自身は、1980年代、1990年代といくつかのプロジェクトに従事してきました。そのほとんどが、新規開発プロジェクトでしたが、後継の商品が開発されないものがほとんどでした。結果、手作業でテストしていたにも関わらず、開発されたソフトウェアが長年にわたって肥大化する前にプロジェクトが終わってしまい、ソフトウェアが腐っていくといことをあまり実感していませんでした。

2000年以降も新規開発プロジェクトにいくつか従事したのですが、一方で、既存のソフトウェアの修正などのレビューも多く行ってきました。さまざまなソフトウェアをレビューしていくなかで、分かったのは、「手動テストだけに頼っているソフトウェアは、年々腐っていく」ということです。

1. 手動テストだけに頼ってテストされており、すべての機能のテストに多くのテスターと長い期間を必要とする
2. 機能が毎年追加されたり、修正されたりしている

1．に関しては、最初は少人数で短期間であっても、機能追加が行われるごとにテスターの人数が増えて、テスト期間が長くなっていきます。

すべての機能を一通りテストする工数が増大してくると、追加された機能やバグ修正された機能だけをQAがテストして、リリースしようとします。そうなると、機能の追加やバグ修正の際に、次のことが（マネジメントから）要求されるようになります。

• 既存の機能のコードには一切変更を入れない。たとえ、新規機能で追加されるコードと共通化できるコードがあっても、共通化が既存の機能のコードの修正になるなら、共通化は行わない。
• バグを修正する場合も、修正コードを追加した結果、仮にif文のネストが深くなったり、caseラベルの処理が長くなったりしても、関数化やメソッド化によって既存の機能のコード変更になる場合、関数化やメソッド化は行わない。

つまり、既存の機能のコードは、一切触らないし、リファクタリングもしないまま、次のようなコードが生み出されていきます。

• 似て非なるコードが多くある。つまり、既存の機能のコードをコピーしてきて、一部を修正しただけのコードが増えていく。
• if文のネストがとても深くなっていく。
• caseラベルの処理が長くなっていく。さらに、その処理にネストが深いif文が書かれる
• 一つの関数やメソッドが長くなっていき、その中のローカル変数のスコープが広くなって、実質的にグルーバル変数のようになってしまう。

このように腐ってしまったソースコードは、エディタで開いた瞬間、そっと閉じたくなるものです。