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

アジャイル手法

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

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

アジャイル手法
アジャイル手法

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

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

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

  1. プロセスとツールを介した個人とチームの対話
  2. 包括的なドキュメントを介した作業ソフトウェア
  3. 契約交渉に関するお客様のコラボレーション
  4. 変更後の対応wing プラン

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

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

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

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

アジャイルプロセス

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

アジャイルプロセスモデル
アジャイルプロセスモデル

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

スクラム

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

スクラム方式
スクラム方式
  • スクラムマスター
    • スクラムマスター チームを立ち上げる責任があり、 sprint 進歩への障害を満たし、取り除く
  • 商品の所有者
    • プロダクトオーナーは、製品バックログを作成し、バックログに優先順位を付け、各イテレーションでの機能の提供に責任を負います。
  • スクラムチーム
    • チームは独自の作業を管理し、作業を完了するために作業を組織します。 sprint またはサイクル

製品のバックログ

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

スクラムプラクティス

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

スクラムプラクティス
スクラムプラクティス

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

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

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

エクストリームプログラミング(XP)

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

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

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

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

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

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

計画

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

分析

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

設計

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

実行

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

ラッピング

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

閉鎖

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

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

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

結晶方法論

Crystal Methodology は XNUMX つの概念に基づいています

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

動的ソフトウェア開発方法(DSDM)

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

  1. 時間 Boxる
  2. MoSCoW の規則
  3. プロトタイピング

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

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

機能駆動開発(FDD)

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

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

リーンソフトウェア開発

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

  1. 無駄をなくす
  2. 学習を拡大する
  3. コミットメントを延期する(できるだけ遅く決定する)
  4. 早期納品
  5. チームに力を与える
  6. 建物の誠実さ
  7. 全体を最適化する

かんばん

かんばん 元々は、製品が完成するまでの各段階で製品に対して実行する必要があるすべての情報が記載されたカードを意味する日本語から生まれました。 このフレームワークまたは方法は、特にアジャイルの概念におけるソフトウェアのテスト方法によく採用されています。

スクラム vs カンバン

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

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

アジャイル指標

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

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