概要・テスト品質を良くするにはテスト報告書にテスト結果とテスト評価を書く
ソフトのテスト報告書はテスト結果とテスト評価の両方を書く
テスト品質を良くするには、今回のテストを振り返って良かった点・悪かった点を次のテストに反映する事が大切です。テスト作業の振り返りはテスト後に作るテスト報告書見て行うのですが、テスト報告書にテストの結果（見つけたバグ等）しか載っていないと、テストの振り返りができません。テスト品質を良くするために、テスト報告書にはテスト結果とテスト評価を分けて書くと書き留めておきましょう。
テスト結果とは、テスト対象のソフトの品質の良し悪しについての情報で、リリースの可否を判断する時に参照する大切な情報です。具体的には、テストで発見した不具合についての分析結果と個々の不具合の内容がテスト結果です。テストの直接的な成果物がテストで発見した不具合ですので、テスト結果とはテスト成果物と言う場合もあります。テストで発見した不具合の情報量は膨大ですので、テストの成果を有効に活用するにはテストの結果を様々な視点から分析した分析結果と合わせて、テスト結果としてテスト報告書に書くのが一般的です。
テスト報告書に書くもう一つのテスト評価とは、テスト内容やテスト日程やテスト効率 などのテスト作業そのものの良し悪しについての評価です。テスト評価とは、今回のテストが計画どおりの効果を出せたか、という視点で書いたテストの良し悪しについての情報です。テスト評価は、今回のテストを振り返って良かった所や悪かった所を確認し、今後のテストの改善役立てる大切な情報です。
テスト結果もテスト評価もどちらも大切な情報ですので、テスト報告書には、この２つの内容を整理して、判り易く書いておきましょう。
テスト結果はリリース判断でのソフト品質の基礎情報
テスト結果とはテストで発見した不具合やバグの状況です。どんな不具合やバグを何件見付けたのか、バグの修正状況はどうなのか、先送りされたバグにはどんな物があるのか、バグ検出の収束状況はどうなのか、などなど今回のテストの対象となったソフトの品質の良し悪しを判定するための情報を整理して、テスト結果として取りまとめます。
このテスト結果は、ソフトのリリース判定でリリースの可否を決めるための最も重要な情報になりますので、できるだけ定量的・具体的に書く事が大切です。特に修正が間に合わずに次回送りとなってしまった残存バグや、一度検出したけどその後再現しなくなってしまった消失バグについては、発生条件や発生頻度や発生した時の影響度合いなど、もしそのバグが市場で発生した時の影響度が判るような内容を判り易く書いておくのが良いでしょう。
残存バグや消失バグの情報とともにリリース判定で重要なのが、まだ見つけていない潜在バグは十分に少ないと言えるのかというテストの十分性です。潜在バグを洗い出し切るのに十分な量と質のテストが実施できているのかを判断できるような情報として、テスト計画に対するテストの完了率や、信頼度成長曲線による残存バグの推定数なども、できるだけ定量的・具体的に書いておおきましょう。
テスト評価はテストプロセスを改善しチームを育てるために
テスト結果はテスト対象のソフトの品質を示す情報ですが、テスト評価はテスト計画や実施した作業の良し悪しについての評価です。計画していたテストの内容が妥当で実際のテストでは計画どおりの成果を出せたのか、テストの内容や日程計画やテスト効率の面から、テストの計画とテストの結果を突き合わせて評価を書いていきます。テスト評価は、今回のテスト作業の良かった点と悪かった点を洗いだし今後のテスト作業のプロセス改善に繋げるための大切な情報という面もあります。テスト評価の書き方もいろいろ在りますが、以下のような３つの観点で書くと判り易くなります。
- テスト内容に対する評価：テストの量や質は今回のソフトの品質の保証に最適だったのか
- テスト日程に対する評価：テストの日程計画は妥当だったのか
- テスト効率に対する評価：テスト作業のコストパフォーマンスの計画は妥当だったのか
（１）テスト内容に対する評価
テストを計画する時には何を重視するのかテスト方針を立てて、そのテスト方針に従って実施するテストの種類や規模や投入する機材・人員を計画していきます。その計画に従って実際にテストをした結果としてバグが検出されるのですが、テストで検出したバグは計画段階で考えていたテストの方針を満たせているか、というのがテスト内容に対する評価です。テスト密度やバグ密度を計画と実績とで対比し、過去の実績と照らし合わせて今回のテスト内容の良し悪しを評価します。
まず最初にテストの量やテスト項目数は妥当だったのか、全体のテスト項目数やテストの種類別のテスト項目数と、それらのテストで検出したバグの件数やバグ密度を元に、テスト項目数の計画の妥当性を評価します。テスト量の評価のつぎはテストの重点領域の設定の妥当性についての評価も必要です。テストの重点領域の設定の仕方には、ソフトの機能を元にして重点領域を決める事もあれば、バグが潜在する可能性の高い領域を想定してテストの重点領域を決める事もあります。テスト計画で考えた重点領域のバグは十分に検出できたのかという観点で評価します。
また、テストの目的として単純なバグの網羅的な洗い出しに重点を置く事もあれば、複雑な条件で発生するようなバグや何百回かに１回発生するような検出が難しいバグの洗い出しに重点をおく場合もあります。どのような考え方でテストの重点領域を設定した場合でも、計画時に設定した重点領域のバグが最初の目論みどおりに検出できたか、という観点から投入したテスト工数と見つけたバグの数を元にテストの計画の妥当性を評価します。
（２）テスト日程に対する評価
テストの日程計画についての評価もしておくのが良いでしょう。テスト作業の日程は計画したとおりに進んだのか、計画よりも遅れが出たのかあるいは計画よりも早く終了したのか、テスト日程の進捗の監視と管理は計画したようにできていたのか。テストの日程が計画どおりに進まなかった部分があれば、それは計画時の推定に何か漏れがあったのかなど、テストの日程計画の良し悪しを評価しておきましょう。
テストの日程は、特にテストの後半から終了間際にかけて計画からズレていく事が多いです。バグが想定以上に大量に見つかったとか、テストの途中で要求仕様の修正が入ってテストの手戻りが発生したとか、ソフト開発の最終段階のテスト工程には、様々な要因で日程が崩れるリスクがあります。日程の管理がうまくできて日程を守れたか、そもそもの日程計画に必要十分なリスク日程が織り込んであったか、等の観点でテスト日程についての評価をします。
（３）テスト効率に関する評価
ソフトのテストは自動化したテストと人手による手動テストに分かれます。自動化したテストが多いほど１回のテストでのテスト効率（テスト項目数/テスト作業員の工数）は良くなります。一方で、自動化したテストは最初に自動化のための開発が必要で、開発の後も変化していくソフトに追従するための保守工数が掛かります。自動化したテストと手動によるテストの比率は、今回のテストにとって最適なコストパフォーマンスを発揮できていたか、評価しておきましょう。
テストは１つのテスト手順で１つのテスト項目を確認するのが基本ですが、テストの手順を工夫すると１つのテスト手順で複数のテスト項目を確認する事もできます。このような工夫をたくさんすればそれだけテストの作業効率は良くなります。これは主に手動テストのテスト効率の良し悪しに影響するのですが、今回のテストではテスト手順１つあたり平均で何項目の確認が行えたのか、という視点でテストの効率を評価しておくのも良い事です。
最後に、テストに仕様した環境や機材の稼働率の面からテストの効率を評価しておきます。コストの面からだけ見れば、環境や機材の稼働率は 100% が良いのですが、稼働率が 100% では逆に環境や機材の空き待ちによるテスト待ちが起きる事もあるので、一概に稼働率 100% が良いとも言えません。普通に考えて、環境や機材の稼働率は70%～90% 程度の場合がテスト人員や日程計画の面も含めた全体としてのテスト効率が良い場合が多いです。今回の環境や機材の稼働率がどの程度になっていたのかも、テストを振り返って評価しておきましょう。
テストが終わったら結果を整理して次に繋げる
テストはソフトリリースの最後のフェーズなので、リリース直前のドタバタに巻き込まれる場合が多いです。場合によっては、リリース判定の直前までテストをしている事もあるでしょう。その様な場合にこそ、テストが終わった後でテストについてのテスト結果とテストの評価をしっかりとテスト報告書に纏めて、次のテストの改善に繋げるようにしましょう。
以下の記事では、テスト報告書の各々の項目についてグータラ親父の経験した事を元にして、もう少し具体的に紹介していきまので、興味のある方はご覧ください。