アジャイルテスト：方法論とライフサイクル

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

アジャイルテスト アジャイルテストは、アジャイルソフトウェア開発のルールと原則に従ったテスト手法です。ウォーターフォール方式とは異なり、アジャイルテストはプロジェクトの開始時から始まり、開発と並行して継続的に実行されます。コーディングフェーズの後にのみ実行されるような逐次的なものではなく、すべてのイテレーションに組み込まれているため、欠陥が発生した瞬間にチームにフィードバックが届きます。

アジャイルテストの原則

アジャイルテストの基本原則は以下のとおりです。

• ソフトウェアが動作することが進歩の主な尺度です。
• 最も良い結果は、自己組織化されたチームから生まれる。
• 価値あるソフトウェアを早期かつ継続的に提供することが最優先事項です。
• 開発者とテスターは、プロジェクト全体を通して毎日協力して作業を進めます。
• 俊敏性は、継続的な技術改善と優れた設計によって向上する。
• 継続的なフィードバックによって、最終製品がビジネスの期待を満たすことが保証されます。
• テストは実装中に実行されるため、開発期間全体が短縮されます。
• 試験プロセスは、一貫性があり持続可能なペースを維持している。
• チームは定期的に立ち止まって振り返り、調整を行うことで、より効果的な活動を目指す。
• 最高のアーキテクチャ、要件、設計は、自己組織化されたチームから生まれる。
• 対面での会話は、チーム内における最も効果的かつ効率的なコミュニケーション手段である。

これらの原則を総合的に適用することで、ソフトウェア開発の生産性が向上し、アイデアから実用的な機能に至るまでの期間が短縮されます。

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

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

段階は以下の通りです。

• フェーズ1：影響評価。 関係者やユーザーから意見を収集します。これはフィードバックフェーズとも呼ばれ、テストエンジニアが次のライフサイクルの目標を設定するのに役立ちます。
• フェーズ2：アジャイルテストの計画。 すべての関係者が集まり、テストのスケジュール、範囲、成果物を計画する。
• フェーズ3：リリース準備。 Rev実装済みの機能を確認し、どれを本番稼働させる準備ができているか、どれを開発に戻す必要があるかを判断します。
• フェーズ4：デイリースクラム。 チームがテスト状況を共有し、その日の目標を設定する朝の立ち会議。
• フェーズ 5: アジリティのテスト Rev見る。 関係者との週次会議を開催し、目標に対する進捗状況を評価し、戦略を調整する。

アジャイルテスト計画

An アジャイルテスト計画 イテレーションで実行されるテストの種類、必要なデータとインフラストラクチャ、 テスト環境そしてテスト結果。ウォーターフォールモデルとは異なり、アジャイルテスト計画はリリースごとに作成され、更新されます。典型的な計画には以下が含まれます。

• テスト範囲。
• 新機能のテスト中です。
• 機能の複雑さに基づいたテストのレベルまたは種類。
• 負荷とパフォーマンスのテスト。
• インフラに関する考慮事項。
• リスクおよび軽減策計画。
• リソース確保。
• 成果物とマイルストーン。

アジャイルテスト戦略

アジャイルテストのライフサイクルは、4つの戦略的な段階に分かれています。

イテレーション0

最初の段階では、初期設定タスクを実行します。これには、テスト対象者の特定、テストツールのインストール、ユーザビリティテストラボなどのリソースのスケジュール設定が含まれます。イテレーション0の目標は次のとおりです。

• プロジェクトの事業計画を策定する。
• 境界条件とプロジェクト範囲を定義する。
• 設計上のトレードオフを左右する主要な要件とユースケースを概説する。
• 候補となるアーキテクチャを1つ以上概説してください。
• リスクを特定します。
• 費用を見積もり、予備的なプロジェクト計画を作成する。

構築の繰り返し

アジャイルテストの第2フェーズは構築イテレーションであり、このフェーズでテストの大部分が行われます。このフェーズは、ソリューションを段階的に構築していく一連のイテレーションで構成されます。各イテレーションにおいて、チームはXP、スクラム、アジャイルモデリング、アジャイルデータといった手法を組み合わせたハイブリッドなアプローチを採用します。

チームは優先順位付けされた要件プラクティスに従います。各イテレーションで、バックログから最も重要な項目を取り出し、実装します。構築イテレーションは、2つの補完的なテスト方法に分かれます。

• 確認検査 システムが関係者の意図を満たしていることを検証する。これはチーム自身によって実施される。
• 調査検査 確認テストでは見逃された可能性のある問題点を探し出す。テスターは潜在的な問題を欠陥事例として報告する。調査テストでは、統合テスト、負荷テスト、ストレステスト、セキュリティテストなどが行われる。

確認検査にはさらに2つの側面がある。 開発者テスト and アジャイル受け入れテスト そしてどちらも自動化されており、ライフサイクル全体を通して継続的な回帰テストが可能になっています。確認テストは、仕様に準拠したテストに相当するアジャイル開発手法です。

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

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

リリースフェーズの目標は、システムを本番環境に正常に展開することです。活動内容には、エンドユーザー、サポートスタッフ、運用チームへのトレーニング、製品リリースのマーケティング、バックアップおよび復元訓練、システムおよびユーザー向けドキュメントの最終化などが含まれます。

アジャイル開発における最終段階のテストには、システム全体のテストと受け入れテストが含まれます。障害なく開発を完了させるためには、構築イテレーション中に製品を厳密にテストする必要があります。最終段階では、テスターは開発サイクルの初期段階で発生した不具合の解決に注力します。

生産

リリース段階の後、製品は本番環境に移行し、実際の動作が監視され、問題があれば次の計画サイクルにフィードバックされます。

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

アジャイルテストのクアドラントは、プロセス全体を4つの領域に分割し、チームがアジャイルテストの実施方法を理解するのに役立ちます。

アジャイル象限 I

第1象限は、チームをサポートする技術主導型テストによる内部コード品質に焦点を当てています。

• 単体テスト。
• コンポーネントテスト。

アジャイル象限 II

第II象限には、チームを支援し要件に焦点を当てた、ビジネス主導型のテストが含まれます。この象限における典型的な作業には、以下が含まれます。

• 想定されるシナリオやワークフローの例をテストする。
• プロトタイプなどのユーザーエクスペリエンス関連成果物をテストする。
• ペアテスト。

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

第III象限は、第I象限と第II象限へのフィードバックを提供します。ここでのテストケースは、多くの場合、自動化の基礎となり、複数回の反復レビューによって製品への信頼が高まります。典型的な作業内容は以下のとおりです。

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

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

第IV象限は、パフォーマンス、セキュリティ、安定性などの非機能要件に焦点を当てています。この象限は、アプリケーションが期待される非機能特性を確実に満たすことを保証します。典型的な作業内容は以下のとおりです。

• 非機能テスト、例えばストレステストや性能テストなど。
• 認証と侵入試行を対象としたセキュリティテスト。
• インフラストラクチャのテスト。
• データ移行テスト。
• 拡張性テスト。
• 負荷テスト。

アジャイルソフトウェア開発における品質保証の課題

アジャイル開発は大きなメリットをもたらす一方で、QAチームにとって新たな課題も生み出す。

• ドキュメント作成の優先順位が低くなるため、エラーのリスクが高まり、品質保証チームにプレッシャーがかかる。
• 新機能が次々と追加されるため、テスターは最新機能を要件やビジネス意図に照らし合わせて検証する時間が少なくなってしまう。
• テスターはしばしば、開発者と同等の役割を担う。
• テスト実行サイクルは大幅に短縮されています。
• 試験計画を準備できる時間は限られています。
• 回帰テストの予算が厳しくなる。
• テスターは、品質の番人から品質におけるパートナーへと役割を変える。
• アジャイル開発では要件変更が頻繁に発生するのが常であり、これは品質保証（QA）における最大の課題の一つである。

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

アジャイル開発において自動化は不可欠だが、チームが積極的に管理しなければならないリスクも伴う。

• 自動化されたUIテストは高い信頼性を提供するものの、動作が遅く、不安定で、維持管理コストも高い。生産性の向上は、テスターが適切なテストの設計方法を理解した場合にのみ実現する。
• 信頼性の低い検査は大きな懸念事項である。検査の不具合や偽陽性の問題を改善することは、引き続き最優先事項でなければならない。
• CI（継続的インテグレーション）を介さずに手動で実行される自動テストは、気づかないうちに結果がずれてしまい、古い結果を生み出すリスクがある。
• 自動化は探索的な手動テストに取って代わるものではありません。期待される品質を確保するには、様々な種類とレベルのテストを組み合わせる必要があります。
• キャプチャ＆リプレイツールは、脆弱で保守が困難なUI主導型のスクリプトを助長する。バージョン管理システム外に保存されたテストは、不必要な複雑さを増大させる。
• 「時間節約」を目的として行われた、計画性のない自動化は、しばしば完全に失敗に終わる。
• テストのセットアップと撤去の手順は、自動化を行う際に見落としがちですが、手動テストでは自然に処理されます。
• 「1日あたりのテストケース数」といった生産性指標は、チームを誤った方向に導き、無益なテストを実行させてしまう可能性がある。
• 自動化チームは、親しみやすく、協力的で、機知に富んだ、有能なコンサルタントでなければならない。そうでなければ、その取り組みは失敗に終わるだろう。
• 継続的なメンテナンスに多大な労力を要するソリューションは、それがもたらす価値を上回る可能性がある。
• 自動テストには、効果的なソリューションを提供するために必要な専門知識が不足している可能性がある。
• 自動化が成功すると、解決すべき重要な問題がなくなり、価値の低い業務へと流れていく可能性がある。

効果的なアジャイルテストのためのベストプラクティス

アジャイルテストを迅速、信頼性が高く、チームにとって価値のあるものにするには、以下の実践が役立ちます。

• Shift 左： テストは要件定義の段階から開始すべきであり、イテレーションの最後に開始すべきではない。
• 開発者とペアを組む： 欠陥を設計段階で排除し、コードに組み込むことのないよう、受け入れ基準を一緒に見直しましょう。
• レイヤー自動化: ユニットテスト、サービステスト、UIテストからなる健全なピラミッドを構築する。
• テストを独立させる： 各テストを個別に実施することで、失敗の原因を単一の根本原因に絞り込む。
• Track 不安定なテスト: 信頼性の低下を防ぐため、不安定なテストは速やかに隔離し、修正する。
• AIを活用した分析を利用する： ツールが影響を受けるテストをフラグ付けし、失敗をグループ化し、マージ後に安定したロケーターを提案できるようにします。

よくあるご質問