軟件測試作為一個工作有很多的價值，因為大家的工作內容都會包含很多東西，而且對產品和項目都是有價值，這里只說說和測試直接相關的所謂的核心的價值吧。我把它人為的分為了三個層次。

　　第一個層次：職位本身帶來的價值。

　　這個有點類似于工廠里的QC， 需要有專人來做檢驗的工作，這種價值和設立這個專門的職位有關。像很多職業(yè)的分工，一旦設立了這個專門的職位，這個職位上的人需要按照設定的要求去驅動某些事情會被做到，對測試而言是產品在出去之前會被檢驗到，對項目經理而言是會按照計劃來驅動項目往前走。的來講是不需要通過這樣的職位設定來驅動某些事情被落實的，因為開發(fā)人員也可以自測，產品集成好了之后也可以從用戶的角度來完整的測試，但是實際上如果沒有這樣的分工和專職的安排，很多事情不會真的被做。還是那上面提到的項目經理來舉例，理論上產品的開發(fā)者應該也可以按照幾乎把事情做了，為什么要一個專職的人來把握項目的進度了(當然項目經理還要做很多別的事情)。

　　從這個角度，這有點像是通過分工來確保落實。而且因為設立了這樣的專職的工作，那么自然有job responsibility，需要對質量負責，而因為有這樣的要求，測試人員會跳出來報出問題，提出不同的意見。一個是制度上的安排，一個是心理上的。反過來可以設想一下，如果在一個正式的商業(yè)產品中，沒有測試人員或者類似的工種，很多時候對質量的要求會流于形式，質量很容易被進度的壓力compromise掉，而且因為測得夠不夠本身是個很模糊的概念，大家可能簡單用一用覺得沒有問題出去了。

　　上面提到的其實是一個很基本的層次，有而且做了而已，至于做得怎么樣，那是另一回事。

　　第二個層次：做得更專業(yè)，更好。

　　這里換一個例子，拿做飯為例，好的酒店里的廚師和那些只在家里做做飯的人區(qū)別是什么。當然，這里說的是通常的情況，個別另類除外。如果按照上面的層次，兩者都能做出還可以的能吃的飯，可以達到這個工作的基本的要求。但是如果只停留在家庭主廚的要求，不會有專業(yè)的廚師這個職業(yè)，還有什么幾級認證之類的。那么專業(yè)的廚師的更進一步的價值在哪里?我想簡單來說大概是做得更專業(yè)，更好吧。

　　同樣，對于測試這個職業(yè)，也是一樣，如果只是把功能都用到了，發(fā)現(xiàn)了bug，那和普通的用戶有什么區(qū)別呢?

　　那什么是更專業(yè)，更好呢?我想用兩個詞來概括，效果和效率。

　　先說效果，下面列了兩個方面：

　　a. 發(fā)現(xiàn)更多的bug，而且很多是簡單用用無法發(fā)現(xiàn)的bug，甚至非常難以發(fā)現(xiàn)的bug。這也好比專業(yè)勘探和去山里玩的驢友，驢友可以發(fā)現(xiàn)奇怪有趣的露在外面的石頭，而專業(yè)的勘探人員能找出埋在地下的有價值的東西。

　　b. 有些測試需要專業(yè)的技能，比如性能測試，穩(wěn)定性測試，安全性測試等需要專業(yè)的技能和工具。

　　對于這類測試，普通用戶是難以發(fā)現(xiàn)的，因為等他們發(fā)現(xiàn)那不是找到bug，而是不幸遭遇到bug。這一部分是非常體現(xiàn)測試人員的技術和專業(yè)能力的地方，有很多地方值得深入的研究。

　　再說說效率，這個放在后面并不表示沒有效果重要。很多時候我們的思考和努力都花在這上面，在現(xiàn)在這個對軟件和服務的推出速度要求越來越高的年代，效率有時候顯得更加重要。因為根據(jù)二八原則，很多時候大家寧愿花20%的時間發(fā)現(xiàn)80%的bug，然后以beta的名義把產品推出去，然后再來改進，因為畢竟大部分的軟件產品，特別是需要嚴格測試的產品都是有商業(yè)價值的，而time to market是一個很重要的因素。

　　所以從這個角度來講，對一個專業(yè)的測試人員的要求還包括更快的發(fā)現(xiàn)問題。這個可能是對工具和能力的要求，也有對測試方法和流程的要求，比如自動化測試，敏捷測試等等。舉個例子來說，好比大家可以在家里做手工，但是如果超市里賣的日常生活用品用這個效率做出來估計沒有什么商業(yè)競爭力，不是嗎?

　　呵呵，說了這么多，突然想到其實意思簡單的是，專業(yè)的是要把事情做得又快又好。

　　如果能做到上面的兩個層次，基本上已經是一個的測試人員了，但是如果只是有這些顯然不夠，總要有些別的追求嘛。

　　現(xiàn)在說說我理解的第三個層次，那是：提高整體產品的quality。

　　為什么這么說呢，因為的兩層都是在找bug，這樣有兩個問題，一是事后才發(fā)現(xiàn)，二是很多東西已經晚了，甚至沒法修補。

　　發(fā)現(xiàn)bug是一個事后的過程，是在代碼已經寫好了之后去測試，發(fā)現(xiàn)了問題需要修改原來的代碼，其實可以做得更好。

　　a. 將發(fā)現(xiàn)bug變得更早，在單元測試(有時是developer來做)的時候發(fā)現(xiàn)，或者產品的build一出來發(fā)現(xiàn)，比如和auto build系統(tǒng)集成的測試。

　　b. defect prevention

　　再往前走，在有缺陷的代碼被寫出來之前發(fā)現(xiàn)問題。比如detail design，requirement specification， 甚至產品的spec制定的時候發(fā)現(xiàn)問題，這類問題有很多，比如很多場景可能沒有被考慮到，有些可能和原來的客戶或者產品的需求不一致，甚至有些地方不具有可測性。那么在這個時候，需要及時的討論和調整。因為這個時候的調整可能比產品出來之后發(fā)現(xiàn)幾個bug更有價值，因為早期的錯誤可能到后面很難改，或者改的代價很大。

　　c. 協(xié)助建立質量的文化。

　　之所以說協(xié)助，是因為覺得這個可能不只是靠測試人員能做到，需要和開發(fā)人員以及產品的管理人員等等一起來創(chuàng)建。