前回までの状況

新しくチームに合流した千秋ちゃんに資料を渡し，一言「テストケース作っておいて」といい残し会議室を後にした中山君。作業場所すら指示されなかった千秋ちゃんですが，だまっていてもしょうがないと直前までいた現場で使っていた席に戻り作業を開始しました。

元のプロジェクトの席に戻っている千秋ちゃんを見て心配になった大塚先輩は，メンバに会議室に集まるように指示を出しました。現状を確認するとチームがチームとして成り立っていない状況でした。大塚先輩の指示もあり，チームの建て直しが図られ，ようやくメンバはそれぞれの役目を意識することができました。

その会議のその場で小川君から作業レベルでの問題点や疑問も共有しておこうという提案があり，トレーニングの件もあるのでまずは千秋ちゃんの作ったテストケースを見ていくこととすることになりました。

今回はリーダではなく担当レベルが知っておく事柄も多いですが，復習と思ってついてきてください。

大塚先輩：

ではみんな千秋ちゃんが作成したテストケースを見てほしい。

千秋の疑問　～テストケースのフォーマット，ツール

千秋：

えっと，何から言えばいいかしら。そうね。これだわ。

千秋：

テストケースの書き方なんですけど，いまどきExcelで書くなんて古臭くありませんか？

千秋：

最近読んだ本にはテストケースはテストコードとして書くのが普通と書いてありました。

中山君：

えっ，そうなの？

千秋：

それに，こんなのいちいち手で書くの無駄よ。スクリプト書いちゃだめ？

千秋：

どうせツールで実行させるんでしょう。Excelで書いてその後スクリプトで書くなんて無駄じゃない。この程度だったらフリーのツールがどっかに転がってるでしょうし。

小川君：

ダメだよ。コードだと可視性が落ちてしまうから，使いどころを見極める必要があるね。今はその時じゃないよ。

千秋：

可読性？　SEだったらコードぐらい読めるでしょう。それに動かしてみなくちゃ，どんな結果がでるのかわからないじゃない。

小川君：

動かしてみて考えるんじゃなくて，事前に期待結果を考えてやらないといけない。

千秋：

設計書に期待結果なんて書いていないじゃない。そんなもの，どうしたらわかるのよ。

中山君：

ちょっと待ってくれ。この案件はシステムテストなんだ。テストの一部分はツール化できるけれども，全部は無理だよ。

千秋：

え～，いちいち手で動かさないといけないわけ？

小川君：

中山先輩，すいません。つい，千秋ちゃんの話に引っ張られてしまって。そうなんだ。システムテストは手で行う部分も多いんだよ。

スクリプトによるテストは見極めを

千秋ちゃんはコンポーネントテストの経験があり，スクリプトでテストを行っていたということですから，推測するにxUnitなどを使ったTDDの手法の経験があったものと思われます。しかし，これから取り組もうとしているのはシステムテストです。そのまま使えるものではありません。

それから，小川君の指摘にもあるように，プログラムコードベースのテストスクリプトはどうしても可読性が落ちてしまいます。そもそもプログラムコードを書ける人じゃないと，作成もできないしメンテナンスもできなくなります。確かにツールを使えば効率は（習熟していれば）上がるでしょうが，メリットデメリットがあることを認識しておくべきです。

プロジェクトで認定されていないツールを使うときは注意

千秋ちゃんはフリーのツールを使えば良いと言いましたが，基本的にはプロジェクトが正式に認定しているツールを利用すべきです。たとえば，そのツールが持っているバグにより正しい結果が得られない場合もあります。また，フリーのツールは基本的に改修の義務もありませんから，報告しても改修してもらえないでしょう。それ以前に「保証がない」ものですから，それを使ったあとのテスト結果は保証がないことになります。

組織によってツールの取り扱い方は変わると思いますが，自分の判断だけでツールの導入をせず，関係者の合意を取り付けるのがリーダとしての振る舞いです。

規定の書式を尊重する

プロジェクトにはたいていの場合，テストケース一覧表のようなドキュメントがあり，規定の書式が存在します。千秋ちゃんはコードで書こうとしたので，このテンプレートから逸脱した書き方をしようとしたことになります。それ自体は必要に生じて行うべきことですが，注意すべきことがあります。この規定の書式に従ったドキュメントは顧客への納品物となることがあります。

今回のケースはシステムテストを案件として取り扱っています。顧客への納品の可能性は高いと言えます。テストケースの表現形式を変える場合にはプロジェクト内の合意をちゃんととっておくことが重要です。