テスト設計の方針は千差万別：ソフトウェアテスト・エンジニアの本音（5）（2/3 ページ）

[大西建児，株式会社豆蔵]

　もう1つのライブイベントである「クイズ テストエンジニア100人に聞きました」とテストライブ共通で用いられた通称「100人システム」の開発を取りまとめた実行委員の佐賀大学の大月美佳（みかまま）から、開発に当たっての体験談を語っていただきましょう。また、そこからソフトウェア開発における注意点などをピックアップしていきましょう。

要求定義段階での仕様のあいまいさを固めていく大変さ

　体験談に入る前に、「クイズ テストエンジニア100人に聞きました」について簡単に説明しておきます。30代以上の方なら覚えているかもしれませんが、1980年代に「クイズ100人に聞きました」という関口宏氏司会の番組がありました。5人1組の家族2チームによる対抗形式のクイズ番組です。問題のテーマごとに100人にアンケート調査をし、アンケート結果の回答数が多い答えを予想して、答え点数を競うというのが大筋です。前半の対抗戦で勝ったチームが、後半の「トラベルチャンス」というイベントに挑戦し、獲得した点数によって海外旅行という特典を受ける人数が決まるという流れになっています。

　JaSST'05では、テストに対して、開発者の卵から、現場のエンジニアに至るまで、どういった印象や認識を持っているかについて、参加者に分かりやすくお伝えする手段として、このクイズ番組を模したプログラムをお届けすることにしました。そこで、テストをテーマにした質問でエンジニアやプロジェクトマネージャ100人に対して実際にアンケート調査を行い、問題を作成しました。

　なお、この結果については、シンポジウムのWebサイトにて公開しています。当日のライブイベントを、できるだけ本物のクイズ番組に近づけるべく、チーム構成や音響、雰囲気作り、プログラム構成に工夫をこらしました。この一環として製作されたのが「100人システム」です。100人システムはチーム対抗にて行う前半線と、後半のトラベルチャンス両方の問題をPC上で表示するために用いました。当日はPCに表示した画面を、会場のプロジェクタに投影し、参加者に見ていただきました。音響効果は別にWAVE形式のWAVファイルとして作ったものを、100人システムの画面の操作と共に、裏方スタッフが別のPCで流すというやり方でした。このため、実は音と絵を合わせるために、リハーサルを何回も繰り返し、本番に臨みました。

　「今回は講習会もないし実行委員といってもラクチンね」と思っていた2004年中ごろ。この見通しは大層甘うございました。

　いつの間にかやることになっていたJaSST'05版「クイズ100人に聞きました」。ほんとにやるの？ という声もありながら企画は進み、パネル表示システム（通称100人システム）は作らないと仕方がないとなりましたが、当然引き受け手はいません。ちょうどそのころ3名の1年生がJavaを学習したいといってきました。「まあ、学生と一緒にちょこちょこっと作ればいいかぁ」と、ごく軽い気持ちで引き受けたのが間違いのもと。

　なおこの時点では、「問題画面と9分割画面のみで、問題や回答は画像に埋め込んでおいて、その画像を入れ替えればいいや」という超簡単なプログラムしか考えていませんでした。それが、なんとテスティングライブでも使いたいという申し出があったのが、10月下旬。「えー」といいつつもほかの候補がダメだというので仕方ありません。よく分からないながらも引き受けましたが、本当に大変さを分かっていませんでした。ええ。

---

　ここでも問題となっているのが、要求定義段階での仕様のあいまいさです。実際にプログラムを動かす動的なテストも大事ですが、要求や仕様のあいまいさをなくすための、レビューやウォークスルーのような静的なテストも大切です。反復型開発であったとしても、要求の全体ボリュームが見えないことには開発の終わりは見えてこないでしょう。

---

　仕様がどこからか出てくるということで待っていましたが出てこないので、取りあえずこちらで考えたα版をリリースしたのが12月15日。これは当初想定した機能のみのものです。ご多分に漏れず、ここで結構な量の機能が追加されました（あんまり簡単だとテストに使えないということはありました）。「これが話に聞く仕様変更か」などと妙な感心をしている場合ではありません。この時点で後1カ月ちょっとしかありませんでした。学生と打ち合わせしている暇もなく、泣く泣く冬休みをつぶして実装を行いました。

　100人システムの仕様作りのため、まずは仕様作成担当にてこの番組のビデオを入手し、内容を確認するところから始めなければなりませんでした。

　すったもんだしながら、このプログラムのとりまとめ担当実行委員が使い慣れているあるCASEツールを使って仕様が作成されました。このとりまとめ氏が業務多忙であったため、仕様を段階的に出さざるをえないという裏事情があり反復型開発のスタイルで作成されました。

　涙の結晶であるα2をリリースしたのが1月5日で、β版リリースが1月12日。テスティングライブ用の仕様書はβ版最後からリバースエンジニアリングで起こしていただきました。バグが取れた最終版ができたのは1月23日。つまりイベント前日で、エラーシーディングは1月23日から24日にかけて調整していました。もう正直ひぃぃぃぃって感じでしたね。

---

　今回の100人システム開発は典型的な短期開発であったため、前述のようにクイズ本番用のシステムと、エラーシーディング版をコンカレントに開発するため、α版とβ版に分けて開発を進めました。ベースが同じでも、機種が分かれるようなプロダクトにはよくある開発アプローチともいえましょう。α版のテストフェイズでは、効果的に不具合を抽出するために、ライブでテストを担当するテストのプロの方々にテストを行ってもらいました。

---

　途中学生にテストしてもらい、いくつかバグを発見してもらいました。また、テスティングライブ関係者の方にもバグを見つけていただきました。非常に珍しいバグも発見していただけたので「さすがにテスト専門家は違うなぁ」と感心したりもしました。本番でバグってたらしゃれになりませんから、バグを発見してもらえたのは本当にありがたかったです。テストって大事ですね。

---

　上記はテストの専門家なら、きちんと時間を取って計画的に不具合を見つけようとすれば見つけられるという好例でしょう。ただし、時間には限りがありますので「何のためにテストを行うのか」というテスト戦略にのっとったテストが重要なのはいうまでもありません。

---

　今回こういう形で開発を行ってみて、ほんの少しだけ現場の苦労を体験できた気もします（いや、現場はもっと大変なんだ、と怒られそうですけど）。大変でしたけど、良い経験にもなりました。協力していただいた方々にはありがとうございました。なお、今回作ったプログラムは大学の講義でも利用する予定ですが、一般の技術者教育などにも活用していけたらなと思っています。