アジャイルテスト-スクラム

スクラム支持者 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
改善の余地
適用するアクションアイテム