首先，我想的是，什么是“技術含量”。我覺得，一般指的有“技術含量”的，就是你能做別人不能做，或者你完成目標比別人快的多的事情，如果隨便一個人很快能上手完成你所做的工作，就不算有技術含量。就好像只把偽代碼轉換為語言的程序員，有多少“技術含量”?從這個角度上看，很多人覺得“手工測試沒有技術含量”就不足為奇了，因為如果按照用例去執行，給出明確的預期結果，誰都應該知道用例執行是通過還是沒有通過。那如果不是用例的執行而是去設計，而是編寫用例呢?給出一個功能點，每個人是否都能快速的設計出有效的測試用例呢。答案一般是否定的，最少同一個公司，有的人寫的快，有的人寫的慢;有的人考慮的周全，思路很清楚，有的人寫用例和不寫用例一樣，想到哪寫哪。測試用例的設計總該算是有“技術含量”了吧，不懂業務的，熟悉業務要很長時間，不曉得邏輯方法的，肯定先要把邏輯弄清楚。
再次，不管什么工作，什么事情，只要能持續的做的深入，總會有能力上的提升。(個人認為，能力包含技術，還有技術以外的東西)對于測試來說，如何定位一個問題，就可以做的很深。上次參加那個交流會，會上某公司的主管就說了一個例子：“假設我們測郵箱發送4M的附件發送失敗，一種做法是直接把附件給開發，說這個附件不能發送;還有一種做法就是將問題進行細化，是文件格式的原因，文件大小的原因，還是最后只是文件里包含了不合法的字符�！比绻呛笠环N，問題解決起來也快，開發也愿意配合，自己也能提升技能。的確，一開始細化問題的時候，會很費力，但是“火車剛發明的時候比馬還慢”，當你能力提升了以后，會發現處理問題會越來越順手。(如果碰到無法理解的問題，肯定要給開發，不能自己轉牛角尖，但是開發修正后，可以去問是什么問題，怎樣修復的。)說句比較考張的話，把平凡的測試變為不平凡的分析去做~
最后，說其他方面的成長。我們肯定很明白一點，測試不是憑想象，想怎么測，就怎么測的，總是在開始測試之前，先把思路理清楚，測試的策略想清楚，于是鍛煉了思維。我們總是在描述bug的時候，擔心開發看不懂，每次以他人的眼光來審視寫的bug，是否有歧義，復現的步驟是否更直白，語句是否更簡練而清楚，順帶著，是否有截圖和圖上重點的標示，于是鍛煉了文字描述。我們總是會和需求人員確認需求，和客服人員確認客戶問題，和開發確認缺陷問題，于是我們鍛煉了溝通。也許有人會不認同這也是一種收獲，那可以問問自己，我們有沒有測試到一半，發現漏了功能點，重新回頭進行測試的情況;我們有沒有寫bug后，開發看不明白，打回的情況;我們有沒有根本沒有了解到客戶的真正問題，就馬上去解決的情況。。。。
任何工作，當想有沒有前途前，想想自己為此付出了多少。如果做自動化或性能，只會簡單的入門，而不去深入，我想也不會有“前途”吧。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
