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

第14回 テスト報告(後編)

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

【今回の登場人物】

大塚先輩:
入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で,暇さえあれば写真を撮りに出かける。

中山君:
入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。

小川君:
入社2年目。新人研修後,その有望さから半年間顧客先に常駐。テスト業務の他,設計作業も経験を積んできた。趣味はベースで,定期的に仲間とライブを行うなど仕事と趣味を両立している。

千秋ちゃん:
入社2年目。小川君の同期で,開発部門所属。今までコーディングと単体テストは経験があるが,システムテストに関わるのは初めての経験。趣味は自分磨き。

ここまでの状況

テスト実行も終わり,最後の仕事としてテスト報告を求められた中山君。二時間ほどで報告書を仕上げて大塚先輩のところに持っていくと,あえなく却下されてしまいました。大塚先輩が言うにはこれはテスト報告書ではないとのこと。また,本来この報告書を書く前にやるべき作業を行っていないと指摘されました。

中山君は席に戻り一生懸命考えてみましたが,何が悪いのかさっぱりわかりません。

小一時間悩んでいると,その様子が気になった小川君が席にやってきました。

テスト報告書は誰のために作るのか

小川君:
中山さん,どうしたんですか? なんだか悩んでるみたいですが。
中山君:
あぁ,小川君か…。
実はね,大塚先輩のところにテスト報告書を持って行ったんだけど却下されちゃって…。
小川君:
なるほど,ちょっと見せてもらってもいいですか?

小川君は中山君からテスト報告書を受け取るとパラパラとめくってみました。

小川君:
なるほど,確かにこれをテスト報告書というところもありますね。
中山君:
うん,大塚先輩は何でこれを駄目だっていうんだろう。
小川君:
でも,普通はテスト報告書とは言いませんね。
中山君:
えっ,どういうこと?
小川君:
これはテスト実行結果ログの表紙を変えただけですよね。テスト実行結果ログそのもで,報告内容がありません。

テスト実行結果は報告書ではない。

テスト実行結果に「テスト報告書」という表紙を付けて終わりにするところもあります。しかし,報告はさまざまな情報を収集し,整理し,分析して,客観的事実を提示しつつ,場合によって見解を述べるものです。

ですから,分析も何もせずに実行結果を報告だというのはあまりに乱暴ですし不適切です。もし,このようなスタイルがまかり通っている場合,ひょっとするとテスト活動を評価するという文化がない可能性があり,それはテストの継続的な向上に大きく支障をきたします。

テスト実行結果ログだけで報告を考えない

テスト実行だけがテスト活動のすべてではありません。テスト計画で作成したテスト計画書に基づいてプロジェクトがすすめられたわけですから,その計画に対して実績がどうであるかを比較する必要があります。また,各工程での問題点などもあるでしょうし,それこそバグの分析結果であるとか,リソースの消費状況なども報告内容になるかもしれません。さまざまな情報を今一度再整理して評価する必要があるのです。報告するのはテストケース消化状況のみではありません。

誰に報告するのか

テスト計画の回でも触れましたが,報告書を作る際には「誰に報告するのか」を明確に意識しなければなりません。今回の場合,大塚先輩は「柏田マネージャに」と言っています。ですから,柏田マネージャが読むことを意識して,内容を吟味する必要があります。

さらに,最終的にはお客様に対して説明しますので,納品物としての品質が保つように意識しなければなりません。

報告内容を吟味しよう

「誰に」が決まったところで,次は「何を」です。報告先によって報告してもらいたい情報は異なるはずです。報告書を作るに当たっては報告内容を報告先にヒアリングするなどして定義する必要があります。報告相手が望んでいない内容は報告でないことを理解してください。

開発プロセスや標準が定義されている場合,たいていの場合テスト報告書のフォーマットは決まっているはずです。まずはそれを探しましょう。ただ,その場合でも,そのフォーマットを使った報告で問題ないかは報告先に確認を取りましょう。

もし社内標準がなく,一から作らなければならない場合は,⁠IEEE std. 829-1998」を利用するという手があります。IEEE std. 829-1998を参考にカスタマイズした目次例を以下に示します)⁠

  1. テスト報告書番号
  2. 本報告の要約と見解
  3. テスト実施内容とようやく
  4. テストの総合評価
  5. 不具合の傾向と積み残し
  6. テストにおける特記事項
  7. テスト実施時のステークホルダー

この目次を元にさらに個別の記述内容を決めていきますが,それは本稿の範囲を超えますので,マインドマップから始めるソフトウェアテストのChapter 9などを参考にしてください。

※)
現在IEEE std. 829 は2008年版となるIEEE std. 829-2008が出ていますが,本稿では日本語での情報が多い1998年版のIEEE std. 829-1998で解説しています。

次回のテスト実行に対する教訓をまとめよう

今回のテスト実行では,小さいながらもさまざまなトラブルが発生しました。その時々で適切な対応が取られたために,大きな問題になることもありませんでした。しかし,このままで終わりにしてしまいますと,毎回同じようなトラブルを起こしてしまう可能性があります。

リーダとして,どんなトラブルがあり,どんな対処を行ったのか,次回のテスト実行にはどんな対策が必要なのかをまとめておく必要があります。

著者プロフィール

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

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

著書


池田暁(いけだ あきら)

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

著書

コメント

コメントの記入