システムテスト用のソフトウェアをリリースするときに、新しい機能を追加せずにバグを修正することは正しいですか？

この質問は、経験豊富なテスターまたはテストリードに対するものです。これはソフトウェアプロジェクトのシナリオです。

開発チームが10の機能の最初の反復を完了し、システムテストにリリースしたとします。テストチームは、これらの10の機能のテストケースを作成し、テストのために5日間を見積もりました。もちろん、開発チームは5日間アイドル状態にすることはできず、次の反復のために10の新しい機能の作成を開始します。この間、テストチームは欠陥を発見し、いくつかのバグを提起しました。バグは優先順位が付けられており、それらのいくつかは次の反復の前に修正する必要があります。問題は、すべてのバグが修正されるまで、新機能や既存の機能への変更を伴う新しいリリースを受け入れないことです。テストチームは、バグ修正に加えて新機能も導入する場合、テスト用の安定したリリースを保証できると述べています。また、反復ごとにすべてのテストケースの回帰テストを実行することもできません。

つまり、開発チームはバグ修正のためだけにコードのブランチを作成し、開発を続ける別のブランチを作成する必要があります。特にリファクタリングとアーキテクチャの変更により、より多くのオーバーヘッドがマージされます。

これが一般的なテスト原則であるかどうかに同意していただけますか。テストチームの懸念は有効ですか。プロジェクトで実際にこれに遭遇しましたか？

代わりに、新機能の各リリースは別々のブランチにあるべきだと言います。これにより、開発とリリースを分離することができます。

エンドユーザーへのリリースはどのようにこのプロセスに取り組んでいますか？システムテストチームは、開発スケジュールをあまり気にせず、代わりに顧客のリリーススケジュールに重点を置く必要があります。

次の10個の機能が同じ機能に触れ、それらの領域を再度テストする必要がある可能性が高いため、開発の継続中に新しい機能を正式にテストする意味はほとんどありません。

開発中に暫定的な内部リリースを非公式にテストし続け、テスト設計を具体化できます（できれば、これらの新機能のほとんどのバグをキャッチできます）が、新機能の正式なテストと回帰のために、開発の最後に追加の期間が必要になります。テスト。

10の新機能のテストに必要な5日間を見積もるとき、検討する必要があるのは、新機能を検証するために、開発サイクルの最後、つまり顧客へのリリース前に5日間必要であることです。バグが見つかった場合）。この期間中、顧客のリリースはテストのために分岐でき、新機能の開発は次のリリースまで継続できます。

ハイブリッドアプローチを使用しています。顧客リリースについては、重大なバグ修正のみを厳密に行うための独自のブランチが確実にあります。

複数のソフトウェアバージョンで定期的な開発が続けられています。たとえば、最新の安定リリースバージョンが2.0だとします。危険な機能はすべて3.0ブランチに追加されます。バグ修正のみが2.0ブランチに入ります。専用のQAチームによるテストは、安定したブランチでのみ行われます。顧客のリリースはもちろん2.0に基づいた別のブランチから行われます。次世代プラットフォームの開発などの長期実行機能は、3.0でさえも4.0で実行されます。

これはすべて紙の上で良さそうです。しかし、顧客が特定の機能を必要とする場合、3.0は顧客にリリースするのに十分安定していないため、2.0ブランチ自体に追加する必要があります。つまり、QAチームは回帰スイート全体を再実行する必要があります。

私たちが行うことの1つは、各回帰テストケースのコードカバレッジを実行することです。機能のコード変更の影響を受ける回帰テストケースのみが実行されます。もちろん、顧客リリースの場合、完全な回帰スイートが実行されます。

それは、新機能とバグ修正が必要な部分との密接な関係に本当に依存します。たとえば、UIの1つの小さな部分に新しいドラッグアンドドロップ機能を追加しても、ユーザーがロードしたファイルの解析に関連するバグには「影響しない」はずです。

そうは言っても、テスターが修正プログラム「Ceteris paribus」をテストすることを理解することは（必ずしも正当化されているわけではありませんが）理解できます（すべての「その他の」ことは同じです）。

リリースの方法とエンドユーザーの期待には、他にもいくつかの懸念があるかもしれません。たとえば、ユーザーは新しい機能がある場合にのみ再インストールまたはアップグレードを希望するため、バグ修正+テストと新しい機能+テストを1回繰り返した後にリリースする必要がある場合があります。一部は至急最優先として修正を要求するかもしれません。

両方のチームをマージすることで、この（一般的な）問題を解決できます。

開発チーム内のテスターは、機能の作成時にテストを行うことで、ほとんどのチームが出力の品質を向上させるのに役立ちます。

カバンを説明するヘンリック・クニバーグのこの素晴らしいブログ投稿を読むことをお勧めします。スクラムプロセスには多くのアイデアがあります（Henrik Knibergによる無料の本）。

彼はまた彼のブログで優れたカンバンVSスクラムの記事を書いた。

楽しい。

テストチームには確かに正当な懸念がありますが、リリースごとにテストを複数回繰り返す必要があるかどうか疑問に思います。なぜユーザーが目にすることのないバージョンのコードで一連のテストを行うのですか？

テスターが定義済みのリリースを顧客に提供しようとしている場合、それは新機能を期待していないので、テスターの要求は妥当で正当化されているので、後方に曲げてそれを提供する必要があります。

これが通常の開発フェーズでの「プロセス」を支援するためだけであり、バグリストが制御不能にならないようにして、問題を発生させないようにする場合は、この制約が少し緩和されるかどうかテストの責任者に尋ねますリリースポイントに近づきます。

ソース管理システムを分散製品に変更することを検討してください。これにより、そのようなリリースの配信がはるかに容易になります。

「これが一般的なテスト原則であるかどうかに同意していただけますか。

Yes

テストチームの懸念は有効ですか

Yes

プロジェクトで実際にこれに遭遇しましたか？」

Yes

：

and Yes Merging is the downside of it 

あなたはそれが誰の責任であるか尋ねませんでしたが、それは構成マネージャーの責任です。このストリーム戦略は彼のCMPにあるはずです。そうでなければ彼/彼女を解雇してください。Pierre 303からの応答も非常に良いと思いますが、技術的に（たとえば、Siebelのリリースを考えて...）、組織的に可能な場合は当然です。

問題は、ブランチでバグをテストする場合、マージされた後、トランクで再テストおよび回帰テストを行う必要があるということです（優れたテスターがまれにしか信頼していない場合を除く）。これは、開発者の仕事を増やすだけでなく、テスターの仕事も増やすことです。

ここでは正しい答えはありませんが、考慮すべきいくつかの点があります。

• これらのバグリリース（新機能なし）がユーザーに届く可能性はありますか？そうであれば、はい、分岐してテストする必要があり、誰もがそれをオーバーヘッドとして受け入れる必要があります。

• 新しい機能を、アプリケーションの完全に別の領域に存在するように、以前に処理されたチャンクに分割することは可能ですか？もしそうなら、これはあなたにオプションを与えます-テスターはアプリケーションのバグの再テストと回帰テストの部分を実行できます。これは理想的ではありませんが、機能し、必要なものを提供できる妥協策です。

• リリースを分岐させるのは本当にどれだけの作業ですか？一般的には苦痛ですが、実際の作業量は通常それほど大きくありません。明らかに、彼らにとってそれが彼らにとってより多くの仕事であるだけではないことを確認するためにそれらを必要とするでしょう（私が言う最初のことを見てください）が、私は場所がこの仕事をするのを見ました。

• ここでバージョン管理を使用するより良い方法はありますか？ Mercurial（http://hginit.com/を参照-読んでください、それでいいです）などの何か、または別の分散バージョン管理システムが別の方法で分岐およびマージし、問題を回避できる場合があります。 ほんとに、あなたの問題の答えかもしれないと思うので、見てください。

しかし幸運、それは苦痛です。何よりも、最善の方法は会社、製品、状況に大きく依存することを忘れないでください。そのことを考え、棚から何かを取り出して100％遵守する必要があると信じないでください。

記述したバグが実際の欠陥であり、設計の最適化ではない場合、はい、実際に修正してから、新機能の作業を開始する必要があります。

既知のバグの上に新しい機能を構築する場合は、カードの家を作成しています。脆弱で予測できないソフトウェアを開発している可能性があります。バグのあるコードと新機能の分離レベルによっては、バグが新機能にも影響を与える可能性があります。もしそうなら、あなたはあなたの新しい機能が正しく動作するかどうかどうやって知るのですか？

最初にバグを修正すると、追加する新機能の基盤が強化されます。

確かに、外力がより良い判断に反対するよう圧力をかけるときがあります。意思決定者がどちらかの行動の結果（つまり、未解決の欠陥と機能の提供日を見逃したこと）を認識している情報に基づいた意思決定を支援し、判断力を行使できるように支援するようにしてください。望ましくないものの、一連の行動が必要となる法的および財政的理由が時々あります。

新しい機能を追加する前に、必ずバグを修正してください。

私が作業している場所では、本番への意図されたリリースごとに独自のブランチがあるというこのシナリオを処理します。たとえば、6月の終わりにリリースがあり、7月の終わりに別のリリースがあるとします。6月のリリースには独自のブランチがあり、すべての機能がそこに追加されてQAに送信されます。この時点で、7月のリリースに取り組み始め、6月のブランチからブランチします。QAがバグを見つけたら、6月のブランチで修正し、修正がQAにプッシュされると、7月のリリースブランチにマージされます。これにより、これらのマージを処理するためのオーバーヘッドが多少追加されますが、通常、マージはかなり簡単です。時々それはあなたが何を知っているかで大きな苦痛ですが、それは大規模な変更が行われたときにのみ起こり、それらはQAサイクル中に起こるべきではありません（しかし、それらは起こります、私が認めたい以上のもの）。しかし、優れた一連のテスト（単体および統合）、コードカバレッジ、およびその他すべてのTDD流行語を使用すると、リスクは少し軽減されます。手助けするために、私たちは通常、プロジェクトごとに1人の担当者がマージを処理します。