テスト品質を良くするにはテストの種類とテスト計画とテスト管理とテスト報告書が重要

2021年10月20日テスト品質

ソフトのテスト品質を良くするための4項目

テスト品質を良くするには何をすれば良いでしょうか? テスト品質の定義も色々なので、これが正解という物も無いのですが、グータラ親父は以下の4つの項目でテスト品質を良くする活動をしてきました。

  1. テストの目的と種類:何に重点を置いてテストをするのか、どんな種類のテストをするのかの方針がまず必要です
  2. 良いテスト計画  :方針と目標と体制と日程と管理とバグトラッキング等を具体化した計画書を作りましょう
  3. 良いテスト報告書 :テスト結果(ソフト品質)とテスト評価の両方が書かれた報告書でテストを振り返ります
  4. 必須のテスト項目 :リークテスト、ロールオーバテスト、高負荷エージング 等などは組み込みに必須のテストです

品質を保証するとはテストをして正しく動く事を確認したという事

ソフトの品質を保証するために一番重要なのがテストです、ソフトに限らないですがテストだけが製品の品質を直接的に保証する事ができるからです。ソフトが仕様書に書かれた機能や性能を満たしている事を保証するにはテストをしてその結果が正しい事を確認する以外に方法はありません。テストの品質の良し悪しでソフトの品質保証の良し悪しが決まるので、テスト品質はソフトの品質保証にとって非常に重要です。

1. テストは目的に合わせて計画して管理と評価もしっかりと

ではどんなテストをどれだけ実施すれば良いのでしょうか? 正常系テストや異常系テスト、単体テストシステムテストRAS機能テストセキュリティテスト、などいろいろな呼び名のテストがありますが、どんな種類のテストをどれだけの量実施すればソフトの品質を十分に保証できるのでしょうか?

実施するテストの種類や量が決まったら、それらのテストをリリースの時期までに実施するために必要な機材とテスト人員を整理したテストの計画も必要になってきます。テストの計画ができれば、その計画どおりに進んでいるのかのテストの管理も必要です。そして最後に、テストの結果からソフトの品質の良し悪しを判断するテストの評価も必要です。

ソフトの規模が大きくなるにつれて、ソフト開発におけるテストの重要性はどんどん大きくなり、これらのテストの計画と管理と結果の評価にも、いろいろなノウハウが要るようになってきまた。この記事のグループでは、グータラ親父がこれまでの経験から生理してきたテストに関する様々な事柄を紹介していきます。

テストの名前は目的を意識して使いましょう

一言にテストと言っても、色々な目的がありその目的に沿ったテストの名前が付いています。ソフトの世界はサイエンスではなく泥臭い現場の活動が多いので、テストの名前もいろいろとあってどのテストをすれば良いのか迷う事もよくあります。

開発フェーズでテストを分けると単体テスト結合テストシステムテストという名前がでてきます、機能確認で分けると正常系テスト準正常系テスト異常系テストとなります、設計検証妥当性確認という少し広い範囲を指すテストの名前もありますし、探索的テストとか組み合せテストというような名前もありますし、RAS機能テストセキュリティテストというように、個々の要件に沿ったテストの名前もあります。もう少し詳しく見ていくと、システムテストカテゴリと呼ばれる目的別のテストの名前もあります。

いろいろなテストの名前があると混乱しがちですが、まずはテストの目的に沿って必要なテストを考えて、その考えに合ったテストの名前を使うと、テストの設計や実行がやり易くなります。ここではまず、テストの目的別にどな名前のテストがあるのか、グータラ親父の経験と独断で分けてみました。

2. テストも計画書の作成が大切

最近は特にテストが大規模になって、多くの人がたくさんの機材を使って複数の場所でテストを実施するようになってきました。こうなってくると、ソフトそのものの開発と同じようにテストもしっかりしたテスト計画書が大切になってきます。テストの計画書をしっかりと作って、その計画書を使ってテストチーム全員の意思を揃えて、チーム員全員で同じゴールに向かってテストを進めていかないと、良いテストの成果は得られません。

テスト計画書では、まずテストの方針や目標を明確にして、これらを達成するためのテストチームの体制と役割分担を決め、テストの実施に必要な環境や機材を揃えて、テスト設計と設計レビューの進め方を決め、テストの成果を記録・追跡する方法を決め、これらのテスト作業を管理する方法を決めて、これらの事を計画書に書き出す事が必要になります。 テストの規模が大きくなってくると、テストの状況を把握するために適切なメトリクスを使う必要も出てきますので、これもテスト計画書に書き出します。

テストの計画書を作るにはどんな事を考えておけば良いのか、ここでは、グータラ親父がこれまでに見てきたテスト計画書を元に、テスト計画書に書くべき内容を紹介していきます。

計画書ができたらそれを使ってテストの管理

テスト計画書ができたら、いよいよ実際のテストの開始です。 テスト設計を行い、テスト環境を揃えて、実際のテストを行い、テスト結果を記録し、その結果をトラッキング(追跡)していきます。 テストで見つかったバグはバグ管理を行って、開発部門にフィードバックし、バグが修正されたソフトが再リリースされてきたら修正状況の確認をします。 これらのテスト作業も、複数の担当者による共同作業になるので、様々なテスト管理が必要になってきます。

テストの設計や実施など作業工程について進捗状況を管理したり、テストで検出されるバグの件数や内容を監視してテストの効率を管理したり、見つかったバグの修正が滞りなく進んでいるかデバッグ作業を管理したり、見つかったバグに関して再現に必要な情報がちゃんと記録されているかバグ記録の状況を管理したり、何時テストを終了したらよいかのテストの完了判断を管理したり、テスト管理にはほんとうにいろいろな事が必要で、そのための方法もまた色々なものがあります。

テスト管理はテストを行う組織によって大きく変わるので、これが正解というものはありません。各々の組織やソフト開発プロジェクトに適した管理の仕方を、実際のテスト作業を始める前に検討してテスト計画書に書きだしておきます。そしてテスト作業が始まれば、テスト計画書の内容に従って日々のテスト状況を管理する作業を淡々と進めましょう。

テスト管理で大切な事は、テスト管理を計画書に書いたとおりに淡々と進める事です。一見簡単な事に聞こえますが、実際のテスト現場ではリリースが近づいてきてバックログが溜まってくると、どうしてもテスト作業そのものに過大な負荷が掛かかりテスト管理が手薄になりがちです。しかしその様な状況の時にこそ、限られたテスト資源である人・機材・時間を、最も効果的に運用するための判断の材料を提供するテスト管理が必要になります。デスマーチの中でこそ、テスト管理が必要になる事を決して忘れないでください。

3. テストをしたらその結果を活用して品質を評価し改善する

テストはソフトの品質を保証したり改善したりするための手段ですので、テストの結果は効果的に活用してはじめてテストの目的のソフト品質の保証や改善ができます。テストの結果を使う場面は大きく2つに分かれていて、一つ目はテスト作業の最中でもう一つはテスト作業の後です。

テスト作業の最中に見つかったバグは、効率的にデバッグ行いバグを修正する事が大切です。デバッグのためには、バグ事象の記録(どんな問題が起きたのか)や、発生条件(どうすれ起きるのか)の記録がまず大切です。 また、見つかったバグは設計者やコーダが原因を調べてバグを修正し、テスト担当に渡されてバグ修正の確認が行われます。

テストの大きな目的の1つが潜在バグの発見なので、見つけたバグそのものがテストの成果で、この成果を使って効率よくバグを修正してソフトの品質を良くする事がテストの成果の活用になります。そして、このテスト作業中のテスト結果の活用方法についても、テスト管理と同じ様にテスト計画書に具体的な方法を書いておき、それに従って淡々と進める事が大切です。テスト作業の途中で、テスト結果の使い方を変更すると、デバッグ作業に混乱をもたらす事もあるので、テスト結果の活用方法は、できるだ途中での変更をしないのが良いでしょう。

テスト作業が終わると、見つけたバグやその修正状況などのテスト結果と、そのテスト結果を分析したテスト評価を整理してテスト報告書として取りまとめます。テスト評価とは例えば、今回のテストでのバグ検出率は良かったのか悪かったのか、テストの前半で多くのバグを効率よく見つけられていかた、テストの後半では発見が難しいバグもみつけていたか、など今回のテストが計画した成果を達成できていたかどうかの判定です。

テスト結果は、ソフトの品質の良否を判定してリリース判定に使いますので、テスト作業の最も重要な成果物です。そしてテスト評価はテスト計画やテストの実施というテストプロセスをより良い物に改善するために使います。このテスト評価をしっかりと行ってテストプロセスの改善に結び付けられるかどうかが、良いテストチームへと育っていけるかどうかの大きな分かれ目ですので、しっかりと検討しましょう。

4. 組み込みソフトに必須のテスト項目

組み込みソフトは24時間365日安定して動作する事が必要なので安定性や堅牢性が必要です。安定性や堅牢性を確認するためのテスト項目は色々ありますが、忘れずに実施しておくべき必須のテストもあります。メモリリークテストやタイマ・カウンタのロールオーバーテスト、複数機能の同時実行テストや起動処理での準正常系テスト等です。 その他にも安定性や堅牢性の確認に必須のテスト項目が在りますので、興味のある方は個々の記事をご覧ください。

グータラ親父流テストの紹介

テストに分類されている以下の記事では、ソフトのテストに必要な考え方や情報について、できるだけ整理して記事に書き綴っていきます、まだまだ記事は少ないのですが、少しずつ書き足していきますのでお待ちください。 

記事のタイトルの先頭にソフトのテストに関する小分類を付けてあります。小分類に続くサブタイトルが具体的な記事の概要です。 読む順番は特に決まりはありませんので、気になる記事から順にご覧ください。

全体をざっと理解したい人は、小分類が概要となっている記事をご覧ください。 概要の記事に書いてある事をもう少し詳しく知りたい方は、個々の記事をご覧頂くか、概要の記事の文末からリンクされている個々の記事を順番に読み進めて頂くと良いと思います。

概要・テスト品質を良くするにはテストの目的に合うテストの種類を選ぶ事から  に続く
  •   概要・テスト品質を良くするにはテストの目的に合うテストの種類を選ぶ事から
  •   概要・テスト品質を良くするにはテスト計画書に目的と体制と管理と環境とトラッキングを書く
  •   概要・テスト品質を良くするにはテスト報告書にテスト結果とテスト評価を書く
  •   概要・組み込みソフトのテスト品質を良くするのに重要なテスト項目のいろいろ
  •   テストの種類・単体テストと結合テストとシステムテスト
  •   テストの種類・準正常系と異常系と正常系
  •   テストの種類・通信プロトコル処理での準正常系テスト
  •   テストの種類・状態遷移での準正常系テスト
  •   テストの種類・ハードウエア制御での準正常系テスト
  •   テストの種類・RAS の機能テスト
  •   テストの種類・セキュリティテスト
  •   テストの種類・The Art of Software Testing のシステムテストカテゴリ
  •   テストの種類・機能/大容量データ/高負荷/利用性/セキュリティ/性能/記憶領域
  •   テストの種類・構成/互換性/インストール/信頼性
  •   テストの種類・異常回復性/保守性/ドキュメント/手順書
  •   テストの種類:テストはデバックのためそれとも品質保証のため?
  •   テスト計画・計画書はテストの方針を最初に書く
  •   テスト計画・テスト目標(その1)納期とコストとプロダクト品質
  •   テスト計画・テスト目標(その2)プロセス品質と作業品質とテスト管理
  •   テスト計画・テストの分担と体制(その1)設計と実施と記録と再現
  •   テスト計画・テストの分担と体制(その2)不具合の一次切り分けとデバッグ
  •   テスト計画・テスト管理のメトリクス(その1):日程と成果物の進捗管理
  •   テスト計画・テスト管理のメトリクス(その2):テスト結果の管理
  •   テスト計画・テスト環境と環境の準備
  •   テスト計画・不具合やバグは分類の仕方と記録する項目を決めて置く
  •   テスト計画・不具合やバグの管理には不具合やバグの状態の定義が重要
  •   テスト計画・不具合やバグは優先度をつけてトラッキングする
  •   テスト報告書・発見したバグは分布が判るように分析する
  •   テスト報告書・信頼度成長曲線による潜在バグの推定
  •   テスト報告書・テストの評価はまずテスト内容の評価から
  •   テスト報告書・テスト計画の評価にはテスト日程についての評価も書く
  •   テスト報告書・テスト計画の評価にはテスト効率についての評価も書く
  •   システムテストの必須項目(1)・メモリリークテスト
  •   システムテストの必須項目(2)・メモリ以外の動的資源リークテスト
  •   システムテストの必須項目(3)・タイマやカウンタのロールオーバーテスト
  •   システムテストの必須項目(4)・複数機能の同時実行テスト
  •   システムテストの必須項目(5)・起動時テストには準正常系と異常系を加える
  •   システムテストの必須項目(6)・フラッシュメモリやHDDなどの二次記憶装置の劣化テスト
  •   システムテストの必須項目(7)・高負荷エージングテスト
  •   システムテストの必須項目(8)・品質の悪い通信路でのエージングテスト
  •   テスト品質を良くするにはテストの種類とテスト計画とテスト管理とテスト報告書が重要