談軟體測試人員定位---三年軟體測試總結

　　因為一直從事web産品的測試，我的觀點并不一定适合所有的類型項目。

　　工作已将近三年了，雖然這三個年頭裡我都在積極的學習着與測試相關的技術；但是能沉澱的東西很少。相信測試同學都有類似的感覺。

不要為了測試而測試

　　前幾天做了一個測試的ppt ，就是講項目中要用到的測試技術，總結了半天其實實際的産品中沒什麼技術，熟悉需求，轉化成用例，待項目上線後驗證功能就ok 了；對一個自身品質要求不高的項目，我們有時候為了展現自己價值，非要在一些不痛不養的問題上揪着不放。

　　舉個不恰當例子，某鋼琴高手開了一個補習班教鋼琴，家長送來一孩子目的隻是讓孩子學學鋼琴；鋼琴高手為了體驗自己的價值（牛b），硬是按照貝多芬的标準去培養，孩子彈不會《xx交響曲》不讓孩子走。先不說孩子有沒有貝多芬的鋼琴天資，也許孩子壓根就不想成為貝多芬。

 　  當然了，如果你辦的是“中國音樂家鋼琴協會”，你有責任要求會員達到國際超一流水準，為國家和個人赢得榮譽。

　　有時候不要為了測試去測試，或為了展現自己的價值去做一些對整個項目貢獻不大的事兒。當然，我在這裡不是讓測試人員放棄自己的原則。要知道不管是産品、開發、測試都是圍繞着産品的發展貢獻。

　　為貢獻産品的發展測試遠比為了測試了測試所帶來的價值大得多；是以站在産品的發展上去看待測試工作更能展現自己的價值。

記得去年的總結再讨論自己對流程的了解。随着工作年齡的加長對這些問題也有進一步的看法；是以，再拿來炒一炒，希望能炒出新的味道。

沒有最好的開發測試流程，隻有最适合項目的開發測試的流程；

　　去年的一篇說軟體測試流程，嚴格規範的測試流程一定比沒流程好，靈活的流程一定比傳統的瀑布流程先進。這個觀點沒有大的錯誤，但是我們忽略了所做有産品這個“對象”；忽略了産品的特點與階段。

　　例如兩三個開發合夥開發一個項目（或産品），這時你讓他們建立一套規範的流程，按流程實施，顯然是不現實，我想擺在他們面前最主要的問題是，如何快速的把客戶需要的功能開發出來換成money ，維持生計以及公司運作。

　　例如一個各種功能已經成熟的項目，有着龐大的使用者群，以維護為主的更新，它的版本功能的上線必須要建立嚴格的釋出流程，經過充分的測試才能上線；使用者群越大，暴露的問題越多，問題帶來的影響也會越大。

　　同樣是一個web産品，筆者目前所做的項目流程完全不是這樣；我們的釋出流程很簡單，測試流程也很簡單，不去寫的規範又複雜的測試用例，放棄了使用缺陷管理工具來回報問題；

　　溝通變得尤為重要；我不否認這樣做會給産品帶來了一定的風險；對于嚴重的問題，我們可以通過快速的版本復原，對于輕微的問題，我們很快會在下個版本疊代中修複。是不是有點靈活的味道在裡面。

　　為什麼會這樣？因為這個産品屬于前期開發階段，很多功能還沒上線。整個團隊都在貢獻着産品的發展；需要快速的将需求轉化成功能給使用者使用。

是以，沒有最好的開發測試流程，隻有最适合項目與階段的開發測試的流程；

産品品質與使用者容忍度

　　之前看過不少人讨論到底需不需要測試人員；我想說測試人員n年後不管是被重視了還是被淘汰了“測試的行為”永遠不會消失；因為沒有品質的産品基本上等于沒有價值（也就是說沒存在的意義），至于對産品品質的要求是由使用者容忍度決定的。

　　facebook 沒有測試人員！但是測試行為一直都在。開發找需求，開發、自測、釋出，獲得使用者回報，決定功能下線還是上新的功能---相當于一條龍的服務。因為使用者的容忍度允許他這麼做。

　　微軟不能這麼幹，修複一個windows 的bug成本很高，而且使用者是花錢買的，也許使用者是用來創造價值的（辦室、存儲、管理），也許一個檔案丢失，系統崩潰會給使用者帶來巨大損失；是以，微軟需要很多的測試員。

　　拿修複成本與使用者容忍度做标準，web産品優于用戶端

産品；在web産品中也要分行業；使用者對銀行系統、火車票、購物網站的容忍度顯然要低一些，反過來說也就是對産品的品質要求更高，因為與錢挂鈎。就算同一

個産品，會員與免費使用者的容忍度也是不一樣的；因為會員使用者有權得到更好品質與服務。

是以，關注分析使用者的容忍度的測試才不會把自己變得格格不入。

提升自己的貢獻

　　前面的東西貌似都在“弱化”測試存在的價值；俺本來就不被重視，是以俺就需要更加認真和努力找問題來提升自己存在的價值，你現在說，有些産品不需要太指着的去測試；那你說俺還能幹啥？

　　當我們把測試看成是為開發和産品服務時，也許情況會完全不一樣。我們可以提供哪些服務？

用測試發現産品的不可以測試性

　　前面已經提到隊團不管是否有測試人員，但測試行為一定會存在；如果一個産品都不可測試，如何去發現并修複bug ，如何去維護與擴充？尤其對于web産品來講，不可維護與擴充的産品無疑是緻命的。（可以通過項目重構再解決）

建立産品品質的評估方法

　　為項目團隊提供每個版本的bug趨勢分析資料，讓項目中的每個人都了解項目目前的狀态

　　通過分析bug資料來建立或完善各種checklist，幫助項目團隊更好的完成需求評審、設計評審以及代碼評審，減少bug出現的機會。同時，可以定期将多個項目的checklist進行合并，使單個項目的經驗可以通過test team快速的流動起來，及時的作用于其他項目

　　主動為architect team提供每個項目的性能測試資料，幫助他們擷取更多的實際項目資訊，減少踏入“陷阱”的幾率

建立可持續運作的測試架構

 建立自動化測試測試架構；

建構持續內建，使版本的疊代與更新得到快速的回報。

建立關注開發品質的開發文化

沒有測試人員自測節省人力的了，尤其在單元測試層面。産品的品質應該由開發與測試共同承擔。（現實中的責任到人，讓團隊很難形成這種文化）

貢獻産品發展

　　舊病成醫，測試的産品多了自然會對産品有自己的了解，産品的定位，使用者習慣與體驗； 可以從測試的角度貢獻産品的發展。（這個由産品的特點，公司文化決定）