質量保證人員應如何準確地產生估計值？

Question

在我上一份工作中，我曾與一家從NO方法學到使用Scrum/Agile方法的公司合作。遇到了許多問題，包括Scrum「專家」真的不知道如何有效實施Scrum的事實。

他們使用的計劃相對簡單：
1.開始Sprint計劃會議，其中QA和開發時間的估計值是一個估計值 - 不是QA時間和Dev時間的估計值。
2.當時間估計值達到Sprint的總數時，沒有更多功能添加到該sprint中。

主要問題是QA通常不知道開發人員將如何編寫代碼...畢竟，他們不是編碼人員！因此，質量保證團隊確實沒有任何基礎來形成一個合理的時間估計。相反，99.9％的開發人員不知道理智測試，功能測試，迴歸測試和UAT測試之間的區別......所以他們無法準確估計某些功能需要什麼QA時間。

最後我拿了一顆子彈我的QA團隊，把這個問題向管理層，我在那裏及時解僱不能夠在Scrum的環境中工作，但是這確實不倫不類。

但它確實讓我想知道錯誤在這裏。難道我的問題是僵化的，想要在事情上付出艱辛的時間，還是QA應該天生知道應該花費多長時間來編寫代碼？

Answer 1

我想你們彼此交談，並計算出兩隊之間的時間預算，然後提交管理層。

Answer 2

這並不回答你的問題，但在我看來，QA人員必須能夠使用沒有開發IDE的代碼完成所有工作。瞭解設計，業務邏輯，如何閉環，設計測試等 - 都可以由QA人員完成。

Answer 3

我發現很好的工作是抵消開發/測試周期。所以你在一個迭代中編碼，然後在下一個QA中編碼。這使QA團隊有時間適當地確定工作範圍，而不是根據開發人員估算的估算。

Answer 4

我已經在質量保證和開發。這個過程在任何一個世界都沒有太大的不同，因爲它歸結爲一個簡單的事情：所有的估計都是猜測。它們基於經驗，預測，以及對特定問題的複雜性和風險的評估，但它們充其量是好猜測。

通過分析特定功能區域周圍的一組已知任務，可以使它們更有用。在質量保證中，這意味着從您擁有的角度來看待問題：分析任何可能的用戶故事中的變化，分析可能的輸入，如果您有屏幕的模型等等。基於更好的猜測，手動或自動運行這些變化需要多長時間做一些基本算術。製作一個基於粗略等價類的一些關鍵場景的小二維矩陣，找出花費多少時間a）根據以前的經驗爲每個項目編寫自動化測試，b）根據需要運行手動煙霧測試。

找出在預定的時間線期間需要多久運行一次這些測試。根據您判斷中的錯誤概率（1.5倍，2.0倍，有時爲3.0倍）以及確定正確的相對重要性運行乘數。如果真正重要的是您獲得了經過良好測試的一項功能並且不太重要，那麼需要對其他功能進行充分測試，然後相應地調整您的估算值，但在估算中確定該假設。

調度是關於管理風險，而不是消除它。它的目的是讓您看到需要完成的事情。細節從來都不是很正確，沒關係。我無法想象我曾經參與過的一個項目中，一切都按計劃進行，特別是在開發方面。

敏捷不會改變那麼多的方程;它確實改變了時間表。儘管存在教條，但確保在循環結束時進行測試還有一點空間，因爲您還需要時間來解決不可避免會出現的問題。但你不必把它變成「迷你瀑布」;開發人員可以在所有功能都在工作的情況下繼續工作，因爲他們總是可以開始挑選迭代中優先級較低的任務。

我想知道，在您的情況下，開發團隊是否代表您對QA進行了時間估算？讓其他人打電話通常不是一個好主意。遊戲中皮膚最多的人應該擁有最重的加權意見。但是很多開發人員可以做出相當好的風險評估，所以值得一聽。在敏捷開發週期中，角色排他性應該比瀑布團隊中的小，但我相當確信有些人只是在質量保證任務方面更好，他們自然會挑選大部分工作，即使在試圖走敏捷的思想。如果你的問題是你不願意在不知道實現細節的情況下做出估計，我可以說這是你需要克服的問題;即使在老派的方法論中，我也很少有完整的知識。

我想補充的一件事是：具有QA人才的人應該和他們的發展同行在同一個團隊中。如果他們的職業發展是由不同的經理管理的，但是如果他們是不同的衝刺隊伍的一部分則不好。因此，如果您有一個「測試團隊衝刺」和一個「開發團隊衝刺」，我認爲您會削弱Dev和QA重點資源之間的協作和溝通潛力。