這兩個月陸陸續續面試了十多個應聘者，工做年限在半年到八年之間，但少有滿意。期間，種種感嘆，回想起去年面試六十餘人僅有3人知足要求，如鯁在喉。html
個人要求高麼？linux
個人要求實際上是：有還算不錯的溝通能力，熟悉常見軟件開發流程，有必定的需求分析、用例設計能力，會基本的linux和sql操做能力。有一些代碼能力會加分。這是長期與現實妥協的結果。若是人還算機靈，其實我很願意花時間來培養他們。程序員
面試結果：面試
使人可惜的是，一個合適的人真的很難找。更使人可惜的是，我看到不少入行不少年的同行，能力並無跟隨工做年限一同增加，有些作了五六年的人有時候給人感受居然還不如一個入行一兩年的年輕人。最使人遺憾的是，大部分人居然沒有一個明確的職業發展思路，即便有，也沒有通過深刻一些的思考，而是人云亦云。sql
面試的一些細節： 微信
我準備了一套筆試題，考慮到面試者的不一樣狀況，題目有最基礎的測試方法，也有較高級的sql應用和設計分析。沒有一個應試者給出讓人相對滿意的答案。內部評估的時候，咱們認爲一個工做兩年工做經驗的人就應該能回答的很不錯。 框架
我通常會根據簡歷問一些問題，看看簡歷的真實性。也會問一些基礎的測試知識，查看應試者的專業素質。性能
常見的問題：學習
說說你經常使用的測試方法？測試
百分之九十的人只能答出等價類和邊界值。只有少數人能夠講出其它測試用例設計方法，但深刻問，從沒有一我的能有使人滿意的回答。
給一個很是簡單的小例子，例如登陸操做，讓應試者回答如何使用等價類方法設計用例。
讓人吃驚的是仍然只有不到五分之一可以給出比較滿意的答案。
陳述一個缺陷的生命週期（大家是怎麼管理bug的？）
有一多半人可以說出常見流程，但深刻問一些問題：如缺陷如何同版本、測試輪次等結合起來，一些特殊狀況如何處理等，不少人就懵了，而這些基本上都是工做中經常使用的。
你作的最長的一個項目是什麼？在這期間你遇到了什麼問題讓你最頭疼？你如何解決它？
十我的裏大約只有一人能給出還算不錯的答案（可以識別出問題，提出它帶來的不利影響是什麼，並可以給出必定的解決方案就算是不錯的答案了）。
你感興趣的測試工做是什麼，你想在哪方面有所發展？
十我的裏有4個會說是自動化測試，3個會說性能測試，2個會說是管理，一個會說是白盒測試。並但願提供相應培訓。只有極少數人可以說出具體的思路和技術項。
若是繼續追問：你說的是性能測試吧？你有過這方面的學習麼？
一半會說看過一些網站上的技術文章，一半會說看過loadrunner的書。若是繼續追問，是哪本書？是哪類文章？有哪些具體的知識點能講一下麼？90%答不上來。
問：你有看過哪一本測試書籍？哪些技術博客？哪些網站？
50%的人會說看過QTP的書（QTP的真正使用率已經快遇上諾基亞的使用率了！），而且沒有真正在工做中使用過，而後就沒有別的了。有少一半人最近幾年一本技術書籍也沒有看過。
若是有管理經驗的應試者，我會問一些測試過程管理相關的問題，如給一個最簡單的題：若是測試時間不夠如何？
十我的中只會有兩三個提到排定優先級和測試裁剪，大部分人的回答居然是加班也必定要搞完。
我想說的：
爲了你的前途，請多明確一些我的能力思路吧。你五年後，十年後是個什麼樣子？有沒有一個明確的想法？有沒有你五年後想達到的某我的的程度？若是這些思路不清楚，請多看看外面的世界，看看一些測試作得很是好的人是如何工做的，他們掌握了什麼能力？學習他們，追趕他們並嘗試超越他們。最好認識他們，能夠侃侃大山，志同道合抱團前進很好。另外目標別定太抽象，必定要是能夠分解，能夠檢查的。
多讀一些測試書籍，測試的書並非只有QTP！看看微軟測試專家史亮推薦的書單，這些都是不錯的好書：http://www.cnblogs.com/liangshi/archive/2011/03/07/1973525.html 有些書可以幫助你把測試知識框架搭建起來，比照一下你還缺點啥？
多讀一些其它書籍，不限於技術書籍。若是想讀的書有利於工做，推薦一些如何作思辨思惟的書。《思考的藝術》《六頂思考帽》《你的燈亮着麼》《學會提問》是我喜歡的4本書。它們會教你怎麼獨立思考，養成提問的習慣，而提問的習慣是咱們如今的測試人員最缺少的一件事情。人們每每拿了被測物就開始忙着寫用例，忙着測試。而不是先探索它、研究它。固然IT技術也要掌握，若是你的IT技能可以遇上開發，你發現你作測試的思路會很是的寬廣。
把書籍中的東西跟你的工做對比，把好的東西引入工做（這點是檢驗書本質量的好方法，也是促進你思考，促進你能力提升的好方法。）
關注大牛們的技術博客。國內寫好測試博客的人不是不少（不少人其實頗有水平，可是不喜歡寫blog），可是國外有不少，有人整理了一個list也推薦給你們：http://ssnlove2008.blog.163.com/blog/static/3788942020093284842381/。
搞定你所在行業的領域知識：如常見IT技術，常見業務知識，這些知識掌握的越深，你的價值越高。測試技術是內功，可是你能直接爲企業帶來價值的最大之處是你對被測物熟悉程度，也就是你的領域知識！！！
沒有方向？從你的工做入手，好比，你遇到的最大的難題是什麼？我怎麼解決它？我須要掌握什麼樣的技術解決他？我要推進什麼樣的組織改變來解決它？別人怎麼解決它？有沒有更好的方法？使用後我改進了那些？百度一下別人有沒有一樣的問題？嘗試做對比，若是以爲他作得好，嘗試聯繫那我的討論一下。看看對方的進展。嘗試把活兒幹得特別漂亮。你能解決10箇中等問題之後，你的能力會有大幅度提升。
嘗試作筆記，或者寫博客，要堅持！
另外的吐槽：
野蠻生長沒有通過系統訓練的同窗很是多。這其實有不少因素，分析起來以爲有如下幾點：
大學或者職業教育沒有很是好的課程體系（有些培訓機構還行，可是也須要提升），其實測試技能須要系統訓練和長時間磨練纔能有根本的增加，咱們的職業教育或者再教育體系其實仍是有很大空白的。
說句實話，你們的讀書氛圍不夠濃厚。你們不喜歡看書。而讀書是再教育成本最低，又很是有效的途徑。相比於程序員，測試同窗喜歡讀技術書籍的比率明顯的低，這是一個讓人悲傷的事實。真但願這種現象可以改變。
不少人是不喜歡coding才轉測試，或者是由於IT產業廣泛薪水高才來作測試。不是真正熱愛這份工做，不熱愛其實作很差，由於興趣是最好的老師。
不少人認爲測試門檻低，young talent 不肯意幹，測試吸引人才有點兒困難（我初入行的時候也有這種想法，也是當時被強拉來作測試的，當時想作的是coding和數據DBA相關工做並已經有了一些積累，）。說實話測試的入門門檻的確有一點點低，可是作好測試的門檻確是至關的高，隨着系統愈來愈複雜，測試逐漸會比開發還難作，更有挑戰性，我這麼說你信麼？
專業化社區尚未造成規模，測試人員沒有能有效交流的平臺。這是跟美國和歐洲的一個挺大的差距。他們的社區作得挺好的，咱們也有了一些很好的起步。如一些熱衷測試公益的同窗，一些不錯的會議，一些不錯的線下活動，但還須要大大的發揚光大。
本文分享自微信公衆號 - 軟件測試經驗與教訓（udatest）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。