1

私たちは開発にかなりの数のブランチ（かなり伝統的なメインラインモデル）を利用しており、それは物事を整理し、大規模なチームで開発者を効率的に保つ方法として非常に効果的であることが証明されています。メインラインに戻す前にQAテスト開発ブランチがあり、メインラインが常に安定していることを保証します。

現在、特にテストに関連するいくつかの興味深い問題があります。最も一般的なものはこれです：テスターがテスト中にバグに遭遇したと仮定します。それはすでに修正済みとしてマークされています。それは、修正が失敗したため（この場合、バグを再度開く必要があります）、または修正がテスト対象のブランチに到達していないためですか？

PERFORCEユーザーとして、PERFORCEジョブでこれらの問題を解決することを検討しています。ただし、これはかなり「生の」ツールです。多かれ少なかれ、このための基盤となる機能を提供しますが、特にテスターが使用するための簡単なインターフェイスではありません。ですから、もっとユーザーフレンドリーな方法があるのか​​、それともまったく異なるアプローチがあるのか​​疑問に思います（ただし、この場合、「分岐を避ける」が実用的な答えではないと思います！）

複数のブランチで効果的なQAを実行するためのベストプラクティスは何ですか？これらの問題の自動化とサポートを提供する優れたツールはありますか？

4

2 に答える 2

1

テストは、開発ブランチで 1 回行われ、リリース ブランチにマージされた後に再度行われることがあります。しかし、それはプロセスの選択であり、要件ではありません。

「メインライン」ブランチからのみリリースする場合は、変更がリリース ブランチにマージされた後にのみテストするように、QA プロセスを変更することを検討してください。そして、開発者に依存して、マージ前後の変更をテストしてください。これはより典型的です。

あなたが今持っているものでは、開発者ごとに 1 つのブランチを持っているように思えます (単なる推測です)。そして、各開発ブランチに対してバグを送信します。このプロセスを変更することを真剣に検討します。これは保守性が低く、マージ後のバグ追跡が非常に困難になります。

TrueWill が示唆したように、継続的な統合を設定することは良い考えです。頻繁な (毎日の) ビルドでそれを補足します。次に、ビルドの QA テストを行います。

于 2009-09-24T14:28:57.520 に答える
0

qa がメイン ブランチでバグを発見し、それが dev ブランチで修正された場合:

  • devブランチで修正されていることをqaに確認させます
  • メインブランチのバグをコメントさせますが、開いたままにします
  • 修正がメインブランチにリリースされた後、QAが再度テストしないようにメインブランチ
  • 修正がメインで修正された場合は、メイン ブランチでバグを閉じます。

他の状況については、このようなシナリオを試してみてください (ここにはバグのライフサイクルの一部があります)。いつテストするか、何をテストするか、qa-dev 通信がどのように見えるかのシナリオを準備します。すべてを書き留めます。それがテストプロセスになります。QA がそれに従うようにします (必要に応じて開発を行います)。すべての状況をすぐにカバーできるわけではないので、時間をかけてプロセスを改善してください。

大きなマルチブランチプロジェクトに関しては。おそらく、テストマネージャー/テストリーダー/またはあなたがこの役割を呼びたいものを雇うことを考えてください. qa 作業を管理する人。テスト戦略を準備します。テスト計画を準備します。開発チームと QA 作業を調整します。適切な通信を確保します。さらに、この担当者は、異なるブランチ間の QA 作業を管理できます。並列ブランチを持つ大規模で複雑なプロジェクトでは、qa は適切な管理を必要とします (他の皆と同様)。

ツールに関しては少ないかもしれませんが、HP Quality Center と HP Quick Test Pro だけを使用しました。QTP は、テスト自動化ソフトウェア (記録と再生、データ駆動、スクリプト - VB) です。QC は、テスト (手動と自動の両方)、欠陥のリポジトリであり、要件、テスト結果も保持できます。要件とテストのカバレッジ、およびテストと欠陥のリンクを追跡できます (実際にはテスト実行と欠陥ですが、テスト実行からテストにジャンプできます)。
さらに、サイクルとリリースを定義できます。たとえば、ブランチごとのサイクルやコード リリースごとのリリース (各リリースは特定のサイクルに関連しているため、どのブランチ コードがリリースされたかが明確になります)。または、別の方法でマッピングすることもできます。
問題は、そのソフトウェアにはお金がかかるということです。私は本当にお金を意味します。それはコミットメントです。

于 2009-11-03T23:26:32.227 に答える