misc.log

日常茶飯事とお仕事と

テスト結果報告書が書けない

テストを行った後の報告を、プロジェクトが使っている書式にあわせて書いてみたのだけど……書けない。筋が通らない。難しい。なぜかを考えてみました。

章立てがおかしい

そもそもの原因として、フォーマットにある章立てがおかしいように思います。文章が流れないんです、上から下に。まず、サンプルにあった章立てを見てみると…例によって方眼エクセルの資料、1シート目が

  1. 前提条件
  2. 実施期間
  3. 発生不具合
  4. 分析
  5. 評価

となっていました。続いて、テスト件数等の概略一覧、障害一覧、テストケース一覧とシートが続きます。

先に答えを言いましょう。おかしいのは1シート目、上記箇条書きの中で「テスト結果」を簡単な表と文章で書くべきなのに、それが無い、です。

前提条件??

まず、前提条件が結果報告の冒頭というのがおかしいですね。前提条件は、テスト計画書やテスト仕様書で「テストをやる前に、一言言っておきますよ。」という風に書くべきもの。終わってから「前提はこうだ」というのはそもそも筋が通らない。で、前提なんだから「~とする」だろう、と書いてみると内部レビューで「結果なんだから過去形じゃないとおかしいだろう」と指摘を受ける。もうなんというか、そもそもの前提がよくわかんないので、ヘラヘラと笑いながら「そうですねー」で直すしかありませんでした。

いやいや、まじで、前提条件が過去形とか意味わかんない。
「~のテストは~の理由で省きました」……それは言い訳です。

前提条件は、事前に以下のようなことを開発組織および顧客と取り決め、作業の範囲や、特に、「やらないこと」を明示するためのものです。テストの過程で致命的な問題や不具合が発見された場合などの対策として、納品の条件や既知の不具合として条件をつけることはありますが、それは「前提」ではありません。

発生不具合ありきの報告はおかしい

テストの結果報告であるのに、結果より先に不具合(障害)情報を書くとかどんだけマゾヒスティックテスト、自虐テストなんですか。まずはテストの結果でしょう、書くのは。何件のテストを行ってどれだけの問題が出た/出なかった。そのあとで「発生した問題」と「対応出来なかった残件」の報告ではありませんか。

よく、テスト結果に不具合件数がゼロだから、指標値とのつじつまが合わなくてバグをでっち上げるなんて話がありますが、まさにそれがエスカレートした結果、「テスト結果より先にバグの内容を聞かせろ」となっちゃった感じ。おかしいです。

たぶん、テスト結果は2シート目にテストケースのカテゴリーごとに件数および発生不具合数、対応不具合数を書いているから……ということなんでしょう。ですが、文章を読む人は先頭から読みます。この先にどんな文章がエクセルシートが待っているかを知っているのは作り手だけ。先のシートに結果があるのなら、1シート目の文章による報告には「テスト結果……シート***を参照」などとリンクを書いておくべきです。

分析は何の分析?

いらないと思う。テスト結果の報告は品質や開発体制、方式の分析とは別で、事実を淡々と書くべき。報告者の勝手な分析結果や意見など求めていません。

さらに、あえて書くとしても、明示的に文章の流れの上流で「結果」を書いていない報告書なので、「分析」という章を立てられても何を分析するのか分かりません。仕方なく一番ありそうな分析対象はというと、「文章は上から下に流れる」の流儀から、前述の「発生障害」しかありませんね(物語が逆走したり、エンディングのシーンから始まるのは小説だけです)。

仮にテスト結果に対する分析をここで書くとしても、本来であれば、「テスト結果」が冒頭にあるので、その内容に対する分析。たとえば、「単体テストで処理すべき問題が結合テストでも発生している。テスト期間および要員配置の見誤りで単体テストが不十分だったと考えられる。」といったネガティブな結果に対する分析や、「開発規模が小さいことと、既存機能を流用できたことでテスト期間の短縮と不具合なしという結果となった。」などポジティブな結果分析ができるはず。でもそれが無いから「何書けばいいの??」となる。というか、実際になった。

内容がそろっていないのに評価もへったくれもあるか

資料としては「どこかに書いてある」としても先に述べたとおり、読み手は先頭から読んでいきます。その流れに全体的な結果、テストケースはどれくらいこなして、不具合はどんだけでて、何が片付いていないか、という情報が無いのに「評価」はできません。

通常のウォーターフォール的な手順での開発なら、結合テストのあとはシステムテストとか運用テストとか呼ばれるような行程です。結合テストの評価は、その「次工程」へ進めるかどうかという判定になりますから、通常は「発生した不具合はすべて対応されており、結合テスト完了とみなす」といった判断が記載されるはず。もしくは、最悪のパターンとして「致命的な問題が発生しており、設計工程からの見直しが必要。工期を2週間延長して再テストを実施する必要がある。」というのも「評価」です。

そういう「最終結論」を書くには、やはりそこまでの文章で具体的な「結果」か、もしくは「詳細な結果への参照を含んだ文章」がそろっている必要があります。

どうすべきだったの?

自分だったら……こういう風にするかな。たしか、ソフトウェア・テスト PRESS Vol.5とかに書いてあったかな……。ある程度おきまりのテンプレートがあるはず。下記の内容はあとで訂正するかもしれないですが、

[テスト結果シート]

  • テスト実施期間とテスト環境、作業人員等の消費リソース
  • テスト実施結果
    • 実施予定テストケース
    • テスト実施実績件数
    • 発生障害と未対応件数(テスト期間に間に合わなかったものの有無)
  • 不具合情報
    • 発生不具合件数と傾向
    • 未対応件数と理由
  • テスト結果評価
    • 完了判定
    • 完了に際しての条件(未対応不具合は先で対応する、とか)

[発生不具合リストシート]
必要ならカテゴライズなどして見やすいように。その辺はプロジェクトで不具合管理をどうやっているかによるので一概に言えない。

  • 発生不具合の管理番号
  • 発生不具合の内容概略
  • 対処済み/未対処

テストケースなどは別途資料にまとめるべきだし、報告書は可能なら2枚~3枚に収めるべきでしょう。

なんというか、誰も何も考えてないのかな。