はじめに
昨日、JSTQB ALTAの試験を申し込み、学習をしています。今日はシラバスの１章と２章を学習しました。ALTAのシラバスのみでなく、青本と一緒に学習を進めています。
テストアナリストのタスクである「提供先と提供する情報」については以下にメモしています。
今日のポイントは以下。（シラバスの切り抜きとメモ）
テスト分析
テスト分析について（シラバスより）
テスト計画では、テストプロジェクトの範囲を定義する。テスト分析では、テストアナリストがこの範囲に対して、次のことを行う。
- テストベースを分析する。
- テストベースのさまざまな種類の欠陥を識別する。
- テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる。
- テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。
- リスクベースドテストに付随するタスクを実行する。
テストアナリストはテスト分析を効果的に進めるために、次の開始基準が満たされていることを確認する必要がある。
- （例えば、要件、ユーザーストーリーといった）テスト対象について記述した、テストベースとなりうる知識体系がある
- このテストベースは、適切な結果でレビューに合格しており、レビュー後に必要に応じて更新されている。ハイレベルテストケースを定義する作業が予定されている場合、テストベースはまだ完全に定義する必要ないことがある。アジャイルソフトウェア開発では、各イテレーション開始時にユーザーストーリーを洗練していくので、このレビューサイクル繰り返すこととなる。
- テスト対象に対して、残りのテストタスクを完了するために適切な予算とスケジュールが確保されている。
ハイレベルテストケースの定義のタイミング
ハイレベルテストケースは、テスト対象の基本情報が揃い、テストベースがレビュー済みであれば定義を始められるが、アジャイルではイテレーションごとにテストベースが更新されるため、タイミングが繰り返し発生することがある。
詳細は以下。
- テスト対象の基本情報が揃っている段階
- ハイレベルテストケースを定義するには、テスト対象について最低限の基本情報が必要。このため、要件やユーザーストーリーが概ね整備されている段階でテストケース定義を始める。
- テストベースのレビューが完了している段階
- ハイレベルテストケースを作成する前には、レビュー済みのテストベースがあることが理想。文脈で触れているように、「テストベースが完全には整備されていない」場合でも、レビューを繰り返しながら、テストケースを更新する形で進めることが多い。
- アジャイル開発の場合
- アジャイル開発では、各イテレーションの開始時にユーザーストーリーを見直し、テストベース（テストの基礎情報）も更新されることが多いため、イテレーション開始時に合わせてテストケースを見直し・更新する。つまり、レビューサイクルと連動しながらハイレベルテストケースも並行して定義していく。
テスト設計
ローレベルテストケースがテストベースにある自明でない欠陥を検出できる
一見すると問題がないように見えるが、細かくテストすることで見つかる問題を発見できることを指す。ローレベルテストケースは詳細なテスト手順や具体的なデータを含むため、仕様や要件に隠れた不明確さや矛盾が見つかりやすくなる。
- 入力条件が明確でない場合
- 例えば、要件に「ユーザー名は英数字のみ」と書かれていても、実際には「英数字以外の記号が使えないこと」をテストする必要が出てくる。ローレベルテストケースでは、特定の文字を含むユーザー名など詳細な入力例を使うため、仕様に曖昧さがあるとテストを通して見つかることがある。
- 計算や論理の詳細な処理が不明瞭な場合
- 「合計金額に一定の割引が適用される」との仕様があっても、割引が適用される条件や計算ルールに曖昧さが残っている場合がある。ローレベルテストケースで具体的な計算を行うと、どの条件で割引が適用されるべきか、あるいは計算結果が仕様通りかどうかを細かく確認できる。
- エラーハンドリングの不備
- テストベースがエラーハンドリングについて十分に記載していない場合、ローレベルテストケースの詳細な手順で異常データや不正な操作をテストすると、エラーメッセージが出ない、もしくは正しい対応がされないといった欠陥が発見されることがある。
テストケースの設計（シラバスより）
テストケースの設計は、識別されたテスト条件に対して、テスト技法を使って段階的な推敲、洗練をしていく。テストケースは、再利用可能であり、検証可能であり、テストベース（要件など）までトレーサビリティが確保されているべきである。
テスト設計では、次のアイテムを識別する。
- 目的（観測可能で測定可能なテスト実行の目的）
- プロジェクトまたローカライズされたテスト環境のどちらかの要件、およびそテストのリリース計画、テスト実行前のシステムの状態などの事前条件
- テストデータ要件（テストケースを実行するための入力用データとシステム内に必要なデータの両方）
- 明確な合格/不合格基準が定義されている期待結果
- 影響を受けたデータ、テスト実行後のシステムの状態、後続処理のためのトリガーなどの事後条件
テスト設計におけるアイテムの識別
- 目的
- 意味: テストの具体的な目標。「何を確認するためのテストなのか」を明確にする。
- 例: システムが特定の機能を正しく処理できるか、処理速度が十分かなど、観測や測定可能なものを設定する。
- 事前条件
- 意味: テストを実行する前に必要な条件。プロジェクト全体に必要な環境や、特定のテスト専用の条件が該当する。
- 例: 例えば「システムが初期化されていること」「データが指定された状態に設定されていること」など、テスト開始前に満たしておくべき条件。
- テストデータ要件
- 意味: テストに必要なデータについての条件。入力データだけでなく、システム内での必要なデータも含む。
- 例: ログインテストであれば、「正しいユーザー名とパスワード」「データベースにそのユーザー情報が存在していること」などが該当する。
- 期待結果（合格/不合格基準）
- 意味: テストの成否を判断する基準。テストが成功と見なされる条件が具体的に示される。
- 例: ログインに成功するテストでは、「ダッシュボードが表示されること」が合格基準になる。表示されない場合は不合格。
- 事後条件
- 意味: テスト実行後にシステムやデータに対して期待される状態や次の処理へのトリガーを定義する。
- 例: ユーザーの購入テストであれば、購入後に「在庫が減る」「確認メールが送られる」といった状態を事後条件として定める。
文書化する範囲に影響を及ぼす要因（シラバスより）
テスト条件およびテストケースの開発時には、一般的に、テスト作業成果物となるいくつかのドキュメントを作成する。実際には、テスト作業成果物を文書化する範囲は大幅に異なる。次の要因が文書化する範囲に影響を及ぼす。
- プロジェクトリスク（文書化する必要のあるもの、文書化してはいけないもの）
- ドキュメントがプロジェクトに提供する「付加価値」
- 準拠する必要のある標準および満たす必要のある規制
- SDLC または使用するアプローチ（例えば、アジャイルアプローチでは、「必要最小限」の文書化を目標にする）
- テストベースからテスト分析およびテスト設計を通してのトレーサビリティの要件
文書化する範囲に影響を及ぼす要因の解説
以下の要因により、プロジェクトでどのようなテストドキュメントが必要かが決まり、効率と品質の両面でバランスの取れたテスト計画を実現する。
- プロジェクトリスク
- 意味: プロジェクトにおけるリスクの程度や種類に応じて、どのテスト成果物を文書化するか、もしくはしないかを決めること。
- 例: 重要なデータを扱うシステムの場合、テストケースの詳細なドキュメントが必要だが、低リスクのプロジェクトでは簡易的な文書で済ませる場合もある。
- ドキュメントの「付加価値」
- 意味: 作成するドキュメントがプロジェクトにとってどの程度役立つかを見極めること。単に形としてのドキュメント作成ではなく、実際のテストに貢献するかを評価する。
- 例: 開発者や関係者がドキュメントを頻繁に参照する場合は付加価値が高いと見なされるが、そうでなければ不要な書類は省略する。
- 準拠すべき標準や規制
- 意味: 業界やプロジェクトで従うべきルールや法律、規制があり、それに応じたドキュメントを整備する必要がある。
- 例: 医療や金融などの業界では、厳格な文書管理が求められ、すべてのテスト成果物に関する詳細な記録が必要とされることがある。
- SDLC（システム開発ライフサイクル）やアプローチ
- 意味: 使用する開発アプローチ（ウォーターフォール、アジャイルなど）により、ドキュメントの範囲や詳細が異なる。特にアジャイルでは効率重視で最低限の文書化を目指すことが多い。
- 例: アジャイル開発では、顧客ニーズの変化に柔軟に対応するため、詳細な文書よりもコミュニケーションを優先する。
- トレーサビリティの要件
- 意味: テストケースと元の要件（テストベース）を関連付けて管理する必要がある場合、どこまでテストが進んだかを追跡できるドキュメントが求められる。
- 例: 各テストケースが特定の要件に対応していることを示すためのドキュメントを用意し、テスト結果から要件に対する充足度が確認できるようにする。
テスト実装
テスト実装（シラバスより）
- テスト手順、および、場合によっては自動テストスクリプトを作成する
- 特定のテストランにおいて実行されるテストスイートとして、テスト手順と（もし存在する場合）自動テストスクリプトを整理する
- 実行するテストケースとテストスイートの優先度付けについて、テストマネージャーに相談する
- テストケースの実行を開始するために必要なテスト実行スケジュール（リソース割り当てを含む）を作成する
- テストデータおよびテスト環境の準備を完了する
- テストベースと、テスト条件、テストケース、テスト手順、テストスクリプト、テストスイートなどのテストウェアとの間のトレーサビリティを更新する
さいごに
シラバスの一部切り抜きと解説メモでした。
