对不起，我不同意相同的意见

-发现“很多”错误并不能成为“伟大”的测试人员。找到很多“重要”的错误（重要的错误，产生影响，提供与测试任务相匹配的正确上下文信息）。找到许多要执行的“新”测试可以使测试人员成为出色的测试人员，从而使企业更容易做出质量决策（正确的决策），从而成为出色的测试人员。

--换句话说，一个团队或一个产品不能依赖于测试人员来测试产品，而是依赖于他们来开发产品的测试用例。 如果软件（本质上）使得一旦编写的测试将保持在正确的上下文中，直到软件的生命周期，并且没有改变需求、没有增强、没有质量退化、没有新发现，那么这个陈述将是 100% 正确的软件经过设计，没有集成问题，没有跨平台问题，没有诉讼，没有竞争，没有学习，测试过程中没有新闻测试演变等

基本上，如果你觉得软件和测试的心态是这样的，软件永远不会改变，那么就没有必要观察测试期间（或之后）发生了什么，或者当出现故障时无需进行分析（真实或看似真实）....在这种情况下，一旦编写测试就足够了，任何人甚至 micky mouse 都可以进来执行测试并发布结果。

这取决于（像往常一样）。如果测试用例被适当地自动化，包括生成明确的通过/失败结果，那么任何人都可以运行测试。但是，如果这是一个手动测试、半自动化测试，或者如果结果需要人工干预，那么编写好的测试用例来包含所有可能的步骤和陷阱可能很难甚至不可能。

我相信对于优秀的测试人员有很多定义。在特定的上下文中，所有这些都是正确的。他们也都有缺陷。一个人可以对产品质量负责的想法是有缺陷的。

一旦有多个测试人员，测试团队就需要对需要测试的内容以及谁将进行测试有一个共同的理解是很重要的。在某些组织中，书面测试计划有助于这种理解。可以编写测试用例并将其组织成测试计划的人提供了有价值的服务。如果测试人员在编写测试用例方面做得很好，人们可能会称他为优秀的测试人员。

同时，书面测试用例本身只是纸上谈兵——仅此而已。文档——无论是测试计划、设计文档还是功能规范——很少能替代将产品导向其当前形式的目标、权衡和个性的内部化。除了最微不足道的情况外，任何人都无法在一夜之间将产品的目标和权衡内化。学习过程需要时间，并且需要与团​​队中的其他人互动。此外，每一个测试计划都是不完整的和有缺陷的，受到作者的看法、兴趣和经验的偏见。一个从别人有缺陷的、有偏见的测试计划开始的测试人员，在字里行间阅读，尽管工作乏味和重复，

质量是团队的努力。我并不是说每个人都出现在办公室并向鼓舞人心的优质海报致敬。相反，除非大家齐心协力，否则几乎不可能生产出好的产品。没有人可以将好产品的全部功劳归于任何人，也没有人可以将坏产品的全部责任归咎于任何人。