測試人員在Scrum團隊中到底擔任什么樣的角色？Scrum團隊有測試角色嗎？測試人員是Scrum團隊的正式成員嗎？

測試人員在Scrum團隊中到底擔任什么樣的角色？Scrum團隊有測試角色嗎？測試人員是Scrum團隊的正式成員嗎？

 

一、《Scrum指南》對測試的看法

很多人認為Scrum團隊中的三個角色分別是項目經理、開發人員和測試人員。但其實這三個角色分別是產品負責人、Scrum Master和開發團隊。

 

對于程序員、測試人員、數據庫工程師、分析人員等角色，Scrum團隊不加以區分，他們都是開發團隊的成員之一，這更利于培養端到端交付的集體所有權意識。在傳統的瀑布式團隊下，上級將任務分派給開發人員，開發人員將寫好的代碼交給測試人員。一個任務接著一個任務傳遞下去，每個人都會繼續處理下一個任務，一切看似都在交接中按部就班地順利進行。

 

這不可避免地會出現意外，例如出現Bug導致事情沒有按預期交付，或者因為某個角色完成速度慢導致工作堆積。而Scrum恰恰可以解決這種排隊或交接的問題，讓團隊共同努力，在每個時間盒沖刺內完成解決方案的一小部分。

 

接下來，我們一起看看如何在Scrum團隊中執行測試。

 

二、Scrum團隊如何處理測試

首先，最重要的一點：任何頭腦正常的人都知道Scrum團隊同樣需要進行測試，也是有測試人員的，測試是開發的重要組成部分。

 

Scrum團隊負責開發產品增量所需的所有工作，包括測試工作。Scrum團隊成員可以通過以下多種方法來實現這一目標：

• 團隊中的每個人都可以測試自己所編寫的代碼；
• 團隊中的每個人都可以編寫自動化測試來測試；
• 在團隊中開發人員和測試人員進行配對工作；
• 團隊成員可以結對編程，以確保從一開始就是無bug代碼；
•  ……

 

這其中也存在團隊的開發人員負責測試，典型的測試方法就是雙管齊下的：

• 開發人員不僅編寫代碼，還繼續手動或自動化測試；
• 測試人員繼續執行手動、自動測試。

 

在理想情況下，驗收標準應該在進行任何測試或開發之前確定，預先商定一套具有通用性驗收標準有利于首次的正確構建。

 

其實，更好的方法是采用測試優先的方法，將測試置于開發過程的前面。測試驅動開發（TDD）是一種流行的測試方法，開發人員在編碼之前先編寫一個小型測試以滿足測試。除此之外，還有一些測試優先的方法可以將測試思維擴展到整個讓團隊或團隊的利益相關者，如示例需求說明（SBE）、行為驅動開發（BDD）、驗收測試驅動開發（ATDD）。

 

根據產品需求，Scrum團隊需要進行多個級別的測試，以確保單個功能正確執行，在不會破壞其他任何功能的前提下，正確集成到產品增量中。所有必要的測試都是團隊所應該完成的一部分，且需要在同一個沖刺中執行。

 

到目前為止，這聽起來非常簡單，但落實到實際就會出現各種各樣意想不到的問題。我們一起來看看實際中出現的一些出人意料地測試人員的誤區。

 

三、關于測試人員的誤區

1、最后測試

最后測試是一種常見的誤區。開發人員完成代碼后根本不進行檢查，直接將代碼扔給測試人員。一些開發人員通過完成多少行代碼編寫來衡量工作的進度，然而測試人員通過發現多少bug來衡量進度。在這種情況下，開發人員和測試人員都在忙碌，但實際上他們所做到對整個項目卻沒有產生任何影響。

 

2、沒有商定驗收標準

在瀑布式開發的團隊中，有時會存在這種情況：測試人員認為自己具有獨立性，甚至認為自己比程序員更了解系統。這可能會導致測試人員沒有與團隊同步正在使用的驗收標準，那出現代碼無法通過測試的情況也不足為奇。這就需要測試人員和開發人員對驗收標準達成一致，以確保每個人都有相同的目標。

 

3、 “我的工作是破解你的代碼” 

一些測試人員將破解代碼視為自己的主要工作。Scrum團隊成員的目標應該具有一致性，是為了提供有價值的解決方案。測試人員進行測試并不是為了破解代碼，而是為了確保軟件能夠按照預期上線。在這種情況下，測試人員應與開發人員密切合作，以有效地構建高質量的解決方案，并避免出現解決不必要的bug而浪費時間的情況。

 

4、 “我是唯一可以進行測試的人” 

?只有一個人有測試權限?，這恰恰是許多企業或組織對測試的常見誤區。如果只有一個人有測試權限，那么當他不在場時是否要停止工作？顯然不能，因為這會造成項目的積壓，因此團隊必須共同參與測試工作。

 

5、“如果沒有他們，我們本來可以完成”

團隊中的開發人員和測試人員之間會出現明顯的分工和隔離，表現的完全像是兩個不同的團隊。發生這種情況主要是因為團隊成員傾向于依賴熟悉的工作方式，他們只專注于完成自己的任務，而忽略了提供客戶價值的更大目標。相比于此，一些企業為開發團隊和測試團隊保留了獨立的組織結構，建立厚重的部門墻，這阻礙了兩個部門之間的溝通與交流。

6、支持多個 Scrum 團隊的測試人員池

測試人員會根據團隊需求提供測試支持，但每個團隊都會堆積未經測試的代碼，這使得測試人員將其視為待處理的任務堆積。在這種情況下，測試人員往往不是團隊的一部分，他們可能沒有權力參與交付過程，甚至可能錯過待辦事項細化會議，不了解他們正在測試的項目或客戶的需求。

結果是相當可預測的：測試人員有大量甚至重復性的測試工作，但對客戶交付方面沒有價值意義。這通常不是為了鞏固專業知識，而是為了保護某些測試經理的位置。

 

7、設立卓越測試保證中心

一些企業在建立卓越測試中心方面可能會走向錯誤的方向。當代碼存在問題時，企業可能會設立一個特定部門負責質量，以解決這個問題。然而，問題在于卓越測試中心無法直接改變代碼質量，其職責只是揭示其他人需要解決質量問題了。

 

舉個例子：

所有測試和質量保證人員都是卓越測試保證中心的成員，他們向CoE經理匯報。該經理要求每個測試人員每周提交一份關于他們發現的Bug數量的報告。測試人員1發現了20個bug，測試人員2發現了40個bug，他們誰做得更好？如果測試人員沒有找到20個bug，還需要更加努力嗎？要不要修改bug數量報告以獲得更多bug或更少bug？

 

這一系列疑問表達了一個常見的問題：將測試的效果僅僅歸結為缺陷數量的報告。這種方法可能會導致測試人員為了追求數量而犧牲質量，或者感到受到懲罰或獎勵的壓力。這并不能真正改善產品的質量，而只是創造了一個表面上的指標。

 

8、“當你開發時我們的測試人員正在睡覺”

一個有趣的想法是在開發人員睡覺時讓一組離岸測試人員進行過夜測試。乍一看，這個想法具有可操作性，特別是試圖降低測試人員的每小時成本。

 

然而，將測試外包給離岸測試團隊是毫無意義。首先，測試人員無法及時與開發人員溝通和解決問題，這實際上增加了更多的溝通成本，這會對質量和交付產生不同程度的影響。團隊想要提高效率，就需要整個團隊成員（包括測試人員）都要對工作內容有共同的理解。

 

9、所有測試用例和結果都需要寫在我們的標準工具中

使用適當的測試工具可以提高測試效率和質量，但要意識到工具只是輔助手段，而不是唯一的衡量價值的標準。

 

不少企業強制使用標準測試工具是為了通過工具生成的報告來展示測試團隊為流程增加的價值。強制使用工具只是管理者通過報告活動來展示價值的一種方式。然而，這種方法忽略了一個重要的事實：價值不在于活動本身，而在于向客戶交付的解決方案。

 

測試團隊的真正價值在于他們能夠發現問題、提供質量保證和改進產品的質量。而這些價值往往無法完全通過報告來展示。因此，重要的是要將關注點放在為客戶提供高質量的解決方案上，而不僅僅是工具和報告。

 

10、我們只是修復關鍵bug

“所有軟件都有Bug，在sprint結束時不可能做到完全沒有bug?！比绻麍F隊抱有這種想法，那么他們就無法準確地執行計劃，因為每個sprint都可能會出現一個重大的生產問題。

?

11、故障單羽毛球

在軟件開發過程中，使用bug跟蹤工具作為開發人員和測試人員之間的溝通方式是很常見的。團隊通常會將Bug報告通過bug跟蹤工具分配給開發人員，開發人員收到通知后進行查看。

 

然而，如果團隊成員過于關注關閉時間的指標，可能會導致一些問題。例如，如果存在積壓的項目和缺乏明確的驗收標準，那么測試人員會面臨大量的任務。每個成員都知道時間正在流逝，因此他們會盡快關閉或重新分配工單。

 

在這種情況下，團隊成員不是進行真正的對話，而是利用該工具的“力量”來回移動任務以進行交流，這會導致溝通不暢或責任轉嫁等問題。

?

12、生產中的測試

開發人員不測試代碼，團隊就連測試人員也沒有。試想一下，代碼未經任何測試就投入生產會產生什么樣的后果可想而知。

 

?

四、寫在最后

對于技術團隊來說，測試是一項至關重要的活動。專門從事測試的人最好退一步思考如何創造客戶價值、測試的目的以及引入缺陷所造成的浪費。

• 產品待辦事項列表 引入沖刺的項目應該在沖刺中一直完成。
• 那些被視為完成的項目應該完全是零缺陷。
• 測試的良好實踐包括測試優先的方法。
• 測試和質量是整個團隊的責任，而不僅僅是一個接受過培訓且頭銜恰好是測試員的人的責任。

最后，我們要明確一點，Scrum團隊不對具體開發團隊的成員職責加以區分，他們都是開發團隊的成員之一。測試人員與其他團隊成員共有同一個職責：在沖刺結束時開發一個潛在可發布產品增量，以實現沖刺目標。