てりぶろ

JSTQB　その５。

今週末に試験があります。　あと５日、がんばるゾー。
今日は４章と５章前半。

模擬テストの結果：
３章：100
４章：90
５章：100

4.テスト設計技法

4.1.テスト条件の決定とテストケースの設計
(1)このプロセスは非形式的～形式的まで、いろいろな方法で実施する
(2)まず、何をテストするか（テスト条件）を決定するために、テストベースを分析する
・テスト条件は検証できる項目として定義する（機能、トランザクション、品質特性、構造的要素）
(3)テスト条件から仕様や要件へのトレーサビリティを確立すること
・要件を変更した時に、関連するテストのカバレッジと影響度分析の両方が可能となる。
・テスト設計で決めるテストのアプローチは様々な要素で決まるが、特に対策要なリスクは重要。
(4)テストケース仕様を決めるときは、テスト設計技法を決めてテストケースやテストデータを準備（記述・作成）すること。
・テストケースとは、あるテスト条件を網羅するために詳細設計したもの。構成要素は、入力データ・実行条件・期待する結果・実行後に期待する条件など。
・IEEE829ではテスト設計仕様、テストケース仕様の内容を記述している。
・IEEE829：テスト計画(Test Plan)、テスト設計仕様(Test Design Spec)、テストケース仕様(Test Case Spec)、テスト手順仕様(Test Proc Spec)
(5)期待する結果を必ずテストケース仕様に含めること。
・期待する結果が定義されていないと、正否を誤認する可能性がある。
(6)テストケースを実行する順番に並べたものがテスト手順仕様。
・テスト手順はテストを実行する一連の手順を定義したもの。ツール（テストスクリプト）を使う場合でも自動実行手順として定義する。
・テスト手順仕様のメリット：テストケースに重複する手順を記載しないで済む。手順変更を局所化できる。テストの実施順序を決めやすい。
・テスト手順仕様のデメリット：テストケースの内容がわかりにくくなる。テストケースとは別管理になる。管理負荷が増す。
・テスト手順仕様作成のポイント：テストケースを構造化したテスト手順仕様に変換。テスト担当者に適したレベルで記載。優先順位や技術的・論理的依存関係でテストケース実行スケジュールを立てる。
(7)１つのテスト実行計画は、テスト手順や自動実行スクリプトをまとめたもの。
・いつ、誰が、どのテスト手順をどの順番で実施するかを決める。
・回帰テスト、優先順位、技術的・論理的な依存性も考慮すべき。

4.2.テスト設計技法のカテゴリ
(1)テスト設計技法の分類は大きく２つ：ブラックボックステストとホワイトボックステスト（グラスボックステスト、クリアボックステストとも）
・ISTQBでは３つで分類：仕様ベース・経験ベース（ブラックボックス）、構造ベース（ホワイトボックス）。
(2)ブラックボックステスト（仕様ベースのテスト技法）
・内部構造は参照せず、ドキュメントをベースにしてテスト条件やテストケースを作成したり、選択する方法。仕様が明らかになっていることが前提。
・ドキュメントとはシステムやコンポーネントを機能的、非機能的な特性を記述したものとする
・対象となる問題・ソフトウェア・コンポーネントを定義する場合はモデルを使用する
・モデルをベースに、体系的にテストケースを作成する
(4)ホワイトボックステスト（構造ベースのテスト技法）
・システムやコンポーネントの内部構造を分析してテストを設計する技法
・例えば、コードや設計をもとにテストケースを作成する
・テストケースを基に、ソフトウェア構造に関するカバレッジを計測でき、カバレッジを上げるためのテストケースを体系的に作成できる
・C0:ステートメントカバレッジ、C1:ブランチカバレッジ
(5)経験ベースのテスト技法
・担当者の知識・経験をベースにテストケースを作成する。
・テスト担当者・開発担当者、ユーザ、その他のステークホルダのソフトウェア知識、使用法、使用環境など
・類似した欠陥や、欠陥が存在する箇所に関する知識
・探索的テスト：ベテランによる経験ベースのテスト。モンキーテスト：単なるやみくもなテスト

4.3.仕様ベース、ブラックボックスのテスト技法

4.3.1.同値分割法
・同じ処理をする入力値をグループに分割（同値クラス）して、グループ内の入力を同等に扱う。
・正常値のグループ、不正値のグループ等に分割。
・対象とする値は、出力値、内部変数、時間に依存する値（時刻、イベントの前後）、インタフェースパラメータ等もある
・このテストではグループを網羅するようテスト設計する。
・カバレッジ＝テストした同値クラス数÷全同値クラス数
・あらゆるテストレベルに適用できる。

4.3.2.境界値分析
・同値分割したグループの境界上の動作には欠陥が潜む可能性が高い
・境界値とはグループの最小値、最大値のこと。ともに正常の境界値、不正の境界値をカバーするようテスト設計すること
・あらゆるテストレベルに適用できる。

4.3.3.デシジョンテーブルテスト
・行：条件一覧（入力値）・結果一覧（処理結果）、列：規則、交差点：条件の組み合わせ（真偽）、組み合わせに対応する結果。
・論理的な条件を含む複雑なシステム要件を把握する場合に有効
・トリガーとなる条件（入力条件の真偽の組合せが多い）、条件の組合せに対する処理で構成される。
・デシジョンテーブルのカバレッジとはひとつの列が最低１回は実行されたこと、つまりトリガーとなる組合せの全てを網羅することをになる
・利点はテスト以外ではありえない組合せも確認できること、全ての状況に適用可能
・カバレッジ＝テストした規則数÷全規則数

4.3.4.状態遷移テスト
・状態の遷移を網羅（状態遷移図・状態遷移表）し、各状態間の遷移・状態を変える入力やイベントと、その結果起きる処理を確認する
・カバレッジ：chowのカバレッジメトリクス、セル網羅基準

4.3.5.ユースケーステスト
・各ユースケースには事前条件・事後条件があり、ユースケースが正常に動作するには、その条件を満たす必要がある。
・通常ユースケースにはメインストリームになる基本フロー（基本シナリオ）があり、別シナリオへのブランチもある。
・代替フローは基本フロー以外のアクションを行うが、事後条件はは同じになる。
・ユースケース記述を元にしたユースケースケーステストはシステムが稼動している状態でプロセスフローの欠陥を見つける場合に効果がある
・ユースケース（シナリオ）は受け入れテストや、コンポーネント統合テストで有効

4.4.構造ベース、ホワイトボックスのテスト技法

4.4.1.ステートメントテストとカバレッジ
・ステートメント（命令）の実行率を評価する場合に用いる。

4.4.2.デシジョンテストとカバレッジ
・ブランチテスト（ブランチカバレッジ）ともいう
・判定の実行率を評価する場合に用いる。
・１００％のデシジョンカバレッジは１００％のステートメントカバレッジであるが、逆は成立しない

4.4.3.その他の構造ベース技法
・条件カバレッジ（コンディションカバレッジ）：判定条件内の個々の条件文まで網羅する
・複合条件カバレッジ（マルチコンディションカバレッジ）：複数の条件文の評価方法まで考慮して網羅する

4.5.経験ベースのテスト技法
(1)エラー推測のテスト技法
・テストケースはテスト担当者の経験が元になる、よって効率にはバラツキが多い
・体系的なテスト技法を補完するものとして利用すべき
・エラー推測の例：ゼロの割り算、ヌル値の参照、空白のリスト・要素が１つのリスト、うるう日
(2)探索的テスト
・テスト目的など、テストの役割をベースにしたもの
・仕様がほとんどない、不十分である、スケジュールに余裕がない場合や、他のテスト技法を補完する場合に効果がある

4.6.テスト技法の選択
(1)テスト技法の選択
・システムの種別
・規則や標準
・顧客や契約上の要件
・リスクのレベルや種類（高リスク機能を重点にするなど）
・テストの目的（欠陥の検出なのか、動作の確認なのか）
・テストベース（入手可能なドキュメントは？）
・テスト担当者の知識レベル
・時間と予算
・開発ライフサイクル（アジャイル開発ではテストファーストなので構造ベース技法は使えない）
・ユースケースモデル
・摘出した欠陥に対する経験、など
(2)テスト設計はいくつかテスト設計技法を組み合わせて使う
・仕様が入力条件の組み合わせを含む場合は、原因－結果グラフの作成から始める
・どんな場合でも境界値分析はする
・入力と出力の有効・無効の同値クラスを分類してテストケースにする
・エラー推測によりテストケースを補完する
・構造ベース技法でカバレッジ基準を満たすようテストケースにする

5.テストのマネジメント

5.1.テスト組織

5.1.1.テスト組織と独立性
(1)独立した組織によるテスト形態
・同じ開発プロジェクト内の独立したテストチーム
・同じ会社内の独立したテストチーム
・顧客などから派遣されたテストチーム
・使用性・セキュリティ・標準準拠などある特定のテストを行うスペシャリスト
・組織外の独立したテストチーム
(2)一般に複雑・安全性最優先のシステムでは、あるレベル／全レベルを独立したテストチームで行うのがよい
(3)独立したテストの利点
・先入観がないため、（開発者が見つける欠陥とは）異なる欠陥を摘出できる
・システムの仕様策定中や実装中に想定どおりかを検証できる
(4)逆に欠点は
・開発チームから離れている
・最終チェックポイントとしてボトルネックになる
・開発担当者の品質に対するマインドが薄れる（テスト担当者任せになる）

5.1.2.テストリーダとテスト担当者の作業
(1)テストリーダ
・テストマネージャ、テストコーディネータと呼ぶこともある
・プロジェクト管理者、開発管理者、品質保証管理者、テストグループの管理者が行う
・大プロジェクトでは一般に、テスト計画、テスト作業のモニタリングとコントロールを行う
(2)テストリーダの作業
・テスト戦略の具体化、プロジェクト管理者やその他関係者と連携してテスト計画をたてる
・プロジェクトのテスト戦略や組織のテストポリシーを策定したりレビューする
・テストの観点から、プロジェクトの他作業に貢献する
・リスクを考慮し、テストの選択、要する時間、工数、コストの見積り、リソースの確保、テストレベル、サイクル、手法、目的の定義、インシデント管理の計画などのテスト作業を計画
・テストの実行結果や進捗をもとに、計画を実施し、必要な対策をとる
・トレーサビリティの向上、テストウェアの構成管理をｾｯﾄｱｯﾌﾟ
・テスト進捗のモニタリングに最適のメトリクスを選定する
・作業の自動化範囲、自動化方法、支援ツール選定をする
・構築するテスト環境を決める
・テストの順番を決める
・テスト進捗のモニタリングからテストレポートを作成する
(3)テスト担当者の作業
・テスト計画をレビュー、改善案の提案
・テスト容易性の観点で、要件、機能仕様、モデルを分析・レビュー・評価する
・テスト仕様を作成
・テスト環境をセットアップ
・テストデータの入手・作成
・テストの作成、実行、ログ採取、結果の評価、期待する結果との差異をドキュメントに残す
・必要に応じてテストコントロールツール、マネジメントツール、モニタ用ツールを使用
・テストの自動化
・必要に応じて性能の計測
・他者のテストをレビュー

5.2.テスト計画作業と見積り

5.2.1.テスト計画作業
(1)IEEE829
・Test plan identifier
・Introduction
・Test items（テストの個々の要素）
・Features to be tested（試験対象機能）
・Features not to be tested（試験非対象機能）
・Approach（テスト戦略）
・Item pass/fail criteria（合否判定基準）
・Suspension criteria and resumption requirements（中止・再開基準）
・Test deliverables
・Testing tasks（テスト作業）
・Environmental needs（環境要件）
・Responsibilities
・Staffing and training needs
・Schedule
・Risks and contingencies
・Approvals
(2)テスト計画作業
・組織のテストポリシー、テストの範囲、目的、リスク、制限、緊急度、テスト容易性、使用リソースなどの影響を受ける
・プロジェクトの進行により情報が増し、より具体化できる
・連続的な作業であり、テスト作業のフィードバックによりテスト計画を変更するリスクを認識できる

5.2.2.テスト計画策定
(1)テスト計画策定
・テスト戦略：テストに対する基本的なアプローチを定義する
・テストレベル、開始・終了基準などの定義を含む
・ソフトウェアライフサイクルでの作業にテスト作業を統合・協調させる
・何をテストするか、どのような作業を行うか、いつテストを進めるか、テスト結果をどのように評価するか、いつテストを終了するかを決める
・定義した作業にリソースを割り当てる
・テストドキュメントの量、詳細度、構成、テンプレートなどを決める
・テストの前準備、実行、欠陥の解決、リスク問題のモニタリングやコントロールをするためのメトリクスを選ぶ
・テスト手順の詳細化度合いを決める

5.2.3.終了基準
(1)いつテストを終えるかを定義する。基準とは：
・コード、機能性、リスクのカバレッジのように網羅性や完全性がわかる値
・欠陥密度や信頼性の見積り値（信頼度成長モデル）
・コスト
・残存リスク（未修正の欠陥や、カバレッジ不足の領域）の程度
・出荷時期などのスケジュール

5.2.4.テストの見積り
(1)見積り方式
・以前のプロジェクトや類似のプロジェクトのメトリクスや、代表的な値をベースに見積もる方式
・作業の実行者やエキスパートによる見積もる方式
(2)工数見積りが終了すると、必要なリソースとスケジュールを決定できる
(3)影響する要素とは
・プロダクトの規模、問題の複雑性、信頼性、セキュリティ要件、ドキュメントへの要件
・開発プロセスの特性：組織の安定度、使用ツール、テストプロセス、スキルレベル、時間のプレッシャー
・テスト出力結果：欠陥数、修正工数

5.2.5.テストアプローチ（テスト戦略）
(1)アプローチの分類
・予防的アプローチ：欠陥の発生を予防するため、早い時期にテスト設計する方法
・対処的アプローチ：ものが出来てからテスト設計する方法
(2)代表的なアプローチ
・分析的アプローチ：緊急度の高い分野を重点的にテストするリスクベースのテスト
・モデルベースアプローチ：故障率（信頼度成長モデル）、使用法（稼動状況）による統計的情報を使う確率的テスト
・方法論的アプローチ：障害をベースにしたもの（エラー推測、フォールト攻撃）、チェックリストベース、品質特性ベースなど
・プロセス準拠アプローチ、標準準拠アプローチ：アジャイル方式など、業界に固有の標準に則る方法
・動的経験則に基づくアプローチ：探索的テスト
・コンサルテーションベースのアプローチ：技術的アドバイスやガイドライン、ビジネスドメインのエキスパートの意見に従うテスト、
・回帰的アプローチ：既存テストの再利用や、標準のテストスイートの利用
(3)アプローチを組み合わせることもできる
(4)アプローチを決める要素とは
・リスク：プロジェクト失敗のリスク、プロダクトへの影響度など
・スキル・経験：対象とする技術、ツール、方法に対する人員のスキルレベルや経験
・テストの目的とテストチームの責務
・規則上の条件（開発規約など）
・プロダクトやビジネスの特性