測試工程師在敏捷專案中扮演什麼角色？

敏捷團隊中的測試人員主要負責執行各種測試，以滿足 “已完成” 的定義，從而為團隊在重複迭代中努力交付的持續價值創造做出貢獻。對於測試人員來說，擁有敏捷的心態是至關重要的，如果沒有敏捷的思維方式，他們可能就不能果斷地計劃、劃分優先順序並執行他們的任務，因此會無意中影響團隊滿足迭代目標的能力。敏捷的思維方式是測試人員展示正確行為的先決條件，這些行為能夠加速整個團隊的效能。

為了在敏捷專案中取得成功，測試人員應該關注以下實踐：

1.態度勝過一切

團隊中的測試人員可能不具備敏捷背景、自動化技能或豐富的測試經驗——只要他們具備成為敏捷團隊一員的正確態度，這仍然是可以的。正確的態度會反映在以下行為中，比如：相信敏捷宣言和實踐，信任教練並全力以赴地遵循它，對新的學習和變化持開放態度，清晰表達和透明，致力於對團隊重要的活動，在這段時間內主動改進和變得更好等等。

敏捷、自動化、測試或其他培訓，對於擁有正確態度的人來說，是可以齊頭並進的。

根據我的經驗，在工作中使用僵化思維的測試人員減慢了迭代的進度。有些行為是——僅在 ALM 工具中更新狀態時才測試缺陷；在測試環境關閉時，閒置而不在本地主機上執行健全性測試；考慮在會議期間單獨測試活動；在部署時堅持團隊成員的正式溝通，阻止決議和暗示等。

相反，以開放的心態來的測試人員轉變了自己，為團隊服務，並以各種可能的方式做出貢獻，例如，他們中的一些人在空閒時間編寫 Junit 案例來幫助開發人員，學會編寫服務來模擬測試環境，在高度動態的環境中靈活調整計劃和測試方法。

2.將迭代目標優先於外部分配

在矩陣式組織結構中，測試人員在敏捷團隊中與 Scrum Master 一起工作，但他們向測試實踐部門的直線經理或同一專案中的測試經理報告。這些在敏捷團隊中驅動整體測試的測試經理，可能會給測試人員分配許多與團隊迭代計劃不一致的特別任務。

在我與測試人員的多次接觸中，我發現他們很難在兩方面之間取得平衡——兼顧績效評估和致力於工作。他們中的大多數人都試圖在沒有通知敏捷團隊的情況下承擔外部任務，因為他們不想讓直線經理不高興。一些人知道它會影響正在進行的迭代活動，於是透過延長工作時間即加班來完成這些任務，但也有很多人犧牲了迭代活動。由於這種妥協，他們無法交付迭代目標，這導致了使用者故事的常規溢位，也影響了團隊的信任和內聚水平。

在這種情況下，測試人員應該怎麼做？答案是——迭代活動應該總是優先於任何其他活動。但是，如果他們能夠在不影響迭代目標的情況下完成外部任務，那麼他們就可以繼續！但是，如果外部任務有可能影響迭代目標，那麼他們應該諮詢團隊以獲得集體同意或意見分歧，並將決策告知直線經理。

3.跨職能團隊中的關係平等

“我不能測試這個使用者故事，因為開發人員沒有部署它”，一個測試人員在每日站會中說，開發人員回答說：“抱歉，我忘了它，但你也應該聯絡其他開發人員來完成。”。這個場景突出了團隊缺乏協作和所有權。推動一個使用者故事的完成並消除間歇的阻礙因素並不是個人的責任，而是團隊的努力，作為團隊一部分的測試人員也不例外。

測試人員的某些行為有助於加快交付速度——無論是否與測試相關，都需要關注到阻礙因素；經常與開發人員同步，而不是透過電子郵件溝通；積極參加 scrum 會議以提高團隊的決策能力，與團隊的計劃保持一致，從而使他們的活動保持一致等等。

一些與其他團隊過度交往的測試人員更喜歡挑選低優先順序的任務。因為他們需要花費數小時來解決其他團隊的問題，卻以犧牲自己的工作為代價——這種行為超出了在跨職能團隊中作為平等夥伴的邊緣。團隊成員應該優先解決他們的問題，如果需要的話，為其他團隊提供幫助應該是次要的目標。

4.假設並不是一種選擇

有時，利益相關者的評審意見顯示，團隊在驗收標準方面存在一些不必要的假設。假設不是特定的對測試人員的選擇，因為測試是工作流中的最後一個活動，因此也是團隊中任何人驗證需求的最後機會。此外，測試人員的專長在於發現有問題的可交付成果。

我瞭解一些讓測試人員陷入不合理假設的根本原因。這些原因是：害怕被人評判他們提出正確問題的能力，對他們以前的問題沒有得到適當的答覆，溝通能力差，使他們無法抓住任何機會，缺乏一個安全的環境來公開挑戰接受標準，或者在積壓工作改進會議期間無知，不提出問題需要澄清的問題。

在敏捷專案中，假設的成本太高了，因為產品增量很快就會推出給最終客戶——交付的任何缺陷都會影響投資回報（ROI），並需要返工，消耗的預算超過了功能的價值。

迭代經理、ScrumMaster 或教練使用諸如 5 個為什麼之類的技術對這些根本原因進行徹底的分析，對於設計有效的指導計劃和在隨後的迭代中控制這些行為非常有益。