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

スクラムは、すべてのチームメンバーがすべてのプロジェクトアクティビティに参加しなければならないという意味で、 Whole Team Approach を支持しています。スクラムチームは、プロジェクトの成果物に対する説明責任で自己組織化しています。意思決定はチームに委ねられ、その結果、適切なアクションが適切なタイミングで遅延なく実行されます。また、このアプローチは、1つのアクティビティに制限するのではなく、チームの才能の適切な使用を促進します。また、テスターはすべてのプロジェクトおよび開発活動に参加し、テストの専門知識を提供します。

チーム全体がテスト戦略、テスト計画、テスト仕様、テスト実行、テスト評価、テスト結果の報告に協力します。

共同ユーザーストーリーの作成

テスターはユーザーストーリーの作成に参加します。テスターは、システムの可能な動作に関するアイデアを提供します。これは、顧客やエンドユーザーが実際の環境でシステムを理解し、結果として実際に何を望んでいるかを明確にするのに役立ちます。これにより、要件の凍結が速くなり、要件が後で変更される可能性も低くなります。

また、テスターは、お客様が同意したすべてのシナリオの受け入れ基準を考え出します。

テスターは、テスト可能なユーザーストーリーの作成に貢献します。

リリース計画

リリース計画は、プロジェクト全体に対して行われます。ただし、スクラムのフレームワークには、スプリントの実行中により多くの情報が得られるため、反復的な意思決定が含まれます。したがって、プロジェクトの最初のリリース計画セッションでは、プロジェクト全体の詳細なリリース計画を作成する必要はありません。関連情報が利用可能なため、継続的に更新できます。

すべてのスプリントエンドにリリースを用意する必要はありません。リリースは、スプリントのグループの後にできます。リリースの主な基準は、顧客にビジネス価値を提供することです。チームは、リリース計画を入力としてスプリントの長さを決定します。

リリース計画は、リリースのテストアプローチとテスト計画の基礎です。テスターはテスト作業を見積もり、リリースのテストを計画します。リリース計画が変更された場合、テスターは変更を処理し、リリースのより大きなコンテキストを考慮した適切なテスト基盤を取得する必要があります。テスターは、すべてのスプリントの最後に必要なテスト作業も提供します。

スプリント計画

スプリント計画は、各スプリントの開始時に行われます。スプリントバックログは、その特定のスプリントでの実装のために製品バックログからピックアップされたユーザーストーリーで作成されます。

テスターは-

スプリント用に選択されたユーザーストーリーのテスト容易性を決定する
受け入れテストを作成する
テストレベルを定義する
テスト自動化を特定する

テスターは、スプリントでのテストの労力と期間の推定値でテスト計画を更新します。これにより、タイムボックス化されたスプリント中に必要なテストの時間を確保し、テスト作業の説明責任を果たすことができます。

テスト分析

スプリントが開始されると、開発者が設計と実装のためにストーリー分析を行うため、テスターはスプリントバックログのストーリーのテスト分析を実行します。テスターは、必要なテストケースを作成します-手動テストと自動テストの両方。

テスト

スクラムチームのすべてのメンバーがテストに参加する必要があります。

開発者は、ユーザーストーリーのコードを開発するときに単体テストを実行します。ユニットテストは、コードが記述される前に、すべてのスプリントで作成されます。ユニットテストケースは、低レベルの設計仕様から派生しています。
テスターは、ユーザーストーリーの機能的および非機能的な機能を実行します。
テスターは、チーム全体が製品の品質に対する集合的な責任を負うように、テストの専門知識を備えたスクラムチームの他のメンバーを指導します。
スプリントの最後に、顧客および/またはエンドユーザーはユーザー受け入れテストを実施し、スクラムチームにフィードバックを提供します。これは、次のスプリントへの入力として形成されます。
テスト結果が収集され、維持されます。

自動化テスト

スクラムチームでは、自動化テストが非常に重要です。テスターは、自動化されたテストと結果の作成、実行、監視、および保守に時間を費やします。スクラムプロジェクトではいつでも変更が発生する可能性があるため、テスターは、変更された機能のテストと、関連する回帰テストに対応する必要があります。自動化テストにより、変更に関連するテスト作業の管理が容易になります。すべてのレベルの自動テストにより、継続的な統合が容易になります。自動テストは、手動テストよりもはるかに高速に実行され、追加の作業は必要ありません。

手動テストは、探索的テスト、製品の脆弱性、欠陥の予測に重点を置いています。

テスト活動の自動化

テスト活動の自動化により、繰り返し作業の負担が軽減され、コストが削減されます。自動化

テストデータ生成
テストデータの読み込み
テスト環境への展開の構築
テスト環境管理
データ出力の比較

回帰試験

スプリントでは、テスターはそのスプリントで新規/修正されたコードをテストします。ただし、テスターは、以前のスプリントで開発およびテストされたコードも、新しいコードとともに動作することを確認する必要があります。したがって、スクラムでは回帰テストが重要になります。自動回帰テストは継続的な統合で実行されます。

構成管理

自動化されたビルドおよびテストフレームワークを使用する構成管理システムは、スクラムプロジェクトで使用されます。これにより、新しいコードが構成管理システムにチェックインされるときに、静的分析と単体テストを繰り返し実行できます。また、新しいコードとシステムの継続的な統合も管理します。自動回帰テストは、継続的インテグレーション中に実行されます。

手動テストケース、自動テスト、テストデータ、テスト計画、テスト戦略、およびその他のテストアーティファクトは、バージョン管理する必要があり、関連するアクセス許可を確保する必要があります。これは、構成管理システムでテスト成果物を維持することで実現できます。

アジャイルテストの実践

スクラムチームのテスターは、以下のアジャイルプラクティスに従うことができます-

ペアリング-2人のチームメンバーが一緒に座って共同作業を行います。 2人は、2人のテスターまたは1人のテスターと1人の開発者になります。
インクリメンタルテストデザイン-スプリントがインクリメンタルに進行し、ユーザーストーリーが追加されると、テストケースが開発されます。

アジャイルメトリック

ソフトウェア開発中、メトリックの収集と分析はプロセスの改善に役立ち、それにより生産性、成果物、顧客満足度の向上を実現します。スクラムベースの開発ではこれが可能であり、テスターは必要なメトリックに注意を払う必要があります。

スクラム開発にはいくつかのメトリックが提案されています。重要なメトリックは次のとおりです-

成功したスプリントの比率-（成功したスプリントの数/スプリントの総数） *100 。成功したスプリントは、チームがそのコミットメントを満たすことができるものです。
速度-チームの速度は、スプリント中にチームが獲得したストーリーポイントの量に基づいています。ストーリーポイントは、推定中にカウントされるユーザーストーリーの測定値です。
フォーカス係数-*（速度/チームの作業能力）/100 *。フォーカスファクターは、完成したストーリーをもたらすチームの努力の割合です。
推定精度-*（推定作業量/実際の作業量）/100 *。推定精度は、チームが努力を正確に推定する能力です。
Sprint Burndown -Remaining Vsである作業（ストーリーポイントまたは時間単位）。理想的に残っている必要がある作業（推定による）。
それ以上の場合は、チームができる以上の仕事をしていることを意味します。
少ない場合、チームが正確に推定しなかったことを意味します。
欠陥カウント-スプリントの欠陥の数。欠陥数は、バックログに対するソフトウェアの欠陥の量です。
欠陥の重大度-欠陥は、その重大度に応じて、マイナー、メジャー、およびクリティカルに分類できます。テスターは分類を定義できます。

スプリント振り返り

Sprint Retrospectivesでは、すべてのチームメンバーが参加します。彼らは共有する-

うまくいったこと
測定基準
改善の範囲
適用するアクション項目

Agile-testing-scrum

目次