ソフトの品質を保証するテストにはテストの種類とテスト計画とテスト管理とテスト報告書が重要
ソフトのテスト品質を良くするための４項目
ソフトの品質を保証するために一番重要なのがテストです、テストの品質の良し悪しでソフトの品質保証の良し悪しが決まるので、テスト品質はソフトの品質保証にとって非常に重要です。では、テストの品質を良くするには何をすれば良いでしょうか？ グータラ親父は ①テストの種類を正しく選ぶ 事と ②良いテスト計画を立てる事 と ③良いテスト報告書をまとめる事 と ④必須のテスト項目を忘れずに実施する事 の４つの項目でテスト品質を良くする活動をしてきました。
①のテストの種類を正しく選ぶ とはテストの主要な目的に合わせて実施するテストの種類を選ぶという意味です。テストは初版ソフトのリリースの為に機能を確認する事が大切な事もあれば、バグ修正版ソフトのリリースの為に二次不具合が混入していない事の確認を確認する事が大切な場合もあります。それぞれのテストの主要な目的に従って、機能テストや性能テストや高負荷エージングテスト等のテストの種類や、正常系テスト、異常系テスト、準正常系テスト等のテストの種類から、どのテストを実施するのかをうまく選ぶ事が大切です。
②の良いテスト計画を立てる とはテストの日程に加えて必要な機材や人員の準備、テストで見つけた不具合やバグの管理方法、テストの進捗や品質の管理方法やテスト作業の分担などテストの実施に必要な事が漏れなく検討されたテスト計画を作るという意味です。ソフトの規模が大きくなるにつれてテストの規模大きくなり多くの機材とテストエンジニアが関わる場面が増えてきました。十分に検討されたテスト計画が無いと、リリース予定日までにテストが終わらない様な事も起こり得ます。良いテスト計画は品質の良いテストのための第一歩です。
③の良いテスト報告書をまとめる とはテストの成果とテストの評価の両方を整理してテスト報告書に纏めましょうという意味です。テストの成果とはテストで見つけた不具合です、どんな不具合を見付けてそれらの不具合の調査や修正の状況がどうなっているのか、というのがテストの成果です。テストの成果はソフトリリースの判定で品質の良し悪しを判断する重要な情報ですので、判り易くテスト報告書に書いておく事が大切です。もうひとつのテストの評価とは、今回のテストが計画したとおりに実施できたかどうかというテスト作業の良し悪しに関する記録です。実際のテストでは、色々な要因から最初の計画したとおりに行かない場面がでてきます。それらを振り返って、次回のテストを計画する時にどんな事に注意すれば良いかが判るようにテスト報告書に書いて置くことで、次からのテストをより良いものへと改善していく事ができます。
④の必須のテスト項目 とは前の３件とはちょっと観点が違うのですが、組み込み系ソフトにとって重要な安定性や堅牢性を確認するために忘れてはならない、リークテスト、ロールオーバテスト、高負荷エージングなどのテスト項目が幾つかあります。これらの重要なテスト項目は必ず実施しましょうという意味です。
それでは①から④の４つの内容について、もう少し詳しく紹介していきましょう。
1. テストは目的に合わせて実施するテストの種類を選定して管理と評価もしっかりと
ソフトの品質を保証するにはどんな種類のテストをどれだけ実施すれば良いのでしょうか？ 正常系テストや異常系テスト、単体テストやシステムテスト、RAS機能テストやセキュリティテスト、などいろいろな種類のテストがありますが、どんな種類のテストをどれだけの量実施すればソフトの品質を十分に保証できるのでしょうか？
実施するテストの種類や量が決まったら、それらのテストをリリースの時期までに実施するために必要な機材とテスト人員を整理したテストの計画も必要になってきます。テストの計画ができれば、その計画どおりに進んでいるのかのテストの管理も必要です。そして最後に、テストの結果からソフトの品質の良し悪しを判断するテストの評価も必要です。
ソフトの規模が大きくなるにつれて、ソフト開発におけるテストの重要性はどんどん大きくなり、これらのテストの計画と管理と結果の評価にも、いろいろなノウハウが要るようになってきまた。この記事のグループでは、グータラ親父がこれまでの経験から生理してきたテストに関する様々な事柄を紹介していきます。
テストの種類は目的を意識して使いましょう
一言にテストと言っても、色々な目的がありその目的に沿ったテストの種類があります。ソフトの世界はサイエンスではなく泥臭い現場の活動が多いので、テストの種類もいろいろとあってどのテストをすれば良いのか迷う事もよくあります。
開発フェーズでテストを分けると単体テスト、結合テスト、システムテストというテストの種類がでてきます、機能確認で分けると正常系テスト、準正常系テスト、異常系テストとなります、設計検証と妥当性確認という少し広い範囲を指すテストの種類もありますし、探索的テストとか組み合せテストというような種類もありますし、RAS機能テストやセキュリティテストというように、個々の要件に沿ったテストの種類もあります。もう少し詳しく見ていくと、システムテストカテゴリと呼ばれる目的別のテストの種類分けもあります。
いろいろなテストの種類があると混乱しがちですが、まずはテストの目的に沿って必要なテストを考えて、その考えに合った種類のテストを選ぶと、テストの設計や実行がやり易くなります。詳細の記事ではテストの目的別にどな種類のテストがあるのか、グータラ親父の経験と独断で分けてみましたので、興味のある方はそちらもご覧ください。
2. テストも計画書の作成が大切
最近は特にテストが大規模になって、多くの人がたくさんの機材を使って複数の場所でテストを実施するようになってきました。こうなってくると、ソフトそのものの開発と同じようにテストもしっかりしたテスト計画書が大切になってきます。テストの計画書をしっかりと作って、その計画書を使ってテストチーム全員の意思を揃えて、チーム員全員で同じゴールに向かってテストを進めていかないと、良いテストの成果は得られません。
テスト計画書では、まずテストの方針や目標を明確にして、これらを達成するためのテストチームの体制と役割分担を決め、テストの実施に必要な環境や機材を揃えて、テスト設計と設計レビューの進め方を決め、テストの成果を記録・追跡する方法を決め、これらのテスト作業を管理する方法を決めて、これらの事を計画書に書き出す事が必要になります。 テストの規模が大きくなってくると、テストの状況を把握するために適切なメトリクスを使う必要も出てきますので、これもテスト計画書に書き出します。
テストの計画書を作るにはどんな事を考えておけば良いのか、ここでは、グータラ親父がこれまでに見てきたテスト計画書を元に、テスト計画書に書くべき内容を紹介していきます。
計画書ができたらそれを使ってテストの管理
テスト計画書ができたら、いよいよ実際のテストの開始です。 テスト設計を行い、テスト環境を揃えて、実際のテストを行い、テスト結果を記録し、その結果をトラッキング（追跡）していきます。 テストで見つかったバグはバグ管理を行って、開発部門にフィードバックし、バグが修正されたソフトが再リリースされてきたら修正状況の確認をします。 これらのテスト作業も、複数の担当者による共同作業になるので、様々なテスト管理が必要になってきます。
テストの設計や実施など作業工程について進捗状況を管理したり、テストで検出されるバグの件数や内容を監視してテストの効率を管理したり、見つかったバグの修正が滞りなく進んでいるかデバッグ作業を管理したり、見つかったバグに関して再現に必要な情報がちゃんと記録されているかバグ記録の状況を管理したり、何時テストを終了したらよいかのテストの完了判断を管理したり、テスト管理にはほんとうにいろいろな事が必要で、そのための方法もまた色々なものがあります。
テスト管理はテストを行う組織によって大きく変わるので、これが正解というものはありません。各々の組織やソフト開発プロジェクトに適した管理の仕方を、実際のテスト作業を始める前に検討してテスト計画書に書きだしておきます。そしてテスト作業が始まれば、テスト計画書の内容に従って日々のテスト状況を管理する作業を淡々と進めましょう。
テスト管理で大切な事は、テスト管理を計画書に書いたとおりに淡々と進める事です。一見簡単な事に聞こえますが、実際のテスト現場ではリリースが近づいてきてバックログが溜まってくると、どうしてもテスト作業そのものに過大な負荷が掛かかりテスト管理が手薄になりがちです。しかしその様な状況の時にこそ、限られたテスト資源である人・機材・時間を、最も効果的に運用するための判断の材料を提供するテスト管理が必要になります。デスマーチの中でこそ、テスト管理が必要になる事を決して忘れないでください。
3. テストをしたらその結果を活用して品質を評価し改善する
テストはソフトの品質を保証したり改善したりするための手段ですので、テストの結果は効果的に活用してはじめてテストの目的のソフト品質の保証や改善ができます。テストの結果を使う場面は大きく２つに分かれていて、一つ目はテスト作業の最中でもう一つはテスト作業の後です。
テスト作業の最中に見つかったバグは、効率的にデバッグ行いバグを修正する事が大切です。デバッグのためには、バグ事象の記録（どんな問題が起きたのか）や、発生条件（どうすれ起きるのか）の記録がまず大切です。 また、見つかったバグは設計者やコーダが原因を調べてバグを修正し、テスト担当に渡されてバグ修正の確認が行われます。
テストの大きな目的の１つが潜在バグの発見なので、見つけたバグそのものがテストの成果で、この成果を使って効率よくバグを修正してソフトの品質を良くする事がテストの成果の活用になります。そして、このテスト作業中のテスト結果の活用方法についても、テスト管理と同じ様にテスト計画書に具体的な方法を書いておき、それに従って淡々と進める事が大切です。テスト作業の途中で、テスト結果の使い方を変更すると、デバッグ作業に混乱をもたらす事もあるので、テスト結果の活用方法は、できるだ途中での変更をしないのが良いでしょう。
テスト作業が終わると、見つけたバグやその修正状況などのテスト結果と、そのテスト結果を分析したテスト評価を整理してテスト報告書として取りまとめます。テスト評価とは例えば、今回のテストでのバグ検出率は良かったのか悪かったのか、テストの前半で多くのバグを効率よく見つけられていかた、テストの後半では発見が難しいバグもみつけていたか、など今回のテストが計画した成果を達成できていたかどうかの判定です。
テスト結果は、ソフトの品質の良否を判定してリリース判定に使いますので、テスト作業の最も重要な成果物です。そしてテスト評価はテスト計画やテストの実施というテストプロセスをより良い物に改善するために使います。このテスト評価をしっかりと行ってテストプロセスの改善に結び付けられるかどうかが、良いテストチームへと育っていけるかどうかの大きな分かれ目ですので、しっかりと検討しましょう。
4. 組み込みソフトに必須のテスト項目
組み込みソフトは24時間365日安定して動作する事が必要なので安定性や堅牢性が必要です。安定性や堅牢性を確認するためのテスト項目は色々ありますが、忘れずに実施しておくべき必須のテストもあります。メモリリークテストやタイマ・カウンタのロールオーバーテスト、複数機能の同時実行テストや起動処理での準正常系テスト等です。 その他にも安定性や堅牢性の確認に必須のテスト項目が在りますので、興味のある方は個々の記事をご覧ください。
グータラ親父流テストの紹介
テストに分類されている以下の記事では、ソフトのテストに必要な考え方や情報について、できるだけ整理して記事に書き綴っていきます、まだまだ記事は少ないのですが、少しずつ書き足していきますのでお待ちください。
記事のタイトルの先頭にソフトのテストに関する小分類を付けてあります。小分類に続くサブタイトルが具体的な記事の概要です。 読む順番は特に決まりはありませんので、気になる記事から順にご覧ください。
全体をざっと理解したい人は、小分類が概要となっている記事をご覧ください。 概要の記事に書いてある事をもう少し詳しく知りたい方は、個々の記事をご覧頂くか、概要の記事の文末からリンクされている個々の記事を順番に読み進めて頂くと良いと思います。