ここまでの状況

テスト実行の工程に入り、まずはそれぞれがテスト実装で分担した範囲のテストケースを実行することとなりました。15時になりお互いの状況を確認するために会議室に集合した3人でしたが、お互いに状況を共有してみると問題が山積みでした。混乱した状況を見た大塚先輩は、3人にアドバイスを出すことにしました。前回は、小川君にテストレポートやインシデントレポートのフォーマットについてのアドバイスを行いました。今回は千秋ちゃんへのアドバイスに移ります。

テスト実行のためにはテスト環境とその準備が必要

大塚先輩：

次に千秋ちゃん。

千秋：

はい、私には何でしょう？

大塚先輩：

千秋ちゃんはハードの確保やソフトのインストールの作業に手間取っていたという話だったね。

千秋：

だって中山クンが準備してくれてないんだもの。やになっちゃうわ。

中山君：

ご、ごめん。

大塚先輩：

こらこら、人のせいにするんじゃない。千秋ちゃんはテストケースのリストは持っていたわけだから、テストケースの実行計画を考えておくべきだったね。

千秋：

じゃぁテストケースの実行作業の前に準備作業が必要ということ？

大塚先輩：

そう。それから、テストケースの実行順番も考えておいたほうがいいね。小川君の実行結果の記録を見てごらん？

千秋：

リストの一番上からじゃなくて、いろんなところをやっているわね。

小川君：

馬鹿正直に上からやっていくよりは、実行順番を変えたほうが効率的だったからね

テスト環境を用意しておこう

テストケースができたらすぐにテストが実行できるわけではありません。そのテストが適切に実行できるための環境を準備する必要があります。

環境には実行端末やネットワーク、OSやアプリケーション、テストツールなどがあります。また、広い意味での環境にはロケーション（場所）や設備（電源等）も含まれます。テストケースの実行が滞りなく行われるように事前に計画し、準備を行っておく必要があります。

また、テストを実行するための“⁠状態⁠”もあります。たとえば、テストケースの実行時、レジストリの内容、HDDの空き容量やディレクトリ構成、その時のOSやパッチ、DBやメモリ空間の状況などが指定される場合があります。場合によっては複数の状況でテストケースを実行することがあります。この状況をいちいち手作業で設定するのは手間がかかります。この場合は、複数のイメージファイルを用意しておいて、状態の復元を容易にしておくなどの手を打っておくとよいでしょう。

中山君は実行環境についてリソース管理の面からも気を配っておくべきでした。

代替機も用意しておこう

テスト環境ではさまざまな機材を使用しますが、それが突然壊れないとも限りません。代替機を用意しておくか、壊れたときにすぐに手配できるようにしておかねばなりません。そして、テスト実行担当者はその手段を事前にリーダから知らせてもらうことが必要です。

社内ネットワークを使うときには情報システム部門に連絡を

ときに、社内のネットワークを借用してテストを実行する場合があります。このときは必ず関係部門と協議を行い、そのスケジュールや体制を作っておかねばなりません。事前に調整しておかなければ、半月ぐらいテストができないこともあり、進捗に大きな影響を与えます。

テストケースの実行は頭を使おう

テストケースの実行はリストの一番上から行うことが唯一の正解ではありません。

小川君はあまり意識していませんが、複数のテストケースの流れを考慮し、束ねて実行することで、できるだけ効率を上げようとしています。

これは「テストスイートを意識したテスト実行をした」ということです。リーダはテスト実行担当者に対して「どのような考え方でテストケースの実行をすれば効率的になるか」ということを教育したほうがいいでしょう。ときどき現場を回り、適切なアドバイスを与えることもリーダの仕事のひとつです。

テストケースだけではテストできない人もいる

テストケースの粒度は組織によって異なり、プロジェクトやチームによっても異なるところもあるでしょう。そのため、実行手順を把握しにくいテストケースになっているかもしれません。

経験豊富なメンバの場合、このようなテストケースでも自らの力で実行手順を考えられます。しかし、経験が少ないメンバがチーム内にいる場合、テストケースの粒度を下げ、テスト手順まで書かなくては、実行できない可能性があります。

テストケースを手順レベルまで記述すると、誰でも同じ手順に従って間違えずに行うことができます。しかし、手順レベルまで記述するのは非常に手間がかかりますし、時間もかかります。手順を細かく書くことに工数がとられ、期間内にテストが終わらせることができなければ本末転倒です。だからといって、テスト手順を書かなくてもよいと短絡的に決めるわけにはいきません。チームメンバの経験やスキルを考慮し、テスト手順までブレイクダウンしておかないとテストを実行できなくなり進捗が進まなくなることもあります。

テスト手順を書くかどうかはトレードオフになり、リーダの判断に委ねられることになります。今回のケースでは、小川君はテスト手順まで落とさなくてもよいのですが、千秋ちゃんの場合は必要だったかもしれません。どのようにすればよいのか皆さんも考えてみてください。

テストの実行状況をモニタ＆コントロールしよう

大塚先輩：

最後に中山君。テスト実行の管理面が考えられていないね。

中山君：

はい……。小川君に言われてびっくりしました。だって、テストケースリストの実行結果欄が全部埋まれば終わりだと思ってたから……。

大塚先輩：

ふぅ、確かにそれはそれで間違ってないけれど、問題は全部埋まるまでの状況を適切にモニタしなければならないんだよ。

中山君：

モニタですか？

大塚先輩：

思い出してごらん、昔いたプロジェクトで先輩はいろんなグラフを作ったり、実行するテストの順番や数を変更する指示を出していなかったかな？

中山君：

言われてみれば、テストケース消化曲線？とか作っていたような気がします

大塚先輩：

状況を可視化し、何か問題があれば手を打つ。そして期限までにテスト実行が終了するようにコントロールしていくんだ。

テスト実行は実行状況のモニタとコントロールが重要

テストの実行時、すんなりと物事が進むことはあまりありません。千秋ちゃんのように、実行環境ができておらずテストが実行できなかったり、バグの改修が遅れたことでテストが実行できなかったりすることもあります。

実にさまざまな要因にテストの実行は影響を受けます。したがって、テストの実行状況やバグのヒット状況などの情報を常に収集し、何か問題があれば速やかにその問題を取り除く努力をします。このとき、収集すべき情報の定義や情報収集のためのシステムと方法、表現方法や状況フォローミーティングなどについて決めておかねばなりません。

状況はグラフを使って可視化する

テストケースの消化状況やバグの発見状況、改修状況などは、グラフを使って可視化すると管理が容易になります。皆さんも一度は「信頼度成長曲線」といったような言葉を見たり聞いたりしたことがあるかと思います。日々の進捗情報を線グラフなどで表すことにより、現在順調に推移しているのかそれとも滞っているのかを把握するのが楽になります。

また、進捗管理目的だけではなく、インシデントレポートからバグの種類情報をグラフ化して傾向をつかみ、それに応じてテストケースの実行順番を組み替えたり、補強したりすることもできるようになります。

これは航海に似ていますね。テストプロジェクトという船が無事ゴールにたどりつけるように、さまざまな計器を使って情報を可視化し、問題があれば対処します。そして、それらから得られる情報を組み合わせて、次は何をすべきなのかを考えるための指針としていきます。

データのみに頼らない

状況の把握には数字を集めるのが楽ですが、残念ながら数字だけではわからないこともあります。必ず現場を回りミーティングを開くなどして、隠れた（見えない）問題がないかを発見する努力が必要です。中山君はテスト実装のときにもミーティングを開きましたが、同様なことを心がけねばならないのです。

おわりに

テスト実行の初日、それぞれ個別に実行作業を行いましたが、さまざまな問題が発生しました。小川君はテスト実行の結果の記録方法について、千秋ちゃんはテスト実行環境について、そして中山君はテスト実行管理について、でした。これらはそれぞれ独立した問題のように見えますが、リーダがこれらをすべて考慮しておく必要があります。どのように行うのかをしっかりとメンバに伝え、そしてその状況をつかまなければなりません。

このテスト実行工程では特に「進捗管理」の観点がリーダに求められます。星取表に印をつけるだけ、というようなチープな管理にならないようにしましょう。進捗管理をしっかり行うと、その分の工数は増えますが、問題の早期発見・早期対処が可能ですので、全体としては工数の削減に寄与します。面倒くさがらずにしっかりと取り組みましょう。

次回は、これまでのテスト活動を総括して報告する「テスト報告」です。