能寫出計算機程序卻寫不出一個完整句子的軟件工程師現在還有。但不幸的是，要成為一個成功的軟件測試工程師，你需要清楚的交流。

你怎么去學習寫？通過寫。如果文字水平太粗糙，上一門創造性寫作的課。每天寫工程流水記錄或發email。關鍵是學習（或重新學習）怎樣用清晰可懂的語言表達你的思想。一個好的寫作參謀是William Strunk Jr.和E.B. White寫的The Elements of Style，它一點也不象初中教科書。

測試工程師必須把產品測試的技術寫成文件。測試計劃提供指導并把測試設計轉化為設置、實現測試和評估結果的步驟指導。具有一般軟件和產品特性不同層次經驗的工程師都能使用這樣一個詳細的測試計劃。如此測試設計者或測試方案作者之外的工程師也能能進行測試。

測試計劃也幫著佐證測試策略的正確性。項目中的每個人都應當參與審查（即市場、開發、支持、技術寫作及測試人）。計劃的審查是必不可少的，因為盡管測試工程師盡最大努力來達成一個對產品的全面定義，這一測試設計者所基于的定義不一定是完整或準確的。此外，就象開發者很難測試他們自己的編碼一樣，測試工程師也很難明確評估他們自己的測試計劃。每一個計劃審查者都可能根據其經驗及專長建議修改，有時候審查者還能提供測試工程師在組織產品定義時不具備的信息。例如，一個市場人員可能了解到了新的客戶要求，一個軟件支持專家可能從有關的產品領域了解到了一個新的缺陷報告。

測試計劃強調測試計劃和執行的原則。在測試計劃中描述進行測試所需的測試設計和步驟是另一層關于測試設計和計劃的原則。在測試設計和計劃中的錯誤與欠缺在設計轉化成測試計劃中特定的結構和測試步驟后就經常是再已無法彌補。

測試計劃可作為其它項目，例如為不同的產品準備測試時的參考資料。當被測試軟件找到缺陷解決并證實后，測試計劃所述的測試可以用于證實缺陷的解決方案。同時，一個主要的測試設計信息來源，特別對于舊產品的新版本而言，是相關產品或前版本的測試計劃。在建立新版本時，舊版本的軟件測試計劃都應當被重新審查。

與功能與設計說明不同，測試計劃將從測試的角度來描述產品的功能操作。從這方面說，測試計劃構成了公司公共檔案的一部分。隨著時間的流逝人們會離開公司，帶走他們的知識。以前產品的測試計劃就能幫助你定義新產品的測試。

軟件測試工程師還要寫測試結果報告。測試結果必須寫成文檔，這樣就能確定被測軟件的狀態，提供關于必須要解決的缺陷的記錄。產品測試中發現的所有缺陷的記錄是測試部門最顯眼、保存時間最長的文檔。測試計劃和測試報告在項目的最后常被遺忘，但現存缺陷的清單（或數據庫）代表項目未完成的議程。這一議程沒完成是因為一些缺陷必須在對原來產品的一個patch或maintenance release的時候糾正，或者它們在這個產品作為后續產品的基礎之前被修復。

在與軟件產品打交道的過程中，測試工程師比其他部門的人參與項目的更多方面。測試部門應當記錄項目過程中重大事件（例如設計決定）的信息。這個信息應能幫助測試部門和其他部門避免在后續項目中犯同樣的錯誤。錯誤是不可避免，在一個項目中可能出問題。從這些經驗中學習就可能避免問題，避免今后的同樣錯誤。從錯誤中學習的第一步就是記住它們，記憶的第一步就是把它們寫下來。