第一个是封邮件：改进测试过程 全文如下：
大家好：
我们正在面临一个严重的风险那就是无法完成【测试】开发。即使“问题”文档中的每个问题【例如，需求中的未解决问题】都在今天得到解决，基于测试人员现有的大量的测试执行需求，我仍然怀疑【测试工程师】能有时间来完成所有未完成测试用例的开发。【因此】我建议我们（我们3人）用以下类别来挑选剩余的测试用例：
1.覆盖关键的质量风险。必须在这部分寻找尽可能多的缺陷；必须完成测试开发并生成可靠的测试用例。
2.覆盖重要的质量风险。必须尝试发现关键的（影响客户的、数据丢失或商务妥协）缺陷；必须完成测试开发，但是测试用例可以留有一定的不清晰性。
3.覆盖非重要的质量风险。在这部分进行随机测试或不进行测试都是可以接受的，在时间允许的情况下完成测试开发。
我们可以和所有相关人员召开【一次】会议...【来解决】所有和第一类测试用例有关的问题。
回复1：客户联系人要求提供一些有关未完成测试数量的度量。 （测试经理：提供了对应的细节）
回复2：根据现有的信息尽测试部门的可能做到最好。
最终：测试部门在测试规格说明书和测试执行采用了“最佳猜测”的方针。该方针导致了在测试执行期间存在大量的错误肯定，实际上把缺陷报告过程变成了反向追溯需求规格说明的过程。
第二个是表格：测试结果总结举例
测试结果总结举例
作为测试经理，倾向于不生成任何类型“必须修复”缺陷列表。---最好由项目利益相关者的跨职能团队去进行。本例是客户要求测试部门给意见，所以才写出想法。
