測試工程師在敏捷項目中扮演什麽角色？
本篇目錄
爲了在敏捷項目中取得成功，測試人員應該關注以下實踐：
1.態度勝過一切
團隊中的測試人員可能不具備敏捷背景、自動化技能或豐富的測試經驗——只要他們具備成爲敏捷團隊一員的正確態度，這仍然是可以的。正確的態度會反映在以下行爲中，比如：相信敏捷宣言和實踐，信任教練並全力以赴地遵循它，對新的學習和變化持開放態度，清晰表達和透明，致力于對團隊重要的活動，在這段時間內主動改進和變得更好等等。
根據既往經驗，在工作中使用僵化思維的測試人員減慢了叠代的進度。有些行爲是——僅在ALM工具中更新狀態時才測試缺陷；在測試環境關閉時，閑置而不在本地主機上執行健全性測試；考慮在會議期間單獨測試活動；在部署時堅持團隊成員的正式溝通，阻止決議和暗示等。
2.將叠代目標優先于外部分配
在矩阵式组织结构中，测试人员在敏捷团队中与Scrum Master一起工作，但他们向测试实践部门的直线经理或同一项目中的测试经理报告。这些在敏捷团队中驱动整体测试的测试经理，可能会给测试人员分配许多与团队迭代计划不一致的特别任务。在與測試人員的多次接觸中，我發現他們很難在兩方面之間取得平衡——兼顧績效評估和致力于工作。他們中的大多數人都試圖在沒有通知敏捷團隊的情況下承擔外部任務，因爲他們不想讓直屬領導不高興。一些人知道它會影響正在進行的叠代活動，于是通過延長工作時間即加班來完成這些任務，但也有很多人犧牲了叠代活動。由于這種妥協，他們無法交付叠代目標，這導致了用戶故事的常規溢出，也影響了團隊的信任和內聚水平。
在這種情況下，測試人員應該怎麽做？答案是——叠代活動應該總是優先于任何其他活動。但是，如果他們能夠在不影響叠代目標的情況下完成外部任務，那麽他們就可以繼續！但是，如果外部任務有可能影響叠代目標，那麽他們應該咨詢團隊以獲得集體同意或意見分歧，並將決策告知直屬經理。
3.跨職能團隊中的關系平等
“我不能測試這個用戶故事，因爲開發人員沒有部署它”，一個測試人員在每日站會中說，開發人員回答說：“抱歉，我忘了它，但你也應該聯系其他開發人員來完成。”。這個場景突出了團隊缺乏協作和所有權。推動一個用戶故事的完成並消除間歇的阻礙因素並不是個人的責任，而是團隊的努力，作爲團隊一部分的測試人員也不例外。測試人員的某些行爲有助于加快交付速度——無論是否與測試相關，都需要關注到阻礙因素；經常與開發人員同步，而不是通過電子郵件溝通；積極參加scrum會議以提高團隊的決策能力，與團隊的計劃保持一致，從而使他們的活動保持一致等等。
一些與其他團隊過度交往的測試人員更喜歡挑選低優先級的任務。因爲他們需要花費數小時來解決其他團隊的問題，卻以犧牲自己的工作爲代價——這種行爲超出了在跨職能團隊中作爲平等夥伴的邊緣。團隊成員應該優先解決他們的問題，如果需要的話，爲其他團隊提供幫助應該是次要的目標。
4.假設並不是一種選擇
有時，利益相關者的評審意見顯示，團隊在驗收標准方面存在一些不必要的假設。假設不是特定的對測試人員的選擇，因爲測試是工作流中的最後一個活動，因此也是團隊中任何人驗證需求的最後機會。此外，測試人員的專長在于發現有問題的可交付成果。我了解一些讓測試人員陷入不合理假設的根本原因。這些原因是：害怕被人評判他們提出正確問題的能力，對他們以前的問題沒有得到適當的答複，溝通能力差，使他們無法抓住任何機會，缺乏一個安全的環境來公開挑戰接受標准，或者在積壓工作改進會議期間無知，不提出問題需要澄清的問題。
在敏捷项目中，假设的成本太高了，因为産品增量很快就会推出给最终客户——交付的任何缺陷都会影响投资回报（ROI），并需要返工，消耗的预算超过了功能的价值。
迭代经理、Scrum Master或教练使用诸如5个为什么之类的技术对这些根本原因进行彻底的分析，对于设计有效的指导计划和在随后的迭代中控制这些行为非常有益。
作者：陳琦，資深敏捷測試顧問，作爲國內知名項目管理軟件—— 禅道的團隊成員，主要負責開源自動化測試管理框架——ZTF的開發工作。擁有十多年的敏捷過程實踐經驗，現致力于測試自動化和DevOps相關領域的實踐和研究。
