1.テストプロセス(JSTQB Advanced Levelアナリスト)

※出題される60問の中で2番目に出題数が多い章(18.0%程度)

 

1.2 ソフトウェア開発ライフサイクルにおけるテスト

  • 他の関連する組織領域に情報を提供する可能性がある点を認識する必要がある
    • 要求エンジニアリングおよびマネジメント
      • 要件レビュー
    • プロジェクトマネジメント
      • スケジュール
    • 構成管理および変更管理
      • ビルド検証テスト
      • バージョンコントロール
    • ソフトウェア開発
      • 提供される内容とタイミングの予測
    • ソフトウェアメンテナンス
      • 欠陥マネジメント
      • ターンアラウンドタイム(欠陥を見つけてから解決するまでの時間)
    • テクニカルサポート
      • 回避策の正確な文書化
    • テクニカルドキュメントの生成
      • これからドキュメントへの入力とドキュメントのテクニカルレビュー
 
  • 関与への期待度とタイミングを理解する必要がある
  • アジャイルプロジェクト
    • 最も早期に関与する必要がある
    • 初期のアーキテクチャ、設計の作業を開発者と連携して行う必要がある
    • プロジェクト全体を通して関与する
  • 埋め込み型イテレーティブモデル
    • 標準的な計画作業、設計の側面に関与する
    • ソフトウェアの開発、テスト、変更、および展開と段階が進むにつれ、より相互作用的な役割に移行する
 

1.3 テストの計画作業、モニタリング、およびコントロール

  • テスト計画作業時には、テストアナリストはテストマネージャと連携して、次の項目を検討し、計画する必要がある
    • テスト計画を、機能テストに限定されないようにする
      • 使用性テストに責任を持つことがある
    • テストマネージャと連携してテスト見積りをレビューし、テスト環境の調達と妥当性確認のために適切な時間が計上されていることを確認する
    • 構成テストを計画する
    • ドキュメントのテストを計画する
    • インストール手順のテストを計画する
    • ソフトウェアライフサイクルとの整合性が取れるようにテストを計画する
    • クロスファンクショナルなチームと連携してリスクの識別および分析を行うための適切な時間を計上する
      • リスクマネージメントセッションを編成する責任を持たないが、これらの活動に積極的に関与する必要がある
 
  • テストマネージャ:テストのモニタリングとコントロール
  • テストアナリスト:コントロールを可能にするための測定
 
  • 定量的データを収集する必要がある
    • 完了した計画作業の割合
    • 達成したカバレッジの割合
    • 合格および失敗したテストケースの数
 
  • テストマネージャ:メトリック情報の要約を編集およびレポート
  • テストアナリスト:各メトリックの情報を収集
 
  • 正確なメトリクスを使用することにより、テストマネージャはプロジェクトをマネジメントし、必要に応じて変更を開始(コントロール)できる
  • テストアナリストは、データが正確で、タイムリーであり、客観的であるようにする必要がある
 

1.4 テスト分析

  • テストアナリストは、スコープを利用して以下を行う
    • テストベースを分析する
    • テスト条件を識別する
 
  • テストアナリストは、テスト分析を効果的に進めるために、次の開始基準が満たされていることを確認する必要がある
    • テストベースとして機能するテスト対象が記載されたドキュメントが存在する
    • このドキュメントは、レビューに適切な評価で合格しており、レビュー後に必要に応じて更新されている
    • テスト対象に対して、残りのテスト作業を完了するために適切な予算とスケジュールが確保されている
 
  • テスト条件を識別するには、テストベースとテスト目的を分析する
    • ドキュメントが古いままで更新されていないか、存在しない場合、例えばワークショップやスプリント計画作業の際に、関連するステークホルダと会話することによりテスト条件を識別できることがある
    • これらのテスト条件は、テスト戦略およびテスト計画内で識別されるテスト設計技法を通して、何をテストするかを決定するために使用する

 

1.5 テスト設計

  • 特定の状況で最適な種類のテストケースを決定すること
 
  • 具体的テストケースは、以下に役立つ
    • テスト担当者の経験が少ない場合
    • 監査などテストの外部検証が必要な場合
    • 優れた再現性だが、メンテナンスに非常に多くの労力を必要とし、実行時にテスト担当者の創造力を制限する傾向にある
  • 論理的テストケースは、以下に最適
    • 要件が適切に定義されていない場合
    • テストを実行するテストアナリストがテストとプロダクトの両方に精通している場合
    • 公式なドキュメントが必要でない場合
    • 具体的テストケースよりも優れたカバレッジを提供することがあるが、再現性が失われる可能性もある 
 

1.6 テスト実装

  • テスト設計の実現
    • テストケースの実行を開始するために必要な自動テストの作成
    • テストの実行順序の編成
    • テストデータおよびテスト環境を完成されること
    • リソース割り当てなどのテスト実行スケジュールの作成
    • 対象テストレベルの明示的および暗黙的な開始基準のチェック
    • プロセス内の前の手順の終了基準が満たされていることの確認
  • テストレベルまたはテストプロセスの手順のいずれかの終了基準を省略した場合、実装作業がスケジュール遅延、不十分な品質、予期しない余分作業の影響を受ける可能性がある
  • 手動および自動のテストを実行する順序を完成させて確認し、特定の順序でのテストが求められるというような制約を入念に確認する必要がある
  • 依存関係を文書化し、チェックする必要がある
 

1.7 テスト実行

  • 適切な時間をかけて、テスト時に観察された他の興味を引くテストシナリオおよび振る舞いを確実にカバーする必要がある
  • 実行結果と期待結果を比較することに注意を払い、焦点を当てる必要がある
  • インシデントを入念に精査し、その原因を究明し、インシデントの解決を支援するデータを収集する必要がある
  • 欠陥を識別したら、テストドキュメントを入念に評価して、テストドキュメントが正しいことを確認する
 
  • テスト実行時に考慮する必要のある特定の領域
    • 「関連性のない」異常なものを見つけたり、探索したりしなさい
    • 想定されない振る舞いをプロダクトが行っていないことを確認しなさい
      • 行うことが想定されていない何かをプロダクトが誤って行っていないことを確認する必要がある
    • テストスイートを構築し、時間と共に成長し変化していくことを予期しなさい
    • 次のテスト向けにメモを記述しなさい
    • すべての手動テストを再実行することを期待しない
    • テストケースを追加するため、欠陥追跡ツールを使用してデータを調べなさい
    • 回帰テストの前に欠陥を見つけなさい
 

1.8 終了基準の評価とレポート

  • 終了基準に満たすことに向けて進捗を評価するために、テストマネージャが使用する情報を提供し、データが正確であることを確認する責任がある
  • テストアナリストは一般的に、テストサイクルの期間中にステータスレポートを提供し、テスト終了時に最終レポートの作成に貢献する
  • テストアナリストは、レポートツールを使用でき、テストマネージャが必要な情報を抽出できるように、適切な情報を提供する必要がある
 

1.9 テスト終了作業

  • 成果物を必要とする人々へそれを届けることへの関与を期待されている
  • 振り返りミーティングに参加する必要がある
  • ミーティングで要求される情報を豊富に提供でき、プロセス改善に関する価値ある情報を収集するミーティングには参加する必要がある
  • 結果、ログ、レポート、その他のドキュメント、および成果物を保管する必要がある
 
以上。

3.4.3 探索的テスト(JSTQB Advanced Levelアナリスト)

  • テスト担当者が、以下を同時に行う
    • プロダクトとその欠陥の分析
    • 行うべきテスト作業の計画
    • テストの設計と実行
    • 結果の報告
  • テスト実行時に、テスト目標を動的に調整し、軽量のドキュメントのみを準備する
 
【適用】
  • 優れた探索的テストは、しっかりと計画されており、相互作用的で創造的
  • テスト対象のシステムに関するドキュメントをほとんど必要としないため、ドキュメントが存在しないか、他のテスト技法では適切でない場合に使用することが多い
  • 多くの場合、他のテストを補完したり、追加のテストケースを開発するための基準を提供したりするために使用
 

【制限/注意事項】

  • マネジメントおよびスケジュールが困難
  • カバレッジがまちまちでまとまりがなく、再現するのが困難
  • 再現するのが困難であるためすべての活動を完全に記録することがある
 
探索的テストをマネジメントする方法
  • テストセッションでカバーする領域を指定した指示書と、テストで使える時間を決定するタイムボックスを使用することができる
  • 1回のテストセッション終了時、または複数のセッション終了時に、テストマネージャーはテスト結果を収集し、次のセッションのチャータを決定するために報告会を開催する

 

【カバレッジ】

  • チャータは、目的と最低限やるべきこと(作業と成果物)が明示された簡易な指示書
    • テスト作業で重点を置く領域
    • テストセッションのスコープ内およびスコープ外
    • 計画したテストを完了するために必要なリソース

 

【検出できる欠陥の種類】

  • 手続き化された機能テストで見逃されたシナリオベースの問題
  • 機能境界間に存在する問題
  • ワークフロー関連の問題
  • 性能問題
  • セキュリティ問題
 
以上。

3.4.2 チェックリストベースドテスト(JSTQB Advanced Levelアナリスト)

  • チェックリストは、レビューで用いるのが普通であるが、チェックリストベースドテストは、そのチェックリストから動的なテストケースを作成して実行する技法
    • メモすべき項目やチェックすべき項目
    • 覚えておくべき項目
    • プロダクトに対して検証を行うルールや基準のセット
 
【適用】
  • テスト対象のソフトウェア、またはチェックリストによりカバーされる領域に精通している経験を積んだテストチームが行うプロジェクトで、最も有効に使用される
  • テストケースおよびテスト手順で一般的に見られる詳細な手順が抜ける傾向にある
  • 体系的に整理できていて、追加が容易になっていないといけない
  • すべてのテストレベルで使用できる
  • チェックリストは、回帰テストおよびスモークテストにも使用できる
 

【制限/注意事項】

  • 単調なテストケースが多くなり、他の形式なテストに比べて、カバレッジが高めの数値になりがちである
  • テスト実行が容易であるため、早期にカバレッジが上昇する
  • テスト担当者によりチェックリストの解釈が異なり、チェックリストの項目を満たすために異なる確認方法をとる可能性があり、再現性が悪い
  • テスト対象のソフトウェアの重要な側面をチェックリストが確実にカバーするように、メンテナンスを行う必要がある

 

【カバレッジ】

  • カバレッジはチェックリストと同様であるが、チェックリストを実行する人によって異なる可能性がある

 

【検出できる欠陥の種類】

  • データや手順がテスト担当者によって異なることが、欠陥検出につながっている
 
  • テスト時のデータ
  • 手順の順序
  • 全般的なワークフローなどが異なることによりもたらされるもの
 
以上。

3.4.1 エラー推測(JSTQB Advanced Levelアナリスト)

  • コードの設計および開発時に作り込まれた可能性のある潜在的なエラーを推測する
  • エラーの結果として生じる欠陥を明らかにするために使用する最善の方法を決定する
  • 潜在的な故障モードを識別するためのリスク分析時にも役立つ
 
【適用】
  • 統合テスト、システムテスト
  • すべてのテストレベルで使用できる
  • 多くの場合、他の技法と組み合わせて使用する
  • 既存のテストケースのスコープ拡大するのに役立つ
  • 一般的な誤りやエラーをテストする場合にも効果的に使用できる
 
  • チェックリスト欠陥分類法は、体系的・網羅的にチェック項目や典型的な欠陥や原因を整理したもの。これをベースにすれば、エラー推測のテストを追加しやすい(漏れや派生に気付きやすい)
  • 追加したテストに相当するチェック項目や原因をフィードバックして、チェックリストや欠陥分類を洗練させておくことも期待される
 

【制限/注意事項】

  • カバレッジを評価することは困難
  • 能力と経験に応じて大きく異なる
  • テスト対象のコードの種類に共通して作り込まれる欠陥の種類に精通している熟練のテスト担当者が使用する場合に最善となる
  • 文書化しないことが多く、他の形式のテストに比べて再現性に劣っている

 

【カバレッジ】

  • 分類法を使用すると、該当するデータ異常と欠陥の種類によりカバレッジを決定できる
  • 分類法を使用しないと、経験と知識や利用可能な時間によりカバレッジが制限される

 

【検出できる欠陥の種類】

  • ドメイン内の機能的な問題
  • 境界値の取り扱い
  • 変数の相互作用の問題
  • エラー処理
 
  • 推測した欠陥
 
以上。

3.3.2 欠陥分類法(JSTQB Advanced Levelアナリスト)

  • 欠陥タイプを分類した一覧
  • 非常に汎用的で高位レベルのガイドラインとして使用
  • 非常に限定的に使用
 
  • テキストフィールドでの問題
    • 有効なデータが受け付けられない
    • 無効なデータが受け付けられる
    • 入力長が検証されない
    • 特殊文字が検出されない
    • ユーザエラーメッセージが有益でない
    • ユーザは誤りのあるデータを修正できない
    • ルールが適用されない
  • 日付フィールドでの問題
    • 有効な日付が受け付けられない
    • 無効な日付が拒否されない
    • 日付範囲が検証されない
    • 精度データが正しく処理されない(例:hh:mm:ss)
    • ユーザは誤りのあるデータを修正できない
    • ルールが適用されない(例:終了日は開始日よりも未来にある必要がある)
 
  • 分類法を作成するには
  1. ゴールを作成し、期待する詳細度(分類の階層の深さと、共通する欠陥の記述レベルの両方)を定義する
  2. 基準として使用する特定の分類法を選択する
  3. 値と、組織内の実績または外部のプラクティスまたはそれら両方から共通の欠陥を定義する
 
  • カスタマイズするには最初に分類法の目標または目的を定義する必要がある

 

  • 詳細度を高めるほど、開発とメンテナンスにかかる時間が多くなるが、テスト結果における高い再現性をもたらす
  • 詳細な分類法は冗長になる可能性があるが、テストチームは、情報またがカバレッジの不足を発生させることなく、テストを分割して実施できる

 

  • テスト条件とテストケースを作成するために使用できる
  • 特定のリスク領域に焦点を当ててテストするのに役立つ
  • 使用性や性能など、非機能領域に対しても使用できる
  • 多くの分類法の一覧が、IEEEやインターネット上で提供されている
 
以上。

3.2.9 ドメイン分析(JSTQB Advanced Levelアナリスト)

  • ドメインは、定義済みの値のセット
  • 1つの変数の値の範囲(1次元ドメイン)
    • 同値分割法と境界値分析を使用
      • IN:分割領域内(すべての境界条件を満たし、境界上の点ではない)
      • OUT:分割領域外(どの境界条件も満たさない点である)
      • ON:分割領域の境界上(境界上の点である)
        • 開境界「より大きい、より小さい、未満、超」
        • 閉境界「以上、以下、等しい」
      • OFF:分割領域境界に隣接(境界上の点ではない)
        • 属する同値領域の外側にある方
      • 65歳以下は、ONが65、OFFが66(以下は65が入るので、OFFは入らない66)
      • 65歳未満は、ONが65、OFFが64(未満は65が入らないので、OFFは入る64)
  • 相互作用する変数の値の範囲(多次元ドメイン)
 
【適用】
  • 多くの変数が相互作用していてデシジョンテーブルで扱いづらい場合に、ドメイン分析を適用する
  • すべてのテストレベルで使用できるが、統合テストとシステムテストで頻繁に使用する
 

【制限/注意事項】

  • 欠陥はOFF、OUTに潜んでいることが多い
  • テストケース削減したい場合は、明らかなINから割愛すれば良い
  • テスト領域を定義するために開発者と連携する際に使用する強力な技法

 

【カバレッジ】

  • 最小カバレッジは、各ドメインでIN、OUT、ON、OFFのそれぞれの値をテストすること

 

【検出できる欠陥の種類】

  • ドメイン内の機能的な問題
  • 境界値の取り扱い
  • 変数の相互作用の問題
  • エラー処理
 
以上。

3.2.8 ユーザストーリーテスト(JSTQB Advanced Levelアナリスト)

  • アジャイル方法論では、要件はユーザストーリーの形式で記述される
  • 1つのユーザストーリーは、1回のイテレーションの中で設計、開発、テスト、実証(デモンストレーション)までは行える小さなユニットを対象とする
  • 実装すべき機能や非機能要件の記述と受け入れ基準を含んでいる
 
【適用】
  • アジャイル、および類似のイテレーティブ/インクリメンタル開発の環境で使用する
  • すべてのテストレベルで機能/非機能に関係なく、ユーザストーリーテストは実施できる
 

【制限/注意事項】

  • ストーリーは機能のわずかな増分(インクリメント)であるので、実際には実現する一部をテストすることになる。そのため、ドライバおよびスタブの作成が必要となる
  • この要件を満たすためには、プログラミング能力と、APIテストツールなどテストに役立つツールを使用する能力が必要である

 

【カバレッジ】

  • 最小カバレッジは、指定した各受け入れ基準の達成を検証すること

 

【検出できる欠陥の種類】

  • 指定した機能をソフトウェアが提供できないという機能面での欠陥
  • 既存機能に関する新しいストーリーにより、機能の統合問題という欠陥
  • ストーリーは個別に開発するので、性能、インターフェース、およびエラー処理の問題を検出することもある
 
  • 新しいストーリーをテスト用にリリースした場合は常に、提供している個々の機能のテストと、統合テストの両方を実施することが重要
 
以上。

3.2.7 ユースケーステスト(JSTQB Advanced Levelアナリスト)

  • システムの使われ方をエミュレートするトランザクションベーステストおよびシナリオベースのテストを可能にする
  • アクターと、何らかの目標を達成するシステムとの間の相互作用の観点で定義する
 
【適用】
  • システムテスト、受け入れテストのテストレベルで適用する
  • 統合の状況によっては統合テストにも適用する
  • コンポーネントの振る舞いに応じてコンポーネントテストでも使用できる
  • 性能テストの基礎となる
 

【制限/注意事項】

  • 様々な大替パスを正確に定義する必要がある
  • ユースケースはガイドラインとして扱い、テスト対象の完全な定義として扱ってはならない

 

【カバレッジ】

  • テスト済みのパスの数 ÷ 主要パスと大替パスの合計
 
  • 最小カバレッジは、主要パス用の1つのテストケースと、大替パス(例外パスおよび失敗するパスを含む)またはフローごとに1つのテストケースを含む。

 

【検出できる欠陥の種類】

  • 定義済みシナリオの誤った処理
  • 大替パス処理の欠落
  • 提示された条件の誤った処理
  • 読みにくいまたが不正なエラーレポート
 
以上。

3.2.6 組み合わせテスト技法(JSTQB Advanced Levelアナリスト)

  • 複数の値を持つ複数のパラメータを含むソフトウェアをテストする場合で、組み合わせ数が膨大なときに使用する
    • ペアワイズテスト
      • パラメータをペアとして組み合わせてテスト
    • 直交表テスト
      • すでに定義されている数学的に裏付けられた表
      • 表内の変数をテスト対象となるアイテムに置き換えることで、テスト時のカバレッジ度合いを達成する組み合わせのセットを生成できる
    • クラシフィケーション
      • テスト対象の組み合わせの規模(2つの値、3つの値の組み合わせなど)を定義できる
 
【適用】
  • 統合テスト、システムテスト、システム統合テストのテストレベルで適用する
 
  • 複数の入力欄のある画面
  • 多数の次元でシステムを構成できる場合
 

【制限/注意事項】

  • 想定されない相互作用が特定の変数間に存在する場合、その組み合わせはテストしない限り、その欠陥は検出されない可能性がある
  • パラメータとそれぞれの値を識別するのが困難な場合がある
  • 特定カバレッジの度合いを満たす組み合わせの最小セットを手作業で見つけることは困難であり、一般的にはツールを使用する
  • ドメイン知識またがプロダクトの使用情報に基づいて、パラメータを重要として扱うかどうかを選択できる

 

【カバレッジ】

  • 1ワイズカバレッジ(シングルカバレッジ)
    • すべてのパラメータにおけるそれぞれの値を、選択した組み合わせの1つ以上に含める
  • 2ワイズカバレッジ(ペアカバレッジ)
    • 任意の2つのパラメータについて、各値のすべてのペアを1つ以上の組み合わせに含める必要がある
  • nワイズカバレッジ
    • n個のパラメータの任意のセットについて、値のすべての組み合わせを、選択した組み合わせに含める必要がある

 

【検出できる欠陥の種類】

  • いくつかのパラメータの値の組み合わせに関する欠陥
 
以上。

3.2.5 状態遷移テスト(JSTQB Advanced Levelアナリスト)

  • ソフトウェアが、有効またが無効な遷移を介して、定義された状態の開始および終了を実行できるかどうかをテストするために使用する
 
  • 【状態遷移図】:状態間のすべての有効な遷移を図で示す
  • 【状態遷移表】:有効および無効の両方の可能性のあるすべての遷移を表す
 
【適用】
  • 定義済みの状態を持ち、それらの状態間の遷移(例えば、画面の変更)を引き起こすイベントを持つすべてのソフトウェアに適用できる
  • すべてのテストレベルで使用できる
 

【制限/注意事項】

  • 0スイッチ:個々の遷移
  • 1スイッチ:2つの連続した遷移のシーケンス
  • 2スイッチ:3つの連続した遷移のシーケンス

 

【カバレッジ】

  • 許容できる最低限のカバレッジ度合いは、すべての状態に遷移し、すべての遷移を通ること
  • 【ラウンドトリップカバレッジ】:繊維のシーケンスがループを形成する時に適用する

 

【検出できる欠陥の種類】

  • 以前の状態で発生した処理の結果である現在の状態での不正な処理
  • 不正またがサポートされていない遷移
  • 終了しない状態
  • 必要にもかかわらず存在しない状態または遷移
 
  • 仕様ドキュメントの欠陥
  • 欠落(特定の状況で実際に何が発生するかに関する情報が存在しない)
  • 矛盾
 
以上。