你不需要測試人員嗎?
我曾經和來自不同開發機構的人探討過關于他們如何管理軟件開發，如何組織，他們遵循什么樣的開發實踐，以及什么樣的開發實踐真正有效。工作在小團隊的大部分人都沒有人手幫他們測試程序，因為測試人員們不是真正開發軟件的人，所以通常覺得他們是多余的。這就意味著程序員許要自己測試他們的軟件 – 或者用戶來測試。
敏捷團隊中的測試人員能做什么？
很少敏捷團隊會覺得需要測試人員。測試人員被看作是瀑布時代的產物（需求、設計、編碼、測試）。在XP團隊，每個人都是程序員，每個程序員都要負責測試自己的代碼，寫自動的單元測試，使得用戶需要的驗收測試自動化。Scrum根本沒有定義測試要做什么 – 團隊會最終找到解決方案，因為他們會檢閱自己并調整自己，以獲得最佳的實踐。
如果程序員已經測試了他們的代碼（也通過結隊的方式進行了代碼審查），那么他們需要測試人員做什么呢？
Janet Gregory和 Lisa Crispin寫了一本書來說明敏捷團隊中測試人員的作用，它向程序員和測試人員說明測試人員是如何配合敏捷開發的，但這仍然沒有改變大多數團隊的看法，尤其在“工程驅動的文化”（程序員創立的創業團隊）中更是如此。
他們的論點是敏捷團隊的步伐相對于測試人員來說太快了，黑盒測試人員們僅僅通過寫測試計劃，通過手動的測試代碼來測試，或許要不斷的更新他們的質量中心或Selenium UI回歸測試，這些都不可能追得上在短時間內就要發布新功能的團隊的進度。如果測試人員不會用Fitness或Cucumber寫驗收測試，或者沒有足夠的業務知識幫助填補客戶/產品擁有者的空當，不能回答程序員的問題的話，那么他們又有什么優勢呢？
這個問題在持續開發中更為顯著，一些公司如IMVU和Facebook，使得某種編程實踐變得流行起來，他們查看自己的工作，寫自動測試用例，查看代碼看看測試是否通過了，更新都是很快的，然后自動發布到在線系統中去。
讓用戶來測試你的代碼
一些公司把持續開發看作是“眾包”(crowdsource)他們測試的機會 – 讓他們的客戶來為他們測試。這實際上很有競爭力。然而也很難用這種方法寫出可靠安全的軟件 – 可能也是不可能的。針對持續發布給用戶的系統的質量問題，James Bach有一篇批評的文章，是關于他們花了20分鐘時間去測試一個持續部署的程序，就發現在很短的時間內就發現了問題。
有一些持續部署的公司更小心些，他們按照Etsy/Flickr的做法，在晚上上線：持續的發布更新，但是在用戶量很大之前就進行了測試，他們還會密切關注結果。
然而，很重要的一點是用戶只能測試某些功能，事實上，也只有用戶可以測試它們：一個功能是不是有用，一個功能是不是可用的，他們需要什么信息才能正確的完成一個任務，工作流程應該如何優化。這才是對比測試所應該達到的效果 – 通過實驗不同的想法，功能和工作流程，收集數據，然后找到用戶最喜歡什么，以及他們不喜歡什么。去嘗試不同的方法，并獲得反饋。
但是你不會問你的客戶他們是否測試完畢了，代碼是否有效，系統是否穩定安全，負載大的情況下是否正常工作。
你需要從測試團隊中獲得什么？
就算是最好的，最負責的，最有經驗的程序員都會犯錯。在我們公司，每個人經驗都很豐富，其中有些人工作了10-15年以上了。他們很仔細的測試代碼，每次check-in之后都會更新自動測試用例。在持續集成過程中這些測試都會運行 – 我們非常依賴于這些測試(現在已經有成千上萬的測試用例了，并有較高的覆蓋率)，靜態分析的缺陷核查，以及安全核查工具來對付基本的代碼錯誤。所有的更改都會讓另外一個高級的程序員來核查，從來沒有過例外。
但就算有好的方法和工具，優秀的程序員還是會犯錯：一些細微的問題（不一致，界面問題，數據轉換和建立問題，沒有編輯等問題）以及一些基礎的問題 (負載下的運行失敗，同步問題，缺少需求，規則錯誤，異常處理中的錯誤)。我想確保在用戶發現錯誤之前發現大部分（盡管不是全部）的錯誤。程序員也是。
這也就是測試團隊起作用的地方了。我們擁有一個小的，但是經驗豐富的，有特別專長的測試團隊。一個測試人員專注于驗收測試，驗證功能需求，可用性，以及業務工作流程。另一個測試人員專注于功能的回歸測試以及業務規則的正確性和覆蓋率，找到程序員測試用例中的規則漏洞，并在API層讓集成測試自動化。還有個測試人員主要做操作測試，壓力測試，以及soak test來找到峰值和垃圾回收的問題，破壞測試 – 盡可能的破壞系統。當其中一個人不在的時候，他們也知道如何擔負他人的職責，但他們有自己獨特的專長和技能，以及自己的解決問題的方法。
當我們初次建立系統的時候，我們有一個更大的測試團隊，主要通過寫測試計劃，詳盡的手工測試核查表，在UI層編寫自動的回歸測試，來測試覆蓋率和可靠性。但用這種方法浪費了許多時間。
現在我們更依賴于程序員針對功能覆蓋率和回歸保護自己編寫的自動測試用例。我們的測試團隊將精力更多的放在探索性的功能以及操作，基于風險和以用戶為中心的測試中去了，以找到最重要的缺陷，發掘系統的弱點。我們都喜歡這種方法，因為我們在測試中找到了真正的重要的缺陷，那些躲得過代碼審查和單元測試的缺陷。
當程序員作了更改后，測試人員馬上測試更改。他們和程序員一起結隊去測試新功能，和程序員一起運行模擬來找出運行錯誤，競態條件(race condition)以及現實世界中的時間相關的問題和工作流程問題。他們摧毀系統以確保錯誤探測和錯誤恢復機制是成功的。他們測試安全功能，和顧問一起搭建和管理測試。他們也和操作人員一起，和新用戶以及新部門處理集成檢查。他們和團隊的其他人員一起以非常快的速度，每兩周就發布到在線系統（有時更頻繁）。
測試團隊也會負責軟件的發布。他們將每個發布都集中在一起，查看依賴，決定發布什么時候進行，什么將會發布，什么不會發布，他們會核對我們是否完成了整個團隊同意去做的更改，他們會測試過去的測試用例還有數據轉換測試，最后和操作人員一起發布到在線系統中去。
他們沒有讓整個團隊的進度慢下來，他們也沒有阻礙我們發布軟件。他們確保了軟件上線的時候正常工作。
測試人員找到更多的缺陷
我為高可靠性，高集成性的業務工作了很久，沒有測試人員是不可取的 – 犯錯的代價太高了。我不認為你可以創建真正的軟件，而不需要人來測試它。除非你是在創業的早期，還處于概念的迸發期，或者你只有一個小團隊，僅僅為內部使用而寫的軟件(可能你也沒堵到這篇文章)，否則你需要人來為你測試系統以確保系統是正常運行的。
不管你如何工作，不管你用什么方法 – 敏捷開發還是瀑布開發方法，都改變不了需要測試人員的事實。如果你推進得太快了，測試人員需要加快步伐，以適應能夠獲取信息的方式。好的測試人員可以做到的。
我就算再蠢也不會認為測試團隊能找到所有的缺陷——雖然這是他們的工作。當然，我希望測試人員會在客戶發現之前找到明顯的錯誤。
我需要為他們做的也正好幫自己回答了一些重要的問題：我是否可以發布了？有什么還是粗糙的或者不穩定的或者不完善的？什么需要遲些發布？什么需要更進一步審查或者重寫？設計中什么地方很薄弱？什么地方沒有自動測試用例？哪里需要更好的測試工具？什么功能難以理解或不一致或者很難搭建？什么消息漏掉了，或者容易誤導人的？我們是否做太多了，做太快了？我們是否需要更改設計，代碼，還是設計或編碼的方式，以使得系統更好用，更可靠？
| 測試不能提供所有的信息，但能提供一部分。好的測試可以提供許多有用的信息。——James Bach (Satisfice) |
沒有測試人員，你不僅發布了一些你本來應該沒有錯誤的代碼，你也失去了一些重要的信息，譬如你的軟件真的那么好嗎，例如你可以做什么讓它更好。如果你想構建好的軟件，那么現在你的機會來了。
