はじめに
テスト実行管理に関わるトピックとして、今回テスト結果を取り上げてみた。
自分は2016年にプロダクトマネージャからテストエンジニアにロールチェンジしました。
当初は、JSTQBも知らず、独学なやり方でQA組織の構築を行なってきた。
その中でも、テストレポートは当初テキトーでしたw
JSTQBやテストに関する書籍を通して、レポートの書き方、重要性を徐々に学び、経験してきた。
そこで、当時の過去の自分に教えたい、テストレポートの重要性を書き綴る。
テストレポートとは
テストレポートは、ソフトウェアテストの実施結果をまとめたドキュメントです。
テストの目的、範囲、実施期間、発見された不具合、テスト結果の評価などを客観的に記録し、関係者に報告するために作成する。
テストレポートの主な目的として、5つ挙げる
1. テスト結果の記録と展開
テストの実施状況、発見された不具合、テストケースの結果などを客観的に記録し、将来の閲覧や分析に用いる。
開発チーム、プロジェクトマネージャー、顧客などステークホルダーに、テスト結果を正しく、わかりやすく展開する。
2. 品質評価
テスト結果に基づいて、ソフトウェアの品質レベルを評価し、リリースの可否を判断するための品質評価になる。
3. 改善点
潜在的な問題やリスクを早期に特定し、今後の改善に繋げる。
プロダクトの品質だけではなく、テストケース、テスト環境、テスト手法などの改善点を見つけることで、今後のテストプロセスの効率化にも貢献なる。
さらに、開発プロセスにおける問題点を洗い出し、開発プロセス全体の改善に繋がる場合もある。
4. 責任の所在の明確化
不具合が発生した場合、誰がいつどのようなテストを行ったのかを明確にすることで、原因究明や責任の所在を明らかにできる。
5. コミュニケーション
テスト結果を展開して、開発チームと顧客間のコミュニケーションを円滑にし、プロジェクトの成功に貢献する
テストレポートは、単なる報告書ではありません。
ソフトウェア開発の意思決定の材料になる。
これら目的を達成するために、正確かつ客観的な情報を盛り込み、ステークホルダーが理解できるようにすることが重要である。
不具合レポートの必要要素
不具合レポートは単に報告書ではありません。
レポートを受け取ったエンジニアが、短時間で状況を把握し、バグ修正に必要な情報がそろっていて、そのバグを直すように働きかけることが求められる。
レポートを書くにあたって、以下のことを意識するといい。
1.再現（発生頻度）
バグがどの確率で発生するかを示す。
エンジニアがバグの再現をするときに、発生頻度が低い場合バグ出ないと誤判断してしまうためである。
また、具体的な数字（５回中５回発生するのか、１００回中１回なのか）を記述すると、エンジニアは助かる。
2.分離（原因特定）
一つのバグに対しテスト条件を変えてテストする。
そこからバグの原因につながるような情報（限られた条件で発生する等）を導き出す
例えば、chromeで発生するが、firefoxで発生しない（ブラウザ依存のバグ）。
user Aで発生するが、user Bで発生しない（ユーザー依存のバグ）。 など
3.一般化（影響範囲）
一つのバグに対して類似した処理が同様のバグを含んでいないかを確認する
2に近しいかもしれない。
例えば、商品Aの購入が失敗した場合、別の商品でも失敗（購入処理の大きな機能不具合であるか、データ依存なのか）しないかを確認する
4.比較
旧バージョンのシステム、別の環境（iOS、Android等）で見つかったバグの再現性を確認する。
今回のバグがデグレ、特定環境でのみ起きる、既存バグであるかを確認することで、開発の対応判断の助けになる
5.要約
バグの内容を簡潔に、いろいろなステークホルダに理解できるようにまとめる。
バグ報告、分析等を行いやすくする
また、エンジニアは、長文やテストステップを全部読むと時間がかかってしまうため、１センテンスで何が起きたのかがわかると助かる。
6.凝縮・明確化
不必要な情報、あいまいな情報を削る。
報告されたバグの内容から発散しないように、誤解を招かないようにする
余計な情報を含むと、脱線して調査する可能性がある。
7.中立化
中立の立場からバグを客観的に報告する。
プログラマ、システムの実装、コーディングの非難、バグ改修内容の提案などは避ける。
自分がレポートを受け取った時に、不愉快を感じないかを考えてみると良い。
8.プライオリティ
バグの重要性、優先度を定義する。
このバグにより、ほかのテスト活動に影響の有無を伝える（例えば、これがブロッカーとなりほかのテストが実行できない等）
また、このバグによりビジネスリスクがどの程度あるかを伝える
伝える技術
「ＢＣＧ流経営者はこう育てる」の書籍の中で、「伝えるから共有へ」というセンテンスがある。
Said ≠ Heard
（こちらが言ったからといっても、聞いてもらえたわけではない）
Heard ≠ Listened
（“聞いて”もらえたからといっても、“聴いて”もらえたわけではない）
Listened ≠ Understood
（聴いてもらえたからといっても、理解してもらえたわけではない）
Understood ≠ Agreed
（理解してもらえたからといっても、賛成してもらえたわけではない）
Agreed ≠ Convinced
（賛成してもらえたからといっても、腑に落ちて納得し行動しようと思ってもらえたわけではない）
これは何を指しているかというと、不具合レポートに置き換えてみると、「不具合レポートを言った（作った）」からといって、エンジニアが納得して不具合改修へ行動してくれるわけではない」ということである。
先に記載したように、テストエンジニアは、不具合レポートを持って、エンジニアに不具合改修させることが、真に求められる活動である。
つまり、レポートを書くだけに終わらせてはいけない。
言った後に、エンジニアに動いてもらうために、どうするか、何が必要なのかを考えた上で、レポートを作成して展開する必要があると思う。
このことは、過去の自分に何回も言わせたことだと思う。
いくつもの不具合レポートで放置されたものがあったことかw
テストエンジニアには、レポートスキルだけではなく、そのレポートで人を動かすためのスキルも必要です。