敏捷ALM - 開發人員在測試過程中的角色

Question

我試圖採用敏捷概念，並且已經做了大量的研究，但是我還沒有遇到過一個問題的答案。我知道盡管開發人員最初編寫迭代任務時，測試人員可以準備他們的測試計劃和測試用例，但是當測試開始時，如果沒有錯誤被確定用於進一步編碼和重新測試，那麼應該開發人員正在努力呢？在我目前的SDLC中，開發人員將開始研究下一個版本的內容，但在敏捷方面，似乎只能在當前的迭代/衝刺階段完成工作，直到完成完成。

Answer 1

@ user3329073 - 出於好奇，你目前正在計劃衝刺和發佈 - 還是你還在使用瀑布？還是採用混合方式？

無論如何，在計劃週期中，您的開發人員看起來會完成他們打算處理的所有任務，並將這些任務交給您的QA團隊進行測試。根據缺陷或更改的數量，他們可能會修復這些缺陷或編碼更改 - 或者 - 正在等待將新工作分配給他們。這似乎有點奇怪 - 但這可能是由於我完全不瞭解你的情況。

通常情況下，我會期望（尤其是在敏捷環境），開發人員可以做一個或多個以下的 -

1. 它們可以編寫自動化測試腳本，讓每一個新功能是由您的測試自動化套件覆蓋。 （你目前正在做自動化測試嗎？）
2. 他們可以在同一個sprint中選擇下一個任務/用戶故事/需求 - 並開始研究。
3. 他們可以選擇一些工程任務 - 例如代碼重新考慮性能或其他常見原因，以及其他重要的（但通常不是緊急的）任務 - 甚至是文檔。

這一切都取決於您的團隊運作的整體環境。代碼質量，穩定性，性能和文檔的組織目標是什麼？什麼是測試自動化策略？有哪些工具可以使開發人員和測試人員完成他們的工作？

在我們的工程組織中，例如，在我們遵循更多的看板方法來成爲敏捷的時候，我們幾乎沒有測試人員。我們進行測試驅動開發，開發人員在開始編碼之前必須編寫測試用例。完成編碼後，他們必須自動執行他們編寫的測試用例，並測試代碼以確保其正常工作。完成後，我們會根據需要，由我們的首席架構師和其他工程負責人進行代碼審查。與此同時，開發人員繼續處理下一個用戶故事或缺陷。下面顯示的是我們在整個產品開發板中的開發路線。

此外，我們跟蹤重要的工程任務和工作一個單獨的車道，需要做 - 如果開發商有時間在他們的手，他們會拉從該車道的工作 - 與工作有關它直到完成。

我們有一個1-2手動QA鄉親，誰 - 隨着產品管理 - 做一組特定的功能，都確定了被運往下一個版本的一次大檢閱。

所以，就像我說的，這取決於您的整體方法是管理團隊以及產品部署和交付。看板在幫助您成爲敏捷方面的優勢在於它可以幫助您從現有位置開始，並從那裏改進您的流程。

下面是關於我們的實踐一些額外的閱讀，可以幫助 -

• 所有的看板開發商的日子 - 看板http://bit.ly/1h7kBcH

• 好處 - 降低300％的循環時間 - http://bit.ly/1bmuYLy

希望這有助於！

Answer 2

這聽起來確實如此，在您向敏捷過渡期間，您尚未實現團隊成員的完全整合。考慮將日常構建工作納入測試環境（如果可以的話，可以連續部署），以便測試人員可以隨着工作進展對工作進行審查。

此外，正如@Mahesh Singh提到的那樣，開發人員也可以幫助測試，並且可能會與測試團隊進行交流，指導他們完成測試，因爲新版本將用於審查。

不管你如何設置它，衝刺中總是有一個點，當衝刺開始時沒有更多的故事留下，團隊需要關閉迭代。這是你希望你的「跨職能的團隊成員，使他們可以與任何可能會留幫助：

• 準備演示腳本
• 建築安裝包
• 文檔
• 訓練準備
• 自動化測試
• 回顧即將到來的故事，爲下一次迭代
• 幫助細化估計
• 打一些乒乓球！