我的測試之旅：（1）起點——作為軟體開發人員

可能和大多數的IT人一樣，我的職業生涯也是從一名軟體工程師起步的。雖說頭銜是軟體工程師，但其實是跟隨專案需要什麼都幹，也許和當時的公司是做外包業務有些關係。不過回頭想想這也是好事情，什麼都瞭解一點，什麼都做一點，才不會秉持著“我就只做開發”、“我就是做測試”的這種想法。又幸好我後來很快有機會專職做測試，才沒有淪為啥也不精專的泛泛之輩。

我當時並不知道何為測試驅動開發（TDD）、可接受性測試驅動開發（ATDD）、持續整合或者敏捷測試這個概念，但我確實有做一些相似的事情。我們曾經做過一些SAP的開發，根據從日本客戶那裡拿到的詳細設計書，開發一些ABAP程式。出於對自己的不自信，我完全不敢相信自己寫出的程式碼，於是沒寫出一部分的程式碼，我都要實際地執行一把，看看執行的結果到底是怎樣的。這裡得稱讚一把SAP的這個開發環境，真不錯，幫助很容易查閱，也有一些示例程式，編譯執行也很快，很容易就可以得到對自己編寫程式的反饋。如果用今天的眼光來看待的話，其實也算是覆蓋範圍較小的持續整合了，只是我並非有意思的編寫測試用例進行功能驗證，只是執行程式看看外觀和結果而已。由於每幾段程式碼都能看得到實際的效果，再繼續寫後面的程式碼時我也有著更強的信心，一方面是對自己編寫ABAP程式碼的信心，另一方面是對開發的方向以及ABAP語言的信心。

由於是第一次接觸ABAP語言，所以我並不敢確信自己使用該語言的方式是否正確，所以基本上在進行開發的同時，我還開啟這一個測試專案（Project，IDE工具例如Eclipse中的專案，並非專案管理中的“專案”一詞），類似於一個沙盒。沙盒的作用在於，當我需要使用一些函式或者介面，又不肯定它該如何使用時，我可以在沙盒裡寫一個最簡短又能使用到這個函式或介面的小程式，看看它的效果，輸入輸出引數該如何使用，而後再回到應用程式開發的專案中去使用它。如果我直接在開發中去使用或者嘗試，那麼帶來的風險就太大了。

在其他一些專案中，我也做過許多類似於調整表格標示符位置，檢視對話方塊位置之類的工作，後來我才瞭解到，在測試的社群裡這些被稱作是低等的手工測試工作。當時，我承擔的任務被稱作是“報表套打程式開發”，依然是被當做開發工作來進行的，雖然程式已經開發完畢，但是我們得細細盤查列印出來的實際效果是否正確，在電腦中看到以及排列整齊的表格，一旦列印出來卻是錯誤百出。做這件事情，需要我們執行報表列印程式，列印到檔案，然後觀察列印出來的報表，看看錶格或者一些欄位是否顯示在正確的位置。不僅如此，如果位置不對，那我們要立刻調整報表列印程式中的設定，再列印，再檢查，再調整，重複此過程直到報表顯示正確為止。

當時公司裡除了我所待的開發部，還有一個業務部門，就是本地化（Localization）團隊，其實也就是招來一大堆英語、日語等各種語言的專業人士，讓她們（絕大部分是女同胞，只有一個男同胞）將介面、選單、對話方塊等所有使用者看得見的文字都要轉化為中文。我也曾經被抓壯丁去幫她們做這些工作，其實是非常的繁瑣，也就是要在軟體系統中將相應欄位定義的地方，把文字替換過來，還要檢查在介面上的顯示是否正確，是否和原文介面保持一致風格，等等。關於本地化測試的技術和各種方法，我就不多說了，相關的書籍、文章都不少。只是後來回想，我覺得這樣的過程其實完全可以做得比較自動化一點，可惜當時的我還沒有接觸到系統的測試自動化知識，也沒有足夠的能力可以幫助到她們。當時這個團隊還面臨著另一個問題，她們的成員多數是語言專業畢業， 計算機方面的知識可謂匱乏，遇到翻譯一些專業詞彙之時，就容易出錯，所以她們也會在專案週期中安排一個階段，供我們開發部的同事介入進行後期檢查。有點像是在做系統測試，但麻煩在於，開發部介入比較晚，而要檢查的文字實在太多，彷彿大海撈針，通常也只有憑藉經驗挑選一些容易出錯的地方做重點檢查，現在想想，其實頗有一點基於風險測試（Risk-Based Testing）的意味。

檢視更多“我的測試之旅”文章
1. 起點——作為軟體開發人員
2. 轉變——作為專職測試人員
3. 同期——加入測試自動化小組
4. 並行——自動化迴歸測試
5. 難點——功能改進的測試
6. 跳轉——追逐新鮮事物的探險者
7. 啟程——Scrum中的測試工作者
8. 困難——沒有現成的測試工具
9. 行動——簡化測試文件和流程
10. 貢獻——開發項流程（Development Item Process）
11. 嘗試——Scrum Master
12. 機遇——測試自動化培訓師和教練
13. 轉型——敏捷教練

敬請關注 《大測大悟——測試的敏捷之道》開放出版過程

聯絡方式：
- 新浪微博
- 谷歌郵箱 kaverjody @gmail.com
- LinkedIn