因為一直從事web產品的測試，我的觀點並不一定適合所有的型別專案。
工作已將近三年了，雖然這三個年頭裡我都在積極的學習著與測試相關的技術；但是能沉澱的東西很少。相信測試同學都有類似的感覺。
不要為了測試而測試
前幾天做了乙個測試的ppt ，就是講專案中要用到的測試技術，總結了半天其實實際的產品中沒什麼技術，熟悉需求，轉化成用例，待專案上線後驗證功能就ok 了；對乙個自身質量要求不高的專案，我們有時候為了體現自己價值，非要在一些不痛不養的問題上揪著不放。
舉個不恰當例子，某鋼琴高手開了乙個補習班教鋼琴，家長送來一孩子目的只是讓孩子學學鋼琴；鋼琴高手為了體驗自己的價值（牛b），硬是按照貝多芬的標準去培養，孩子彈不會《xx交響曲》不讓孩子走。先不說孩子有沒有貝多芬的鋼琴天資，也許孩子壓根就不想成為貝多芬。
當然了，如果你辦的是「中國**家鋼琴協會」，你有責任要求會員達到國際超一流水平，為國家和個人贏得榮譽。
有時候不要為了測試去測試，或為了體現自己的價值去做一些對整個專案貢獻不大的事兒。當然，我在這裡不是讓測試人員放棄自己的原則。要知道不管是產品、開發、測試都是圍繞著產品的發展貢獻。
為貢獻產品的發展測試遠比為了測試了測試所帶來的價值大得多；所以站在產品的發展上去看待測試工作更能體現自己的價值。
記得去年的總結再討論自己對流程的理解。隨著工作年齡的加長對這些問題也有進一步的看法；所以，再拿來炒一炒，希望能炒出新的味道。
沒有最好的開發測試流程，只有最適合專案的開發測試的流程；
去年的一篇說軟體測試流程，嚴格規範的測試流程一定比沒流程好，敏捷的流程一定比傳統的瀑布流程先進。這個觀點沒有大的錯誤，但是我們忽略了所做有產品這個「物件」；忽略了產品的特點與階段。
例如兩三個開發合夥開發乙個專案（或產品），這時你讓他們建立一套規範的流程，按流程實施，顯然是不現實，我想擺在他們面前最主要的問題是，如何快速的把客戶需要的功能開發出來換成money ，維持生計以及公司運作。
例如乙個各種功能已經成熟的專案，有著龐大的使用者群，以維護為主的更新，它的版本功能的上線必須要建立嚴格的發布流程，經過充分的測試才能上線；使用者群越大，暴露的問題越多，問題帶來的影響也會越大。
同樣是乙個web產品，筆者目前所做的專案流程完全不是這樣；我們的發布流程很簡單，測試流程也很簡單，不去寫的規範又複雜的測試用例，放棄了使用缺陷管理工具來反饋問題；
溝通變得尤為重要；我不否認這樣做會給產品帶來了一定的風險；對於嚴重的問題，我們可以通過快速的版本回滾，對於輕微的問題，我們很快會在下個版本迭代中修復。是不是有點敏捷的味道在裡面。
為什麼會這樣？因為這個產品屬於前期開發階段，很多功能還沒上線。整個團隊都在貢獻著產品的發展；需要快速的將需求轉化成功能給使用者使用。
所以，沒有最好的開發測試流程，只有最適合專案與階段的開發測試的流程；
產品質量與使用者容忍度
之前看過不少人討論到底需不需要測試人員；我想說測試人員n年後不管是被重視了還是被淘汰了「測試的行為」永遠不會消失；因為沒有質量的產品基本上等於沒有價值（也就是說沒存在的意義），至於對產品質量的要求是由使用者容忍度決定的。
facebook 沒有測試人員！但是測試行為一直都在。開發找需求，開發、自測、發布，獲得使用者反饋，決定功能下線還是上新的功能---相當於一條龍的服務。因為使用者的容忍度允許他這麼做。
微軟不能這麼幹，修復乙個windows 的bug成本很高，而且使用者是花錢買的，也許使用者是用來創造價值的（辦室、儲存、管理），也許乙個檔案丟失，系統崩潰會給使用者帶來巨大損失；所以，微軟需要很多的測試員。
拿修復成本與使用者容忍度做標準，web產品優於客戶端 產品；在web產品中也要分行業；使用者對銀行系統、火車票、購物**的容忍度顯然要低一些，反過來說也就是對產品的質量要求更高，因為與錢掛鉤。就算同一 個產品，會員與免費使用者的容忍度也是不一樣的；因為會員使用者有權得到更好質量與服務。
所以，關注分析使用者的容忍度的測試才不會把自己變得格格不入。
提公升自己的貢獻
前面的東西貌似都在「弱化」測試存在的價值；俺本來就不被重視，所以俺就需要更加認真和努力找問題來提公升自己存在的價值，你現在說，有些產品不需要太指著的去測試；那你說俺還能幹啥？
當我們把測試看成是為開發和產品服務時，也許情況會完全不一樣。我們可以提供哪些服務？
前面已經提到隊團不管是否有測試人員，但測試行為一定會存在；如果乙個產品都不可測試，如何去發現並修復bug ，如何去維護與擴充套件？尤其對於web產品來講，不可維護與擴充套件的產品無疑是致命的。（可以通過專案重構再解決）
為專案團隊提供每個版本的bug趨勢分析資料，讓專案中的每個人都了解專案當前的狀態
通過分析bug資料來建立或完善各種checklist，幫助專案團隊更好的完成需求評審、設計評審以及**
評審，減少bug出現的機會。同時，可以定期將多個專案的checklist進行合併，使單個專案的經驗可以通過test team快速的流動起來，及時的作用於其他專案
主動為architect team提供每個專案的效能測試資料，幫助他們獲取更多的實際專案資訊，減少踏入「陷阱」的機率
建立自動化測試測試框架；
構建持續整合，使版本的迭代與更新得到快速的反饋。
沒有測試人員自測節省人力的了，尤其在單元測試層面。產品的質量應該由開發與測試共同承擔。（現實中的責任到人，讓團隊很難形成這種文化）
舊病成醫，測試的產品多了自然會對產品有自己的理解，產品的定位，使用者習慣與體驗； 可以從測試的角度貢獻產品的發展。（這個由產品的特點，公司文化決定）
（八）軟體測試人員的定位
工作已將近三年了，雖然這三個年頭裡我都在積極的學習著軟體開發與軟體測試的相關的技術 但是能沉澱的東西很少。相信都有類似的感覺。不要為了測試而測試 前幾天做乙個測試的ppt，就是講專案中要用到的測試技術，總結了半天其實實際的產品中沒用到什麼技術含量的技能，熟悉需求，並轉化成用例，待專案上線後驗證功能就...
測試三年規劃
做了一段時間的測試後，我深刻的體會到我還有很高的提公升空間，這是我作為測試小白的親身感受。為了更加有效的提公升自己的測試水平，達到自己的期望，成為乙個合格的測試負責人，我給自己做了乙個三年規劃。第一年，未破殼階段。重點打磨自己的測試基礎能力，比如 掌握更加豐富的案例設計方法，提高自己的溝通能力以及培...
談軟體測試人員的發展方向
如果你不想轉開發，轉管理，轉產品，或自己創業買煎餅果子的話。那麼說明你是對測試是真愛。測試需要掌握的測試技術太寬泛了，所以，我們必須要選擇乙個方向。五年過去了，我想再試著寫寫對這幾個方向的認識。自動化測試 自動化測試有廣義和狹義之分，廣義上一切使用工具或 來代替手工測試都可以認為是自動化測試 不過，...