（学習ノート）JSTQB アジャイルソフトウェア担当者 3.3 アジャイルプロジェクトの技法
はじめに
アジャイルテスト担当者のシラバスを読んで、重要なところを引用し、感想をつけた学習ノートをまとめました。この記事は「3.3 アジャイルプロジェクトの技法」が対象です。
アジャイルプロジェクトで特におさえておきたいポイント技法や用語について解説しています。
テストベース
テストベースとなるものは以下の通りである。
以前のプロジェクトでの経験
システムの既存の機能
フィーチャおよび品質特性
コード、アーキテクチャおよび設計
ユーザプロファイル
既存および以前のプロジェクトの欠陥に関する情報
欠陥分類法での欠陥の分類
適用可能な標準
品質リスク
ユーザーストーリー
受け入れ基準
システムの動作仕様
システムの使われ方
システムをテストするために使用するシステムインターフェース
必要なテストを実行するための十分な知識とスキル
テストを補助するツールの有無
完了（Done）の定義
ユーザーストーリーに対する受入基準
テスト可能にす るために、ユーザーストーリーに受け入れ基準を記載する。
受け入れ基準を記述する際には、下表の内容を考慮する必要がある。
完了（Done）の定義
完了（done）の定義は、ア ジャイルプロジェクトで極めて重要である。
様々な観点で、『完了（done）の定義』を設定することが可能である。
テストレベルに対して、『完了（Done）の定義』を設定する場合
開発対象に対して、『完了（Done）の定義』を設定する場合
イテレーションに対して、『完了（Done）の定義』を設定する場合
イテレーションが正常に完了したこの時点で、ソフトウェアは潜在的にリリース可能である。ただし、すべてのイテ レーションでリリースが行われるということではない。
リリースに対して、『完了（Done）の定義』を設定する場合
リリースの『完了（Done）の定義』は、4つの観点で定義可能である。また、これらは、フィーチャーのリリース条件としても使用できる。
ブラックボックステスト
テスト分析～テスト設計プロセス
開発者のプログラミング活動と並行して、行われる。
テストベース
ユーザストーリーと受け入れ基準（上記テストベース参照）
適用可能なテスト技法
同値分割法
境界値分析
デシジョンテーブル
状態遷移テスト
非機能要件に対するテスト
ブラックボックステスト技法を使用し、テストを作成することが可能。
探索的テスト
アジャイルプロジェクトでの有用性
理由
テスト分析、テスト設計の時間が制限されている
ユーザストーリーの詳細度が制限されている
他のテスト戦略との組み合わせ
リスクベースドテスト、要件ベースドテ スト、モデルベースドテスト、回帰テストなどのテスト戦略と融合させて使用する
探索的テストプロセス
テストチャーターを準備する
テストチャーターに従い、テスト設計とテスト実行を同時に行う。
直近のテストの結果が、次のテストの指針となる。
適用可能なテスト技法
同値分割技法
境界値分析
デシジョンテーブル
状態遷移テストなど
セッションを使って、テスト時間をマネジメントすることが可能
テストチャーターとは
概要
・カバーすべきテスト条件
・以下の情報をテストチャーターとして提供
テストセッションとは
概要
・中断されることのない探索的テストのための時間
・60分～120分／1セッション
・1つのセッションで、以下のいづれかの活動を行う
・調査セッション：動作の仕組みを学習する
・分析セッション：機能や非機能特性を評価（テスト）する
・深さをカバー ：ユースケース、シナリオを評価（テスト）する
テストの記録
・テストを記録することのメリット
▶システムでどのように問題が発見されたかを遡って確認できる。
・文書化すべき内容
▶下表のような記録項目を何らかのマネジメントツールに記録する。
探索的テストの品質
探索的テストの品質はテスト担当者のスキル（下記参照）に依存する。
システムについて把握しておく必要のある最も重要なことは何か?
どのような場合にシステムは機能しなくなるのか?
～の場合は何が起きるか?
～のときには何が起きるべきか?
顧客のニーズ、要件および期待は満たされているか?
サポートされるすべての方法でインストール、削除できるか？
探索的テストの品質を上げるためにできること
下記に対して、理解し、知識として持っていること
テスト対象のソフトウェア
テスト対象のビジネスドメイン
ソフトウェアの使用方法
システムが失敗したかどうか見極める判断基準
この記事が気に入ったらサポートをしてみませんか？