アジャイルテスト-テクニック

従来のテストのテスト手法は、アジャイルテストでも使用できます。これらに加えて、アジャイルプロジェクトではアジャイル固有のテスト手法と用語が使用されます。

テスト基準

アジャイルプロジェクトでは、製品バックログが要件仕様書に置き換わります。製品バックログの内容は通常、ユーザーストーリーです。非機能要件もユーザーストーリーで処理されます。したがって、アジャイルプロジェクトのテストの基礎はユーザーストーリーです。

品質テストを確実にするために、以下もテストの基礎として追加的に考慮することができます-

  • 同じプロジェクトまたは過去のプロジェクトの以前の反復からの経験。
  • システムの既存の機能、アーキテクチャ、設計、コード、および品質特性。
  • 現在および過去のプロジェクトからの欠陥データ。
  • お客様の声。
  • ユーザードキュメント。

完了の定義

完了の定義(DoD)は、スプリントバックログのアクティビティを確実に完了するためにアジャイルプロジェクトで使用される基準です。DoDはスクラムチームごとに異なる可能性がありますが、1つのチーム内で一貫している必要があります。

DoDは、ユーザーストーリーの一部である非機能要件とともに、ユーザーストーリーでの機能と機能の実装を保証するために必要なアクティビティのチェックリストです。DoDチェックリストのすべての項目が完了すると、ユーザーストーリーは完了段階に到達します。DoDはチーム間で共有されます。

ユーザーストーリーの一般的なDoDには、次のものを含めることができます。

  • 詳細なテスト可能な受け入れ基準
  • 反復内の他のユーザーストーリーとの一貫性を確保するための基準
  • 製品に関連する特定の基準
  • 機能的行動の側面
  • 非機能的特性
  • Interfaces
  • テストデータの要件
  • テストカバレッジ
  • Refactoring
  • レビューと承認の要件

ユーザーストーリーのDoDに加えて、DoDも必要です-

  • テストのすべてのレベルで
  • 機能ごとに
  • 反復ごとに
  • リリース用

テスト情報

テスターは、次のテスト情報を持っている必要があります-

  • テストが必要なユーザーストーリー
  • 関連する受け入れ基準
  • システムインターフェース
  • システムが機能することが期待される環境
  • ツールの可用性
  • テストカバレッジ
  • DoD

アジャイルプロジェクトでは、テストは順次アクティビティではなく、テスターは共同モードで作業することになっているため、テスターは次のことを行う責任があります。

  • 必要なテスト情報を継続的に入手します。
  • テストに影響を与える情報のギャップを特定します。
  • 他のチームメンバーと協力してギャップを解決します。
  • テストレベルにいつ到達するかを決定します。
  • 適切なテストが適切な時間に実行されるようにします。

機能的および非機能的テスト設計

アジャイルプロジェクトでは、従来のテスト手法を使用できますが、焦点は初期のテストにあります。実装を開始する前に、テストケースを用意する必要があります。

機能テスト設計の場合、テスターと開発者は、次のような従来のブラックボックステスト設計手法を使用できます。

  • 等価分割
  • 境界値分析
  • デシジョンテーブル
  • 状態遷移
  • クラスツリー

非機能テスト設計の場合、非機能要件も各ユーザーストーリーの一部であるため、ブラックボックステスト設計手法は、関連するテストケースの設計にのみ使用できます。

探索的テスト

アジャイルプロジェクトでは、多くの場合、時間はテスト分析とテスト設計の制限要因になります。このような場合、探索的テスト手法を従来のテスト手法と組み合わせることができます。

探索的テスト(ET)は、同時学習、テスト設計、およびテスト実行として定義されます。探索的テストでは、テスターはテストの実行時にテストの設計を積極的に制御し、テスト中に取得した情報を使用して、新しくより優れたテストを設計します。

探索的テストは、アジャイルプロジェクトの変更に対応するのに便利です。

リスクベーステスト

リスクベーステストは、失敗のリスクに基づいたテストであり、テスト設計手法を使用してリスクを軽減します。

製品品質リスクは、製品品質に関する潜在的な問題として定義できます。製品の品質リスクには以下が含まれます-

  • 機能的リスク
  • 機能しないパフォーマンスリスク
  • 機能しないユーザビリティリスク

リスク分析は、各リスクの確率(可能性)と影響を評価するために行われます。次に、リスクが優先されます-

  • 高リスクには広範なテストが必要
  • 低リスクは大まかなテストのみを必要とします

テストは、各リスクのリスクレベルとリスク特性に基づいた適切なテスト手法を使用して設計されています。次に、リスクを軽減するためにテストが実行されます。

フィットテスト

適合テストは自動化された受け入れテストです。Tools FitおよびFitNesseは、受け入れテストの自動化に使用できます。

FITはJUnitを使用しますが、テスト機能を拡張します。HTMLテーブルは、テストケースを表示するために使用されます。フィクスチャは、HTMLテーブルの背後にあるJavaクラスです。フィクスチャはHTMLテーブルの内容を取得し、テスト対象のプロジェクトでテストケースを実行します。