QAチームがGitflow分岐モデルでテストを行う場所
私たちは、同じgitリポジトリを使用して複数のプロジェクトに取り組んでいる大きなチーム（10〜12人の開発者と4 qa）です。そのスプリングブートベースのバックエンドWebサービス。私たちは良いgitブランチとデプロイ戦略を探しています。また、機能が期待どおりに機能することを保証するqaチームもあります（ある程度バグがありません）。
いくつかの記事を読んだ後、 Gitflow モデルがうまく機能すると感じました。ここに私の質問があります。
QAチームはどこで機能をテストする必要がありますか？
- 彼らがバグを発生させ、開発者がそれを修正する機能ブランチでテストする必要があります。QAテストに合格したら、マージして開発します。そしてQAは再び開発ブランチで整数化テストを行います。
- すべての機能（ユニットテストと開発者による基本テストの後）をマージしてブランチを開発し、そこからqaテストを実行する必要があります。修正とテストはすべて開発でも行われます。
他の人にどのようなアプローチがうまくいったか知りたいです。
QAはおそらく2回テストする必要があります。
最初のテストは特定の変更を中心にして、機能ブランチで行う必要があります。これにより、特定の変更についてQAテストを行い、特定の変更が指定どおりに完了し、期待どおりに動作することを確認できます。また、テストの第2ラウンドの早期プレビューも提供します。これは、QAにとって実際に重要なことです。
さまざまな規制環境での私の経験から、2番目のテストは、リリースに対応する開発ブランチのタグ、リリースブランチ、またはマスターブランチのいずれかで行う必要があります。リリース前に、QAはデプロイされる前にデプロイされる完全で完全なコードをテストする必要があり、QAによってテストされたものはすべて本番環境にデプロイされたものとまったく同じであることを主張できるはずです。私の好みは、コードがフリーズした後、タグがリリースブランチに適用され、QAがそれをテストすることです。変更は、開発ブランチで行われ、スポットチェックされ、リリースブランチの新しいタグで再度テストされます。リリースブランチのこれらのタグは、リリース候補に対応します。承認されたリリース候補はマスターにマージされ、リリースされたバージョンとして識別されます。
ここではいくつかの仮定をしています。まず、開発者ベースのテストをある程度カバーしています。理想的には、これは、開発者が任意のブランチのコードをQAに送信する前に実行および実行する自動化された単体テストと統合テストです。開発者は、UIの周りで探索的テストを実行して、QAテストの前に物事が正しく表示されることを確認することもできます。第2に、機能に基づいて十分なQA時間を確保するために組み込まれる変更を計画するために、開発とQAの間には適切な調整があります。
すばらしい質問です。これに対する「公式な」正解はないと思います。テストできる速さによって異なります。
本質的な問題は、マージ、コンパイル、さらには展開のたびにバグが発生する可能性があることです。テストチェーンをさらに「上」に行くほど、バグについて早く知ることができますが、再テストの回数も増えます。
お客様が使用しているソフトウェアを確実にテストするには、お客様のトラフィック（Webアプリを想定）が青/緑の展開パターンを介してこれらのサーバーにルーティングされる前に、実際の展開を実際にテストする必要があります。
しかし、明らかに、コードをチェックするのが初めてになるのは少し遅れます。
Qa envでリリースブランチをテストする場合、リスクを冒して、ライブテストをスモークテストのみに減らすことができます。リリースブランチにバグ修正を適用します。ただし、リリースを作成する前に、機能が完了しているかどうかを評価することはできません。
開発をテストすると、小さなバグ修正機能のブランチが作成されます。機能は評価される前にまだマージされており、次のリリースの機能は現在のリリースのテストと衝突する可能性があります。
機能ブランチをテストする場合は、100万の環境が必要であり、マージの順序を調整してサインオフをテストする必要があります。さらに、多くの再テスト。
私の経験から、私はお勧めします：
開発マシンでの機能ブランチのクイックテスト。その機能が完全であることを確認し、テスター/開発者が要件の意味について合意します。
Qaサーバーにデプロイされたdevブランチでの日々のテスト/自動テスト。すべての機能を一緒にテストして、リリースする準備ができたときに言うことができます。
すべての機能が含まれているが、テストが完了していない場合。例えば、スプリントは完了です。リリースブランチを作成し、2番目のqa環境にデプロイします。これにより、リリース1でのバグ修正/テストをリリース2の機能と同時に続行できます。
（スクラム愛好家は、バグ修正のみをスプリント2に入れる必要があると言いますが、実用的にしましょう）
切り替え前のグリーン/ブルーのライブ展開の煙のテスト。開発中に誰も実際に探していない構成/環境エラーを拾うので、これらは非常に重要です。