できるだけ早く物事をマージする必要がある場合のQAテストの管理
私は約8人の開発者とQAがいる12人のチームで働いています。 gitフローモデルには従いませんが、個々の機能開発が行われ、それらがマスターにマージされてリリースされる機能ブランチがあります。開発者が多く、QAが1つしかないため、マスターにマージする前に機能ブランチでテストを行う必要があるため、QA担当者は常にボトルネックを作ります。
ただし、テストフェーズ中に時間がかかるためにマージの競合が発生するため、開発者をブロックします。したがって、QA担当者はできるだけ早く物事をマージし、マスターですべてを一緒にテストするように依頼される必要があります。
このプロセスを改善するためにできることはありますか？ gitフローをフォローすると役立ちますか？それはより多くのメンテナンスの心配を引き起こす可能性がある追加の開発ブランチの層を追加しますが？
QAは、機能ブランチではなく、開発ブランチ（あなたの場合はマスター）で行います。
開発者は機能ブランチをテストして機能が完全であることを確認する必要がありますが、QAは新しい機能をマージした後で製品全体をテストする必要があります。
それ以外の場合は、機能ブランチとマージ後に2回テストします
バグが見つからないと仮定して、合計を行うだけです
スプリントの1、2、3日目に完了する3つの機能を持つスプリントがあるとします。
機能ブランチでのテスト-マスターからのマージバックなし
- テストFB1
- テストFB2
- テストFB3
- すべてをマージ
- テストマスター
- テストの合計実行回数：4
機能ブランチでのテスト-マージバックあり
- テストFB1
- テストFB2
- テストFB3
- fB1をマージ
- テストFB2
- テストFB3
- fB2をマージ
- テストFB3
- fB3をマージ
- テストマスター
- テストの合計実行回数：7
マスターのみでのテスト
- すべてをマージ
- テストマスター
- 合計テスト実行数：1
開発者とテスターの比率の問題を別にしておくと、おそらくそれを修正する立場にないので、問題は機能ブランチがマスターより遅れているようです。
Ewanが指摘したように、何がデプロイされるかを表すコードをテストする必要があります。そのため、masterの背後にある機能ブランチでテストするのはよくありません。
マスターが更新されるたびに機能ブランチをリベースすることで、機能ブランチをマスターの最新状態に保つことができます。
はい、それはより多くの作業を作成しますが、コードをテストしていることを確認しながら、機能ブランチでテストを維持することを可能にします本番環境で行われるように。また、QAパス後のマスターへのマージも簡単に行えます。
残っている唯一のことは、機能ブランチをリベースするのは開発者またはQAの責任であるかどうかを決定することです。新しい機能に影響を与えずにマスターから変更を取得する方法を最もよく理解しているDevをお勧めします。
常にすべてをテストするようにQAに依頼するのをやめます。開発者に自分でやってもらいます。
私が働いている場所では、QAはテストを行いません。開発者が正しいプロセスに従っていることを確認するためにあります。
彼らがテストに関与するのは、ソフトウェアが顧客にリリースされる前の最後の正式なテストだけです。それでも、実際にボタンを押すのではなく、テストが正しく実行されていることを確認するためにあります。
いくつかのことが私には際立っています。
まず、テスターに対する開発者の比率は非常に偏っていることが際立っています。
私の経験では、1人の手動テスターに対して3〜5人の開発者が良い比率です。テスターが要件開発の初期段階から関与して、テスト戦略、アプローチ、およびケースの特定を開始している限り、これはうまくいくようです。テストの開発作業は、機能の開発と同時に開始されます。開発者が開発を完了し、作業が引き渡される場合、どこかに明示的に文書化されていない限り、テスターに質問があるか、Edgeケースの動作について確信がないため、開発者はテストをサポートするためにシフトする必要があることがわかりました。
次に、マスターにマージする前に機能ブランチでのテストが関係しています。機能ブランチをマスターにマージするときに解決する必要がある競合があるため、これは増加します。
テストされているコードは、最終的に製品のメインラインになるコードではないようです。これは、マージ後の製品に存在する問題をテストが見つけているかどうかを確認できないことを意味します。これを修正するには2つの方法があります。まず、定期的にマスターブランチを長期実行機能ブランチにマージしてテストします。すべてを再テストする必要はないかもしれませんが、競合がある場合は、差分を分析して、どのテストを再実行する必要があるかを選択できます。第2に、計画的なリリースサイクルで作業している場合、gitflowモデルのようなものは、機能と開発ブランチが相互に同期しているときにmasterがリリースを確実に反映するのに役立ちます。
第三に、自動化します。
テストスイートの自動化に取り組みます。さまざまなテストスイートを非常に簡単に実行できるようにします。以前の修正済みの問題が再発しないようにして、それを確実にすることは、回帰に重点を置いています。ただし、ユニットからシステムレベルまで可能な限り自動化し、実行を容易にします。ビルドプロセスに統合することも、各ブランチが良好な状態であることを確認するのに役立ちます。
第四に、品質は皆のビジネスです。
品質保証をチームの全員にシフトします。これは不可能かもしれません-場合によっては、開発者とテスターの間の分離を強制する契約または規制上の要件があります。これらの場合でも、要件が実際に何であるかを完全に理解し、ワークロードを共有するようにしてください。規制された環境での私の経験から、組織は検証、検証、および独立性などの要件を誤って解釈する傾向があり、開発とテストの間に常に明確な境界がある必要はないことが多く、その場合でも、開発はある程度のテストを行うことができますテストグループがより楽な時間を過ごせるようにするため。