動作確認テストという昔話

現在構築中の CMS が佳境を迎えていたためと、既存のデータを全て入力していたため、（とネタがなかったため、）ここのところ全くエントリーをかけないでいた。やはり自分で構築した CMS は妙な話、子のように思える。思うにこれは、MT を使ったものと違う点ではなかろうか。

CMS を使ってデータをガシガシ入力していったのだが、そうすることでバグを見つけることができる。そしてすぐ修正、引き続きガシガシ、という流れ。どれだけ入力しやすくても、ウェブサイトで言えばどれだけデザインが美しくても、不具合が頻発すればマイナスの評価しか得られない。デザインや内部設計、コーディング等々の手順があるが、テストほど重要性の高い局面はないと思われる。

私は以前、シニアテスタという職で動作確認テストを行っていた。プロダクトについては伏せさせていただくが、当時、みなさんが使っていたものである。私も含めた仲間の中で最も狂喜乱舞することはと言えば、bugzilla のようなバグ管理ツールにおいて、我々が発見し報告したバグが開発部によって「重要度：高」「緊急度：高」という 2 種類がマークされたときだ。我々はこのマークによって、最高の達成感を得ていた。それと同時に、開発部にとっても、修正する作業が増えるのだが、悪い話ではなかったと思う。もしこのまま出荷していればもっと大変なことになっていた筈だからである。

ある日、私は海外向けのとある製品のテストを行っていた。テストシートというテストする項目が列挙されている一覧をもとにテストを実施していたが、なにかひっかかる。変な話、今までに培われてきた勘とでも言おうか、そういう類いであった。定時が過ぎ、直属の上司も「テストシートの項目が終わっているなら帰ってもいいよ」と言ってくるのだが、まだ「勘」は働いたままだった。そう、「なにか潜在的なバグがある」とどうしても思えてしまうのだった。そして時間は過ぎて行き、上司に堪らず言った。「徹夜したい」という心からの叫びだった。しかし、どこにバグがあるのかは判らなかった。ただ、妙に引っかかっていたという勘を頼りにしていただけだ。

そして、その瞬間が訪れた。我々はバグを見つけても必ず再現確認を行う。さらに可能な場合はバグを発生させる原因を追究し、できるだけ絞り込んだ上で報告を行うようにしていた。しかしこの場合はその追究をする許可がないプロダクトであったため、100% 発生する手順を確認し、報告を行った。そのバグはすぐに修正に取りかかられた。なぜなら、リリース当日だったからだ。私はこの勘以外にも、リリース日という「この日を逃せばもう修正する手だてがない」状況と、担当していた開発の人に少しでも貢献したかったという面もあった。もし致命的なバグを残せば、雲の上の人から雷を落とされるのはその開発部であり、開発部の人が後日「いい仕事をした」と気分よく社内を歩けるようにするには、なんとしてもバグを残してはならないという想いもあった。そのプロダクトのテストを担当したのは私だけであり、数いるテスタから私を選んでくれたせめてもの恩返しをしたかった。

動作確認テストというとひょっとしたら「終わりまであと一息」みたいな捉え方をしている人がいるかもしれない。しかしここが本当の山場であると私は言いたい。テストを軽く扱ってなんの不幸も起きない人は稀である。大抵は「もっとテストしておけば良かった」と、「もっと勉強しとけば良かった」と表現は似ているがより深刻な気分を味わうことになるだろう。

かつて私はテストを疎かにする同僚に「所詮、機械は人間に勝てない」と言ったことがある。1 年以上経ってから彼は言ってきた。「あのとき言われたことが、今になってようやく判った。最近はテストに時間をかけるようになった」

プロダクトの命運を決めるのはテストであると、私は思う。