テスト分析
テスト分析とは、テスト計画に基づいてテストケースを作成する際に行う工程のことで、「要件定義書やテストベースなどのインプット資料をもとに、情報を整理し、テスト対象の機能や仕様を把握すること」です。
JSTQBでは、テスト分析の目的は、テスト対象の品質特性やリスクに応じて、テスト条件やテストカバレッジを特定すること」と定義されています。すなわち、「何をテストするか」を決める工程と言えるでしょう。PTWにおいては、テスト見積もり時やテスト設計工程の最初に行われることが多いです。
テスト分析は、以下の進め方で分析を行います。
(1)テスト対象のドキュメントや仕様を確認し、テスト対象の理解を深める。
テスト対象にどのような機能があるのか、どのような不具合が考えられるのかを考察します。不明な箇所がある場合は、早めに質問をあげ、お客様や開発者にヒアリングをします。
(2)テスト対象の機能やリスクを洗い出し、テストの優先順位や範囲を決める。
テスト対象の機能を洗い出し、その機能毎にテスト観点や考えられる不具合を整理します。また、機能やテスト観点毎の優先度もここで決めます。テスト工数もあるので、もしテスト対象外の範囲があればお客様や開発者と合意形成します。この作業は、(1)と同時に進めることが多いです。
(3)テスト項目書の構成を決める。
案件によっては「観点(大)」「観点(中)」「観点(小)」、「観点1~3」のような項目書のヘッダーを用いることがあります。その場合、各ヘッダー部に何を記載するかが決まっていないと、機能毎に記載粒度が変わってしまい、抜け漏れが発生する可能性があります。それを防ぐためにも、例えば、「観点(大)には機能名を記載する」等のルールを明確にして挙げることが重要です。特に複数人でテストケースを作成する場合には、記載粒度のズレが発生しやすいので注意が必要です。
テスト設計
テスト設計は、テスト分析で洗い出した機能やテスト観点から、テスト条件を特定していく作業です。テストを行う上での具体的な前提条件や手順、期待値の詳細などの記載は、「テスト実装」の工程になります。実作業においては、テスト設計とテスト実装を並行して行うことも多くあります。
テスト条件の特定については、「Aボタンを押下したら、B画面に遷移することを確認する」というような、観点とテスト条件が1:1の関係にあるような場合もあれば、
「年齢が20歳未満と60歳以上の人は割引されることを確認する」というように、テスト観点とテスト条件が1:多の関係になる場合もあります。後者の場合、テスト条件(=年齢)は0~120歳以上まで取りえますが、取りうる値をすべてテストする必要はあるでしょうか?テストの知見がない方でも「それはさすがに不要では?」と思いますよね。では、すべてテストしないとして、どのように絞り込むのが良いのでしょうか。その時に活用するのが「テスト技法」です。JSTQBのシラバスでは、ブラックボックステストの技法として以下の技法が紹介されています。
・同値分割法
・境界値分析
・デシジョンテーブルテスト
・状態遷移テスト
・ユースケーステスト
・組み合わせテスト
1つの技法だけで、1つの記事が書けてしまうほど奥深いものなので、ここでは説明は割愛しますが、
絞り込みたい対象によって適宜選択していく必要があります。
まとめ
今回はソフトウェアテストのプロセス(テスト分析・設計)についてご紹介しました。
テストケースがないと、テスト実施者の経験則や勘に頼るテストとなってしまい、本来テストすべき観点が抜け落ちてしまう可能性が高く、不要に多くの工数をかけることにも繋がりやすいです。テストの分析・設計を行うことで、「何を」「どのように」テストするのかが明確になり、テストすべき観点の抜け漏れを減らせるため、最小限の工数で最大限の成果を出すことも可能になっていきます。
PTWのソフトウェアテストに関するサービスについて詳しく知りたい方は、下記ページをご覧いただき、お気軽にお問い合わせください。