測某一個功能很容易，但是如果被測的對象是功能的改進（Improvement）呢？例如要提高性能（Performance），提高配額（Quota）準確度，過濾以減少不必要的日志數量。
當我拿到這樣的功能需求規格說明書時，我一頭霧水。其實我都算是二手，這個被測大模塊（多個模塊組成的一種服務型模塊）的測試任務（算是個子項目）是從他人手中轉交給我的，他人也是剛剛接受作為這個領域的測試負責人，上手不到幾個月，連這個測試任務都還沒有熟悉就轉交給我。于是我只能努力地去獲取各種可以提供參考的信息，首先我到測試管理工具中去查找以前版本的測試計劃、測試用例以及測試報告，從中了解被測對象的情況。我還會去閱讀相應的開發方面的文檔，包括設計文檔、實現文檔，甚至代碼。
只是看文檔遠遠不夠，里面的內容總是可能會存在二義性或是含糊不清的地方，這時候就必須要鼓起勇氣去騷擾別人。測試專家、測試架構師、開發團隊（好幾個人呢）、開發團隊小組長、被測大模塊的技術專家，我全都騷擾過。如此高頻度的造訪必須得講求方式方法，不然人家很可能感到厭煩，而后你就會發現他們經常地很忙沒有時間。在問人家問題之前，自己要先做好功課，盡量避免問太簡單和基礎的問題，更不能重復問同樣的問題。而且不管是通過郵件還是當面請教，都要注意說話要有條理性，要能夠在較短時間內以較小的篇幅講清楚問題的背景以及問題本身。
在不斷地交流中，我對被測大模塊的理解也越來越深，要怎么進行測試的想法也越來越具體。寫測試計劃其實就是一個動態的過程，我先寫出一個大概的樣子作為討論的基礎，而后拿著它不斷地和大家交流，詢問他們的意見，然后再修改。根據測試質量管理的規定，我們的測試計劃需要得到批準才可以進入執行階段。得到批準需要我提前兩周邀請相關人員，預約他們的時間參加審核會議；會議一周前要把相關材料發出，并且還要注意催促參會人員都要閱讀這些材料；開會的時候基本不用擔心，我只需要回答大家提出的疑問，如果有確實需要修改的地方，記錄下來會后修改即可，會議的部分有專門的主持人負責主持工作。
測試對象是功能的改進，如何度量其改進，如何選擇度量的對象和指標，如何在測試中去收集這些數據，以及如果設計測試結果分析的部分，都很耗費時間和精力，更難得是得到各方都比較認可的共同理解。不僅僅是在寫測試計劃的過程中，我修改了無數次，在審核會議上也收到太多太多的修改意見，以至于主持人不得不總結說我們還需要召開第二次會議重新審核。一般來說在審核會議上，如果修改意見不多的話，只需要修改好之后郵件發出更新后的版本，大家通過郵件再給反饋即可，只有當修改意見實在太多的時候，才需要按照正式流程再召開一次會議。幸好，第二次審核后，測試計劃獲得大家的認可通過批復。
由于我們要求在設計的測試用例中除了寫明測試步驟，每一個測試步驟都要給出建議執行的操作或者命令，這意味著其實在設計測試用例的時候，我們就必須得實地執行這些命令，或者執行一些命令組合，并從中選擇有效果的部分放入測試用例中。而在這個過程中實際上要重復執行相同的命令、命令組合甚至測試用例很多次，絕對具備了將它們進行自動化的需要。我本來就同時擔任著測試自動化小組的工作，也將測試自動化的理念運用到自己手頭的測試任務上是順理成章的事情，也正是在這個時候，我開始堅信“任何操作，第二次執行的時候就是將其進行自動化的時候”。我很懶，所以我總想著有沒有什么操作是可以拿出來寫成一個函數，或者做一個簡單腳本，在執行某些操作前執行這個腳本省去我手工操作。當時，測試質量管理部門對于測試自動化是有標準的，只需要將測試用例集合中可以、適合、便于實現自動化的部分實現腳本化即可。而我的測試任務完成后，所有的測試用例全都有相應的測試腳本，就連那種本來是要走到實驗室里去親自把板卡從插槽中拔出來的測試用例，我也將它實現成為了半自動的測試腳本。后來有了遠程電源控制的硬件后，可以通過斷電來模擬物理隔離，從而實現了腳本全自動執行。當然再后來，測試自動化小組壯大變為測試自動化團隊后，他們實現了Tcl/Tk語言連接外部設備，還可以操控AX400這類之前必須靠手工操作的設備，可以進行全自動化的承載性能測試了。
這一次的測試任務幫助我學會了如何在信息模糊的情況下去界定測試邊界，以及選擇測試方法。飽受信息不完整以及不清晰的折磨，我也特別注重去改善這方面的狀況，功能需求規格說明書、設計文檔、實現文檔等資料的更新改進都有我的貢獻。在測試報告中我也寫得格外詳細，不只是記錄當前執行的結果，一些很好用的命令或者測試技巧、注意事項，我也都一一寫入測試報告，以及更新到相應的測試用例當中去。藉此我希望能夠免去后續測試人員苦尋資料之苦，只要看到之前一個版本的信息既可，用不著再去尋根溯源浪費氣力。不過，資料做得再全面也不夠，還需要人的手把手協助，后來我把這一塊的測試負責工作移交他人時，也費了不少心思去輔導對方，只可惜對方似乎心不在焉沒有太注意吸收我的講述，更可惜之后不久還未曾經歷太多實戰該測試人員即轉戰他方，知識的傳承紐帶再度斷裂，后續接受的人有得重新去追根溯源一把。此話絕對不假，在我已經擔任敏捷教練職務，也即是離開大模塊測試崗位近三年后，還有人根據測試相關文檔中的作者信息找到我問問題，只可惜我當時就算記憶力再好也無法保證提供給他的答案絕對準確，更不要說在這三年里，大模塊自身也不斷地有新功能增加或是缺陷被修復，我的記憶已然不再是第一手信息。
相關鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發人員
我的軟件測試之旅：（2）轉變——作為專職測試人員
我的軟件測試之旅：（3）同期——加入測試自動化小組
我的軟件測試之旅：（4）并行——自動化回歸測試