第四章 直し壊しのテストフェーズ
実装を終えたシステムを今度は自分たちの手でテストします。 実装とテストの両方を経験し、どのようなことを学んだのでしょう。
長かった実装が終わり、次はテストに入ります。
テストではテストケースを基にアプリケーションを操作して、要件定義や設計の段階で決めていたことが反映されているかどうか、ユーザの立場から本当にアプリケーションが使いやすいものであるかどうかをひとつひとつ確認していきます。テストによって、アプリケーションは“よりよいもの”になっていきます。
スモークテスト
一番初めのテストは“テストが出来るかどうかをテストする”スモークテストです。
各自ひととおりの機能を操作して、バグがあってもアサートがあってもすべての機能を使用することが出来るかどうかを確認します。そしてテストが出来る“Testable”か、テストが出来ない“Not Testable”の判定をするのです。
（アサートとは、例外処理が発生した場合に表示されるダイアログのことです）
…と、偉そうに書いておりますが、初めはスモークテストに対する私たちの理解は見当違いも甚だしいもので、アサートが出るたびに
「アサートだアサートだ！テストできません！」
と喚いていました。そのたびに先輩たちに注意をされていました。
テスト開始
スモークテストで“Testable”の判定が出たので、いよいよ本格的なテストに入ります。
まずは、テストケースを使用せず、各自が思うがままにアプリケーションを操作する中でバグを見つけていく“AdHocテスト”から着手しました。AdHocテストをする上で、先輩から与えられた課題は“ひとり10個以上のバグを見つける”ことでした。最初その課題を聞いた時私たちは
「そんなにたくさん見つけるなんて…」
と腰がひけていました。
ですが、いざテストを始めてみると、出るわ出るわバグの山。最初こそバグの探し方、バグの報告・管理の仕方に戸惑ったものでしたが、結果的に四人全員が10個以上のバグを発見し、無事課題終了となりました。
たくさんのバグを見つけ、課題もクリアし、私たちは課題が終わって良かったなあ、テストって楽しいなあとのほほんと思っていました。
デバッグ
AdHocテストが終了し、次はデバッグをすることとなりました。
前回のコラムでも書きましたが、今回は研修なので本来別々の人間が行うべきテストとデバッグをどちらも新人が行うことになっています。
一週間のうち、私たちに与えられたデバッグの時間は三日間でした。つまりテストで見つけた約50個のバグを三日間でほとんど自分たちで直さなければならなかったのです。テストでうきうきと見つけたバグがプレッシャーとなって私たちにのしかかってきました。
「こんなにたくさんのバグを直すなんて無理だ！」
と全員が思いました。
それから先の三日間は正しく怒涛でした。どこをどう直せば解決するのかまったく見当がつかないバグがほとんどで、実装の時以上にコードを見ては途方に暮れ、悩みに悩みました。
ある新人は頭が真っ白になり、ある新人は自己嫌悪に陥り、またある新人は自分の不甲斐なさに頭を掻き毟り、一喜一憂ではなく一憂一憂の状態に・・・。
個人的には
「こんなに直すのが大変なら、テストの時、あんなにたくさんのバグを見つけなければよかった…」
と溜息を吐いてしまったこともしばしばありました。
それでも先輩方は私たちに丁寧なアドバイスをくれました。時に優しく、時に厳しく。私たちは何度助けられたか分かりません。バグの中には、先輩方に引き取ってもらって解決したものが数多くあります。自分が如何に無力なのか、改めて痛感しました。
そんなデバッグの時、特に身にしみて思ったことは『自分で自分を管理する』ということです。
与えられた課題──デバッグの場合はバグの修正がそれにあたるのですが──
それを期日までに終わらせるかどうか、
自分の実力と使える時間を冷静に判断し、
実現可能な見積もりが出せるかどうか、
出来ない時に『できません』と言えるかどうか、
言葉にしてしまえば簡単なのに、私たちはなかなかそれが出来ませんでした。
何も考えずに『がんばります』と言うだけでは社会人失格です。
見積もりと、こまめな報告。デバッグとは直接関係はないのですが、私たちが学んだ中で最も大きいものはそのふたつです。
事件勃発、ブロッキング登場
怒涛のデバッグが終了し、もう一度スモークテストとAdHocテストを行いました。
デバッグで修正したバグが本当に直っているかどうかを確認するのです。
しかしそのAdHocテストで、アプリケーションの中で核になっている機能が、まったく動作してくれないことが分かったのです。
青天の霹靂でした。それを見たテストリーダーの先輩が
「ブロッキングバグだね」
と言いました。ブロッキングバグ、テストが始まる前の講義で名前だけは聞いていましたが、実際に登場するのは初めてでした。アプリケーションの機能が正常に動作するかを検証するためのテストですが、ブロッキングバグによって検証すべき機能が丸々一つ動きません。
そもそもテストを実施することが出来ないほどの重大なバグ、それをブロッキングバグといいます。すぐに私たち四人と先輩方で会議を行いました。そして、一旦予定されていたその日のテストを全て中止し、開発としてブロッキングバグを解決するということが決定しました。
しかしその時の私たちは、ブロッキングバグの本当の重大さに全く気が付いていなかったのです…。
ブロッキングバグ、そのとき私たちは
ブロッキングバグの修正が決定した会議で、並行して発生していた課題がありました。
それまでテストのために私たちがアプリケーションで無作為に作成していたデータの整合性が合っておらず、今後のテスト作業に支障をきたし始めていました。それに伴って先輩たちは私たちに一度アプリケーションから作成されたデータをすべて削除するようにと指示を出しました。具体的に言うと、データベースに対してSQL文を発行して不要なデータだけを削除するのです。
消さなければならないデータはいろんな箇所にいくつも点在しており、データを消すためのSQL文もそれなりの分量がありました。なので先輩たちはブロッキングバグの修正と同時に、私たち四人がどの部分のSQL文を書くか、担当を決めておくようにとの指示でした。
会議が終わり、私たちはまずSQL文の担当を全員で話しあうことにしました。
すると話し始めてまもなく、先輩から怒りの声が飛びました。
「ブロッキングバグをほったらかして、何をやっているんだ」と…。
怒られてから0.5秒間、何で怒られているのかさっぱり分かりませんでした。
その0.5秒後、『指示されたことをやっているのに…』と思いました。
その0.5秒後、どうしてなのかをようやく理解しました。
「そうか、ブロッキングが解決しなければ、そもそもテスト作業も出来ないし、データの整合性だって確認できないんだ」
ブロッキングバグはテストも開発も、プロジェクトの動きすべてを文字通り“ブロック”してしまうバグ、その真の恐ろしさを分かっておらず、データベースの話をしていた私たち。先輩たちが見たら、こいつら何やっているんだと思われて当然でした。
テストの終わり
つらかったこと、楽しかったこと、色々なことがありましたが、私たちは今ようやくテストフェーズの終わりを迎えようとしています。
はじめはたくさんあったバグも少しずつ数が減ってきました。機能そのものが動かないような致命的なバグも、最初はたくさん出てきたのですが、近頃ではあまり見かけません。しかしその陰にはたくさんの“直さないことになったバグ”があり、それなくしてはテストのコラムは書けないだろうと私は思っています。
現在作っているアプリケーションのリリースは10月の末、もう日にちがありません。そんな中ですべてのバグを直していたら時間がありません。ユーザの使用に支障をきたさないものや、悪影響が比較的少ないバグを選定する必要がありました。これは、どのプロジェクトでも必ずあることなのだそうです。
要件定義は、お客様の要件をすべて書き出したら終わりです。設計は、その要件をすべて機能に落としこんだら終わりです。実装は機能になったものを、すべてコードに変えたら終わります。
しかし、テストだけはそういった明確なゴール地点はありません。すべてのバグを直すことはできないし、そもそもそのアプリケーションに潜んでいるすべてのバグを見つけだすこと自体が不可能なのです。
だからこそ、テストは他のフェーズよりも更に“自分で自分を管理すること”“こまめに報告をすること”が不可欠なのではないかと私は思っています。
自分でゴールを決めなければ、いつまで経ってもテストは終わらないのですから…。そのことに気が付くことが出来て、本当によかったと思っています（管理や報告は先輩方にまだまだだと特に言われていることなので、これからも精進は必要なのですが…）。
この経験はテストだけではなく、これから先どんな仕事をしていてもきっと活きることでしょう。テストが終われば、次はリリース・社内での使用方法説明会など、まだまだ行事が目白押しです。最後まで気を抜かずに邁進したいと思っています。
