みなさん、こんにちは。
7月も後半となり、23日からは連休となりますね（2020年投稿時）。
如何お過ごしでしょうか。
私は変わらずテスト自動化の学習などを取り組んでいます。
テスト自動化につきましては、情報がまとまり次第、記事投稿したいと考えています。
今回は、引き続きJSTQB Foundation Levelのシラバス4項「テスト技法」について述べていきたいと思います。
■4.1テスト技法のカテゴリ
こちらでは、テスト技法の選択、カテゴリと特徴、同値分割法、境界値分析について述べていきます。
□4.1.1 テスト技法の選択
テスト技法を選択するケースとして、以下を含む様々な要因を検討します。
私の見解として、大枠で3つのケースに分けてみました。
「プロジェクトや案件に関するもの」
・スケジュールと予算
・規制、標準
「ソフトウェア、システムの特性に関連するもの」
・コンポーネント、あるいはシステムの種類や複雑さ
・ソフトウェア開発ライフサイクルモデル
・ソフトウェアの想定される使用方法
・コンポーネント、システムで想定される欠陥の種類
・利用できるツール
・入手できるドキュメント
・リスクレベル、リスクタイプ
「テスト担当者、テスト管理者に関するもの」
・テスト目的
・テスト担当者の知識とレベル
・テスト担当者が利用できるツール
・テスト対象のコンポーネント、システムに関してテスト技法を使用した経験
テスト担当者、テスト管理者は、テストケースの設計を行う前に、テスト技法を組み合わせて使用し、テスト活動で最善を結果を得られるように対応すると良いでしょう。
テスト分析、テスト設計、テスト実装の活動で、形式に沿わない（仕様書などのドキュメントが無い等）活動から形式に従った活動まで、テスト技法を使用できます。
形式の度合いとしまして、プロジェクト規模、対象となるソフトウェア、システムの開発状況によって決まります。
□4.1.2 テスト技法のカテゴリと特徴
JSTQB Foundationのシラバスでは、テスト技法について、ブラックボックス、ホワイトボックス、経験ベースに分けて解説されています。
「ブラックボックステスト技法」
テストベース（例：形式に沿った要件ドキュメント、仕様書、ユースケース、ユーザーストーリー、ビジネスプロセス）の分析に基づきます。
機能テスト、非機能テストの両方に適用できます。
テスト対象の入力と出力に着目し、その内部構造は参考にしません。
（内部構造はホワイトボックステスト技法が該当します）
(特徴)
・テスト条件、テストケース、テストデータは、ソフトウェア要件、仕様、ユースケース、ユーザーストーリー、などテストベースから導出します。
・テストケースは、要件と実装との相違、及び要件からの意逸脱を検出するために使用できます。
・カバレッジは、テストベース内のテスト済みアイテムと適用した技法に基づいて計測します。
「ホワイトボックステスト技法」
アーキテクチャー、詳細設計、内部構造、テスト対象のコードの分析に基づきます。
ブラックボックステスト技法とは異なり、テスト対象の内部構造と処理に重点を置きます。
（特徴）
・テスト条件、テストケース、テストデータは、コード、ソフトウェアアーキテクチャー、詳細設計、ソフトウェア構造に関する他の情報などのテストベースから導出します。
・カバレッジは、選択した構造（例：コード、インターフェース）内のテスト済アイテムに基づいて計測します。
・仕様書は、期待結果を決定するための追加の情報源として使用されることがあります。
「経験ベースのテスト技法」
テストケースの設計、実装及び実行のため、開発担当者、テスト担当者、ユーザーの経験を活用します。
経験ベースのテスト技法では、ブラックボックステスト技法やホワイトボックステスト技法と組み合わせて使用できます。
（特徴）
・テスト条件、テストケース、テストデータは、テスト担当者、開発担当者、ユーザー、その他のステークホルダーの知識や経験などテストベースから導入します。
■4.2ブラックボックステスト技法
ブラックボックステスト技法について、以下の技法について述べていきます。
□4.2.1 同値分割法
同値分割法は、同等に処理されると想定したデータすべてを同じパーティション（同値クラス、くくり）に振り分ける技法です。
有効な値、無効な値の両方に対して同値パーティションがあります。
カバレッジは、1つ以上の値を使用してテストした同値パーティションの数を、識別された同値パーティションの合計数で除外して計算します。（パーセンテージで表す傾向が多い。）
同値分割法は、すべてのテストレベルで適用が可能です。
（特徴）
・有効な値：コンポーネント、システムに受け入れられる値。有効同値パーティションとも呼ばれます。
・無効な値：コンポーネント、システムに拒否される値。無効同値パーティションとも呼ばれます。
・入力、出力、内部チ、時間関連の値などテスト対象に関連数rあらゆるデータ要素、及びインターフェースのパラメーターに対するパーティションが識別できます。
・パーティションは、必要に応じてさらに細かく分割される場合があります。
・各値は、必ず1つの同値パーティションだけ属する必要があります。
・無効同値パーティションは、複数を組み合わせず、単独でテストを行うことが望ましいです。
（複数の組み合わせで行い、予期せぬ故障が発生した場合、どちらに起因しているか判断がつかないため）
（例）アトラクションを利用できる人、そうでない人の場合
・利用条件：18歳～60歳までの男女
この場合の有効値、無効値は以下となります。
・有効値：18歳～60歳
・無効値：0歳～18歳未満、61歳以上
□4.2.2 境界値分析
境界値分析（BVA）は同値分割法の拡張でもあります。
パーティションが数値または順序付け可能な値で構成される場合だけ使用できます。
パーティションの最小値及び最大値が境界値となります。
（特徴）
・同値パーティションの境界上での振る舞いは、同値パーティション内での振る舞いよりも正しくないことが多い傾向にあります。
・境界値分析はすべてのテストレベルに適用できます。
・この技法では、数値の範囲を必要とする要件に対するテストケースに使用できます。
（例）同値分割の例を参考に境界値分析をすると以下となります。
・境界値：17歳,18歳,19歳、59歳,60歳,61歳となります。
□4.2.3 デシジョンテーブル
デシジョンテーブルは、組み合わせテストのアプローチです。
システム要件から実装した条件の様々な組み合わせ事の結果に対する仕様をテストするのに役立ちます。
（特徴）
・システムが実装すべき複雑なビジネス規則を表現するのに有効です。
・テスト担当者は条件（入力）と結果的に起きるシステムのアクションを識別します。
・条件とアクションは表の行となり、条件を上部、アクションを下部に記述します。
・条件とアクション値は、ブール値（真か偽）または離散値（例：赤、緑、青）で表現したり、数値等で表現することもあります。
（デシジョンテーブルの一般的な表記方法）
「条件」
・Y：条件が真であることを意味します。（T、１とも表記します）
・N：条件が偽であることを意味します。（F、0とも表記します）
・–：条件の値は判定に影響しないことを意味します。（N/Aとも表記します。）
「アクション」
・X：アクションが発生することを意味します。
・空白：アクションが発生しないことを意味します。
（例）アトラクションの料金パターン
一例を作成してみました。
・18歳～60歳まで利用可能
・個人料金：大人1,000円、学生700円
・団体での料金：大人800円、学生500円
・祝日での割引：学生のみ更に100円引き
料金のパターンは6パターンとなります。
□4.2.4 状態遷移テスト
状態遷移図は、ソフトウェアの取り得る状態、ソフトウェアが開始及び終了する方法、ソフトウェアが状態間で遷移する方法を示します。
遷移はイベントにより開始されます。（例：ユーザーによるフィールドの入力など）
そのイベントはガード条件で明確となり、条件が変化するとソフトウェアでアクションが実行されます。
状態遷移図のテスト設計は以下のような内容が考えられます。
・状態の典型的な順序をカバーする
・すべての状態をテストする
・すべての遷移をテストする
・遷移を特定の順序でテストする
・無効な遷移をテストする
（特徴）
・メニューベースのアプリケーションのため使われることがあります。
・組込みソフトウェア業界にて幅広く使われます。
・特定の状態を持つビジネスシナリオのモデル化、及び画面遷移のテストをするためにも適しています。
・カバレッジは、テストをした状態または遷移の数を、テスト対象の識別した状態または遷移の合計数で除算して計算するのが一般的となっています。
（例）
・電子マネーアプリで支払いするケース
□4.2.5 ユースケーステスト
ユースケースは、ソフトウェアアイテムとの相互作用に合わられるソフトウェア機能の要件を取り込むための設計方法です。
ユースケースは、以下をつないでいます。
・サブジェクト（ユースケースが適用されるコンポーネントまたはシステム）
・アクター（ユーザー、外部ハードウェア、その他のコンポーネントやシステム）
（特徴）
・ユースケースには、基本的な振る舞いのバリエーションの他、例外的な振る舞い及びエラー処理を含むことがあります。
・エラー処理にはプログラミング、アプリケーション及びコミュニケーションのエラーに対するエラーメッセージの表示といった、システム応答や回復の処理があります。
・テストでは、定義した振る舞いを実行するように設計します。
・カバレッジは、テストしたユースケースの振る舞いをユースケースの振る舞いの合計数で除算して計測します。
（例）
アクター：銀行システムを使用するユーザー、サブジェクト：銀行システム
■4.3ホワイトボックステスト技法
ホワイトボックステストは、テスト対象の内部構造を基にしたテストです。
一般的にはコンポーネントテストレベルで使用することが多いです。
□4.3.1 ステートメントテストカバレッジ
ステートメントテストは、コード内の実行可能なステートメントをテストします。
カバレッジは、テストにより実行したステートメント数を、テスト対象の実行可能ステートメントの合計数で除算して計測します。
（イメージ図）
□4.3.2 デシジョンテストとカバレッジ
デシジョンテストは、コード内の判定をテストし、実行したコードを判定結果に基づいて評価します。
このため、テストケースは、判定ポイントを通る制御フローに従います。
判定分岐のルートを網羅するようにテストを行います。
カバレッジは、テストにより実行した判定結果の数をテスト対象の判定結果の合計数で除算して計測します。
（イメージ図）
□4.3.3 ステートメントテストとデシジョンテストの価値
ステートメントカバレッジ
100％のステートメントカバレッジの達成は、コード内のすべての実行可能なステートメントを1回以上テストしたことを保証します。
しかし、すべての判定ロジックをテストしたことは保証しません。
ステートメントカバレッジは、他のテストでは遂行されないコードの中にある欠陥を見つけるのに役立ちます。
デシジョンカバレッジ
100％のデシジョンカバレッジの達成は、すべての判定結果を実行したことを意味します。
これには、真の結果、偽の結果、さらには明示的な偽のステートメントが存在しない場合を含みます。
デシジョンカバレッジは、他のテストでは真の結果と偽の結果の両方が実行されないコードの欠陥を見つけるのに役立ちます。
■4.4経験ベースのテスト技法
経験ベースのテスト技法は、テスト担当者のスキルと直感の他、アプリケーションや技術における経験からテストケースを導出します。
この技法は、体系的な技術では容易に識別できないテストを識別するのに役立ちます。
経験ベースのテスト技法は、テスト担当者のテストの進め方と経験に大きく依存するため、カバレッジや有効性にはバラつきがあったります。
一般的に使用される経験ベースの技法は、以下のエラー推測、探索的テスト、チェックリストベースドテストについて述べたいと思います。
□4.4.1 エラー推測
エラー推測は、誤り、欠陥、故障の発生をテスト担当者の以下の知識に基づいて予測する技法です。
・アプリケーションの過去の動作状況
・開発担当者がおかしやすい誤りの種類
・他のアプリケーションで発生した故障
エラー推測技法に対するアプローチとして、起こり得る誤り、欠陥、故障のリストを作り、それらの故障やそれらを引き起こす欠陥を検出するテストケースを設計します。
（例）
Login画面のテストを行う際、以下のようなエラー予測が行えます。
仕様：ID、Password欄には英数字のみ入力可能
・ID、Password欄に、記号、2バイト文字、機種依存文字、空白スペースを入力し、Loginボタンを押す
・ID、Password欄を空白のままLoginボタンを押す
□4.4.2 探索的テスト
探索的テストは、形式的ではないテストであり、テスト実行時に動的に設計、実行、ログ記録、及び評価を行います。
テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成します。
探索的テストは、仕様がほとんど無かったり、不十分であったり、テストのスケジュールに余裕がなかったりする場合に、効果が最も大きくなります。
また、他の形式的なテスト技法を補完する場合にも有効です。
探索的テストは、他のブラックボックス、ホワイトボックス、経験ベースの技法と併用できます。
「セッションベースドテスト」
探索的テストで、活動を体系化するために使用します。
こちらは、探索的テストをあらかじめ決められた時間枠内で実施します。
テスト担当者は、テスト目的を含むテストチャーターに従ってテスト実行します。
テスト担当者は、テストセッションシートを使用し、実行した手順や発見した事象を文書化する場合があります。
□4.4.3 チェックリストベースドテスト
チェックリストベースドテストでは、チェックリストにあるテスト条件をカバーするように、テストケースを設計、実装、実行します。
テスト担当者は、新しいチェックリストの作成、若しくは既存のチェックリストの拡張をテスト分析の一環として行います。
チェックリストは、経験、ユーザーにとって何が重要であるかという知識、若しくはソフトウェアが不合格となる理由と仕組みについての理解に基づいて作成します。
詳細なテストケースが無い場合、チェックリストベースドテストがガイドラインとなり、ある程度の一貫性を実現します。
■最後に
今回は、テスト技法について述べてみました。
正直、ホワイトボックステストなど、私自身理解不足な部分もあり、うまく説明できないケースもありました。
申し訳ございません。
JSTQB Foundation Levelでは、概要となる表記が多いため、具体的なケースなどが無いため、理解するのが難しい部分もあります。
そのような部分は、別途個別の技法ごとにフォーカスをあてて、記事を投稿したいと考えております。
最後まで、読んで頂きありがとうございました。
サイトトップへ
https://susakiworks.com/
ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応
