開發/質量保證/生產環境

Question

我是一家大型企業軟件公司的QA測試主管，擁有超過30名開發人員和一個小型QA測試團隊。我們目前使用SVN來完成我們所有的代碼和模式檢查，然後在數小時後每天晚上建立它。

我的兩難處境是：所有的開發代碼都從他們的機器每天都被提升到中央存儲庫，形成一個分支。這個分支是我們下一個軟件版本的產品代碼。每當檢入代碼時，穩定分支都會使用這段新代碼去穩定化，直到QA可以對其進行測試。 QA有時需要幾周時間才能獲得特定的代碼來測試。所有這一切中最糟糕的部分是，我們提前幾個月確定哪些代碼將進入標準發行版，以及哪些代碼會碰到下一個分支，這使我們一直編碼，直到幾乎實際發佈日期。

我真的開始看到這個過程的影響（由我的前任設置），我試圖想出一種方法，不會因爲他們可以將代碼推廣到質量保證環境，而不會阻礙另一個開發人員的一段代碼。我們很多代碼都有共享庫，正如我之前提到的，它有時可能需要QA才能獲得一段代碼進行測試。我不想在某段代碼等待測試時阻止某個領域的開發。

我現在的問題是，這裏採用什麼最好的方法？有沒有軟件可以幫到你呢？我真正想要做的是確保QA有足夠的時間來測試版本，而不需要任何新代碼直到測試完成。根據該組織中的很多人的說法，我不想在街上尋找新工作，因爲「QA工作很糟糕」。

任何建議，非常感謝，將有助於我們的測試和產品。

Answer 1

您需要一個能夠自動構建，測試和部署的持續集成服務器。我會看看Apache Hudson，JUnit（DBUnit），Selenium和Sonar等代碼質量工具的組合。

Answer 2

使用沒有分支的SVN看起來像是一個浪費的資源。他們應該建立一個穩定的分支和一個測試分支（即每日構建）。當代碼在日常構建中被測試時，它可以被推送到開發版本分支。

就像Albert提到的，取決於你的代碼是什麼，你也可以看看一些共享庫的一些自動化測試（這取決於你在開發中的位置確實不應該改變那麼多，或者你的開發團隊是做一個組織imho糟糕的工作）。

您也可以與您的開發團隊領導（或曾經管理過他們的人）討論並討論他們對QA的看法以及QA可以做些什麼來幫助他們做到最好。問：您的開發團隊在發佈之前是否設置了截止時間？你測試每一行代碼嗎？有沒有地方你可能花費了太多的詳細時間測試？它不應該都落在質量保證上，質量保證和開發人員需要共同努力才能獲得產品。

Answer 3

這是一個廣泛的問題，需要廣泛的回答，而且我不確定是否知道所有需要的東西（我一直在作爲開發主管和架構師，而不是測試經理）。我看到你所描述的過程中的幾個問題，每個需要一個解決方案：

1. 測試團隊對中間版本
   工作這應該與分裂他們的工作精力投入到有意義的迭代開發傢伙（稱爲工作處理敏捷方法論中的衝刺）和每隔幾周發佈一個工作版本。此外，應該確定該功能是優先實施的。這有利於保持「測試差距」的固定性：您總是測試幾周前的最新版本，並且開發人員明白，您發現的任何問題都比下一版本的新功能更重要。

2. 測試團隊在非穩定版本上工作
   測試團隊絕對沒有理由爲什麼要投入時間在「到貨時間到了」的版本。持續集成是一種儘快找到「破解代碼」的方法。這需要對Hudson或本土解決方案等產品進行一些投資，以確保在發生故障時發出故障通知，並對其應用一些「煙霧測試」。

3. 您的測試周期長
   投資自動化測試。這並不是說你的測試人員需要學習編程;相反，您應該投入資金，通過編寫穩定的自動化測試，用自己的知識和熱情招募或培養人才。

4. 您選擇「直到幾乎實際發佈日期爲止一直編碼」
   這是正確的;這是您和您的管理層做出的選擇，有利於提供超過穩定性和質量的更多功能。對於需要儘快進入市場或有重要客戶滿意的公司來說，這是一個很好的選擇;但這是一項糟糕的長期投資。一旦你說服你的管理層是一種選擇，你可以在真正需要時停止服用。

再次，這是我的兩美分。

Answer 4

爲了確保QA測試的代碼是唯一的且不會不斷變化，您應該使用TAG。標籤就像一個分支，除了內容是不可變的。一旦簽入/提交了一組文件，就不能更改，然後在這些文件之上進行提交。這樣QA就有一個穩定的代碼版本。