后來我被直接派駐客戶（諾基亞網絡杭州3G研發中心，現諾基亞西門子網絡杭州研發中心）現場，再后來被直接買下，成為了諾基亞的員工。也正是從派駐諾基亞那時起，我開始了自己作為專職測試人員的旅程。但編程這個活動一直都伴隨著我，直到現在，這也是我從來都不認為開發、測試有著很清晰的界限的原因，欲知詳情請繼續往下看。
當時我們兩家公司合作已經有一段時間，已經有數十位工程師在諾基亞干活，我們這一批人是專門為研發中心某個產品線的測試部門補充人力的。團隊管理非常簡單，我們自己公司的事務由自己的外包經理或者叫協作者經理（Collaboration Manager）管理，當然，在我們這批人和經理之間還有小組長（Team Leader）。而從做事情做項目的角度呢，我們則直接由諾基亞的項目經理來負責管理，也即由他們來分配任務、確定時間表等各種事務。
該產品線的結構應該屬于比較常見的一種，分為幾個開發部門和一個測試部門，支持型的部門還有質量管理部和產品管理部、項目集群（Program）管理部等等。使用的是自己獨特的開發模式，類似于瀑布模型，也即分階段、基于文檔的開發模式。一個產品的開發會被分割為多個項目集群，而后項目集群再分作多個項目，每一個項目又分割為多個子項目。通常一個子項目也即是某個或某些模塊的開發任務，或者測試任務，測試和開發是獨立分開進行的子項目。測試項目要等待整體的開發完成之后才開始。
剛到諾基亞時，我頗為感慨，果然是大公司啊，真是有風范，的確很有人文關懷的感覺，我們所擔心的事情都有人考慮到。當時，諾基亞的新員工都要先參加總長度兩個月的入職培訓，包括從諾基亞介紹、價值觀等人事的部分，也包括對產品線產品的介紹，以及開發模式的介紹，以及開發、測試具體流程的介紹，總之，非常的全面，凡是未來會用到的全都有涉及到。只要保留好課堂的材料和自己的筆記，回頭上手干活基本上沒有任何問題。
機緣巧合，我還在參加培訓就被小組長抽調過去先參與到測試項目的工作中去了，也許是因為我看著比較順眼吧……當時的我心中非常忐忑，不知道該如何干活，所幸有諾基亞的導師（Tutor）制度在，小組長給我安排了一位導師（在此要非常感謝她的輔導，幫助我順利地融入諾基亞的氛圍，真的非常感謝！），她教給我作為一個測試人員所要做的各種事情，給我很多的相關資料可以自我學習，也手把手地指導我執行以及分析和寫測試報告等等很多很多。總之，和她配合，我受益頗多，測試項目開始不久，我就差不多已經可以獨立工作了。
我加入時導師已經在開始執行測試的階段，于是我主要是要去理解測試計劃、理解測試用例，熟悉測試工作和被測產品，掌握測試執行的各種操作命令。測試部門的知識傳承做得相當不錯，所有的文檔都有模板和介紹，很容易就上手，知道各個部分寫的是什么東西，以及如何使用。而且在測試用例中，不止包含測試步驟，通常也包括要執行的命令，和每個步驟的預期結果，以及最終的預期測試結果。測試報告也有模板，只要按照模板的要求，將測試時的環境，被測對象的各種版本信息，執行的命令和返回的輸出等等各種信息都記錄下來就行。
當我漸漸地熟悉如何執行測試后，就開始對周遭事物有著各種好奇，成天都纏著導師問各種問題。一開始主要是在測試失敗，或者得到一些不完全符合預期的輸出時，不知道該算是通過還是失敗，就要去找導師請教。慢慢地就開始問很多關于，為什么要這么設計這個用例啊，到底要測試的是什么功能，之類的問題，而導師的回答總會附上一句，“多看看功能需求說明書吧”。于是我就開始看功能需求說明書（Functional Requirement Specification），從中去理解我所測的對象所應該實現的功能。功能需求說明書也是有模板的，不過依然會出現不清楚或者難以理解的地方，這也是讓測試人員很頭疼的地方，因為無法確定測試的對策。最好的解決辦法就是去問文檔的作者，只不過這份文檔的作者通常就是其開發人員（或者開發人員所在領域的專家），而他們通常都比較忙，忙著進行后續版本的開發（針對同一版本，測試總在開發完成后開始，所以測試開始時，開發人員都已經在做新功能的開發了）。
而我的幸運則在于，當時開發那個功能模塊的開發人員人都很好，是公認的牛人，而且很健談，很愿意和測試人員交流（基于開發項目的進度壓力，這一點還是比較難得的）。而且他的特點在于，除了開發自己負責的模塊，他會花很多時間，多數是自己的業余時間，閱讀其他模塊的代碼，而后是其他領域（Domain，技術領域）。他后來的發展也非常快，因為他閱讀的代碼很多，所以開發起來也就速度很快，了解的多分析問題也就很快、對整體架構把握也好。而我則是從他身上了解到很多該模塊設計的原理，以及所要實現的功能，和服務的對象（其他模塊），對我理解被測對象從而更好地有針對性地進行測試幫助非常大。
這一個模塊的測試還有一個比較特殊的地方，它其實是支持型模塊，為系統內其他模塊提供調試、日志相關的服務，所以測試中很必然地要針對各種情況下的記錄、顯示燈功能進行驗證。如果直接借用現有模塊來測試，會有一定的困難：首先是處于穩定性的考慮，其他模塊一般都是要等到我們測試完成了才會開始使用；其次，就算有一些模塊在使用，也不大會專門為了測試而頻繁地修改它的代碼，編譯，然后提供給我們用于測試，除開開發人員工作繁忙，也還有編譯和版本管理實踐很花時間的原因。因此，我必須要自己開發一些測試應用程序（Test Application），這個程序里面，使用被測對象所提供的服務，并且要知道如何修改產品的啟動列表，從而可以使這個測試應用程序可以在設定的時間點其中以及打印相關的信息。
我們當時所使用的測試工具也是諾基亞內部的工具部門自己開發的，說實話，相當好用。由于我們的產品具有自己的一套人機交互界面，所以只能用自己的工具來操作測試。這個測試工具自帶的就有提供一個類C的腳本語言，可以很方便的寫測試腳本，語言本身也很簡單，上手不難，而且會寫一點腳本對于測試 工作的輔助作用也很大。因而，從這個角度出發來看的話，我們并不存在完全手工的測試。
做測試不可避免地肯定會發現軟件的缺陷（Bug），發現缺陷之后需要將相關的信息記錄下來，錄入到缺陷追蹤系統中去，開發人員會相應地收到通知。看到這里大家腦海里恐怕會浮現出一幅景象：測試人員提交缺陷報告后，過了好久開發人員終于回復過來“缺乏信息，需要得到某某模塊的輸出”，測試人員又吭哧吭哧地重現場景，再填好信息發過去，結果開發人員又要求別的信息，通常都要來回好幾趟，才最后可能定位出問題根源，然后開發人員開始修改。當時我們的流程中對于開發人員最后的回復有一些要求的，定位出問題根源后，需要給出描述，以及計劃在哪一個版本中進行修復，有一個例外，就是如果這個問題是“正常的”，不用改，那么通常會標識為“無需修訂”（CNN，Correction Not Needed），打回給測試人員，結束當前的缺陷追蹤流程。如果測試人員對此有異議，就好玩了，就開始打嘴仗，最后再和開發、測試的資深工程師（一般是相關技術領域的技術專家和測試專家）一起討論定奪。缺陷修復的速度主要受到測試開發雙方人員溝通效率的影響，從發現缺陷并記錄下來，到定位出問題根源制定修復計劃，通常以天數計算，而修復的過程，一般來說都是以小時計算，個別疑難問題稍微多花一些時間。
有一次，我發現了一個錯誤，然后把現象記錄下來，提交到缺陷追蹤系統中，結果開發人員的回復是無法重現。于是我在測試環境中又再執行了好幾次，發現問題都能夠很穩定的重現，于是就再通過系統把這個信息返回回去。幸得開發人員也是態度很積極的工程師，估摸著心里很好奇，就直接來找我，于是我就在座位上給他重現，結果，居然沒有重現成功！讓人百思不得其解。長話短說，后來發現原因在于我之前執行的時候，都是用跑腳本的方式執行，而我們現場調試是手工執行的方式，但這兩種方式的差別在哪里呢？經過仔細地分析，我們發現和測試用例的步驟有關。測試用例是要在一個會話（Session）上監聽消息（產生特定消息是模塊的功能之一），所以我們會先打開一個會話開啟監聽，然后再打開一個會話，再里面進行一些操作，然后回到之前的會話里去查看相應的消息是否有出現。而手工和腳本的差別在于，手工的情況下，我們人眼看到操作結束，就返回到第一個會話去停止監聽，而后檢查監聽到的消息。在腳本中，為了確保操作是成功的，通常會等待一點時間，然后再切換到第一個會話執行后續的動作。但最大的區別在于，手工操作時，我們可以在測試工具中打開兩個小窗口，監聽和操作的會話都是處于活動狀態（Active）的，而在腳本中，則只有當前會話處于活動狀態。
通過多次地現場協同重現缺陷場景，開發人員確定該問題不是被測的模塊所引起的，還給了我一些建議，建議我找會話管理這一塊的人來看看。后來發現這正是問題所在，通過分析之前執行的測試日志記錄，包括我們現場重現的情況，對方很快就確認原因是會話超時（Timeout），為了節約資源避免浪費，每一個會話都有超時時間，超過這一時間沒有任何動作的話，會話就會被關閉。而我的測試中，恰好離開第一個會話再回來，中間的間隔就超過了這個超時時長，導致會話關閉，第一個會話中的監聽無法得到要監聽的內容，測試結果分析的時候得不到預期的結果，測試也就無法通過了。修復非常的簡單，對于會話超時處理的地方修改幾行代碼即可，但這個問題解決（Troubleshooting）的過程才是最艱難的地方，需要我們細心檢查，發現任何可能的蛛絲馬跡，甚至還要發揮想象力，將不同線索聯系起來，最終才定位出缺陷的根源。
正由于上述提到的缺陷管理時間中的溝通成本，我們一直在思索如何能夠改進。一是從缺陷管理工具入手，加強它的功能，提高它的速度；二是從缺陷管理流程的角度出發，盡量簡化，提高它的可操作性；三則是從組織架構方面出發，思考是否可以改變現有開發模式，拉近開發、測試人員之間的距離，使得溝通無需依賴工具也可以進行。
相關鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發人員