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

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

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

アジャイルテストの原則

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

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

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

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

アジャイルテストライフサイクルは、次の図に示すように、5 つの異なるフェーズで完了します。

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

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

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

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

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

フェーズ 5: アジリティのテスト Review： アジャイルライフサイクルの最後の段階はアジリティです Rev週次会議。利害関係者との週次会議で、目標に対する進捗状況を定期的に評価および査定します。

アジャイルテスト計画

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

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

アジャイルテスト戦略

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

イテレーション0

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

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

構築の繰り返し

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

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

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

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

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

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

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

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

生産

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

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

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

アジャイル象限 I

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

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

アジャイル象限 II

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

よろしければ：