經營成功的測試職業生涯 ---(James A. Whittaker)(3)

　　來自測試的信息意味著你必須關注在測試時所做的一切，并使用獲得的信息來影響今后的測試。你是否知道你的測試是如何與需求結合的，知道何時某一特定需求已經得到足夠的測試?你是否使用代碼覆蓋率來影響未來的測試?你知道當代碼更新或缺陷修復時那些測試會受到影響，還是知識重新運行所有的測試?理解測試進行到什么程度并隨著測試調整測試策略，這是測試成熟的標志。

　　我以前曾在微軟的Visual Studio的一個小組工作過，我們大量使用代碼改動量(由于添加新特性或修復缺陷而改變的代碼)和代碼覆蓋來影響我們的測試。我們花了很大的力氣將代碼覆蓋和代碼改動量通知測試人員，幫助他們理解哪些測試用例對覆蓋率有貢獻，幫助他們測試改動過的或修改過的組件。最終的結果是在代碼確實被改動時，我們清楚地知道哪些測試會被影響而只重新運行那些測試。我們還知道每個新的測試用例是如何對總體的接口，特性和代碼覆蓋率產生作用的，從而指導我們的測試人員，讓團隊中的每個人在他們所創建的所有測試用例基礎上，寫出更有意義的測試。

　　你用哪些信息來指導你的測試?你如何保證信息是可獲取的，以便在測試中隨時可以得到?你如何使得信息變得有用，以便它能以良好的方式影響你的測試?這些問題的答案將決定你在走下專家測試山峰時的前進速度。

　　下山

　　到達測試山峰的頂峰的時候，你已經成為一個十分能干的測試人員了，能力也許相當于你組里所有同事能力的總和。無論你在做什么，請不要試圖做得比你的整個團隊都好，不管你對此感覺有多好，或是你的老板對你遏得有多緊。一旦你走在下坡的路上，就不要再去爭取“找到最多缺陷的人”或是“找到最有意義缺陷的人”這樣的榮譽頭銜。反而我推薦你減少花在測試上的時間，而把創新作為你的首要任務。

　　在測試上創新指不急于向前，而是仔細觀察、洞察先機、找到瓶頸并改進團隊中所有其他人的工作方式。你的工作變為幫助其他人進步。在微軟，我們有一個專門為此而設的正式職位——測試架構師。不過，不要因為缺少一個很酷的頭銜而讓你沮喪。無論別人怎么稱呼你，當你在“下坡的路上，你能做的最好的事就是盡量保證更多的人能成功地爬上山峰的另一側。

原文轉自：http://www.anti-gravitydesign.com