ソフトウェアテストにおけるアジャイル手法

テストにおけるアジャイル手法とは何ですか?

アジャイル手法とは、 連続反復 プロジェクトのソフトウェア開発ライフサイクル全体にわたる開発とテストの管理。ソフトウェアテストのアジャイルモデルでは、ウォーターフォールモデルとは異なり、開発とテストの両方のアクティビティが同時に行われます。

アジャイルソフトウェア開発とは何ですか?

この アジャイルソフトウェア開発 方法論は、ビジネスニーズのビジョンをソフトウェアソリューションに変えるための最もシンプルで効果的なプロセスの XNUMX つです。アジャイルは、継続的な計画、学習、改善、チームのコラボレーション、進化的な開発、早期配信を採用するソフトウェア開発アプローチを表すために使用される用語です。変化に対する柔軟な対応を促します。

アジャイルソフトウェア開発では、XNUMX つの核となる価値観が重視されます。

プロセスとツールを介した個人とチームの対話
包括的なドキュメントを介した作業ソフトウェア
契約交渉に関するお客様のコラボレーション
計画に従った切り替えへの対応

アジャイルモデルとウォーターフォールモデルの比較

アジャイルモデルとウォーターフォールモデルは、ソフトウェア開発プロセスの XNUMX つの異なる方法です。アプローチは異なりますが、要件とプロジェクトの種類に応じて、両方の方法が役立つ場合があります。

アジャイルモデル	ウォーターフォールモデル
ソフトウェアテストにおけるアジャイル方法論の定義: アジャイル方法論は、ソフトウェア設計に対する増分的かつ反復的なアプローチを提案します。	ウォーターフォールモデル: ソフトウェアの開発は開始点から終了点まで順番に行われます。
このアジャイルプロセスソフトウェアテストでは、設計者が作業する個々のモデルに分割されます	設計プロセスは個々のモデルに分割されていない
顧客は製品を見て、プロジェクトに対する意思決定や変更を行う機会を早期かつ頻繁に得ることができます。	顧客はプロジェクトの終了時にのみ製品を見ることができます
テストにおけるアジャイルモデルは、ウォーターフォールモデルと比較して構造化されていないと見なされます	ウォーターフォールモデルは計画指向であるため、より安全です
小さなプロジェクトは非常に迅速に実装できます。大規模なプロジェクトの場合、開発時間を見積もることは困難です。	あらゆる種類のプロジェクトを見積もり、完了することができます。
エラーはプロジェクトの途中で修正できます。	最後にのみ、製品全体がテストされます。要件のエラーが見つかった場合、または変更が必要な場合は、プロジェクトを最初から開始する必要があります。
開発プロセスは反復的であり、プロジェクトは短い (2 ～ 4 週間) 反復で実行されます。計画性は非常に低いです。	開発プロセスは段階的に行われ、その段階は反復よりもはるかに大きくなります。すべてのフェーズは、次のフェーズの詳細な説明で終了します。
ドキュメントの優先順位は以下よりも低くなりますソフトウェア開発	ドキュメントは最優先事項であり、スタッフのトレーニングや別のチームとのソフトウェアのアップグレードにも使用できます。
すべての反復には独自のテスト段階があります。新しい機能やロジックがリリースされるたびに回帰テストを実装できます。	個別の部分が完全には機能しないため、開発フェーズの後にのみテストフェーズが実行されます。
アジャイルテストでは、反復が終了すると、製品の出荷可能な機能が顧客に提供されます。新機能は出荷後すぐにご利用いただけます。顧客とのコミュニケーションを円滑にする場合に役立ちます。	開発されたすべての機能は、長い実装フェーズの後に一度に提供されます。
テスターと開発者が協力して作業する	テスターは開発者とは別に作業します
各スプリントの最後にユーザー受け入れが行われます	ユーザーの受け入れは、実行プロジェクトの終わりに。
開発者との緊密なコミュニケーションが必要であり、要件と計画を一緒に分析する必要があります。	開発者は要件や計画のプロセスには関与しません。通常、テストとコーディングの間には時間の遅れが生じます。

また、チェックしてください：- アジャイルとウォーターフォール: 方法論の違いを理解する

アジャイルプロセス

以下を確認してくださいアジャイル方法論成功したシステムを迅速に提供するためのプロセス。

様々な アジャイル手法 アジャイルテストに存在するもので、それらは以下にリストされています。

スクラム

SCRUM は、チームベースの開発環境内でタスクを管理する方法に特に焦点を当てたアジャイル開発手法です。基本的に、スクラムはラグビーの試合中に発生するアクティビティに由来しています。スクラムは開発チームに権限を与えることを信じており、小規模なチーム (たとえば 7 ～ 9 人のメンバー) で作業することを推奨しています。アジャイルとスクラムは XNUMX つの役割で構成され、その責任は次のように説明されます。

スクラムマスター
- スクラムマスターチームの立ち上げ、スプリントミーティング、進捗の障害の除去を担当します。
商品の所有者
- プロダクトオーナーは、製品バックログを作成し、バックログに優先順位を付け、各イテレーションでの機能の提供に責任を負います。
スクラムチーム
- チームは自らの作業を管理し、スプリントまたはサイクルを完了するために作業を整理します。

製品のバックログ

これは、各リリースで完了する要件（ユーザーストーリー）の数の詳細とともに要件が追跡されるリポジトリです。これはプロダクトオーナーによって維持および優先順位付けされ、スクラムチームに配布される必要があります。チームは新しい要件の追加、変更、または削除を要求することもできます。

スクラムプラクティス

実践方法について詳しく説明します。

スクラム方法論のプロセスフロー:

のプロセスフロースクラムテスト次のとおりです。

スクラムの各反復は次のように知られています。 Sprint
製品バックログは、最終製品を得るためにすべての詳細を入力するリストです。
それぞれの間に Sprint、プロダクトバックログのトップユーザーストーリーが選択され、 Sprint バックログ
チームは定義されたスプリントバックログに取り組む
チームは毎日の作業をチェックします
スプリントの最後に、チームは製品の機能を提供します

エクストリームプログラミング（XP）

エクストリームプログラミング手法は、顧客からの要求や要件が常に変化する場合、またはシステムの機能がよくわからない場合に非常に役立ちます。短い開発サイクルで製品を頻繁に「リリース」することを推奨しており、これによりシステムの生産性が本質的に向上し、顧客の要件を簡単に実装できるチェックポイントも導入されます。 XP は、顧客をターゲットに保つソフトウェアを開発します。

ビジネス要件はストーリーの観点から収集されます。そういった物語はすべて駐車場という場所に保管されています。

このタイプの方法論では、リリースは 14 日間の期間のイテレーションと呼ばれる短いサイクルに基づいています。各反復にはコーディング、単体テスト、システムテストなどのフェーズが含まれており、各フェーズでいくつかのマイナーまたはメジャーな機能がアプリケーションに組み込まれます。

エクストリームプログラミングのフェーズ:

アジャイル XP 手法には 6 つのフェーズがあり、それらについては次のように説明されます。

計画

利害関係者とスポンサーの特定
インフラストラクチャ要件
セキュリティ関連情報と収集
サービスレベル契約とその条件

分析

駐車場でのストーリーのキャプチャ
駐車場でのストーリーを優先する
推定のためのストーリーのスクラブ
反復スパン(時間)の定義
開発チームと QA チームの両方のリソース計画

設計

タスクの内訳
タスクごとのテストシナリオの準備
回帰自動化フレームワーク

実行

コーディング
単体テスト
手動テストシナリオの実行
欠陥レポートの生成
手動回帰テストケースから自動回帰テストケースへの変換
中間イテレーションのレビュー
イテレーション終了レビュー

ラッピング

小規模リリース
回帰テスト
デモとレビュー
ニーズに基づいて新しいストーリーを開発する
イテレーション終了後のレビューコメントに基づいたプロセスの改善

閉鎖

初動
トレーニング
量産開始
SLA保証の保証
RevSOA戦略を見る
プロダクションサポート

毎日の作業を追跡するために利用できる XNUMX つのストーリーボードがあり、それらは参考のために以下にリストされています。

ストーリーダンボール
- これは、毎日の XP アクティビティを追跡するために、ボード内のすべてのストーリーを付箋の形式で収集する伝統的な方法です。この手動作業にはより多くの労力と時間がかかるため、オンラインフォームに切り替えることをお勧めします。
オンラインストーリーボード
- ストーリーを保存するには、オンラインツール Storyboard を使用できます。 複数のチームが使用可能 さまざまな目的のために。

結晶方法論

クリスタルメソッドは3つの概念に基づいています

チャーター： このフェーズに含まれるさまざまなアクティビティには、開発チームの編成、予備的な実現可能性分析の実行、初期計画の作成、開発方法の微調整などがあります。
周期的な配信: 主な開発フェーズは XNUMX つ以上のデリバリーサイクルで構成されます。
1. チームはリリース計画を更新し、改良する
2. XNUMX つ以上のプログラムテスト統合反復を通じて要件のサブセットを実装します。
3. 統合された製品が実際のユーザーに提供される
4. Revプロジェクト計画と採用された開発方法論の概要
要約： このフェーズで実行されるアクティビティは、ユーザー環境への展開、展開後のレビューと反映です。

動的ソフトウェア開発方法（DSDM）

DSDM は、迅速なアプリケーション開発 (RAD) ソフトウェア開発へのアプローチを採用し、アジャイルなプロジェクト配信フレームワークを提供します。 DSDM の重要な側面は、ユーザーが積極的に関与する必要があり、チームには意思決定の権限が与えられていることです。 DSDM では、製品の頻繁な配送が積極的な焦点となります。 DSDM で使用される技術は次のとおりです。

Time Boxる
MoSCoW の規則
プロトタイピング

DSDM プロジェクトは 7 つのフェーズで構成されます

プレプロジェクト
実行可能性検証
ビジネス研究
機能モデルの反復
設計と構築の反復
製品の導入
プロジェクト後

機能駆動開発（FDD）

この方法は、機能の「設計と構築」に焦点を当てています。ソフトウェアエンジニアリングの他のアジャイル手法とは異なり、FDDは機能ごとに個別に実行する必要がある非常に具体的で短い作業フェーズを説明します。これには、ドメインウォークスルー、設計検査、ビルドへの促進、コード検査、設計が含まれます。FDDは、ターゲットで次のことを維持しながら製品を開発します。

ドメインオブジェクトのモデリング
機能ごとの開発
コンポーネント/クラスの所有権
機能チーム
検査
設定管理
通常のビルド
進捗状況と結果の可視化

リーンソフトウェア開発

リーンソフトウェア開発手法は、「ジャストインタイム生産」の原則に基づいています。ソフトウェア開発のスピードを上げ、コストを削減することを目的としています。リーン開発は 7 つのステップにまとめることができます。

無駄をなくす
学習を拡大する
コミットメントを延期する（できるだけ遅く決定する）
早期納品
チームに力を与える
建物 Integrity
全体を最適化する

かんばん

かんばんもともとは、完成までの過程の各段階で製品に対して実行する必要があるすべての情報を含むカードを意味する日本語から生まれました。このフレームワークまたは方法は、特にアジャイルコンセプトのソフトウェアテスト方法で広く採用されています。

スクラム vs カンバン

スクラム	かんばん
スクラムテクニックでは、テストは1スプリント内で完了できるように分割する必要があります。	特定のアイテムのサイズは規定されていません
優先順位付けされた製品バックログを規定します	優先順位付けはオプションです
スクラムチームは反復のために特定の量の作業に取り組みます	コミットメントは任意です
バーンダウンチャートが規定されている	特定のアイテムのサイズは規定されていません
各スプリントの間にスクラムボードがリセットされる	カンバンボードは永続的です。ワークフロー状態のアイテムの数を制限します
進行中の反復に項目を追加することはできません	容量が利用可能な場合はいつでもアイテムを追加できます
WIP は間接的に制限される	WIP は直接限定されています
規定されたタイムボックス反復	タイムボックス反復はオプション

また、チェックしてください：- カンバン vs. スクラム: 違いは何ですか?

アジャイル指標

アジャイルを効果的に使用するために収集できる指標は次のとおりです。

抗力係数
- スプリントの目標に貢献しない時間での努力
- 抗力係数は、共有リソースの数を減らし、寄与しない作業の量を減らすことで改善できます。
- 新しい推定値は、抗力係数のパーセンテージによって増やすことができます - 新しい推定値 = (古い推定値 + 抗力係数)
速度
- スプリントの出荷可能な機能に変換されたバックログ（ユーザーストーリー）の量
追加された単体テストの数
毎日のビルドを完了するのにかかる時間間隔
反復または以前の反復で検出されたバグ
製造不良の漏洩

よろしければ：