前回までの状況

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

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

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

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

大塚先輩：

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

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

千秋：

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

千秋：

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

千秋：

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

中山君：

えっ、そうなの？

千秋：

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

千秋：

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

小川君：

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

千秋：

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

小川君：

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

千秋：

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

中山君：

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

千秋：

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

小川君：

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

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

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

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

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

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

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

規定の書式を尊重する

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

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

小川君の疑問　～テストケースの優先度は？

千秋ちゃんのヒアリングがある程度進んだところで、小川君が質問をしました。

小川君：

書いたテストケースのすべてをテスト実施しますか？

中山君：

今回はわからないけれども、全部はできないことが多いね。

小川君：

実施するテストとしないテストの区別はどうやっているんですか？

中山君：

ケースバイケースだなぁ。プロジェクトによってそれぞれ違うから。

小川君：

…質問を変えます。テストケースに優先度はありますか。

中山君：

品質リスクを狙ったテストケースは優先度が高いかなぁ。

小川君：

このシステムにおける品質リスクについて書かれたものはありますか？

中山君：

……。

テストケースの優先順位付け

システムテストというのは、開発工程の最終工程に近いため、開発の歪みをすべてかぶってしまう工程です。マスタースケジュールで予定していた開始時期をかなり後ろにずらして、たとえば1ヵ月とか2ヵ月遅れて開始することはよくあることです。開始時期が遅れたから終了時期も遅らせられるかというと、なかなかそうはいきません。なぜならば製品やサービスのリリース時期が決まっていることがほとんどだからです。

開始時期は遅れるけれども終了時期に変更は無いということが多いのです。そのため、当初予定していたテスト期間が確保できず、想定していたテストのすべてを行うことが難しくなってきます。

このような場合、テストケースに優先順位を付けて優先度の高いものから実施します。重要なテストから先に行うのです。今回の小川くんの質問の意図ですが、もう少しレベルが高く、テスト実施時に重要なテストを知るのではなく、テストケースを書く段階で重要度の高いテストは何かを知って対応したいということです。つまり、よりよいテストケースを書くためにテスト対象の品質リスクを把握しておきたいということです。リーダとしてテスト対象の品質リスクは何かをメンバに伝えた方がよいでしょう。

大塚の質問　～テストケースの粒度

小川君の質問が終わったところを見計らって大塚先輩が質問をしました。

大塚先輩：

千秋ちゃんのテストケースを見て、みんな気づくことはあるかな。

千秋：

大塚さん、私のテストケースが駄目ってことですか。

小川君：

僕も少し気づいていたんですが、言葉にできなくて。

千秋：

何よ。ちゃんとはっきり言ったらどうなの。

小川君：

前のプロジェクトでも似たようなことがあったんだ。前のプロジェクトはたくさんの人がテストケースを書いていたんだ。それを見たときに感じたんだけど。

中山君：

それは、テストケースの粒度かもしれない。テストケースには粒度があるんだ。
（⁠やっと、先輩らしいことが言えた）

千秋：

テストケースの粒度？　聞いたこと無いわ。

小川君：

当たり前だろう。僕らは知らないことが多いんだ。中山先輩、その粒度というものを少し説明してもらえますか。

中山君：

えっ、説明？！　うまく説明できないけれども、テストケースには粒度はあるんだ。

大塚先輩：

それについては、後で本を紹介するよ。それを読めばおおむね分かると思うよ。

（本の該当ページを読んだ後）

千秋：

テストケースに粒度があるってのはわかったわ。じゃあ、適切な粒度ってのは誰に聞けばいいの？

小川君：

テストケースの粒度を決めるのはリーダの仕事ですか？

中山君：

まぁ、そうなるのかなぁ。

千秋：

中山クンが決めなかったからいけなかったってこと？

テストケースの粒度を決める。

一人でテストケースを書く場合は、テストケースの粒度にそれほど悩まないかもしれません。また、書く人が多くても、同じチームでずっと仕事をしているのであれば、コンテキストが共有されていますので、それほど困らないかもしれません。しかし、プロジェクトで仕事をしている場合、そのつど要員が集められますので、コンテキストが共有されていません。そのため、テストケースの粒度にリーダは気を配らなくてはならないのです。

テストケースの粒度というのは、言葉の定義と異なり定義しづらいものです。一言で表現できるものではありません。そこで、テストケースのサンプルなどを用意して、メンバの理解を促す必要があります。勘違いして欲しくないのですが、リーダがテストケースのサンプルを書くべきだと言っているわけではありません。テストケースのサンプルを用意するというタスクを計画の中に入れ、作業を指示する必要があるということです。

テストケースの粒度について

大塚先輩が言っていた本は、『基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために』です。

同書によれば、Rex BlackがRoss Collardの話として次のレベルを提示しています。

アメリカの事例ですので、日本の現場でよく見かけるテストケースとは異なる記述もありますが、粒度についてのニュアンスは伝わると思います。

ここで伝えたいことは、テストケースには粒度があり、テストの種類のよっては細かすぎてもいけないし、大まかすぎてもいけないということです。また、同じシステムテストでも、テストの種類によっては、粒度を変えなければいけません。これらを理解した上で、粒度を決めていく必要があります。

大塚の質問　～リーダとしてのテスト実装を考える

大塚先輩：

中山君はリーダとしてどのようにテスト実装工程を考えれば良いと思う？

今までの議論を聞いていて大塚先輩はきっと中山君はリーダとしてのテスト実装のイメージがないのではないかという疑問を持ったので、あえて質問をしたのです。

中山君：

リーダとしてテスト実装をどう考えればいいか…ですよね。

（…こまったなぁ。今までは、自分がテストケースを書いていけばいいんだし、今もテストケースを書く立場なんだけど…。）

（⁠「⁠テストケース書いたことあるよね。」「⁠じゃぁ、書いて。」だけじゃだめなんだよね。たぶん。）

（そういえば、進捗は何ではかるんだ？　1日あたりの作成テストケース数か？）

（テスト実装工程には計画上1週間用意してあるけれども、その間どうやってみていくんだ？）

考え込む中山君に、大塚先輩が声をかけました。

大塚先輩：

多くの場合、このテスト実装工程から急にテスト担当者が増員される。それだけに、指示の出し方や進捗管理といった視点が強く必要になる。

中山君：

はい。テスト設計までは、どちらかというと少人数で集中的に行いますものね。

中山君：

なるほど、僕には「多人数で作業を分担しながら行う」という視点が抜けていたようです。

テスト実装の方針を示す

先ほど、小川君が「テストケース作成の優先度を示してほしい」というようなことを言っていましたが、それこそが方針のひとつです。テストケースの作成には大きな手間がかかりますし、分担して行うことも多い作業です。したがって、方針を出して、それに従って作業を行ってもらう必要があります。

テストケースの作成状況をモニタする

テスト実装工程での主な成果物はテストケースです。ですから、日々の進捗を図るひとつの指標としてテストケースがあります。目標数に対してどれくらい作成できているのかを把握して、もし作成ペースが遅かったりした場合には手を打ちましょう。たとえば、テストケースを作成する対象や適用するテスト技法についての詳しさによってペースは変わります。また、テストケース作成難易度というものもありますから、そこらも加味しながら注意深く決めていく必要があります。

作成したテストケースはレビューする

あるプロジェクトでは、作成したテストケースのうちの20％はそれ自身がバグを持っていたそうです。バグがあるテストケースに従ってテストをしても結果はきっと間違った結果となりますし、テストケース群が持つ信頼性も下がります。従ってテストケースは作りっぱなしにせず、確実にレビューを行わなければなりません。そしてその最終的な承認を行うのはリーダやマネージャとなります。リーダはテストケースの品質に責任を負いますので、レビューなど品質を確保するための施策をとる必要があります。

定期的なミーティングを行おう

もちろん他の工程でも重要ですが、複数担当者による分担作業が増えてくるこのテスト実装工程以降はより細かい進捗管理が必要となることがすでに書きましたが、そのための仕組みを入れる必要があります。メールベースでの進捗報告も対面での進捗報告会を行いましょう。日ごとや週ごとに定期的に行い、状況把握の漏れを防止するとともに、プロジェクトに起きている問題の早期発見、メンバ間のコミュニケーション、連絡事項の示達を行います。

できるだけ、それぞれのミーティングが短時間で終わるように報告内容を決め、また、ちゃんとモデレータを置いて進行しましょう。朝ミーティングや週次ミーティングを行っていない現場は導入をお勧めします。

おわりに

大塚先輩のアドバイスに中山君はまず自分のリーダとしての像を考えるべきだと思いました。そこで、翌日に改めてリーダとしてのミーティングを開くこととし、それまでの時間までに千秋ちゃんの（最低限の）受け入れ作業を行うことになりました。今回は中山君にとっても反省することが多かったできごとでした。

このように、テスト実装から人員が大量に追加されることも多いかと思いますが、ここで失敗してしまう人も多いでしょう。追加されたメンバに単なるお手伝いとして作業を担当してもらうのではなく、プロジェクトのリソースとして活用する視点がリーダには必要となります。また、テスト実装の方針、たとえばテストケースを作成するにあたってのその優先度や表現形式などを示しておくことも必要です。

果たして中山君は「単なる作業振り分け屋」からリーダに脱皮できるでしょうか。それは、今回の大塚先輩のアドバイスなどを意識して行動できるかどうかにかかっています。

次回は、テストケースを実行する工程「テスト実行」です。