アジャイルテスト-クイックガイド
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)と呼ばれます。これは、ウォーターフォールテストの最後のフェーズとしてのテストとは対照的です。
アジャイルテスト活動
プロジェクトレベルでのアジャイルテスト活動は次のとおりです。
リリース計画(テスト計画)
すべての反復について、
反復中のアジャイルテストアクティビティ
回帰試験
リリースアクティビティ(テスト関連)
反復中のアジャイルテストアクティビティには、次のものが含まれます。
- 反復計画への参加
- テストの観点からのタスクの見積もり
- 機能の説明を使用してテストケースを作成する
- ユニットテスト
- 統合テスト
- 機能テスト
- 欠陥の修正
- 統合テスト
- 受け入れ試験
- テストの進捗状況に関するステータスレポート
- 欠陥追跡
アジャイルは反復型開発方法論であり、プロジェクトチーム全体がすべての活動に参加します。要件は、顧客と自己組織化チーム間のコラボレーションを通じて、反復が進むにつれて進化します。コーディングとテストはインタラクティブかつ段階的に行われるため、開発の過程で、最終製品は高品質になり、顧客の要件が保証されます。
すべての反復により、統合された作業成果物が増加し、ユーザー受け入れテストに提供されます。このようにして得られた顧客のフィードバックは、次の/後続の反復への入力になります。
継続的インテグレーション、継続的品質
継続的インテグレーションは、アジャイル開発を成功させるための鍵です。必要に応じてリリースの準備ができるように、少なくとも毎日、頻繁に統合します。アジャイルでのテストは、開発のすべてのフェーズの不可欠なコンポーネントになり、製品の継続的な品質を保証します。プロジェクトに関係するすべての人からの絶え間ないフィードバックは、製品の品質を向上させます。
アジャイルでは、コミュニケーションが最重要事項であり、必要に応じて顧客の要求を受け取ります。これにより、すべての入力が考慮され、開発全体で高品質の製品が利用可能であるという顧客の満足度が得られます。
アジャイル手法
アジャイル開発をサポートするいくつかのアジャイル手法があります。アジャイル手法には以下が含まれます-
スクラム
スクラムは、チーム中心のアプローチに重点を置いたアジャイル開発手法です。これは、すべてのプロジェクト開発活動へのチーム全体の参加を提唱しています。
XP
エクストリームプログラミングは顧客中心であり、絶えず変化する要件に焦点を当てています。頻繁なリリースと顧客からのフィードバックにより、最終製品は、プロセス中に明確になる顧客の要件を満たす品質になります。
結晶
Crystalは、用船、定期配送、およびまとめに基づいています。
傭船には、開発チームの編成、予備的な実現可能性分析の実行、初期計画の達成、および開発方法論が含まれます。
2つ以上の配信サイクルを伴う循環配信は、開発フェーズと最終的な統合製品配信に重点を置いています。
まとめ、ユーザー環境への展開、展開後のレビュー、および反映が実行されます。
FDD
機能駆動開発(FDD)には、機能の設計と構築が含まれます。FDDと他のアジャイル開発手法の違いは、機能が特定のフェーズと短いフェーズで別々に開発されることです。
DSDM
Dynamic Software Development Method(DSDM)は、Rapid Application Development(RAD)に基づいており、アジャイルフレームワークに対応しています。DSDMは、製品の頻繁な配信に重点を置いており、ユーザーを積極的に関与させ、チームが迅速な意思決定を行えるようにします。
リーンソフトウェア開発
リーンソフトウェア開発では、無駄を排除し、顧客に価値を提供することに重点を置いています。これにより、迅速な開発と価値のある製品が実現します。
廃棄物には、部分的に行われた作業、無関係な作業、顧客が使用していない機能、納期の遅れを助長する欠陥などが含まれます。
ザ・ Lean Principles は−
- 無駄をなくす
- 学習を増幅する
- コミットメントの遅延
- チームに力を与える
- 高速配信
- で整合性を構築する
- 全体を見る
かんばん
かんばんは、チームメンバーに過負荷をかけずに、ジャストインタイム(JIT)配信に重点を置いた作業管理に重点を置いています。タスクは、すべての参加者が表示できるように、またチームメンバーがキューから作業をプルできるように表示されます。
かんばんはに基づいています-
- かんばんボード(開発全体で視覚的かつ永続的)
- 仕掛品(WIP)の制限
- リードタイム
アジャイルテストの方法論
テストの実践は、アジャイルであるかどうかにかかわらず、すべてのプロジェクトで明確に定義されており、高品質の製品を提供します。従来のテストの原則は、アジャイルテストでよく使用されます。それらの1つは、-に焦点を当てた早期テストです。
システムの動作を表現するためのテストケースの作成。
早期の欠陥防止、検出および除去。
適切なテストタイプが適切なタイミングで適切なテストレベルの一部として実行されるようにします。
私たちが議論したすべてのアジャイル方法論において、アジャイルテスト自体が方法論です。すべてのアプローチで、テストケースはコーディングの前に作成されます。
このチュートリアルでは、アジャイルテストの方法論としてスクラムに焦点を当てます。
他の一般的に使用されるアジャイルテスト方法論は次のとおりです。
Test-Driven Development (TDD) −テスト駆動開発(TDD)は、テストによって導かれるコーディングに基づいています。
Acceptance Test-Driven Development (ATDD) −受け入れテスト駆動開発(ATDD)は、顧客、開発者、テスター間のコミュニケーションに基づいており、事前定義された受け入れ基準と受け入れテストケースによって推進されます。
Behavior-Driven Development (BDD) −ビヘイビア駆動開発(BDD)テストは、開発中のソフトウェアの予想される動作に基づいています。
アジャイルテストのライフサイクル
スクラムでは、テスト活動には次のものが含まれます。
テストケースとして描かれているシステムの予想される動作に基づいてユーザーストーリーに貢献する
テストの労力と欠陥に基づくリリース計画
ユーザーストーリーと欠陥に基づくスプリント計画
継続的テストによるスプリントの実行
スプリント完了後の回帰テスト
テスト結果の報告
自動化テスト
以下の図に示すように、テストは反復的でスプリントベースです。
アジャイル開発はチーム中心であり、開発者とテスターはすべてのプロジェクトと開発活動に参加します。チームワークは、アジャイルプロジェクトでのテストの成功を最大化します。
アジャイルチームのテスターは、すべてのプロジェクトアクティビティに参加して貢献する必要があり、同時にテストの専門知識を活用する必要があります。
アジャイルテスターは、従来のテストスキルを持っている必要があります。さらに、アジャイルテスターには次のものが必要です。
優れた対人スキル。
チームメンバーや利害関係者と積極的かつソリューション指向で行動する能力。
製品について批判的で品質志向の懐疑的な考えを示す能力。
利害関係者から積極的に情報を取得するために積極的に行動する能力。
テスト可能なユーザーストーリー、受け入れ基準を定義する際に、顧客や利害関係者と効果的に連携するスキル。
開発者と協力して高品質のコードを作成する優れたチームメンバーになる才能。
適切なテストケースを適切なタイミングで適切なレベルで実行し、スプリントの期間内に適切に実行するためのテストスキルのユーザビリティ。
テスト結果、テストの進捗状況、および製品の品質を評価および報告する機能。
テストケースの変更、追加、改善など、変更に迅速に対応するためのオープン性。
仕事を自己組織化する可能性。
継続的なスキルの成長への熱意。
テスト自動化、テスト駆動開発(TDD)、受け入れテスト駆動開発(ATDD)、ビヘイビア駆動開発(BDD)、および経験ベースのテストにおける能力。
アジャイルチームにおけるテスターの役割
アジャイルチームのテスターは、すべてのプロジェクトおよび開発活動に参加して、最高のテスト専門知識を提供します。
アジャイルテスターの活動には以下が含まれます-
テストツールの適切な使用を保証します。
テスト環境とテストデータの構成、使用、および管理。
テストの関連する側面で他のチームメンバーを指導する。
リリースおよびスプリントの計画中に適切なテストタスクがスケジュールされていることを確認します。
テスト戦略の理解、実装、更新。
開発者、顧客、および利害関係者と協力して、テスト容易性、一貫性、および完全性の観点から要件を明確にします。
適切なテストを適切なタイミングで適切なテストレベルで実行します。
欠陥を報告し、チームと協力して問題を解決します。
該当するすべてのカバレッジディメンションにわたるテストカバレッジの測定とレポート。
スプリントの回顧展に参加し、改善を積極的に提案して実施します。
アジャイルライフサイクルでは、テスターは次の点で重要な役割を果たします。
- Teamwork
- テスト計画
- スプリントゼロ
- Integration
- アジャイルテストの実践
チームワーク
アジャイル開発では、チームワークが基本であるため、次のことが必要です。
Collaborative Approach−テスト戦略、テスト計画、テスト仕様、テスト実行、テスト評価、およびテスト結果レポートについて、部門の枠を超えたチームメンバーと協力します。他のチーム活動と組み合わせてテストの専門知識を提供します。
Self-organizing −他のチームメンバーからの専門知識を統合することにより、テストの目標を達成するために、スプリント内で十分に計画および編成します。
Empowerment −チームの目標を達成するために適切な技術的決定を行う。
Commitment −顧客や利害関係者の要求に応じて、製品の動作と特性を理解し、評価することを約束します。
Transparent −オープンで、コミュニケーションを取り、説明責任を果たします。
Credibility−テスト戦略、その実装、および実行の信頼性を確保します。顧客と利害関係者にテスト戦略に関する情報を提供し続ける。
Open to Feedback−成功と失敗の両方から学ぶためにスプリント回顧展に参加する。顧客からのフィードバックを求め、迅速かつ適切に行動して、高品質の成果物を確保します。
Resilient −変更への対応。
テスト計画
テスト計画はリリース計画中に開始し、各スプリント中に更新する必要があります。テスト計画は、次のタスクをカバーする必要があります-
テストの範囲、テストの範囲、テストおよびスプリントの目標を定義します。
テスト環境、テストツール、テストデータ、および構成を決定します。
機能と特性のテストを割り当てます。
テストタスクのスケジュールとテストの頻度の定義。
テスト方法、手法、ツール、およびテストデータを特定する。
先行タスク、専門知識、トレーニングなどの前提条件を確認します。
機能、コード、システムコンポーネント、ベンダー、テクノロジー、ツール、アクティビティ、タスク、チーム、テストタイプ、テストレベル、制約などの依存関係を特定します。
顧客/ユーザーの重要性と依存関係を考慮した優先順位の設定。
テストに必要な期間と労力で到着します。
各スプリント計画でのタスクの特定。
スプリントゼロ
スプリントゼロには、最初のスプリントの前の準備活動が含まれます。テスターは、次のアクティビティでチームと協力する必要があります-
- スコープの特定
- ユーザーストーリーをスプリントに分割する
- システムアーキテクチャの作成
- ツール(テストツールを含む)の計画、取得、およびインストール
- すべてのテストレベルの初期テスト戦略を作成する
- テストメトリクスの定義
- 「完了」の定義とも呼ばれる受け入れ基準の指定
- 終了基準の定義
- スクラムボードの作成
- スプリント全体のテストの方向性を設定する
統合
アジャイルでは、高品質の実用的な製品は、開発ライフサイクルのどの時点でもリリースできる状態になっている必要があります。これは、開発の一部としての継続的インテグレーションを意味します。アジャイルテスターは、継続的テストとの継続的インテグレーションをサポートする必要があります。
これを達成するために、テスターは次のことを行う必要があります-
- 統合戦略を理解します。
- 機能と機能の間のすべての依存関係を特定します。
アジャイルテストの実践
アジャイルテスターは、アジャイルプロジェクトでのテストにアジャイルプラクティスを適応させる必要があります。
Pairing−2人のチームメンバーが同じキーボードで一緒に作業します。それらの1つがテストとして、他はテストをレビュー/分析します。2人のチームメンバーは
1人のテスターと1人の開発者
1人のテスターと1人のビジネスアナリスト
2人のテスター
Incremental Test Design −テストケースは、ユーザーストーリーから構築され、単純なテストから始まり、より複雑なテストに移行します。
Mind Mapping−マインドマップは、情報を視覚的に整理するための図です。マインドマッピングは、アジャイルテストの効果的なツールとして使用できます。これを使用して、必要なテストセッション、テスト戦略、およびテストデータに関する情報を整理できます。
テストステータスを伝達できます-
- 毎日のスタンドアップミーティング中
- 標準のテスト管理ツールの使用
- メッセンジャー経由
タスクが「完了」であるかどうかを判断するには、テスト合格ステータスによって決定されるテストステータスが重要です。完了とは、タスクパスのすべてのテストを意味します。
テストの進捗状況
テストの進行状況は、-を使用して追跡できます。
- スクラムボード(アジャイルタスクボード)
- バーンダウンチャート
- 自動テスト結果
テストの進捗状況は、開発の進捗状況にも直接影響します。これは、ユーザーストーリーをに移動できるためですDone受け入れ基準に達した後にのみステータス。これは、受け入れ基準がテストステータスによって判断されるため、テストステータスによって決定されます。
テストの進行に遅延や障害がある場合は、チーム全体が話し合い、協力して同じ問題を解決します。
アジャイルプロジェクトでは、変更が頻繁に行われます。多くの変更が行われると、テストステータス、テストの進行状況、および製品の品質が絶えず進化することが期待できます。アジャイルテスターはその情報をチームに提供する必要があります。これにより、適切な決定を適切なタイミングで行い、各反復を正常に完了するための軌道に乗ることができます。
変更が発生すると、以前のイテレーションの既存の機能に影響を与える可能性があります。このような場合、回帰リスクに効果的に対処するには、手動テストと自動テストを更新する必要があります。回帰テストも必要です。
製品の品質
製品品質メトリクスには以下が含まれます-
- テストの合格/不合格
- 欠陥が見つかりました/修正されました
- テストカバレッジ
- テストの合格/不合格率
- 欠陥発見率
- 欠陥密度
製品品質メトリクスの収集とレポートを自動化することは、次のことに役立ちます。
- 透明性の維持。
- 関連する必要なすべての指標を適切なタイミングで収集します。
- 通信遅延のない即時レポート。
- テスターがテストに集中できるようにします。
- メトリックの誤用のフィルタリング。
製品全体の品質を確保するために、アジャイルチームは、製品が顧客の期待を満たしているかどうかについて顧客からのフィードバックを得る必要があります。これは各反復の最後に実行する必要があり、フィードバックは後続の反復の入力になります。
主な成功要因
アジャイルプロジェクトでは、アジャイルテストが成功すれば、高品質の製品を提供できます。
アジャイルテストを成功させるには、次の点を考慮する必要があります。
アジャイルテストは、テストファーストおよび継続的テストアプローチに基づいています。したがって、テストラストアプローチに基づいて構築された従来のテストツールは適切でない場合があります。したがって、アジャイルプロジェクトでテストツールを選択する際には、アジャイルテストとの整合性を検証する必要があります。
開発ライフサイクルの早い段階でテストを自動化することにより、合計テスト時間を短縮します。
アジャイルテスターは、開発リリーススケジュールに合わせてペースを維持する必要があります。したがって、テストアクティビティの適切な計画、追跡、および再計画は、製品の品質を目標としてその場で実行する必要があります。
手動テストは、プロジェクトのテストの80%を占めています。したがって、専門知識を持つテスターはアジャイルチームの一員である必要があります。
開発ライフサイクル全体を通じて専門知識を持つこれらのテスターが参加することで、チーム全体が顧客の期待に応える高品質の製品に集中できるようになります。
エンドユーザーが期待する製品の動作を強調するユーザーストーリーを定義します。
顧客の期待に応じて、ユーザーストーリーレベル/タスクレベルで受け入れ基準を特定します。
テスト活動の労力と期間の見積もり。
テスト活動の計画。
開発チームと連携して、事前のテスト設計で要件を満たすコードを確実に作成します。
最初のテストと継続的なテストを行って、完了ステータスが予想される時間に受け入れ基準を満たしていることを確認します。
スプリント内のすべてのレベルでのテストを保証します。
各スプリントの最後の回帰テスト。
プロジェクトの成功に役立つ製品メトリックを収集して分析します。
欠陥を分析して、現在のスプリントで修正する必要があるものと、後続のスプリントに遅らせることができるものを特定します。
お客様の視点から重要なことに焦点を当てます。
リサクリスピンは、アジャイルテストの成功のための7つの重要な要素を定義しました-
Whole Team approach−この種のアプローチでは、開発者がテスターをトレーニングし、テスターが他のチームメンバーをトレーニングします。これにより、誰もがプロジェクトのすべてのタスクを理解できるようになり、コラボレーションと貢献が最大のメリットをもたらします。テスターと顧客のコラボレーションも、最初から期待を設定し、受け入れ基準をテストに合格するために必要なものに変換するための重要な要素です。
Agile Testing Mindset −テスターは、品質を継続的に改善し、チームの他のメンバーと常に協力することに積極的に取り組んでいます。
Automate Regression Testing−テスト容易性を設計し、テストを使用して開発を推進します。簡単に始めて、チームがツールを選択できるようにします。アドバイスを提供する準備をしてください。
Provide and Obtain Feedback−これはアジャイルのコアバリューであるため、チーム全体がフィードバックを受け入れる必要があります。テスターは専門家のフィードバックプロバイダーであるため、関連する必要な情報に焦点を当てる必要があります。その見返りとして、フィードバックを取得する際には、テストケースの変更とテストに対応する必要があります。
Build a Foundation of Core Agile Practices −コーディング、継続的インテグレーション、共同テスト環境、段階的な作業、変更の受け入れ、相乗効果の維持とともにテストに焦点を当てます。
Collaborate with Customers −例を引き出し、製品の動作にマッピングする要件を理解して確認し、受け入れ基準を設定し、フィードバックを取得します。
Look at the Big Picture −実世界のテストデータを使用し、他の領域への影響を考慮して、ビジネス向けのテストと例を使用して開発を推進します。
この章では、アジャイルテストのいくつかの重要な属性について説明します。
アジャイルテストの利点
アジャイルテストの利点は次のとおりです。
迅速で継続的な完全にテストされた製品と顧客フィードバックの追求による顧客満足。
顧客、開発者、およびテスターは継続的に相互作用するため、サイクルタイムが短縮されます。
アジャイルテスターは、実行可能なものに焦点を当てるためにテストの専門知識を提供する要件の定義に参加します。
アジャイルテスターは、テストの労力と時間を評価する見積もりに参加します。
受け入れ基準を反映した初期のテスト設計。
チーム全体で統合されたテスト要件。欠点を回避します。
チーム全体が製品の品質に常に焦点を合わせています。
の定義 Done テストに合格したステータスを反映することで、要件が満たされていることを確認します。
チーム全体の努力ですぐに解決できるように、遅延または閉塞に関する継続的なフィードバック。
要件の変化に迅速に対応し、すぐに対応します。
継続的インテグレーション主導の回帰テスト。
開発とテストの間に時間の遅れはありません。最初にテストし、継続的なテストアプローチに従います。
自動化テストは開発ライフサイクルの早い段階で実装されるため、テストの時間と労力が削減されます。
アジャイルテストのベストプラクティス
以下に示すベストプラクティスに従ってください-
すべてのレベルのすべてのタイプのテストの専門知識を持つテスターの包含。
要件の定義に参加し、製品の予想される動作について顧客と協力するテスター。
テスターは、開発者や顧客と継続的にフィードバックを共有しています。
開発作業に合わせて、最初の継続的テストアプローチをテストします。
高品質の製品の提供に重点を置いて、テストのステータスと進行状況を迅速かつ継続的に追跡します。
サイクルタイムを短縮するための開発ライフサイクルの早い段階での自動化テスト。
回帰テストを実行するには、効果的な方法として自動化テストを活用します。
アジャイルテストの課題
アジャイルテストには次の課題があります-
アジャイルアプローチとそのビジネスおよび管理による制限を理解していないと、達成できない期待につながる可能性があります。
アジャイルはチーム全体のアプローチに従いますが、誰もがテストプラクティスの本質を知っているわけではありません。テスターは他の人を指導することをお勧めしますが、実際のシナリオでは、タイムボックス化されたスプリント(反復)では実行不可能な場合があります。
テストファーストアプローチでは、開発者はテスターフィードバックに基づいてコーディングを行う必要がありますが、実際のシナリオでは、開発者は顧客またはビジネスからの要件に基づいてコーディングを行うことに慣れています。
高品質製品の説明責任はアジャイルチーム全体にありますが、初期段階では、開発者は実装モードに移行しているため、品質に焦点を当てていない可能性があります。
継続的インテグレーションでは、自動化する必要がある場合でも、かなりの労力を必要とする回帰テストが必要です。
テスターはアジャイルの考え方で変更に適応できますが、結果として生じるテストの変更とテストに対応することは、スプリント中に終了することを目標にするのは現実的でない可能性があります。
手動テストの労力と時間を削減できるように、早期自動化をお勧めします。しかし、実際のシナリオでは、自動化できるテストに到達し、それらを自動化するには、時間と労力が必要です。
アジャイルテストガイドライン
アジャイルテストを実行するときは、次のガイドラインを使用してください。
リリース計画に参加して、必要なテストアクティビティを特定し、テスト計画の初期バージョンを作成します。
見積もりセッションに参加して、テスト作業と期間に到達し、テストアクティビティが反復に対応できるようにします。
ユーザーストーリー定義に参加して、受け入れテストケースに到達します。
すべてのスプリント計画会議に参加して、範囲を理解し、テスト計画を更新します。
スプリント中に開発チームと継続的に協力して、スプリント内でテストとコーディングを成功させます。
毎日のスタンドアップミーティングに参加し、テストの遅延や障害がある場合はそれを伝えて、すぐに解決します。
テストステータス、テストの進捗状況、製品の品質を定期的に追跡および報告します。
テストケース、テストデータの変更に対応して、変更に対応する準備をします。
スプリントレトロスペクティブに参加して、ベストプラクティスと学んだ教訓を理解し、貢献してください。
各スプリントで顧客フィードバックを取得するために協力します。
従来のテストの場合と同様に、アジャイルテストもすべてのテストレベルをカバーする必要があります。
- ユニットテスト
- 統合テスト
- システムテスト
- ユーザー受け入れテスト
ユニットテスト
- 開発者によるコーディングと一緒に行われます
- 100%の設計カバレッジを保証するテストケースを作成するテスターによってサポートされています
- ユニットテストケースとユニットテストの結果を確認する必要があります
- 未解決の主要な欠陥(優先度と重大度による)は残されていません
- すべてのユニットテストは自動化されています
統合テスト
- スプリントが進むにつれて継続的インテグレーションとともに行われます
- すべてのスプリントが完了した後、最後に完了
- すべての機能要件がテストされます
- ユニット間のすべてのインターフェースがテストされます
- すべての欠陥が報告されます
- テストは可能な限り自動化されます
システムテスト
- 開発が進むにつれて行われます
- ユーザーストーリー、特徴、機能がテストされます
- 実稼働環境で行われるテスト
- 品質テストが実行されます(パフォーマンス、信頼性など)
- 欠陥が報告されます
- テストは可能な限り自動化されます
ユーザー受け入れテスト
各スプリントの終了時とプロジェクトの終了時に完了
お客様が行います。フィードバックはチームによって行われます
フィードバックは後続のスプリントへの入力になります
スプリントのユーザーストーリーは、テスト可能であることが事前に検証されており、定義された受け入れ基準があります
テストタイプ
- コンポーネントテスト(ユニットテスト)
- 機能テスト(ユーザーストーリーテスト)
- 非機能テスト(パフォーマンス、負荷、ストレスなど)
- 受け入れテスト
テストは、完全に手動、完全に自動、手動と自動の組み合わせ、またはツールでサポートされる手動にすることができます。
プログラミングと批評製品のテストをサポートする
テストは-のためにすることができます
Supporting Development (Support Programming) −サポートプログラミングテストはプログラマーによって使用されます。
システムの特定の動作を実現するために作成する必要のあるコードを決定する
新しいコードがシステムの残りの動作を妨げないことを確認するために、コーディング後に実行する必要のあるテスト
Verification only (Critique Product) −批評製品テストは、完成品の不備を発見するために使用されます
ビジネス向けおよびテクノロジー向けテスト
どのテストをいつ実行するかを決定するには、テストが-であるかどうかを判断する必要があります。
- ビジネスに直面している、または
- テクノロジーに直面している
ビジネスに直面するテスト
テストは、ビジネスドメインからの単語で囲まれた質問に答える場合、ビジネス向けのテストです。これらはビジネスの専門家に理解されており、システムの動作をリアルタイムのシナリオで説明できるように関心を持っています。
テクノロジーに直面するテスト
テストは、テクノロジードメインからの単語で囲まれた質問に答える場合、テクノロジーに直面するテストです。プログラマーは、テクノロジーに関する説明に基づいて、何を実装する必要があるかを理解しています。
テストタイプのこれら2つの側面は、BrianMarickによって定義されたアジャイルテスト象限を使用して表示できます。
アジャイルテスト象限
テストタイプの2つの側面を組み合わせて、次のアジャイルテスト象限はBrianMarickによって導出されます-
アジャイルテスト象限は、チームが必要なテストを特定、計画、および実行するのに役立つ分類法を提供します。
Quadrant Q1−ユニットレベル、テクノロジーに直面し、開発者をサポートします。ユニットテストはこの象限に属します。これらのテストは自動テストにすることができます。
Quadrant Q2−システムレベル、ビジネス向け、および製品の動作への適合。機能テストはこの象限に属します。これらのテストは手動または自動のいずれかです。
Quadrant Q3−システムまたはユーザーの受け入れレベル、ビジネスに直面し、リアルタイムのシナリオに焦点を合わせます。ユーザー受け入れテストはこの象限に属します。これらのテストは手動です。
Quadrant Q4−システムまたは運用上の許容レベル、テクノロジーに直面し、パフォーマンス、負荷、ストレス、保守性、スケーラビリティテストに重点を置いています。これらのテストには、自動化テストとともに特別なツールを使用できます。
これらを組み合わせて、反映するアジャイルテスト象限 What-Testing-When 次のように視覚化できます-
スクラム支持者 Whole Team Approach、すべてのチームメンバーがすべてのプロジェクト活動に参加する必要があるという意味で。スクラムチームは、プロジェクトの成果物に対する説明責任を持って自己組織化しています。意思決定はチームに任されており、時間の遅れなしに適切なタイミングで適切なアクションが実行されます。このアプローチは、1つのアクティビティに制限するのではなく、チームの才能を適切に使用することも奨励します。テスターは、テストの専門知識に貢献するすべてのプロジェクトおよび開発活動にも参加します。
チーム全体が、テスト戦略、テスト計画、テスト仕様、テスト実行、テスト評価、およびテスト結果レポートに協力して取り組みます。
共同ユーザーストーリーの作成
テスターはユーザーストーリーの作成に参加します。テスターは、システムの可能な動作に関するアイデアを提供します。これは、顧客やエンドユーザーが実際の環境でシステムを理解し、結果として実際に何を望んでいるかを明確にするのに役立ちます。これにより、要件の凍結が速くなり、後で要件が変更される可能性も低くなります。
テスターはまた、顧客が同意したすべてのシナリオの受け入れ基準を考え出します。
テスターは、テスト可能なユーザーストーリーの作成に貢献します。
リリース計画
リリース計画はプロジェクト全体に対して行われます。ただし、スクラムフレームワークには、スプリントを実行する過程でより多くの情報が取得されるため、反復的な意思決定が含まれます。したがって、プロジェクト開始時のリリース計画セッションでは、プロジェクト全体の詳細なリリース計画を作成する必要はありません。関連情報が利用可能であるため、継続的に更新できます。
すべてのスプリントエンドにリリースがある必要はありません。リリースは、スプリントのグループの後に行うことができます。リリースの主な基準は、顧客にビジネス価値を提供することです。チームは、リリース計画を入力としてスプリントの長さを決定します。
リリース計画は、リリースのテストアプローチとテスト計画の基礎です。テスターは、テストの労力を見積もり、リリースのテストを計画します。リリース計画が変更された場合、テスターは変更を処理し、リリースのより大きなコンテキストを考慮して適切なテスト基準を取得する必要があります。テスターは、すべてのスプリントの最後に必要なテスト作業も提供します。
スプリント計画
スプリントの計画は、各スプリントの開始時に行われます。スプリントバックログは、その特定のスプリントに実装するために製品バックログから取得したユーザーストーリーを使用して作成されます。
テスターは-
- スプリント用に選択されたユーザーストーリーのテスト容易性を判断する
- 受け入れテストを作成する
- テストレベルを定義する
- テスト自動化を特定する
テスターは、スプリントでのテスト作業と期間の見積もりでテスト計画を更新します。これにより、タイムボックス化されたスプリント中に必要なテストのための時間の提供と、テスト作業の説明責任が保証されます。
テスト分析
スプリントが始まると、開発者が設計と実装のためにストーリー分析を実行するときに、テスターはスプリントバックログ内のストーリーのテスト分析を実行します。テスターは、手動テストと自動テストの両方で必要なテストケースを作成します。
テスト
スクラムチームのすべてのメンバーがテストに参加する必要があります。
開発者は、ユーザーストーリーのコードを開発するときに、単体テストを実行します。ユニットテストは、コードが記述される前に、すべてのスプリントで作成されます。単体テストケースは、低レベルの設計仕様から派生しています。
テスターは、ユーザーストーリーの機能的機能と非機能的機能を実行します。
テスターは、スクラムチームの他のメンバーをテストの専門知識で指導し、チーム全体が製品の品質について集合的な説明責任を果たすようにします。
スプリントの最後に、顧客および/またはエンドユーザーはユーザー受け入れテストを実行し、スクラムチームにフィードバックを提供します。これは、次のスプリントへの入力として形成されます。
テスト結果が収集され、維持されます。
自動化テスト
自動化テストは、スクラムチームで非常に重要です。テスターは、自動化されたテストと結果の作成、実行、監視、および保守に時間を費やします。スクラムプロジェクトではいつでも変更が発生する可能性があるため、テスターは変更された機能のテストと、関連する回帰テストに対応する必要があります。自動化テストにより、変更に関連するテスト作業の管理が容易になります。すべてのレベルでの自動テストにより、継続的インテグレーションの実現が容易になります。自動テストは、追加の労力なしで手動テストよりもはるかに高速に実行されます。
手動テストは、探索的テスト、製品の脆弱性、欠陥の予測に重点を置いています。
テスト活動の自動化
テスト活動の自動化により、繰り返し作業の負担が軽減され、コストが削減されます。自動化
- テストデータの生成
- テストデータの読み込み
- テスト環境へのデプロイメントのビルド
- テスト環境管理
- データ出力の比較
回帰試験
スプリントでは、テスターはそのスプリントで新規/変更されたコードをテストします。ただし、テスターは、以前のスプリントで開発およびテストされたコードが新しいコードでも機能することを確認する必要もあります。したがって、スクラムでは回帰テストが重要視されます。自動回帰テストは継続的インテグレーションで実行されます。
構成管理
スクラムプロジェクトでは、自動ビルドおよびテストフレームワークを使用する構成管理システムが使用されます。これにより、新しいコードが構成管理システムにチェックインされるときに、静的分析と単体テストを繰り返し実行できます。また、新しいコードとシステムの継続的インテグレーションも管理します。自動回帰テストは、継続的インテグレーション中に実行されます。
手動テストケース、自動テスト、テストデータ、テストプラン、テスト戦略、およびその他のテストアーティファクトはバージョン管理されている必要があり、関連するアクセス許可を確保する必要があります。これは、構成管理システムでテストアーティファクトを維持することで実現できます。
アジャイルテストの実践
スクラムチームのテスターは、次のアジャイルプラクティスに従うことができます-
Pairing− 2人のチームメンバーが一緒に座って、共同で作業します。2人は、2人のテスターまたは1人のテスターと1人の開発者にすることができます。
Incremental Test Design −テストケースは、スプリントが段階的に進行し、ユーザーストーリーが追加されるにつれて開発されます。
アジャイルメトリクス
ソフトウェア開発中、メトリックの収集と分析は、プロセスを改善し、それによって生産性、高品質の成果物、および顧客満足度を向上させるのに役立ちます。スクラムベースの開発では、これが可能であり、テスターは必要なメトリックに注意を払う必要があります。
スクラム開発には、いくつかの指標が提案されています。重要な指標は次のとおりです。
Ratio of Successful Sprints − (Number of successful Sprints / Total number of Sprints) * 100。成功したスプリントとは、チームがそのコミットメントを果たすことができるスプリントです。
Velocity−チームの速度は、スプリント中にチームが獲得したストーリーポイントの量に基づいています。ストーリーポイントは、推定中にカウントされたユーザーストーリーの尺度です。
Focus Factor − (Velocity / Team’s Work Capacity) / 100。フォーカスファクターは、完成したストーリーをもたらすチームの努力のパーセンテージです。
Estimation Accuracy − (Estimated effort / Actual effort) / 100。見積もり精度は、作業量を正確に見積もるチームの能力です。
Sprint Burndown−残りの作業(ストーリーポイントまたは時間単位)と 理想的に残る必要がある作業(見積もりによる)。
それ以上の場合は、チームが実行できるよりも多くの作業を行ったことを意味します。
それより少ない場合は、チームが正確に見積もりを行っていないことを意味します。
Defect Count−スプリントの欠陥の数。欠陥数は、バックログに対するソフトウェアの欠陥の量です。
Severity of Defects−欠陥は、重大度に応じて、マイナー、メジャー、およびクリティカルに分類できます。テスターは分類を定義できます。
スプリント回顧展
スプリントレトロスペクティブでは、チームメンバー全員が参加します。彼らは共有します-
- うまくいったこと
- Metrics
- 改善の余地
- 適用するアクションアイテム
アジャイルテストでは、一般的に使用されるテスト方法は従来の慣行からのものであり、原則である「早期テスト」に沿っています。テストケースは、コードが記述される前に記述されます。適切なテストタイプを適切なタイミングで適切なレベルで実行することで、欠陥の防止、検出、および除去に重点が置かれます。
この章では、方法を理解します-
- テスト駆動開発(TDD)
- 受け入れテスト駆動開発(ATDD)
- ビヘイビア駆動開発(BDD)
テスト駆動開発
テスト駆動開発(TDD)メソッドでは、自動テストケースによって指示されたTestfirstアプローチに基づいてコードが開発されます。テストケースは最初に失敗するように書かれ、テストに合格することを保証するためにそれに基づいてコードが開発されます。メソッドが繰り返され、リファクタリングはコードの開発を通じて行われます。
TDDは、次の手順で理解できます。
Step 1 −記述する必要のあるコードの機能の予想される動作を反映するテストケースを記述します。
Step 2−テストを実行します。コードがまだ開発されていないため、テストは失敗します。
Step 3 −テストケースに基づいてコードを開発します。
Step 4−テストを再実行します。今回は、機能がコーディングされているため、テストに合格する必要があります。テストに合格するまで、手順(3)と手順(4)を繰り返します。
Step 5 −コードをリファクタリングします。
Step 6 −テストを再度実行して、合格することを確認します。
繰り返す Step 1 – Step 6機能を追加するためのテストケースの追加。追加されたテストと以前のテストは、コードが期待どおりに実行されていることを確認するために毎回実行されます。このプロセスを高速化するために、テストは自動化されています。
テストは、ユニット、統合、またはシステムレベルで行うことができます。テスターと開発者の間の絶え間ないコミュニケーションを確保する必要があります。
受け入れテスト駆動開発
受け入れテスト駆動開発(ATDD)方式では、コードは受け入れテストケースによって指示されたテストファーストアプローチに基づいて開発されます。焦点は、顧客、エンドユーザー、および関連する利害関係者と協力して、ユーザーストーリーの作成中にテスターによって作成された受け入れ基準と受け入れテストケースにあります。
Step 1 −顧客およびユーザーと協力して、ユーザーストーリーとともに受け入れテストケースを作成します。
Step 2 −関連する受け入れ基準を定義します。
Step 3 −受け入れテストと受け入れ基準に基づいてコードを開発します。
Step 4 −受け入れテストを実行して、コードが期待どおりに実行されていることを確認します。
Step 5−受け入れテストを自動化します。繰り返すStep 3 – Step 5 イテレーションのすべてのユーザーストーリーが実装されるまで。
Step 6 −回帰テストを自動化します。
Step 7 −自動回帰テストを実行して、継続的な回帰を確認します。
ビヘイビア駆動開発(BDD)
ビヘイビア駆動開発(BDD)はテスト駆動開発(TDD)に似ており、システムの期待される動作を確認するためにコードをテストすることに重点が置かれています。
BDDでは、ユーザー、テスター、開発者にとって意味のある英語などの言語が使用されます。それは保証します-
- ユーザー、テスター、開発者間の継続的なコミュニケーション。
- 開発およびテストされているものの透明性。
従来のテストのテスト手法は、アジャイルテストでも使用できます。これらに加えて、アジャイルプロジェクトではアジャイル固有のテスト手法と用語が使用されます。
テスト基準
アジャイルプロジェクトでは、製品バックログが要件仕様書に置き換わります。製品バックログの内容は通常、ユーザーストーリーです。非機能要件もユーザーストーリーで処理されます。したがって、アジャイルプロジェクトのテストの基礎はユーザーストーリーです。
品質テストを確実にするために、以下もテストの基礎として追加的に考慮することができます-
- 同じプロジェクトまたは過去のプロジェクトの以前の反復からの経験。
- システムの既存の機能、アーキテクチャ、設計、コード、および品質特性。
- 現在および過去のプロジェクトからの欠陥データ。
- お客様の声。
- ユーザードキュメント。
完了の定義
完了の定義(DoD)は、スプリントバックログのアクティビティを確実に完了するためにアジャイルプロジェクトで使用される基準です。DoDはスクラムチームごとに異なる可能性がありますが、1つのチーム内で一貫している必要があります。
DoDは、ユーザーストーリーの一部である非機能要件とともに、ユーザーストーリーでの機能と機能の実装を保証するために必要なアクティビティのチェックリストです。DoDチェックリストのすべての項目が完了すると、ユーザーストーリーは完了段階に到達します。DoDはチーム間で共有されます。
ユーザーストーリーの一般的なDoDには、次のものを含めることができます。
- 詳細なテスト可能な受け入れ基準
- 反復内の他のユーザーストーリーとの一貫性を確保するための基準
- 製品に関連する特定の基準
- 機能的行動の側面
- 非機能的特性
- Interfaces
- テストデータの要件
- テストカバレッジ
- Refactoring
- レビューと承認の要件
ユーザーストーリーのDoDに加えて、DoDも必要です-
- テストのすべてのレベルで
- 機能ごとに
- 反復ごとに
- リリース用
テスト情報
テスターは、次のテスト情報を持っている必要があります-
- テストが必要なユーザーストーリー
- 関連する受け入れ基準
- システムインターフェース
- システムが機能することが期待される環境
- ツールの可用性
- テストカバレッジ
- DoD
アジャイルプロジェクトでは、テストは順次アクティビティではなく、テスターは共同モードで作業することになっているため、テスターは次のことを行う責任があります。
- 必要なテスト情報を継続的に入手します。
- テストに影響を与える情報のギャップを特定します。
- 他のチームメンバーと協力してギャップを解決します。
- テストレベルにいつ到達するかを決定します。
- 適切なテストが適切な時間に実行されるようにします。
機能的および非機能的テスト設計
アジャイルプロジェクトでは、従来のテスト手法を使用できますが、焦点は初期のテストにあります。実装を開始する前に、テストケースを用意する必要があります。
機能テスト設計の場合、テスターと開発者は、次のような従来のブラックボックステスト設計手法を使用できます。
- 等価分割
- 境界値分析
- デシジョンテーブル
- 状態遷移
- クラスツリー
非機能テスト設計の場合、非機能要件も各ユーザーストーリーの一部であるため、ブラックボックステスト設計手法は、関連するテストケースの設計にのみ使用できます。
探索的テスト
アジャイルプロジェクトでは、多くの場合、時間はテスト分析とテスト設計の制限要因になります。このような場合、探索的テスト手法を従来のテスト手法と組み合わせることができます。
探索的テスト(ET)は、同時学習、テスト設計、およびテスト実行として定義されます。探索的テストでは、テスターはテストの実行時にテストの設計を積極的に制御し、テスト中に取得した情報を使用して、新しくより優れたテストを設計します。
探索的テストは、アジャイルプロジェクトの変更に対応するのに便利です。
リスクベーステスト
リスクベーステストは、失敗のリスクに基づいたテストであり、テスト設計手法を使用してリスクを軽減します。
製品品質リスクは、製品品質に関する潜在的な問題として定義できます。製品の品質リスクには以下が含まれます-
- 機能的リスク
- 機能しないパフォーマンスリスク
- 機能しないユーザビリティリスク
リスク分析は、各リスクの確率(可能性)と影響を評価するために行われます。次に、リスクが優先されます-
- 高リスクには広範なテストが必要
- 低リスクは大まかなテストのみを必要とします
テストは、各リスクのリスクレベルとリスク特性に基づいた適切なテスト手法を使用して設計されています。次に、リスクを軽減するためにテストが実行されます。
フィットテスト
適合テストは自動化された受け入れテストです。Tools FitおよびFitNesseは、受け入れテストの自動化に使用できます。
FITはJUnitを使用しますが、テスト機能を拡張します。HTMLテーブルは、テストケースを表示するために使用されます。フィクスチャは、HTMLテーブルの背後にあるJavaクラスです。フィクスチャはHTMLテーブルの内容を取得し、テスト対象のプロジェクトでテストケースを実行します。
テスト計画はリリース計画時に作成され、スプリント計画ごとに改訂されます。テスト計画は、完全なテストカバレッジを実現するためのテストプロセスのガイドとして機能します。
テスト計画の典型的な内容は次のとおりです。
- テスト戦略
- テスト環境
- テストカバレッジ
- テストの範囲
- テストの取り組みとスケジュール
- テストツール
アジャイルプロジェクトでは、すべてのチームメンバーが製品の品質に責任を負います。したがって、誰もがテスト計画にも参加します。
テスターの責任は、必要な指示を提供し、チームの他のメンバーにテストの専門知識を提供することです。
ユーザーストーリー
ユーザーストーリーは、原則として作業成果物をテストしていません。ただし、アジャイルプロジェクトでは、テスターはユーザーストーリーの作成に参加します。テスターは、顧客に価値をもたらし、システムのさまざまな可能な動作をカバーするユーザーストーリーを作成します。
テスターはまた、すべてのユーザーストーリーがテスト可能であることを確認し、受け入れ基準を確認します。
手動および自動テスト
テストの最初の実行中に、手動テストが使用されます。それらは以下を含みます-
- ユニットテスト
- 統合テスト
- 機能テスト
- 非機能テスト
- 受け入れテスト
その後、テストは後続の実行のために自動化されます。
に Test Driven Development、ユニットテストは最初に失敗するように記述され、コードはテストに合格することを確認するために開発およびテストされます。
に Acceptance Test Driven Development、受け入れテストは最初に失敗するように作成され、コードはテストに合格することを確認するために開発およびテストされます。
他の開発方法では、テスターはチームの他のメンバーと協力して、テストカバレッジを確保します。
すべてのタイプの方法で、継続的インテグレーションテストが含まれる継続的インテグレーションが行われます。
チームは、いつ、どのテストを自動化するかを決定できます。テストの自動化に労力と時間が必要な場合でも、結果として得られる自動化されたテストにより、アジャイルプロジェクトの反復中の反復テストの労力と時間が大幅に削減されます。これにより、チームは、新しいユーザーストーリー、変更など、他の必要なアクティビティにより多くの注意を払うことができます。
に Scrum、反復はタイムボックス化されます。したがって、特定のスプリントでユーザーストーリーのテストを完了できない場合、テスターは毎日のスタンドアップミーティングで、ユーザーストーリーがそのスプリント内で完了ステータスに到達できないため、次のスプリントまで保留する必要があることを報告できます。
試験結果
アジャイルプロジェクトでのテストのほとんどは自動化されているため、ツールは必要なテスト結果ログを生成します。テスターは、テスト結果ログを確認します。テスト結果は、スプリント/リリースごとに維持する必要があります。
-を含むテストサマリーを作成することもできます。
- テスト範囲(テストされたものとテストされなかったもの)
- 可能であれば、根本原因分析とともに欠陥分析
- 欠陥修正後の回帰テストのステータス
- 問題とそれに対応する解決策
- 保留中の問題(ある場合)
- テスト戦略で必要な変更
- テストメトリクス
テストメトリクスレポート
アジャイルプロジェクトでは、テストメトリクスにはスプリントごとに以下が含まれます-
- テストの取り組み
- テスト推定精度
- テストカバレッジ
- 自動テストカバレッジ
- 欠陥の数
- 欠陥率(ユーザーストーリーポイントあたりの欠陥数)
- 欠陥の重大度
- 同じスプリントの欠陥を修正する時間(現在のスプリントから逃れるバグを修正するには24倍の費用がかかります)
- 同じスプリントで修正された欠陥の数
- スプリント内の顧客による受け入れテストの完了
スプリントレビューとレトロスペクティブレポート
テスターは、スプリントレビューとレトロスペクティブレポートにも貢献しています。代表的な内容は−
- テストメトリクス
- テスト結果ログレビュー結果
- テストの観点から何がうまくいき、何を改善できるか
- ベストプラクティス
- 学んだ教訓
- Issues
- お客様の声
アジャイルテストアクティビティは、かんばんの概念を使用して効果的に管理できます。以下は、反復/スプリント内でテストが時間内に完了することを保証し、したがって高品質の製品の提供に焦点を合わせます。
テスト可能で効果的なサイズのユーザーストーリーは、指定された制限時間内に開発とテストを行います。
WIP(Work-In-Progress)制限により、一度に限られた数のユーザーストーリーに焦点を合わせることができます。
ワークフローを視覚的に表すかんばんボードは、テストアクティビティとボトルネックがある場合はそれを追跡するのに役立ちます。
かんばんチームのコラボレーションコンセプトにより、ボトルネックが特定されたときに、待ち時間なしでボトルネックを解決できます。
テストケースを事前に準備し、開発の進行に合わせてテストスイートを維持し、カスタマーフィードバックを取得することで、イテレーション/スプリント内の欠陥を排除できます。
完了の定義(DoD)は、テストも完了した後にのみストーリーが完了状態に達するという意味で、完了-完了と呼ばれます。
製品開発におけるテスト活動
製品開発では、機能かんばんボードを使用してリリースを追跡できます。特定のリリースの機能は、機能開発ステータスを視覚的に追跡する機能かんばんボードに割り当てられます。
リリースの機能はストーリーに分割され、アジャイルアプローチを使用してリリース内で開発されます。
次のアジャイルテストアクティビティは、すべてのリリースおよびすべてのリリースの終了時にも高品質の配信を保証します-
テスターはユーザーストーリーの作成に参加するため、次のことを確認します。
システムのすべての可能な動作は、ユーザーストーリーとユーザーストーリーの一部である非機能要件によってキャプチャされます。
ユーザーストーリーはテスト可能です。
ユーザーストーリーのサイズにより、イテレーション内で開発とテストを完了(完了)できます。
ビジュアルタスクかんばんボード-
タスクのステータスと進行状況を示します
ボトルネックは発生するとすぐに特定されます
最適化できるサイクルタイムの測定を容易にします
チームコラボレーションは次のことに役立ちます-
チーム全体の高品質な製品に対する説明責任
ボトルネックが発生したときにそれを解決し、待機時間を節約します
すべての活動におけるすべての専門知識の貢献
継続的インテグレーションテストに焦点を当てた継続的インテグレーション
テストの労力と時間を節約するためのテストの自動化
開発者向けに以前に作成されたテストケースによる欠陥防止と、システムのさまざまな動作によって予想されることについて開発者を指導する-
一度に限られた数のユーザーストーリーに焦点を合わせるためのWIP制限
反復内の欠陥修正を確認するための、開発の進行に伴う継続的テスト-
テストカバレッジを確認する
未解決の欠陥の数を少なく保つ
ストーリー探索
Story Explorationは、アジャイルチーム内でのコミュニケーションであり、製品の所有者がストーリーを渡して開発を受け入れるときに、ストーリーの理解を探ります。
製品の所有者は、システムに期待される機能に基づいてストーリーを考え出します。開発者は、受け入れの準備ができているとマークする前に、各ストーリーをさらに調査します。テスターは、テストの観点からコミュニケーションに参加し、可能な限りテスト可能にします。
ストーリーの完成は、プロダクトオーナー、開発者、テスター間の継続的かつ継続的なコミュニケーションに基づいています。
推定
見積りは、リリース計画と各反復計画で行われます。
リリース計画では、テスターは以下を提供します-
- 必要なテスト活動に関する情報
- 同じための労力の見積もり
イテレーション計画では、テスターは、イテレーションに含めることができるストーリーの数と数の決定に貢献します。決定は、テストの労力とテストスケジュールの見積もりによって異なります。ストーリー見積もりは、テスト見積もりも反映しています。
かんばんでは、ストーリーが開発され、テストされ、欠陥のない完全なものとしてマークされた場合にのみ、完了が完了します。
したがって、テスト推定はストーリー推定において主要な役割を果たします。
ストーリープランニング
ストーリーの計画は、ストーリーが推定され、現在のイテレーションに割り当てられた後に開始されます。
ストーリープランニングには、次のテストタスクが含まれます-
- テストデータを準備する
- 受け入れテストを拡張する
- 手動テストを実行する
- 探索的テストセッションを実施する
- 継続的インテグレーションテストの自動化
これらのテストタスクに加えて、次のような他のタスクも必要になる場合があります。
- 性能試験
- 回帰試験
- 関連する継続的インテグレーションテストの更新
ストーリーの進行
Story Progressionは、開発者とテスターの間の継続的なコミュニケーションによって必要とされる追加のテストを明らかにします。開発者が実装をより明確にする必要がある状況では、テスターは探索的テストを実行します。
継続的テストはストーリーの進行中に実行され、継続的インテグレーションテストが含まれます。チーム全体がテスト活動に参加します。
ストーリーの受け入れ
ストーリーの受け入れは、ストーリーが完了-完了状態に達したときに発生します。つまり、ストーリーは開発され、テストされ、完全なものとして通知されます。
ストーリーテストは、ストーリーパスまたはテスト自動化のレベルに関連するすべてのテストが満たされたときに完了したと言われます。
アジャイルプロジェクトでは、テスターは次の日常業務を担当します-
システムの予想される動作を明確にして、開発者のコーディングをサポートします。
開発者が効果的かつ効率的な単体テストを作成するのを支援します。
自動化スクリプトを開発します。
自動化テストツール/スクリプトを回帰テストの継続的インテグレーションと統合します。
これらのタスクを効果的かつ迅速に実装するために、コードのCIとテストコンポーネントをサポートする継続的インテグレーション(CI)システムが、ほとんどのアジャイルプロジェクトで使用されています。
アジャイルプロジェクトのテスターと開発者は、テストセッションを管理し、欠陥レポートを作成して送信するためのさまざまなツールを利用できます。アジャイルテスト専用のツールに加えて、アジャイルチームはテスト自動化およびテスト管理ツールの恩恵を受けることもできます。
Note −記録と再生、テストラスト、ヘビーウェイト、およびテスト自動化ソリューションは、次のようにアジャイルではありません。
このようなツールによって推奨される最後のテストワークフローは、アジャイルチームでは機能しません。
このようなツールで作成された保守不可能なスクリプトは、変更の障害になります
このような専用ツールは、テスト自動化スペシャリストの必要性を生み出し、サイロを育成します
広く使用されているツールは次のとおりです。
S.No. | ツールと目的 |
---|---|
1 | Hudson CIフレームワーク |
2 | Selenium 機能テスト–ハドソンと統合 |
3 | CruiseControl CIフレームワーク |
4 | Junit Javaユニットテスト |
5 | Nunit .Netユニットテスト |
6 | Cobertura / JavaCodeCoverage / JFeature / JCover / Javaテストカバレッジ |
7 | Jester Java-ミューテーションテスト/自動エラーシード |
8 | Gretel Javaテストカバレッジ監視ツール |
9 | TestCocoon C / C ++またはC#-冗長なテストを見つけてデッドコードを見つけることにより、テストの量を減らします |
10 | JAZZ Java-ブランチ、ノード、およびDefuseカバレッジであり、GUI、テストプランナー、動的インストルメンテーション、およびテストアナライザーを実装します |
11 | Ant Java –自動化ビルド |
12 | Nant .Net-自動化ビルド |
13 | Bonfire JIRA用のアジャイルテストアドオン |
アジャイルテスト自動化ツール
効果的なアジャイルテスト自動化ツールのサポート-
テストファーストアプローチを使用した初期のテスト自動化。
実際の言語、ドメイン固有言語を使用してテスト自動化コードを記述します。
システムの予想される動作に焦点を当てます。
テストの本質を実装の詳細から分離し、テクノロジーに依存しないようにします。
コラボレーションの促進。
自動化された単体テスト(JUnitまたはNUnitを使用)は、コーディングのためのテストファーストアプローチをサポートします。これらはホワイトボックステストであり、設計が健全であり、欠陥がないことを確認します。このようなテストは、テスターのサポートを受けて開発者によって構築され、必要な機能から独立させることができます。その結果、顧客の要件を満たさない可能性があり、したがってビジネス価値のない製品が提供されます。
この懸念は、顧客、他の利害関係者、テスター、および開発者の協力を得て作成された受け入れテストを自動化することによって対処されます。自動化された受け入れテストは、製品の予想される動作を反映して、顧客または製品の所有者/ビジネスアナリストによって作成されます。開発者の関与により、要件に従ってコードを確実に作成できます。ただし、テストが受け入れのみに焦点を合わせている場合、結果のコードは拡張できないままになる可能性があります。
したがって、自動化された単体テストと自動化された受け入れテストは補完的であり、どちらもアジャイル開発に必要です。
自動受け入れテストをサポートするアジャイルツールとフレームワークは次のとおりです。
- Fit
- Fitnesse
- Concordion
- Ruby
- Cucumber
フィット
Ward Cunninghamは、受け入れテストの自動化に使用できるツールFitを開発しました。フィットが可能-
MicrosoftWordおよびMicrosoftExcelを使用した製品の動作の例を示す顧客または製品所有者
プログラマーは、これらの例を簡単に自動テストに変えることができます。
Fit 1.1は、Javaと.NETの両方をサポートしています。
FitNesse
FitNesseはwikiであり、既存のページの変更や新しいページの作成など、訪問者が編集できるWebサーバーのスタイルです。シンプルなマークアップ言語を使用すると、見出しの作成、テキストの太字、下線、斜体の作成、箇条書きの作成、その他の種類の簡単な書式設定を簡単に行うことができます。
FitNesseでは、受け入れテストの自動化は次のとおりです。
入力データと期待される出力データのテーブルとしてテストを表現します。
FitNesseを使用して、編集可能なページにテストテーブルを配置します。
または、テストテーブルをMicrosoft Excelに配置し、クリップボードにコピーしてから、 Spreadsheet to FitNesse FitNesseにテーブルを適切にフォーマットさせるコマンド
テストを実行します
テストテーブルのセルを色分けしてテスト結果を取得します
緑のセルは、期待値が得られたことを表します
赤いセルは、予想とは異なる値が得られたことを表します
黄色のセルは、例外がスローされたことを表します
きゅうり
Cucumberは、Behavior Driven Development(BDD)フレームワークに基づくツールです。主な機能は次のとおりです。
Webアプリケーションの受け入れテストを作成するために使用されます。
平易な英語のように読みやすく理解しやすい形式で機能検証を自動化できます。
Rubyで実装され、Javaフレームワークに拡張されました。どちらもJUnitをサポートしています。
Perl、PHP、Python、.Netなどの他の言語をサポートします。
Selenium、Watir、Capybaraなどと一緒に使用できます。