アジャイルテストとは何ですか? プロセスとライフサイクル

アジャイルテストとは何ですか?

アジャイルテスト アジャイル ソフトウェア開発のルールと原則に従ったテスト手法です。 ウォーターフォール手法とは異なり、アジャイル テストは、開発とテストを継続的に統合してプロジェクトの開始時に開始できます。 アジャイル テストの方法論は逐次的ではなく (コーディング段階の後でのみ実行されるという意味で)、継続的です。

アジャイルテストの原則

アジャイル テストの重要な原則は次のとおりです。

  • このアジャイル テスト モデルでは、ソフトウェアが動作することが進捗の主な尺度になります。
  • 最良の結果は、自己組織化されたチームによって達成されます。
  • 価値のあるソフトウェアを早期かつ継続的に提供することが私たちの最優先事項です。
  • ソフトウェア開発者は、プロジェクト全体を通じて毎日収集するように行動する必要があります。
  • 継続的な技術改善と優れた設計により俊敏性を強化します。
  • アジャイル テストは、継続的なフィードバックを提供することで、最終製品がビジネスの期待を満たしていることを確認します。
  • アジャイルテストプロセスでは、実装中にテストプロセスを実行する必要があるため、開発時間が短縮されます。
  • アジャイルのテストプロセスは一貫した開発ペースで機能する必要があります
  • より効果的になる方法について定期的に振り返ります。
  • 最高の archi構造、要件、設計は、自己組織化されたチームから生まれます。
  • チームは会合するたびに、より効果的になるために自分たちの行動を見直し、調整します。
  • 開発チームとの対面での会話は、チーム内で情報を伝達する最も効果的かつ効率的な方法です。

アジャイル テストには、ソフトウェアの生産性の向上に役立つさまざまな原則が含まれています。

アジャイルテストのライフサイクル

以下に示すように、アジャイル テストのライフ サイクルは XNUMX つの異なるフェーズで完了します。wing 画像:

アジャイルテストのライフサイクル

アジャイル プロセスのテスト手順は次のとおりです。

フェーズ 1: 影響評価: この初期段階では、関係者やユーザーからの意見を収集します。 このフェーズは、テスト エンジニアが次のライフ サイクルの目標を設定するのに役立つため、フィードバック フェーズとも呼ばれます。

フェーズ 2: アジャイル テスト計画: これはアジャイル テスト ライフ サイクルの第 XNUMX フェーズであり、すべての関係者が集まってテスト プロセスと成果物のスケジュールを計画します。

フェーズ 3: リリースの準備: この段階では、開発/実装された機能が稼働する準備ができているかどうかを確認します。 この段階では、どれを前の開発フェーズに戻す必要があるかも決定されます。

フェーズ 4: 毎日のスクラム: この段階には、テストの状況を把握し、その日全体の目標を設定するための毎回の起立式朝礼が含まれます。

フェーズ 5: アジリティのテストのレビュー: アジャイル ライフ サイクルの最後のフェーズは、アジャイル レビュー ミーティングです。 これには、関係者との毎週の会議が含まれ、目標に対する進捗状況を定期的に評価および評価します。

アジャイルテスト計画

アジャイルテスト計画 テスト データ要件、インフラストラクチャ、 テスト環境、およびテスト結果。 ウォーターフォール モデルとは異なり、アジャイル モデルでは、テスト計画が作成され、リリースごとに更新されます。 アジャイルにおける典型的なテスト計画には次のものがあります。

  • テストの範囲
  • テスト中の新機能
  • 機能に基づくテストのレベルまたは種類 complexITY
  • 負荷とパフォーマンスのテスト
  • インフラストラクチャの検討
  • 緩和またはリスク計画
  • リソーシング
  • 成果物とマイルストーン

アジャイルテスト戦略

アジャイル テストのライフ サイクルは XNUMX つの段階に及びます

アジャイルテスト戦略

イテレーション0

最初のステージまたは反復 0 では、初期セットアップ タスクを実行します。 これには、テスト対象者の特定、テスト ツールのインストール、リソース (ユーザビリティ テスト ラボ) のスケジュール設定などが含まれます。wing ステップは反復 0 で達成されるように設定されています

  • プロジェクトのビジネスケースを確立する
  • 境界条件とプロジェクト範囲を確立する
  • 設計のトレードオフを引き起こす主要な要件とユースケースの概要を説明する
  • 1 つ以上の候補の概要を説明します archi構造
  • リスクの特定
  • コストの見積もりと予備プロジェクトの準備

構築の繰り返し

アジャイル テスト方法の XNUMX 番目のフェーズは構築の反復であり、テストの大部分はこのフェーズで行われます。 このフェーズは、ソリューションの増分を構築するための一連の反復として観察されます。 これを行うには、各反復内で、 チームが実装する XP、スクラム、アジャイル モデリング、アジャイル データなどの実践のハイブリッドです。

構築の反復では、アジャイル チームは優先順位付けされた要件の実践に従います。各反復で、作業項目スタックから残っている最も重要な要件を取り出して実装します。

構築の反復は、確認テストと調査テストの XNUMX つに分類されます。 確認検査濃縮物 システムがこれまでにチームに説明された利害関係者の意図を満たしており、チームによって実行されていることを検証します。 調査テストでは、確認チームがスキップまたは無視した問題が検出されます。 調査テストでは、テスターは欠陥ストーリーの形で潜在的な問題を特定します。 調査テストでは、統合テスト、負荷/ストレス テスト、セキュリティ テストなどの一般的な問題を扱います。

繰り返しになりますが、確認テストには XNUMX つの側面があります 開発者テスト > アジャイル受け入れテスト。 二人とも ライフサイクル全体を通じて継続的な回帰テストを可能にするために自動化されています。 確認テストは、アジャイルでの仕様に対するテストに相当します。

アジャイル受け入れテストは、従来の機能テストと開発チームとしての従来の受け入れテストを組み合わせたもので、関係者が一緒に実行します。 一方、開発者テストは、従来の単体テストと従来のサービス統合テストを組み合わせたものです。 開発者テストでは、アプリケーション コードとデータベース スキーマの両方が検証されます。

リリースエンドゲームまたは移行フェーズ

「リリース、エンドゲーム」の目標は、システムを本番環境に正常に導入することです。 このフェーズに含まれるアクティビティには、エンド ユーザー、サポート担当者、運用担当者のトレーニングが含まれます。 また、製品リリースのマーケティング、バックアップと復元、システムとユーザードキュメントの完成も含まれます。

アジャイル方法論の最終テスト段階には、完全なシステム テストと受け入れテストが含まれます。 最終テスト段階を障害なく完了するには、構築の繰り返し中に製品をより厳密にテストする必要があります。 エンドゲーム中に、テスターはその欠陥ストーリーに取り組むことになります。

生産

リリース段階の後、製品は生産段階に移行します。

アジャイル テスト クアドラント

アジャイル テスト クアドラント

アジャイル テスト象限は、プロセス全体を XNUMX つの象限に分けており、アジャイル テストがどのように実行されるかを理解するのに役立ちます。

アジャイル象限 I

この象限では内部コードの品質が主な焦点であり、テクノロジー主導でチームをサポートするために実装されるテスト ケースで構成されます。

  • ユニットテスト
  • コンポーネントのテスト

アジャイル象限 II

これには、ビジネス主導型であり、チームをサポートするために実装されるテスト ケースが含まれています。 この象限では要件に焦点を当てます。 このフェーズで実行されるテストの種類は次のとおりです。

  • 考えられるシナリオとワークフローの例のテスト
  • プロトタイプなどのユーザーエクスペリエンスのテスト
  • ペアテスト

アジャイル クアドラント III

この象限は、象限 XNUMX と XNUMX にフィードバックを提供します。 テスト ケースは、自動テストを実行するためのベースとして使用できます。 この象限では、何度も反復レビューが実行され、製品に対する信頼が高まります。 この象限で行われるテストの種類は次のとおりです。

  • ユーザビリティテスト
  • 探索的テスト
  • 顧客とのペアテスト
  • 共同テスト
  • ユーザー受け入れテスト

アジャイル クアドラント IV

この象限は、パフォーマンス、セキュリティ、安定性などの非機能要件に焦点を当てます。この象限の助けを借りて、アプリケーションは非機能品質と期待される価値を提供するように作成されます。

  • ストレステストやパフォーマンステストなどの非機能テスト
  • に関するセキュリティテスト 認証 とハッキング
  • インフラストラクチャのテスト
  • データ移行テスト
  • スケーラビリティテスト
  • 負荷テスト

アジャイル ソフトウェア開発における QA の課題

  • アジャイルではドキュメントの優先順位が低いため、エラーが発生する可能性が高く、最終的には QA チームへのプレッシャーが大きくなります
  • 新機能が迅速に導入されるため、テスト チームが最新の機能が要件を満たしているかどうか、またビジネス スーツに本当に対応しているかどうかを確認するために使用できる時間が短縮されます。
  • テスターは多くの場合、準開発者の役割を果たすことが求められます。
  • テストの実行サイクルが大幅に圧縮される
  • テスト計画を準備する時間が大幅に短縮される
  • 回帰テストの場合、最小限のタイミングが必要です
  • 品質の門番から品質のパートナーへの役割の変化
  • アジャイル手法には要件の変更と更新がつきものであり、QA にとって最大の課題となります

アジャイルプロセスにおける自動化のリスク

  • 自動化された UI は高い信頼性を提供しますが、実行が遅く、保守が脆弱で、構築にコストがかかります。 テスターがテスト方法を知らなければ、自動化によってテストの生産性が大幅に向上しない可能性があります。
  • 信頼性の低いテストは、自動テストにおける大きな懸念事項です。 誤検知を避けるためには、失敗したテストを修正し、脆弱なテストに関連する問題を解決することが最優先事項である必要があります。
  • 自動テストが CI (継続的インテグレーション) 経由ではなく手動で開始される場合、定期的に実行されないリスクがあり、そのためテストの失敗が発生する可能性があります。
  • 自動テストは、探索的な手動テストに代わるものではありません。 製品の期待される品質を得るには、テストの種類とレベルを組み合わせて行う必要があります
  • 市販の自動化ツールの多くは、手動テスト ケースのキャプチャと再生の自動化などの単純な機能を提供します。 このようなツールは UI を介したテストを奨励し、本質的に脆弱で保守が困難なテストにつながります。 また、テスト ケースをバージョン管理システムの外部に保存すると、不要な com が作成されます。plexITY
  • 時間を節約するために、多くの場合、自動化テスト計画が適切に計画されていないか計画外であり、その結果テストが失敗します。
  • テストのセットアップと破棄の手順は通常、テストの自動化では見逃されますが、手動テストを実行すると、テストのセットアップと破棄の手順がシームレスに行われるように見えます
  • XNUMX 日に作成または実行されるテスト ケースの数などの生産性指標は、非常に誤解を招く可能性があり、無駄なテストの実行に多額の投資を行うことにつながる可能性があります。
  • アジャイル自動化チームのメンバーは、親しみやすく、協力的で、機知に富んだ有能なコンサルタントでなければなりません。そうしないと、このシステムはすぐに機能不全に陥ります。
  • 自動化により、提供される価値に比べて継続的なメンテナンスが多すぎるテスト ソリューションが提案および提供される場合があります。
  • 自動テストには、効果的なソリューションを考案して提供するための専門知識が不足している可能性があります
  • 自動テストが成功しすぎて、解決すべき重要な問題がなくなって、重要でない問題に目を向けてしまう可能性があります。

要約

ソフトウェアテストにおけるアジャイル手法では、できるだけ早い段階でテストを行う必要があります。 ソフトウェア開発ライフサイクル。 顧客の高度な関与と、コードが利用可能になったらすぐにテストすることが求められます。 コードは、システム テストに使用できるほど安定している必要があります。 広範な回帰テストを実行して、バグが修正されテストされていることを確認できます。 主に、チーム間のコミュニケーションがアジャイル モデル テストの成功につながります。