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

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

測試工程師必須把產(chǎn)品測試的技術(shù)寫成文件。測試計劃提供指導(dǎo)并把測試設(shè)計轉(zhuǎn)化為設(shè)置、實現(xiàn)測試和評估結(jié)果的步驟指導(dǎo)。具有一般軟件和產(chǎn)品特性不同層次經(jīng)驗的工程師都能使用這樣一個詳細(xì)的測試計劃。如此測試設(shè)計者或測試方案作者之外的工程師也能能進(jìn)行測試。

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

測試計劃強調(diào)測試計劃和執(zhí)行的原則。在測試計劃中描述進(jìn)行測試所需的測試設(shè)計和步驟是另一層關(guān)于測試設(shè)計和計劃的原則。在測試設(shè)計和計劃中的錯誤與欠缺在設(shè)計轉(zhuǎn)化成測試計劃中特定的結(jié)構(gòu)和測試步驟后就經(jīng)常是再已無法彌補。

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

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

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

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