私はインターネット上のいくつかの非常に優れたリソースを読んで、最初に提案されたテストプロセスが有効なオプションであるかどうかを調べました。ですから、アドバイスや推奨事項をいただければ幸いです。
現在、Dev
およびTest
環境があり、これまでのところ十分にニーズに対応しています。 QAとUATを同じTest
環境でテストしていますが、QAテスターは、両方のチームを同じ環境でテストすると、テストスクリプトの検証で問題が発生し、これがどのように問題になるかを確認できます。 。ただし、QA
がテストを完了するのを待ってから、UAT
がそれを確認する必要はありません。これは、アジャイル開発の理想に反しているようです。
QAとUATの並列テストを可能にするために、次の新しいプロセス/アーキテクチャを提案しました。
異なるモジュール/バージョンを並行してテストできるように、別々のQA
環境とUAT
環境を用意します。したがって、QA
をテストしている間にModuleA
をテストすることができますUAT
はModuleB
をテストしています。
基本的には、互いに干渉することなく、異なるモジュール(または同じモジュール)を並行してテストする必要があります。
私はこれをシステムエンジニアに提示し(環境を構築できるように)、彼らはUAT
が完了するまでQA
は決して起こらないと言いました。現時点でのアジャイルプロセスの理解から、提案されたプロセスをさらに推し進めたいと思いますが、何かを見落としているのではないでしょうか。
ありがとう!
あなたのシステムエンジニアは正しいです。アジャイルを含む実質的にすべてのSLDCでは、QAが青信号になるまで、テスト用のソフトウェアのバージョンをユーザーに提供しないでください。
ただし、アジャイルではスプリントでのソフトウェアの開発が可能であり、各スプリントが完了してQAによって青信号になったら、ユーザーが強打してフィードバックを提供できるようにUATにプッシュする必要があります。これは、成果物がさらに離れて分散し、初期開発がほぼ完了するまでユーザーがテストするソフトウェアを取得しないウォーターフォールまたは同様のSLDCと比較されます。
ですから、この状況では両方の当事者が正しいと言いますが、あなたはもっと正しいです。 QAがテスト対象をテストし、UATがUATリリースのために青信号を出したものをテストできるように、個別のUAT環境とQA環境が必要です。これらはほぼ間違いなく、ソフトウェアの異なるリリースバージョンになります。 QAはUATよりも1〜2回進んでいる必要があり、DevはおそらくQAよりも少なくとも1スプリント進んでいる必要があります。
継続的デリバリーブックは、テストのスループットと柔軟性を向上させるため、ソフトウェアを並列環境に「ファンアウト」することが理にかなっていることを ここ に示しています。 。
http://continuousdelivery.com/wp-content/uploads/2010/09/optimized_pipeline.png
これは紙の上ではいいように聞こえますが、これを行うことの明らかな欠点は、QAによって拒否されるビルドをUATテストする可能性があることです。
このため、おそらくシリアルパイプラインを使用して新しいUAT環境を追加しますが、QAテストの後にビルドをそこに配置します。
これは、ビルドXをUATしてサインオフし、QAチームを満足させるための小さな修正を含むビルドX +1で稼働する必要があるという状況に陥るからです。