アジャイルの技法はアプリケーションの周りに強力なテスト装置を構築するため、適切な単体テストと受け入れテストを準備しておくことを推奨している。しかし、実際にはすべてのアプリケーションがテスト装置を持っているほど幸運ではない。アジャイルテストグループの興味深い議論の中で、グループのメンバが自動テストを持っていないアプリケーションをどのようにテストするかについて各自の推奨する方法を紹介している。
議論が始まったのは、Asad Safari氏が実装しているアプリケーションにテストがないことを告白したからだ。チームの開発者は単体テストに不慣れで、テスト期間は3週間しかない。氏はこの条件下でテストを実施するために何らかのアドバイスを探していた。
Phlip氏は何度か同じ状況に陥ったことがあると答え、下記の方法を推奨した。
- ランダム、または決まりきったインプットを使ってアプリケーションを実行するモジュールを追加する。
- エラーと警告をログファイルに吐き出すロギング機能をプログラムに追加する。
- 巨大なユニットテストをひとつ書く。このテストは対象のプログラムのすべての機能をコールし、用意したインプットを使って実行して、ログを収集する。
- ログの中にエラーがないことを通知するひとつの警告を実装する。
- えらーが発生するごとにこの警告に例外を追加する。
- エラーをつぶし始める。エラーを除去するごとに警告から例外を除去する。
Phlip氏はこの大掛かりなテスト方法の場合、時間が許す限り、小さな的を絞ったテストを書くことから始めるように勧めた。また、次の3週間、チームはアプリケーションの穴を埋める作業に追われるだろうが、小さな単体テストを書き実行するのを始めるには今が最適だと主張した。
Adam Sroka氏はこの提案に賛成して、次のように付け加えた。
ええ、ほとんどのチームが低品質に対応するために作業をゆっくり進めたり、実現する価値を低くしたりしますが、これは実際のところ、品質の向上には寄与していません。必要なのはもっと実用的な解決策です。… 最初からテストをしているのと同じくらい完璧にテストをすることなど不可能なのだから、テストには価値がないと考えるのは間違っています。後からテストを実施しても価値はあるのです。
このような考えに納得しなかったのはBrian Spears氏だ。氏はアジャイルは魔法ではないと主張し、3週間でどうにかする解決策を思いつくのは不可能かもしれないと考えている。氏曰く、
アジャイルは魔法ではありません。このような緊急事態の解決策は、もしあったとしても大量の時間が必要ですので、アジャイルな解決策ではありません。
氏はこの議論で反対の意見を述べている。氏が示したのは、一度アジャイルを適用したほとんどのチームは同じような状況に陥ったことがあるということだ。こういう状況は、実利的なチームになってソフトウエアをより良くするための第一歩を踏み出すためには最良の状況だ。
Annette氏が示したのは、この時点で自動テストを実施するのは時間の無駄なので、現在の状況では何時間もかけて手動テストを行うのが最適だ、ということだ。始めに目立つ機能や利益に結びついている機能をテストすることを勧めている。氏はLisa Crispin氏とJanet Gregory氏の共著Agile Testingも勧めている。
Charles Bradley氏も同じような指摘をしているが、前もって条件を決めておくことも勧めている。氏が言うには、
時間が限られています。ビジネスの視点から考えた最良の方法がどんなものであれ、ROIを最大化しなければなりません。手動で徹底的にテストすべきです。そして意思決定者に、二度とこんな状況にチームを陥らせないということ、もしそれができないなら今後は自動テストを行う時間(と予算)を用意しておくことを確約させるよう努力します。そして、これは次のリリースに向けての作業の開始やリリース後のバグ修正の開始に合わせてすぐに実施すべきだということも主張しましょう。
このように、この状況は完全なテスト装置を実装するタイミングとしては最良ではないかもしれない。チームも手動でテストを行った方がいいのかもしれない。とはいってもこのような状況は、初めに与えられた機会に適切なテスト装置を実装しておくことの重要性を毀損しない。 Jonathan Rasmusson氏は下記のように書いている。
やらなければならないのはバグを修正すること、そしてアプリケーションがリリースされるまで、できる限り手動でテストをすることです。現時点でできることはこれだけです。そしてより巨大で重要な問題は3週間経った次の日にあなたがどうするのか、ということです。