能写出计算机程序却写不出一个完整句子的软件工程师现在还有。但不幸的是，要成为一个成功的软件测试工程师，你需要清楚的交流。
你怎么去学习写？通过写。如果文字水平太粗糙，上一门创造性写作的课。每天写工程流水记录或发email。关键是学习（或重新学习）怎样用清晰可懂的语言表达你的思想。一个好的写作参谋是William Strunk Jr.和E.B. White写的The Elements of Style，它一点也不象初中教科书。
测试工程师必须把产品测试的技术写成文件。测试计划提供指导并把测试设计转化为设置、实现测试和评估结果的步骤指导。具有一般软件和产品特性不同层次经验的工程师都能使用这样一个详细的测试计划。如此测试设计者或测试方案作者之外的工程师也能能进行测试。
测试计划也帮着佐证测试策略的正确性。项目中的每个人都应当参与审查（即市场、开发、支持、技术写作及测试人）。计划的审查是必不可少的，因为尽管测试工程师尽最大努力来达成一个对产品的全面定义，这一测试设计者所基于的定义不一定是完整或准确的。此外，就象开发者很难测试他们自己的编码一样，测试工程师也很难明确评估他们自己的测试计划。每一个计划审查者都可能根据其经验及专长建议修改，有时候审查者还能提供测试工程师在组织产品定义时不具备的信息。例如，一个市场人员可能了解到了新的客户要求，一个软件支持专家可能从有关的产品领域了解到了一个新的缺陷报告。
测试计划强调测试计划和执行的原则。在测试计划中描述进行测试所需的测试设计和步骤是另一层关于测试设计和计划的原则。在测试设计和计划中的错误与欠缺在设计转化成测试计划中特定的结构和测试步骤后就经常是再已无法弥补。
测试计划可作为其它项目，例如为不同的产品准备测试时的参考资料。当被测试软件找到缺陷解决并证实后，测试计划所述的测试可以用于证实缺陷的解决方案。同时，一个主要的测试设计信息来源，特别对于旧产品的新版本而言，是相关产品或前版本的测试计划。在建立新版本时，旧版本的软件测试计划都应当被重新审查。
与功能与设计说明不同，测试计划将从测试的角度来描述产品的功能操作。从这方面说，测试计划构成了公司公共档案的一部分。随着时间的流逝人们会离开公司，带走他们的知识。以前产品的测试计划就能帮助你定义新产品的测试。
软件测试工程师还要写测试结果报告。测试结果必须写成文档，这样就能确定被测软件的状态，提供关于必须要解决的缺陷的记录。产品测试中发现的所有缺陷的记录是测试部门最显眼、保存时间最长的文档。测试计划和测试报告在项目的最后常被遗忘，但现存缺陷的清单（或数据库）代表项目未完成的议程。这一议程没完成是因为一些缺陷必须在对原来产品的一个patch或maintenance release的时候纠正，或者它们在这个产品作为后续产品的基础之前被修复。
在与软件产品打交道的过程中，测试工程师比其他部门的人参与项目的更多方面。测试部门应当记录项目过程中重大事件（例如设计决定）的信息。这个信息应能帮助测试部门和其他部门避免在后续项目中犯同样的错误。错误是不可避免，在一个项目中可能出问题。从这些经验中学习就可能避免问题，避免今后的同样错误。从错误中学习的第一步就是记住它们，记忆的第一步就是把它们写下来。
