我和敏捷團隊的五個約定

agile_boy發表於2009-03-10
敏捷
      我——作為一名測試人員——有一個與眾不同的習慣：每當要加入一個新專案的時候，我總會找到專案中的同伴，真誠而親切地說：“為了更好地合作，我有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（獨立，可協商，價值，可估算，短小，可測）。

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

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566568/，如需轉載，請註明出處，否則將追究法律責任。

相關文章