テストリーダへの足がかり,最初の一歩

第12回 テスト実行(後編)

この記事を読むのに必要な時間:およそ 2.5 分

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

大塚先輩:
最後に中山君。テスト実行の管理面が考えられていないね。
中山君:
はい……。小川君に言われてびっくりしました。だって,テストケースリストの実行結果欄が全部埋まれば終わりだと思ってたから……。
大塚先輩:
ふぅ,確かにそれはそれで間違ってないけれど,問題は全部埋まるまでの状況を適切にモニタしなければならないんだよ。
中山君:
モニタですか?
大塚先輩:
思い出してごらん,昔いたプロジェクトで先輩はいろんなグラフを作ったり,実行するテストの順番や数を変更する指示を出していなかったかな?
中山君:
言われてみれば,テストケース消化曲線?とか作っていたような気がします
大塚先輩:
状況を可視化し,何か問題があれば手を打つ。そして期限までにテスト実行が終了するようにコントロールしていくんだ。

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

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

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

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

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

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

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

データのみに頼らない

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

おわりに

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

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

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

著者プロフィール

鈴木三紀夫(すずき みきお)

1992年,(株)東洋情報システム(現TIS(株))に入社。複数のエンタープライズ系システムの開発に携わり,現在は社内のソフトウェアテストに関するコンサルタントとして活動中。ASTER理事,JaSST実行委員,JSTQB技術委員,SQiPステアリング委員 他。

著書


池田暁(いけだ あきら)

2002年日立通信システム(現日立情報通信エンジニアリング)に入社。設計,ソフトウェア品質保証業務を経て,現在は開発に関する設計/テストツールの導入や,プロセス改善に関する業務に従事。ASTER理事,JaSST実行委員,品質管理学会・ACM正会員。

著書