作者 覃其慧 發布于 2009年3月2日 上午12時30分

我——作為一名測試人員——有一個與眾不同的習慣：每當要加入一個新項目的時候，我總會找到項目中的同伴，真誠而親切地說：“為了更好地合作，我有5個約定，希望大家能盡量遵守”。

約定1. 業務分析師們，我們其實是同一個角色的兩種面孔，請叫上我們參加客戶需求會議

我們的團隊需要讓客戶頻繁的得到可用的軟件，客戶的不斷反饋會給軟件的未來做出最正確的方向指引。

如果我們交付的軟件有很多質量的問題，存在大量的缺陷，客戶會被這些缺陷的奇怪行為干擾，沒有辦法把注意力放在軟件本身的價值是否符合他們的真正需求上， 不能給出最有價值的反饋。所以，我們只有頻繁的做測試，在每次交付之前都把質量問題找出來告訴我們的團隊，問題才能及時的得到改正。

而我堅信“prevention is better than cure”（預防勝于治療），我會要把工作的重點放在預防缺陷上，這樣可以節省Dev們很多修復缺陷的時間與精力。

為了達到這個目的，我需要跟你一起參加客戶需求會議，盡早的了解客戶需求與使用軟件的慣常行為。那么在你完成需求的驗收條件的定義的時候，我也基本完成了測試用例的準備。

我們可以趕在開發人員們寫代碼之前就告訴他們我要測什么，讓他們減少因為過于樂觀而漏掉的一些重要的有破壞性的情況，減少缺陷的發生。這是我測試的一項重要任務。

如果你們在大部分需求都整理好了再交給我們，我會浪費掉等待的時間。更重要的是，開發好的軟件里面已經有很多本來可以不存在的缺陷在里面了，開發人員們可能需要加班加點來保證在項目最終交付時間之前把它們改好。這樣很容易產生新的缺陷的。

所以，請讓我盡早了解需求，請不要讓我到項目后期才能開始測試。

約定2. 開發人員們，雖然你們是編寫自動化測試的專家，但請聽聽我們意見

我知道，對于你們，自動化測試不過是利用junit, rspec, selenium，watir，uiautomation等等寫出的“另一段程序”而已。而對于80%的QA來說，編寫自動化測試并不是一件簡單的事情。

不過我仍然相信，有測試人員介入的自動化測試更有價值。

你們用單元測試，集成測試來保證代碼的質量。然而你們的這些日常測試離代碼更近，離最終用戶還點遠。很多測試都不是在測軟件功能。

你們可以把功能測試寫的又快又多，而我們可以指出什么功能測試最有必要加到自動化測試中。

你們平時大部分精力都在編碼上，沒有太多時間去查都有什么缺陷。而我們可以指出什么地方缺陷可能會出現的比較頻繁，建議在這些脆弱的地方加自動化測試。

所以請聽聽我們的意見，我們可以給你們提供這些信息。

約定3. 項目經理們，請不要要求我們測試軟件的所有路徑

軟件測試是一個永無止盡的任務。基本上沒有什么軟件簡單到我們能夠嘗試完它的每一個可能的路徑的。就連一個看似簡單的微軟計算器都有無窮盡的路徑，無止盡的輸入，更何況比這個更復雜的商用軟件。

如果你們擔心沒有嘗試過全部的路徑不可靠，疑惑我們怎么敢說這個軟件質量是好的還是壞，都有什么風險。請你們先注意，我們是跟業務分析師一樣，都了解軟件的價值的。價值可以幫我們做出判斷，什么時候可以停止測試并對客戶說我們的軟件已經滿足您的要求了，請放心使用。

因為我們了解價值，我們可以肯定的說哪些軟件的使用方式是至關重要的，哪些是不太可能出現的。我們會在全面測試了軟件以后，把主要精力放在價值高的功能點上。合理的利用項目有限的時間。

因為我們了解價值，我們可以正確的把發現的問題分類。我們可以幫助dev們把精力放在重要的缺陷上，避免把時間放在對于客戶微不足道卻不得不花費大量精力才能修正的問題上。

所以，請不要要求我們無止盡的測試一個軟件。我們了解價值，請相信我們的判斷。

約定4. 迭代經理們，如果對于交付風險有任何疑問，請來詢問我

BA和Dev們都是關注一個軟件在什么情況是可以良好的工作。而我們除了驗證這些情況以外，大量的時候都用在尋找什么樣的情況軟件不能正常的運行。所以除 了針對定義好的軟件行為進行測試，我們還會做很多探索性測試。我們通常可以通過這樣的測試發現一些沒有定義的、不曾預期的行為。這些行為往往將會構成軟件 交付的風險。

我們會告訴你們現在都發生了什么問題，分別分布在哪里。

我們會告訴你們，在什么情況下軟件可能會有異常行為，是不是會牽連到其他的部分，是否可以繞過去。

我們會告訴你們，哪些部分功能比較不穩定，需要更多的留意。

約定5. 測試人員們，那些敏捷實踐對于我們也是有用的。

結對不是dev們的專利。我不希望總見到你們獨自坐在自己的位置上冥思苦想。走出去，跟其他隊友多多交流！

多跟測試隊友交流，pair看看設計的測試用例是不是夠全面，獨自一個人想到的未必足夠好。他們會給你誠懇的意見的。對他們，也請一樣認真對待。

如果你發現開發人員們做出的架構決定使測試工作變得更困難。那么請大聲地告訴他們，design for testability（提高你們設計的可測性）。

如果你發現業務分析師寫的需求無法驗證，定義的客戶行為不夠具體，一個用戶故事中包含太多了功能點，等等，那么也請大聲地告訴他，INVEST（獨立，可協商，價值，可估算，短小，可測）。

也請你們多跟開發人員結對寫自動化測試，既可以幫助你們學習怎樣更好的編寫自動化測試，也能幫助開發人員們結對更多的了解用戶行為。

這就是我的五個約定，它們是我在團隊中順利展開工作的基礎。