開発工程で避けて通れないのがテストですが、今回は「受け入れテスト」のテストレベルで行う「テスト分析」「テスト設計」についてまとめてみました。

テストプロセスについて

JSTQBでは以下のプロセスが定義されております。 計画ではどのような目的でどの範囲をテストするかを整理します。 次の工程で「テスト分析」「テスト設計」を行います。

テストプロセスを構成する主な活動のグループは以下の通りである。 ・テスト計画 ・テストのモニタリングとコントロール ・テスト分析 ・テスト設計 ・テスト実装 ・テスト実行 ・テスト完了 各グループは、以降の節で説明する活動で構成する。各グループ内の各活動は、さらに複数の個別のタスクで構成する。 これらのタスクはプロジェクトまたはリリースごとに異なる。 さらに、これらのグループの多くは論理的には順次行われるが、繰り返されることが多い。例えば、ア ジャイル開発では、計画作業を継続的に行いながら、ソフトウェアの設計、ビルド、テストが連続して 行われる活動を、小さな単位で繰り返し行う。このため、この開発アプローチでは、テストの活動も反 復的に継続して行う。シーケンシャル開発でも、活動を論理的な順序で段階的に行う場合、重なりあっ て実行したり、組み合わせて実行したり、同時に実行したり、実行を省略したりするため、システムや プロジェクトの状況に合わせてこれらの主要な活動をテーラリングする必要がある。 JSTQB SyllabusFoundation_Version2018.J02(1.4.2 テストの活動とタスクより)

ことばの意味はわからんがとにかくすごい自信だ！

いろいろと書いてますが・・・ テスト作業の基本的な作業工程と理解いただければと思います。 「テスト分析・設計」の前に「テスト計画」を行い、実施する内容や目的を整理したうえで分析へ着手します。 「テスト計画」も「テスト分析・設計」するための情報の源泉になります。 また、「テスト設計」の後工程である「テスト実装」とは、「テスト実行」できるようテスト手順を項目書へ反映させる工程です。

次に「分析」と「設計」について説明します。

テスト分析とテスト設計

分析 ・・・なにをどのようにテストするのかを決める活動 要件定義書や開発設計書などのテストベース（インプット資料）をもとにテスト対象を理解して分解する。 仕様理解したうえで、どのような切り口でテストを行うかテスト観点を整理する。 会社によってはISO/IEC 25010で定義された品質特性・品質副特性を観点出しの参考にする場合もある。

設計 ・・・分析した要素を目的に沿った設計技法を用いて整理して設計を行う。

落とし穴

要件定義書や設計書があいまいだったり、資料が存在しない場合、それ相当に値する別のものを用意するか、質問して内容理解するか資料作成するということになります。 また、要件定義があいまいだとあいまいなテスト項目書になり、テストの効果が低くなってしまいます。

要件定義書や設計書に書いていない仕様についてもテストを行う必要があるので、過去の経験や標準観点表などを用いたり、入力・出力のパターン表を用いて補完することを行っております。

分析と設計の違い

テスト分析も、テスト設計と行き来して繰り返されるので、同じ工程と考えても間違いではないですが、作業内容は全く異なります。 分析はテストを行うために具体的な仕様、特徴やそのシステムやサービスの使われ方などの情報収集し、テストを行うための条件を導出する「テスト対象分析」とテスト目的とテストの範囲など「テストの要求分析」をすることと言えば多少わかりやすいかもしれません。 明確な成果物というものはないので案件毎に決めておけばいいと思います。

設計は分析した対象をもとに効率よくテストできるために、テスト条件パターンや入力値・結果など整理を行う作業で、テスト技法を用いて合理的にテストパターンを少なくすることや、多くの欠陥を見つかるようにする技法などを使い分けます。

分析（実例サンプル）

テスト分析と設計方法について簡単な「会員登録画面のパスワード登録」を例に説明します。 以下のような画面仕様書があり「パスワード登録」の条件が書かれています。

説明からテスト対象の観点洗い出して条件や範囲を整理します。

あいまいな記述や仕様として記載されていないか確認して質問事項も抽出します。

設計（実例サンプル）

今回のサンプルでは文字数や文字種別の制限があります。全ての有効/無効文字数のパターンを実施する必要はないので「同値分割/境界値分析」を用いて整理を行います。

「6文字以上～18文字以下」という条件を整理すると次の通りになります。

同値分割とは同じ動作を行う条件の集まりのことで、正常作動する有効クラス、エラー作動をする無効クラスに分類する。

• 有効同値クラス：6文字以上、18文字以下
• 無効同値クラス：0文字以上、5文字以下
• 無効同値クラス：19文字以上

同値クラスから代表値を選び出してテストするのを、同値クラステストといいます。 境界値分析とは境界値とその境界値と隣り合う値を候補にする手法です。 7と17は境界値と同じ同値なので省略する。

• 境界値：6、18
• 境界値－１：5
• 境界値＋１：19

なぜ、境界値でテストをするのか？

要件定義書や設計書などの文書で「～より大きい」「～より小さい」「～と同等」「以上」「以下」「未満」といった表現を誤解して欠陥が混入しやすいためです。

if 文字数 > 6 and 文字数 <= 18 then
    message = “有効同値クラス”
else 
    message = “無効同値クラス”
end if

この様にタイプミスで > 6とコーディングされてしまった場合に「 6 」をテスト条件にすれば欠陥は発見できます。

実行パターン（完成イメージ）

テストパターンを整理すると以下の通り

結果が同じで重複しているパターンを削ると以下の通り

まとめ

このようにテスト設計は実装完了を待たなくてもドキュメントのみで可能で、仕様の漏れや指摘（仕様書の欠陥洗い出し）もできます。 早期発見することで手戻りも最小限に抑えられる効果もあります。 テストといってもシナリオ消化だけではなく、このような活動があり、実装開始前にもできることを理解いただければと思っております。