今回は「テスト実施結果報告 は どのように作るべきか」についてまとめます。
報告を受け取る人は何を知りたいのか
【タイミング】
テストフェーズごと（単体テスト、結合テスト…）に結果をまとめて報告する。
システムテストや受入テストなど最終フェーズのテストではそこに至るまでのテスト結果を総括したほうがベター。
労力かかるので実際はあまりやらない気がします（金融系などしっかりした開発を求められる場合は必要かも）。
【報告先】
報告先は自分自身のポジションによりますが、体制図上の上位者が一般的でしょう。
場合によっては、客先やシステムオーナーだったりするかもしれません。
【報告内容】
大きな項目としては「総括を意味する概要」、「具体的な中身を記載した詳細」になります。
報告先にもよりますが、基本はあまり細かな話しをしても仕方がないので、「概要」で8割説明しきる内容で報告が望ましいはず。
「詳細」には「"進捗" と "品質"」と「"テスト" と "アプリ"」を掛け合わせた4観点（テストケース消化、不具合解消、テスト品質、アプリ品質）を記載すると網羅的です。
具体的な内容はこの後の各セクションで詳しく見ていきます。
テスト実施状況の分析
断面として洗い出すとよさそうな数値は以下のようなものがあります。
- 当初計画ケース数
- 実施予定ケース数
- 実施実績ケース数
- 完了ケース数（ or 未完了ケース数）
「当初計画ケース数」は「テストフェーズ開始時点でのテストケース数」、
「実施予定ケース数」は「テストフェーズ完了時点（＝報告書作成時点）でのテストケース数」、
「実施実績ケース数」は「実際に実施してテストケース数」、
「完了ケース数」は「テスト実施して障害検出されずOKとなったケース数」です。
理想的には以下のような数式になるハズです。
「当初計画ケース数」＝「実施予定ケース数」＝「実施実績ケース数」＝「完了ケース数」
「当初計画ケース数」と「実施予定ケース数」にはズレがあることがあります。
テスト実施する中で、テストケースの追加や削除を行った場合です。
これらについては後続のテスト品質分析で原因分析と対策を行います。
「実施予定ケース数」と「実施実績ケース数」がズレることはまずありえないです。
もしあるとすればそれは管理者の管理怠慢としか言えない気がします…。
報告時点ではケース実施不要の判断をして「実施予定ケース数」＝「実施実績ケース数」にしてしまいましょう。
「実施実績ケース数」と「完了ケース数」がズレる場合は状況によってはありえます。
未完了ケースがあるということは、障害が解消できないためにケース消化ができていないという状況です。
該当の障害が後続テストに影響ないことを確認するか、または後続テストに影響がないよう調整します。
時間とともに実施ケース数が増えており、最終的には飽和していることを確認します。
最初はどうしても消化ケースが増えないですが、中盤からいっきに増えます。
終盤で盛り上がっているのは追加テストを実施した場合です。
理想的には一通りテストが終わった後に不具合分析して追加テストして終結するのが良い気がします（コストかかるけど…）。
不具合解消状況の分析
断面として出す数値としては以下のようなものがあります。
理想的には以下のような数式になるハズです。
「総検出件数」＝「解消件数」
一致しない場合、解消できていない障害が残っている状況になるので、残障害となるものそれぞれについて今後どのような対応を行っていくのかの方針を示します。
一般的に信頼度成長曲線はS字カーブを描きます。
時間経過とともに不具合発生件数が飽和していき、不具合解消件数も飽和している状態であることを確認します。
テスト品質の分析
テスト自体（テストケース、テスト実施者、テスト環境）の品質を確認するものです。
実施したテストが必要十分なケースであり問題のないテスト実施であったことを示します。
テスト実施していると「テストケース追加」や「テストケース削除」が起こります。
実施していると見えていなかったものが見えてくることから起こるものです。
「テストケース削除」は「実施できないので後続テストフェーズに移管」か「他ケースで担保できるので実施不要」となって消されることが多いです。
このケースであれば、本当に必要なことをやっていないわけではないので特に問題ではないです。
「テストケース追加」は「ある観点が漏れていた」可能性があります。
類似する観点でほかに漏れがないか確認できているかを示す必要があります。
テスト実施中にはいったん起票されたが実は障害ではなかったというものが紛れています。
そうした障害にならなかったチケットはテストケース、テスト実施者、テスト環境に問題があることが多いです。
以下に示すように大きく3分類してさらに詳細原因を深掘りしていきます。
テストケース不備
- ユーザーの要求事項別
- 機能・サブシステム別
- テストケース作成者別
オペレーションミス
- 根本原因別（プロセス、マニュアル、テストケース不備、テストツール…など）
テスト環境不備
基本的には上述の観点を参考に、どこに偏りがあるかを見つけて対策を打っていきます。
いわゆる「False Negative」なケース。
テスト実施後の承認タイミングで起票漏れが検知されたようなケース。
実施者に問題があるケースが多いイメージはありますが、数値で示すなら以下のような分析をしてみると良い気がします。
- 実施者別
- テストケース作成者別
- ユーザーの要求事項別
- 機能・サブシステム別
アプリケーション品質の分析
テスト実施されたアプリケーションの品質が十分高まっていることを示します。
不具合がなぜ埋め込まれたのか、その影響はどんなところに対するものかなど、不具合が入り込む過程と影響する内容に関する分類です。
| 重大度別 |
主観的な評価になりやすい項目になるのであらかじめ定義が必要です。
たとえば、エンドユーザーに対する影響度という視点で以下のように切り分けてみます。
- 「高＝エンドユーザーに対する影響がある」
- 「中＝その他何かしらの影響がある」
- 「低＝未発現で実質的な影響がない」
これらの定義に従った分類をした際に偏りがないかを確認します。
（障害対応の "優先度" とは異なるので注意してください）
|
| 現象別 |
どのような症状があらわれているかで分類します。
直接原因となっている欠陥の内容ではなく、発現している事象で分類します。
たとえば以下のようなものになります。
- 画面表示（崩れ、位置が不正、項目過不足、無反応）
- 入力チェック
- 登録内容
- メール（未送信、内容不備）
- プッシュ通知（未通知）
- ファイル（出力されない、項目過不足、内容不備）
- 通信（接続できない）
|
| 原因別 |
不具合を埋め込んでしまった根本原因別で分類します。
m-SHELL などを参考に原因分類してみると良いでしょう。
- 管理
- ソフト（プロセス、手順書、マニュアル…など）
- ハード（ツール…など）
- 環境（PC、モニタ…など）
- 当事者
- 関係者
|
| 混入工程別・除去工程別 |
どの工程で欠陥を埋め込んでしまったか、本来どの工程で除去すべきだったかという視点で分類します。
前工程で適切な除去ができていないようであれば、さかのぼって見直しをする必要があります。
|
不具合そのものがどのようなものであるかを分析したものです。
- ユーザーの要求事項別
- サブシステム別・機能別
- ソフトウェアの処理分類別
- データ項目別
| ユーザーの要求事項別 |
不具合に関連する要件を記載します。
複数要件にまたがる不具合も起こりうるので複数入力できると良いでしょう。
特定要件に不具合が集中している場合、その要件の見直しや追加テストを検討します。
逆に特定要件で不具合が出ていない場合、誤ったテストをしていないか、テストに不足がないかを確認します。 |
| サブシステム別・機能別 |
不具合が発生したサブシステム別や機能別に集計します。
分析の考え方は要求事項別と同じで、不具合が多すぎる機能、少なすぎる機能に対して分析を行います。 |
| ソフトウェアの処理分類別 |
不具合の原因となった箇所（欠陥箇所）の処理分類別に集計します。
- 画面表示
- 入力チェック
- データ登録
- データ検索
- データ更新
- データ削除
- 文字列操作
- 算術演算
「不具合の現象」と似ているが異なるものです。
「現象」は「ユーザーによって認識される事象」ですが、
「処理」は「現象を引き起こす不具合の原因（欠陥）」です。
|
| データ項目別 |
不具合が影響を及ぼしているまたは不具合の原因となっているデータ項目別に集計します。
対象としている業務にも依存するので一概に例示できないですが、以下のようなものが考えられます。
- 権限
- ユーザー情報
- 管理者情報
- 企業情報
- 記事情報
少し抽象的な記載になっていますが、もう少し具体的な分析を行えばよく問題を起こすデータ（注意しなければならないデータ）などがあぶりだせるようになります。
過去から修正を繰り返すことで取り回しが難しくなってしまったデータ、なんてものも存在するので…。
|
不具合を見つけたテストに関する情報で分類します。
どちらかと言うとシステム全体を通しての品質分析での利用になると思います。
各テスト工程でこの分類は出てこないでしょう。
| テスト工程別 |
テスト工程別に集計します。
- 単体テスト
- サブ内テスト
- サブ間テスト
- システムテスト
|
| テスト種類別 |
テスト種別ごとに集計します。
- ドキュメントレビュー
- ウォークスルー
- コードレビュー
- 機能確認テスト
- 制御フローテスト
- データフローテスト
- 状態遷移テスト
- リグレッションテスト（修正箇所に関連する）
- デグレードテスト（修正箇所に関連しない）
- セキュリティテスト
- ユーザビリティテスト
- 性能テスト
|
| テスト観点別 |
テスト観点別に集計します。
テスト観点については「テスト観点 の サンプル」にもまとめているので参考にしてください。
|
今回は「テスト実施結果報告 は どのように作るべきか」についてまとめました。
ただ、見て分かる通り、この報告を行うためには障害管理を報告できるように行うようにしないといけません。
障害管理を始めるときにあらかじめ最終的な障害報告までイメージしてないと実運用では困りそうですね…。
参考になったでしょうか？
本記事がお役に立っていると嬉しいです！！
