我們利用分支（一個相當傳統的幹線模型）的發展顯著數量的，它的證明是組織的事情，保持開發效率上一個大的方式非常有效球隊。我們有QA測試開發分支，然後再推回到主線，這確保主線始終穩定。流程和工具，具有多個分支測試大型項目
現在有一些與測試相關的有趣問題。最常見的是：假設測試人員在測試過程中遇到錯誤，這已經被標記爲已修復。是否因爲修復失敗（在這種情況下，他們應該重新打開該錯誤），還是因爲修復尚未到達正在測試的分支？
隨着Perforce的用戶，我們正在尋找與Perforce的工作解決這些問題。這雖然是一個「原始」工具 - 它或多或少爲此提供了基礎功能，但不是一個簡單的界面，特別是測試人員可以使用。所以我想知道是否有更多的用戶友好的方法，或完全不同的方法（我不認爲「避免分支」是在這種情況下，我們的實際答案！）
什麼是最好的在多個分支機構上執行有效QA的做法？有沒有可以爲這些問題提供自動化和支持的好工具？
有時候測試的開發分支進行一次，並再次合併到發佈分支後。但這是一個流程選擇，而不是要求。
如果只從「主線」分支版本，您可能會考慮更改您的QA過程，所以你只測試修改合併到發佈分支後。並依靠開發人員測試合併前/後合併的更改。這更典型。
隨着你現在所擁有的，它聽起來就像也許你有每開發一個分支（只是猜測）。並且您會針對每個開發分支提交錯誤。我會認真考慮改變這個過程。這是不可維護的，並且在合併之後跟蹤錯誤將會非常具有挑戰性。
由於TrueWill建議，建立一個連續的整合將是一個不錯的主意。補充說，頻繁（每日）構建。然後讓QA測試構建。
我們沒有每個開發人員的分支機構 - 我們擁有相當數量的分支機構的唯一原因是我們有很多開發人員。 我們絕對必須在合併到主線之前進行質量檢查。否則，我們最終會遇到穩定性問題，這會給每個人帶來問題。 無論如何，爲我的問題而進行質量保證並不重要。一旦你有一個分支系統，問題是，QA如何知道是否重新打開一個錯誤，或者他們是否需要等待修復到達他們正在測試的地方（無論它在哪裏）。 – 2009-09-24 17:29:44
在你的情況中，這聽起來像是你說QA在主分支中發現了一個錯誤，但是這個錯誤已經被開發人員在子分支中修復了，它還沒有被合併。如果是這樣的話，那麼明確的答案是，錯誤報告不應該被標記爲「固定」，直到它被合併到最初提交它的分支QA中爲止。如果分公司提交反對意見是主要分支，那麼這是一個堅實的過程。否則，您需要非常小心地通過您的缺陷跟蹤系統管理分支。 – 2009-09-24 18:08:16
如果質量檢查小組發現在主枝的bug，並且它是固定在Dev分支則：
至於其他情況，嘗試像這樣的鍛鍊場景（這裏你有一塊bug生命週期）。準備什麼時候測試和測試什麼場景，qa-dev應該如何通信。寫下所有的東西。那將是你的測試過程。讓QA跟隨它（並在適當的時候開發）。可能你不會馬上覆蓋所有情況，所以隨着時間的推移改進你的過程。
至於大型多分支項目。也許考慮聘請測試經理/測試主管/或者任何你想稱之爲這個角色的人。有人會管理qa工作。準備測試策略。準備測試計劃。協調qa與開發團隊合作。確保正確的溝通。此外，此人可以管理不同分支機構之間的QA工作。 在具有平行分支的大型複雜項目中，qa需要良好的管理（與其他人一樣）。
至於工具可能很少，但我只與HP Quality Center和HP Quick Test Pro合作。 QTP是測試自動化軟件（記錄&播放，數據驅動，腳本 - VB）。 QC是測試庫（包括手動和自動），缺陷，也可以保存需求，測試結果。它可以跟蹤需求測試覆蓋率和測試缺陷鏈接（實際測試運行缺陷，但可以從測試運行跳轉到測試）。
此外，您可以在其中定義週期和版本，例如它可以是每個分支的Cycle和每個代碼版本的Release（其中每個版本與給定的週期相關，因此將清楚哪個分支代碼已發佈）。或者你可以用不同的方式繪製它
問題是，該軟件花錢。我的意思是非常有錢。這是一項承諾。
您使用持續集成嗎？這可以在每個分支的基礎上進行設置。 – TrueWill 2009-09-23 01:36:53
我們不是，沒有。在某種程度上，這可能是一個錯誤 - 但已經完成了，現在爲時已晚。但是大多數情況下，我們的應用程序與您想象的一樣非常適合自動化測試，所以它可以提供多大的幫助是有限的。 – 2009-09-23 06:46:37