QAチームはGitflow分岐モデルのどこでテストを行う必要がありますか

私たちは、同じgitリポジトリで複数のプロジェクトに取り組んでいる大きなチーム（10〜12人の開発者と4人のqa）です。そのスプリングブートベースのバックエンドWebサービス。優れたgit分岐および展開戦略を探しています。また、機能が期待どおりに機能することを保証するqaチームもあります（ある程度のバグはありません）。

いくつかの記事を読んだ後、Gitflowモデルは私たちにとってうまく機能するだろうと感じました。ここに私の質問が来ます。

QAチームはどこで機能をテストする必要がありますか？

1. 彼らが機能ブランチでテストすれば、彼らはバグを発生させ、開発者はそれを修正し、それがQAテストに合格したら、開発のためにマージします。また、QAは開発ブランチで整数化テストを再度行います。
2. すべての機能をマージして（ユニットテストと開発者による基本的なテストの後）ブランチを開発し、そこからqaテストを行います。修正とテストもすべて開発中に行われます。

他の人にとってどのアプローチがうまくいったのか知りたいです。

QAはおそらく2回テストする必要があります。

最初のテストは、特定の変更に関するもので、機能ブランチで実行する必要があります。これにより、QAは特定の変更をテストし、特定の変更が指定どおりに完了し、期待どおりに動作することを確認できます。また、第2ラウンドのテストの早期プレビューを提供します。これは実際にQAにとって重要なことです。

さまざまな規制環境での私のバックグラウンドから来て、2番目のテストは、リリースに対応する開発ブランチ、リリースブランチ、またはおそらくマスターブランチで行う必要があります。リリースの前に、QAはデプロイされる前にデプロイされる完全で完全なコードをテストする必要があり、QAによってテストされたものはすべて、本番環境にデプロイされるものとまったく同じであると断言できるはずです。私の好みは、コードがフリーズした後、タグがリリースブランチに適用され、QAがそれをテストすることです。変更は開発ブランチで行われ、スポットチェックされ、リリースブランチの新しいタグで再度テストされます。リリースブランチ上のこれらのタグは、リリース候補に対応します。

ここでいくつかの仮定をしています。最初に、開発者ベースのある程度のテストカバレッジがあります。理想的には、これは開発者がブランチのコードをQAに送信する前に実行する自動化された単体テストおよび統合テストです。開発者は、QAテストの前に物事が正しく見えることを確認するために、UIについていくつかの探索的テストを行うこともできます。第二に、開発とQAの間に十分な調整があり、組み込まれる変更を計画して、機能に基づいて十分なQA時間を確保します。

いい質問ですね。これに対して「公式」の正解があるとは思わない。テストの速度に依存します。

本質的な問題は、各マージ、コンパイル、またはデプロイメントでさえ、潜在的にバグを作成できることです。テストするチェーンをさらに「上」にすればするほど、バグについてより早く知ることができますが、再テストする必要がある回数も増えます。

顧客が使用しているソフトウェアをテストしたことを保証するためには、顧客のトラフィック（Webアプリを想定）が青/緑の展開パターンを介してそれらのサーバーにルーティングされる前に、実際に展開をテストする必要があります。

しかし、これは明らかにコードをチェックしたのが初めてであるため、少し遅れています！

qa envでリリースブランチをテストする場合、リスクを負い、ライブテストをスモークテストのみに減らすことができます。リリースブランチにバグ修正を適用します。しかし、リリースを作成する前に機能が完全かどうかを評価することはできません

開発をテストすると、小さなバグ修正機能のブランチが得られます。機能はまだ評価される前にマージされ、さらに次のリリースの機能は現在のリリースのテストと衝突する可能性があります。

Featureブランチをテストする場合、100万の環境が必要であり、マージの順序を調整し、サインオフをテストする必要があります。さらに多くの再テスト。

私の経験から私はお勧めします：

開発マシンの機能ブランチのクイックテスト。その機能が完全であることを確認し、テスター/開発者が要件の意味について同意します。

qaサーバーにデプロイされたdevブランチでの毎日のテスト/自動テスト。すべての機能を一緒にテストし、リリースの準備ができたときに発言できます。

すべての機能はあるが、テストが終了していない場合。たとえば、スプリントが完了しました。リリースブランチを作成し、2番目のqa環境にデプロイします。これにより、リリース2の機能と同時にリリース1でのバグ修正/テストを継続できます。

（スクラム愛好者は、バグ修正のみをスプリント2に入れるべきだと言いますが、実用的です）

スイッチオーバーの前に、ライブのグリーン/ブルー展開の煙テスト。これらは、開発中に誰も実際に探していない設定/環境エラーを拾うため、非常に重要です。

私はトーマス・オーエンズに同意します。おそらく2回テストする必要があります。マージされる前に機能ブランチに一度、リリースする前にメインブランチに一度。

実際、私はこのワークフローが大好きで、Topicoというツールを作成しました。Topicoは、各プルリクエストごとにアプリの使い捨てバージョンを自動的に構築して実行します。これにより、QAチームは、独自のマシンに何らかの動的なテスト環境をセットアップすることなく、機能ブランチを個別にテストできます。

このアプローチは、人間のテストに合格したコードのみがメインブランチに到達することを意味し、そのため、その整合性が維持されます。

これをいくつかの会社で紹介し、リリースサイクルを大いに助けました。現在、リリースを正確にスケジュールできるようになりました。次のリリースになる可能性のあるものと、将来のリリースを待たなければならないものを理解するのに非常に優れています。それはあなたにもっと多くの自信を与えます。