超(個人)訳JSTQB Foundation Level シラバス Part2
はじめに
前回は「1.1 テストとは何か？」の中で、テストが我々の生活に与える影響や必要性について解説してきた。今回はテストを行う目的とテストとデバッグの違いを中心に解説していく。
引用元について
ISTQBが提供するFoundation Levelシラバスを引用させて頂く。
1.1.1 テスト目的
典型的なテスト目的は以下の通り。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 故障を引き起こし、欠陥を発見する。
- 求められるテスト対象のカバレッジを確保する。
- ソフトウェア品質が不十分な場合のリスクレベルを下げる。
- 仕様化した要件が満たされているかどうかを検証する。
- テスト対象が契約、法律、規制の要件に適合していることを検証する。
- ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
- テスト対象の品質に対する信頼を積み上げる。
- テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。
テストの目的は、テスト対象のコンポーネントまたはシステム、テストレベル、リスク、従うソフトウェア開発ライフサイクルモデル（SDLC）、および、例えば企業構造、競争上の考慮事項、市場投入までの時間といったビジネスコンテキストに関わる要因などのコンテキストによって異なることがある。
以下、各目的について解説していく。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
テストは出来上がったソフトウェアを動かすことで品質を評価すると思われがちだが、ソフトウェア開発の過程で作られるドキュメント全てが対象となる。以下がテスト対象となる成果物の一例である。
- ステークホルダーの要望をまとめた企画書(プロジェクトによっては要求仕様書と呼んだりする)
- ステークホルダーの要求を基に作成した要件定義書
- 開発担当が作成した開発設計書やソースコード
- テスト担当が作成したテストに関する計画書・設計書・テストケース
このように可視化されている文書やソースコードもテストの評価対象に含まれており、それらの品質を評価するのがテストの目的となる。
- 故障を引き起こし、欠陥を発見する。
これを初めて学んだ時に、故障と欠陥って似たような言葉だし、言い方の違いじゃないの？と思った。
故障と欠陥の違いについて、1.1.2で説明するが、ざっくり言うと以下のイメージである。
故障:ソフトウェアを動かしたが、期待した結果にならなかったこと
欠陥:ソフトウェアに潜む故障の原因となる問題そのもの
ソフトウェアの中に欠陥があり、欠陥が悪さをして故障として目に見えるようになるイメージである。
なので、欠陥はソフトウェアを動かした際には見えず、ソフトウェアの内部に当たるソースコードを見ることでどこが悪さをしているかが把握できます。
(QA目線からしたら、欠陥の原因調査と特定がしんどそうに見えるため、開発の人には感謝している)
こうして、故障が見つかった際はその原因となる欠陥を特定し、その問題を引き起こす欠陥を修正し、それを何度も繰り返すことでソフトウェアの品質を段々と向上させることができます。
- 求められるテスト対象のカバレッジを確保する。
人によって「カバレッジって何？」と思うかもしれませんが、カバレッジとは「定められた範囲の中で、今どれくらい満たしているかを数値化したもの」で、何かを示すための指標みたいなものです。
雑な例え話で説明すると、ページ数が50ページの本を現在20ページまで読み終えている場合、
読書の進み具合をカバレッジで示すと「20/50 = 40%」と表現できます。
ソフトウェア開発において、このカバレッジがソフトウェア品質の指標となることが多く、様々な基準を用いて数値化されますが、カバレッジ確保の手段としてテストがあります。
- ソフトウェア品質が不十分な場合のリスクレベルを下げる。
前回の記事で触れたように、ソフトウェアが正しく動かないことで、ソフトウェアの利用者に不利益が被るのはソフトウェアの品質が担保されていないからと言えます。
テストを行うことで、現状のソフトウェアの品質を把握でき、その中でソフトウェアの不備を見つけ、世間に出る前にリスクへ対処することで、十分な品質を確保して利用者に提供できるようになります。
- 仕様化した要件が満たされているかどうかを検証する。
ソフトウェアは要件を解釈し、仕様という形に起こして作られるものであり、テストを実行することはソフトウェアが要件通りに作られているかを検証することである。
- テスト対象が契約、法律、規制の要件に適合していることを検証する。
テスト対象になるのは仕様だけではない。ソフトウェアを作るに当たり、仕様とは別に法律や規制、契約等の仕様の外側にあるルールを満たしているか検証する必要がある。
国内外問わずソフトウェアを提供する際、その土地のルールに準拠していなければ、販売停止やそもそも提供できない可能性もあるため、テストではそうした根本的なルールを守っているか検証するのも1つの役割である。
- ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
テストはステークホルダーが意思決定を行うための貴重な情報であり、テストの結果次第でリリースできるかどうかを判断する指標にもなる。このことから、テスト担当はステークホルダーが経営上重要な意思決定を行うため、必要な情報提供の支援を担っている自覚を持たなければならない。
- テスト対象の品質に対する信頼を積み上げる。
最初にこの目的を学んだ時、信頼を積み上げるってどういうこと？とピンと来なかった。
ただでさえ抽象的な品質の話に加え、別のフワッとした信頼という言葉が出てきて、よく分からないまま意味を深堀りしようとしなかった。
最近になってこの言葉と対面した時に、上で説明した要件の検証や後述する妥当性確認、欠陥の検出といったテストを行った結果を積み重ねることで、品質が信頼に足るレベルにまで到達するという意図があったのかと解釈した。
- テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。
ステークホルダーが欲しいと思う機能を全て実現させたソフトウェアと聞くと、理想的な成果物のように見えるかもしれない。しかし、実際に出来上がったものはとても使えるレベルじゃなかった場合、ステークホルダーの期待に応えられていないと言える。
具体的にイメージすると、機能をてんこ盛りにしたソフトウェアを動かしてみた結果、動作が極端に重くなったり、処理に膨大な時間を要したりすることが考えられる。
ステークホルダーが望むものを全て実現したからと言って、それがステークホルダーの期待するものとイコールにはならない。
テストを通して、要件が全て満たしているかの検証に加え、テスト対象のソフトウェアがステークホルダーの期待に沿って作られているかに焦点を当てて確認すること(=妥当性確認)もテストの目的である。
1.1.2 テストとデバッグ
テストとデバッグは別の活動である。テストをすることで、ソフトウェアの欠陥によって引き起こされ
る故障を発生させたり（動的テスト）、テスト対象の欠陥を直接発見したりすることができる（静的テ
スト）。
動的テスト（第4章参照）が故障を引き起こす一方で、デバッグの関心ごとは、故障の原因（欠陥）を
発見し、その原因を解析し、原因を取り除くことにある。典型的なデバッグの流れは以下の通り：
- 故障の再現
- 診断（根本原因を発見すること）
- 原因を修正すること
テストとデバッグを一緒くたに語っている人がいるが、厳密には活動内容が異なる。
テストとは故障や欠陥を見つけるための活動であり、デバッグはテストで見つけた故障を頼りに原因となる欠陥を直す活動である。
また、テストに関しては故障や欠陥を見つけるアプローチによってテストの内容も変わってくる。
ソフトウェアを動かして故障を引き起こすアプローチが「動的テスト」であり、ソフトウェアを動かさずに欠陥を見つけるアプローチが「静的テスト」である。
前者はイメージが付きやすいが、後者についてはソフトウェア開発に必要な要件定義書や開発仕様書を始めとしたドキュメントがテスト対象で、ドキュメントのレビューが検証方法に当たる。
一方でデバッグは故障の原因に当たる欠陥を発見し、その原因を解析して取り除くことが目的となる。
テストとデバッグの両活動は担当者が異なり、テストはテスト担当者が行うものだが、デバッグはソフトウェアを作った開発担当者が行うものである。
その後に行う確認テストは、修正によって問題が解決されたかを確認する。確認テストは、最初のテストを行った人と同じ人が行うのがよい。修正によってテスト対象の他の部分に故障が発生していないかを確認するために、続けてリグレッションテストを実施することもできる（確認テストとリグレッションテストの詳細については、2.2.3 項を参照）。
静的テストで欠陥を識別した場合、デバッグすることはその欠陥を取り除くことである。静的テストは欠陥を直接発見するものであり、故障を引き起こすことはできないため、再現や診断の必要はない（第3章参照）。
デバッグはテストで見つかった故障の情報を基に欠陥を修正し、欠陥修正完了後はテスト担当者(故障を見つけた人)が故障が再現されないを確認するためのテストを行う。
シラバス上では確認テストと定義しており、プロジェクトによっては、これを改修確認と呼ぶことが多いかもしれない。
テストの目的は、テスト対象のコンポーネントまたはシステム、テストレベル、リスク、従うソフトウェア開発ライフサイクルモデル（SDLC）、および、例えば企業構造、競争上の考慮事項、市場投入までの時間といったビジネスコンテキストに関わる要因などのコンテキストによって異なることがある。
テストの目的について、固定化されているわけではない。
シラバスに記載されている通り、ビジネス上の都合やソフトウェア開発のプロセス等の要因によって、テストの目的に優先度を設けたり、取捨選択が迫られることもある。
テスト担当者としては、テストを行う前にテスト行う目的を把握しておかないと、後になって目的にそぐわない活動に不要な時間を費やしてしまうため、そうならないようテストを計画する段階で目的を決めておくのが重要になる。
おわりに
次回は「1.2 なぜテストが必要か？」を中心に解説を進めていく。
Discussion