アジャイルテスト-概要
Agileは反復型開発手法であり、開発アクティビティとテストアクティビティの両方が同時に実行されます。テストは別のフェーズではありません。コーディングとテストはインタラクティブかつ段階的に行われるため、顧客の要件を満たす高品質の最終製品が得られます。さらに、継続的インテグレーションにより、欠陥を早期に除去できるため、時間、労力、コストを節約できます。
アジャイルマニフェスト
アジャイルマニフェストは2001年にソフトウェア開発者のチームによって発行され、開発チームの重要性を強調し、変化する要件と顧客の関与に対応しています。
The Agile Manifesto is −
私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることによって、ソフトウェアを開発するより良い方法を発見しています。この仕事を通して、私たちは価値に到達しました-
- プロセスとツールを介した個人と相互作用。
- 包括的なドキュメント上で動作するソフトウェア。
- 契約交渉をめぐる顧客のコラボレーション。
- 計画に従った切り替えへの対応。
つまり、右側のアイテムには価値がありますが、左側のアイテムには価値があります。
アジャイルテストとは何ですか?
アジャイルテストは、アジャイルソフトウェア開発の原則に従うソフトウェアテストの実践です。
アジャイルテストには、プロジェクトチームのすべてのメンバーが参加し、テスターから特別な専門知識が提供されます。テストは個別のフェーズではなく、要件、設計とコーディング、テストケースの生成などのすべての開発フェーズと織り交ぜられています。テストは、開発ライフサイクルを通じて同時に行われます。
さらに、テスターがクロスファンクショナルチームメンバーと協力して開発ライフサイクル全体に参加することで、顧客の要件に従って、より優れた設計とコードでソフトウェアを構築するためのテスターの貢献が可能になります。
アジャイルテストは、すべてのレベルのテストとすべてのタイプのテストを対象としています。
アジャイルテストと ウォーターフォールテスト
ウォーターフォール開発の方法論では、開発ライフサイクルのアクティビティは連続したフェーズで発生します。したがって、テストは別のフェーズであり、開発フェーズの完了後にのみ開始されます。
以下は、アジャイルテストとウォーターフォールテストの違いのハイライトです-
アジャイルテスト | ウォーターフォールテスト |
---|---|
テストは別のフェーズではなく、開発と同時に行われます。 | テストは別のフェーズです。すべてのレベルとタイプのテストは、開発の完了後にのみ開始できます。 |
テスターと開発者は協力します。 | テスターは開発者とは別に作業します。 |
テスターは、要件の作成に関与しています。これは、要件を実際のシナリオの動作にマッピングし、受け入れ基準を組み立てるのに役立ちます。また、論理的な受け入れテストケースは、要件とともに準備ができています。 | テスターは、要件フェーズに関与していない可能性があります。 |
受け入れテストはすべての反復の後に行われ、顧客からのフィードバックが求められます。 | 受け入れテストは、プロジェクトの最後にのみ実行されます。 |
すべての反復は独自のテストを完了するため、新しい関数またはロジックがリリースされるたびに回帰テストを実装できます。 | リグレッションテストは、開発の完了後にのみ実装できます。 |
コーディングとテストの間に時間遅延はありません。 | コーディングとテストの間の通常の時間遅延。 |
テストレベルが重複する継続的テスト。 | テストは時間制限のあるアクティビティであり、テストレベルを重複させることはできません。 |
テストはベストプラクティスです。 | テストは見過ごされがちです。 |
アジャイルテストの原則
アジャイルテストの原則は次のとおりです。
Testing moves the project forward−継続的テストは、継続的な進歩を保証する唯一の方法です。アジャイルテストは継続的にフィードバックを提供し、最終製品はビジネスの需要を満たします。
Testing is not a phase−アジャイルチームは、開発チームと一緒にテストを行い、特定の反復中に実装された機能が実際に実行されていることを確認します。テストは後のフェーズのために保持されません。
Everyone tests−アジャイルテストでは、アナリスト、開発者、テスターを含むチーム全体がアプリケーションをテストします。すべての反復の後、顧客でさえユーザー受け入れテストを実行します。
Shortening Feedback Loops−アジャイルテストでは、ビジネスチームはすべての反復の製品開発について知ることができます。彼らはすべての反復に関与しています。継続的なフィードバックにより、フィードバックの応答時間が短縮されるため、修正にかかるコストが削減されます。
Keep the Code Clean−欠陥は、同じ反復内で発生するため修正されます。これにより、開発のどのマイルストーンでもクリーンなコードが保証されます。
Lightweight Documentation −包括的なテストドキュメントの代わりに、アジャイルテスター−
再利用可能なチェックリストを使用して、テストを提案します。
偶発的な詳細ではなく、テストの本質に焦点を合わせます。
軽量のドキュメントスタイル/ツールを使用します。
探索的テストのためにチャーターにテストのアイデアをキャプチャします。
ドキュメントを複数の目的に活用します。
Leveraging one test artifact for manual and automated tests−同じテストスクリプトアーティファクトを手動テストおよび自動テストの入力として利用できます。これにより、手動テストドキュメントと、同等の自動化テストスクリプトが不要になります。
“Done Done,” not just done −アジャイルでは、機能は開発後ではなく、開発とテストの後に行われると言われています。
Test-Last vs. Test Driven−テストケースは要件とともに作成されます。したがって、開発はテストによって推進できます。このアプローチは、テスト駆動開発(TDD)および受け入れテスト駆動開発(ATDD)と呼ばれます。これは、ウォーターフォールテストの最後のフェーズとしてのテストとは対照的です。
アジャイルテスト活動
プロジェクトレベルでのアジャイルテスト活動は次のとおりです。
リリース計画(テスト計画)
すべての反復について、
反復中のアジャイルテストアクティビティ
回帰試験
リリースアクティビティ(テスト関連)
反復中のアジャイルテストアクティビティには、次のものが含まれます。
- 反復計画への参加
- テストの観点からのタスクの見積もり
- 機能の説明を使用してテストケースを作成する
- ユニットテスト
- 統合テスト
- 機能テスト
- 欠陥の修正
- 統合テスト
- 受け入れ試験
- テストの進捗状況に関するステータスレポート
- 欠陥追跡