什麼是現實（但快速）的測試版本計劃？

Question

我的團隊接近部署我們的應用程序，我們即將與一些特定客戶進行內測。我想知道生成新測試版本的實際時間表是多少，以及在我們可以稱第一版足夠穩定以便發佈之前，我們可以實際期望需要多少這樣的週期。

該應用程序本身是一個醫療成像應用程序，所以它絕對不會崩潰或損壞數據。許多用戶還將持續使用該軟件至少四到八小時，因此我期望正常的用戶錯誤會很快遇到。應用程序與特定的硬件綁定，如果他們有硬件，他們將需要這個應用程序或以前版本的應用程序來運行他們的硬件。

當然，現在，現在也有壓力從上面釋放它！因爲他們支付我的工資，所以我有責任按照他們的指示行事，儘管我可能會對快速發佈產生任何疑慮。

我在想，在以下情況下可以發揮出：

1. 兩週的週期時間。我們有一組特定的用戶，說3到5個站點，當他們遇到錯誤時，我們修復它們。我認爲這個週期時間非常快，但我已經可以感覺到這將是如何部署的權力。對於這種方法，我們將產品鎖定到特定版本，並且在下一個版本（可能是50版之後）中修復任何積累的錯誤。
2. 六週週期時間。我們有相同的選擇用戶組，但是該組可以增長，並且隨着它的增長，我們將按照步驟1進行操作。速度不如1，但肯定比較謹慎。問題是，用戶可能會產生這樣的印象，即產品過於錯誤（如果它們遇到錯誤），並且在我們發佈另一個版本之前不會有這種印象，此時他們可能不再在意。由於前面提到的硬件鎖定了，這種繁瑣的印象可能只會轉化爲輕微的抱怨，而不是失去的銷售。但是，每個較新的beta版本都將比上一次更加審覈。
3. 只要修正了錯誤，就可以將固定版本交到用戶手中。我們有一個構建服務器，我們有幾個測試人員，而且我們很快就會做出響應（你甚至可以說'敏捷'）。只要修復程序不會破壞軟件需要的某些其他行爲，就像我們修復錯誤一樣快地修復錯誤，是否存在缺陷？如果我們採取這種方法，我們會做週期，還是隻是一個測試'時期'？

我意識到，這些問題因用戶而異，而像暴雪或Gmail測試版這樣的東西有點長。我仍然想知道我應該如何迴應管理層關於測試版應該投入多長時間的問題。

Answer 1

在我們的案例中，我們讓客戶的反饋決定了我們的週期。在發佈初始測試版之後，我們會聽取反饋意見。有時候會有一個災難性的bug，我們暫停推出測試版，修復它然後恢復。我們根據客戶重要性收集錯誤，然後在抱怨消失後再推出更新。最終，客戶的看法是最重要的（參考速度），因此平衡他們對管理層所要的投訴是棘手的方面。在我們的案例中，我們通常會根據錯誤的數量和緊急程度，在2-4周的時間內進行。

Answer 2

這似乎是一個問題，在您的第一次反饋來自最初的測試版發佈後不久就會回答。如果客戶普遍感到高興，並且問題比結構更美觀，則計劃縮短測試階段。如果你發現相反的話，準備管理層爲更深入的測試階段做準備。

我不知道您的應用程序的具體細節，但我會認爲一套發佈計劃會更容易讓您的客戶跟上。當客戶確實發現優先級較高的問題時，很高興聽到該解決方案已經投入使用，並且只要距離不到幾個月，它將在2周甚至6周內出現在下一個版本中。 '補丁'除非被嚴格區分可能會導致比解決問題更多的問題，因爲客戶擁有奇怪且截然不同的代碼庫，這將很難再現問題。

Answer 3

與數字1一起去吧。毫無疑問，這可能是最好的方法。 ＃2顯然不理想，因爲週期時間長。 ＃3是誘人的，會給你帶來難以置信的麻煩。這就是爲什麼：如果您將修補程序部署到需要它們的人身上，那麼您會完全失去任何理性的版本控制方案，並且跟蹤哪個客戶有哪些修復程序以及哪些版本最棘手。

Answer 4

我見過一對一的發佈時間表。第一個版本計劃，更大，包括功能，aybe 6-8周或有時更多。第二個是計劃的修正，每2週一次。所以每10-12周你有兩個版本。