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

 

　　由於一直從事web產品的測試，個人觀點並不必定適合全部的類型項目。

 

　　工做已將近三年了，雖然這三個年頭裏我都在積極的學習着與測試相關的技術；可是能沉澱的東西不多。相信測試同窗都有相似的感受。

 

 

不要爲了測試而測試

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

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

 　  固然了，若是你辦的是「中國音樂家鋼琴協會」，你有責任要求會員達到國際超一流水平，爲國家和我的贏得榮譽。

 

　　有時候不要爲了測試去測試，或爲了體現本身的價值去作一些對整個項目貢獻不大的事兒。固然，我在這裏不是讓測試人員放棄本身的原則。要知道不論是產品、開發、測試都是圍繞着產品的發展貢獻。

　　爲貢獻產品的發展測試遠比爲了測試了測試所帶來的價值大得多；因此站在產品的發展上去看待測試工做更能體現本身的價值。

 

 

記得去年的總結再討論本身對流程的理解。隨着工做年齡的加長對這些問題也有進一步的見解；因此，再拿來炒一炒，但願能炒出新的味道。

 

 

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

 

　　去年的一篇說軟件測試流程，嚴格規範的測試流程必定比沒流程好，敏捷的流程必定比傳統的瀑布流程先進。這個觀點沒有大的錯誤，可是咱們忽略了所作有產品這個「對象」；忽略了產品的特色與階段。

 

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

　　例如一個各類功能已經成熟的項目，有着龐大的用戶羣，以維護爲主的更新，它的版本功能的上線必需要創建嚴格的發佈流程，通過充分的測試才能上線；用戶羣越大，暴露的問題越多，問題帶來的影響也會越大。

　　一樣是一個web產品，筆者目前所作的項目流程徹底不是這樣；咱們的發佈流程很簡單，測試流程也很簡單，不去寫的規範又複雜的測試用例，放棄了使用缺陷管理工具來反饋問題；

　　溝通變得尤其重要；我不否定這樣作會給產品帶來了必定的風險；對於嚴重的問題，咱們能夠經過快速的版本回滾，對於輕微的問題，咱們很快會在下個版本迭代中修復。是否是有點敏捷的味道在裏面。

　　爲何會這樣？由於這個產品屬於前期開發階段，不少功能還沒上線。整個團隊都在貢獻着產品的發展；須要快速的將需求轉化成功能給用戶使用。

因此，沒有最好的開發測試流程，只有最適合項目與階段的開發測試的流程；

 

 

產品質量與用戶容忍度

 

　　以前看過很多人討論到底需不須要測試人員；我想說測試人員N年後不論是被重視了仍是被淘汰了「測試的行爲」永遠不會消失；由於沒有質量的產品基本上等於沒有價值（也就是說沒存在的意義），至於對產品質量的要求是由用戶容忍度決定的。

　　Facebook 沒有測試人員！可是測試行爲一直都在。開發找需求，開發、自測、發佈，得到用戶反饋，決定功能下線仍是上新的功能---至關於一條龍的服務。由於用戶的容忍度容許他這麼作。

　　微軟不能這麼幹，修復一個windows 的bug成本很高，並且用戶是花錢買的，也許用戶是用來創造價值的（辦室、存儲、管理），也許一個文件丟失，系統崩潰會給用戶帶來巨大損失；因此，微軟須要不少的測試員。

　　拿修復成本與用戶容忍度作標準，web產品優於客戶端產品；在web產品中也要分行業；用戶對銀行系統、火車票、購物網站的容忍度顯然要低一些，反過來講也就是對產品的質量要求更高，由於與錢掛鉤。就算同一個產品，會員與免費用戶的容忍度也是不同的；由於會員用戶有權獲得更好質量與服務。

 

因此，關注分析用戶的容忍度的測試纔不會把本身變得格格不入。

 

 

提高本身的貢獻

 

　　前面的東西貌似都在「弱化」測試存在的價值；俺原本就不被重視，因此俺就須要更加認真和努力找問題來提高本身存在的價值，你如今說，有些產品不須要太指着的去測試；那你說俺還能幹啥？

　　當咱們把測試當作是爲開發和產品服務時，也許狀況會徹底不同。咱們能夠提供哪些服務？

 

• 用測試發現產品的不能夠測試性

　　前面已經提到隊團不論是否有測試人員，但測試行爲必定會存在；若是一個產品都不可測試，如何去發現並修復bug ，如何去維護與擴展？尤爲對於web產品來說，不可維護與擴展的產品無疑是致命的。（能夠經過項目重構再解決）

 

• 創建產品質量的評估方法

　　爲項目團隊提供每一個版本的bug趨勢分析數據，讓項目中的每一個人都瞭解項目當前的狀態

　　經過分析bug數據來創建或完善各類Checklist，幫助項目團隊更好的完成需求評審、設計評審以及代碼評審，減小bug出現的機會。同時，能夠按期將多個項目的Checklist進行合併，使單個項目的經驗能夠經過Test Team快速的流動起來，及時的做用於其餘項目

　　主動爲Architect Team提供每一個項目的性能測試數據，幫助他們獲取更多的實際項目信息，減小踏入「陷阱」的概率

 

• 創建可持續運行的測試框架

 創建自動化測試測試框架；

構建持續集成，使版本的迭代與更新獲得快速的反饋。

 

• 創建關注開發質量的開發文化

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

 

• 貢獻產品發展

　　舊病成醫，測試的產品多了天然會對產品有本身的理解，產品的定位，用戶習慣與體驗； 能夠從測試的角度貢獻產品的發展。（這個由產品的特色，公司文化決定）

 

 ----------------------------------

談軟件測試---一年測試工做總結

軟件測試流程進階----兩年軟件測試總結