2006-05-25 16:59
测试员愿意说:"没有规格说明我怎么测试?"如果要求提供说明就要使用它.要保证项目经理和规格说明编写人员知道测试员要使用,并且知道将如何使用.否则以后他们就不会像测试员提供会他们带来不便的任何材料.他们会说:"我为什么要给你这个?你让我花了那么长的时间为你编写规格说明,但你根本没有用."
2006-05-25 15:31
有大量缺陷是由为了完成项目而加了很多班的程序员在项目的最后几周修改（并延迟）的。对于困难的项目，程序员常常睡眠不足，承受很大压力，并受到太多的咖啡刺激。要编写使这些程序员能够理解的报告。
要使重现步骤的描述简洁:
一次只走查该程序错误一步。
为每一步编号。
不要跳过重现问题所需的任何步骤集。
列出使读者能够重现失效的最少步骤集。
通过空行报告更容易浏览。
使用简短句子。
说明实际发生了什么，自己预期会发生什么。
如果后果很严重，但是测试员有理由怀疑程序员不理解为什么很严重，..
2006-05-25 15:08
别人也会做同样的假设，结果是一些明显的程序错误一直没有报告，直到被B测试员发现。如果认为某个程序错误可能已经被报告，可利用跟踪系统来察看是怎样描述的，以及反应是什么。也许自己可以通过补充注释或增加信息来强化错误报告。如果老的错误报告写得太弱或被拒绝，则有必要写新的错误报告。
对于一些严重程序错误，我们见到过这种情况发生。很多人都知道该程序错误，，但是所有人都假设其他人已经报告了。有一次，直到产品被交付后才真正修改。
2006-05-25 15:00
不要等到第二天或下周才报告程序错误,不要等到忘记了一些关键细节才报告.拖延的时间越长,程序错误被解决的可能性就越小。
拖延报告的另一种风险是：如果经理知道测试员在测试产品的某一部分，而且没有看到错误报告，他们会错误地认为测试员没有发现程序错误，那么这部分功能一定很稳定。
2006-05-25 14:45
质量对于个人来说就是价值。
不同的人对于产品有不同的期望，但是如果产品的合法项目相关人员由于产品做的或没做的事而对产品感到失望，感到产品不那么有价值，那么应该作为错误报告写出来。
测试员的任务就是帮助这样的人写出报告，清晰、有效地表达他们的意见。
2006-05-25 14:37
测试员写得错误报告是要求改正错误的分析文档。
有些错误永远也不会被改正。测试员的责任不是保证所有错误都得到改正，而是准确报告问题，使读者能够理解问题的影响。
深入研究并写出好的报告，常常对错误改正的可能性产生巨大的影响。
2006-05-25 14:31
错误报告是大多数测试员的主要工作产品。测试员的读者通过这些文档认识测试员。报告写得越好，测试员的声誉越高。
程序员通过测试员的报告得到关键信息。重要问题的良好报告会为测试员带来良好的声誉，差的报告会为程序员带来额外（在程序员看来是不必要的）的工作。如果测试员浪费太多的时间，程序员就会躲避测试员及其工作。
程序员并不是测试员的唯一听众。项目经理和执行经理有时也阅读错误报告。人事管理问题会很快引起他们的注意，并刺激他们的神经。这些错误报告看起..
2006-05-25 13:55
测试员很想根据自己的直觉使用具体的测试数据，或判断具体的输出，即测试员自己知道的“本能感觉”，即使说不出来使用这些知识的合理性的理由。我们认为这是由用的感觉，但是只是在开始时更有用，而不是在其他时候。
除了直觉有很强的偏见这个事实之外，真正的问题还在于测试员试图让其他人（例如程序员和经理）认真地对待自己的错误报告和质量评估。除非这种发现是基于大家都有的直觉，否则测试员的工作建议很可能不被采用。
因此，我们建议把直觉用作指南，但不能用作合理..
2006-05-25 13:40
测试员太容易把自己看作是质量卫士了。但是测试员即不会提高质量，也不能降低质量。测试员表现出好像是自己“制服”了产品，但是实际上产品到测试员手中时已经被制服。质量来源于构建产品的人，有时这对他们来说是要背负的沉重负担。测试员使命中的很大一部分，就是帮助他们更有效地对付真正的负担。如果测试员自认为是项目团队中唯一关心交付好产品的人，就不能很好地完成这部分使命。
测试小组的任务可能叫做“质量保证”，但是测试经理可别也这样认为。测试员的测试和错误报告提..
