我们尝试了以下方法：
方法1：项目经理以较高的视角编写测试，例如“创建用户并在数据库中验证”，而不是“转到视图A，单击B并输入C。期望，该用户已添加到表D中”。这些测试的结果在某种程度上使项目经理和测试人员感到沮丧。由于测试脚本对于不太了解产品规格的测试人员来说模棱两可，因此提供给项目经理的反馈也是如此。此外，在某些情况下，这表明项目经理没有尝试编写预期输出的详细信息，因为他不知道应用程序的构建情况。
方法2：项目经理为以下项目编写详细的测试：测试人员。这具有项目经理必须很好地理解控制下的应用程序的优点。他利用自己的全部创造力发明了对应用程序功能和风险有一定涵盖范围的方案。另一方面，测试人员的创造力几乎没有余地。实际上，我们从测试人员那里得到了反馈，他们对进行“猴子工作”感到沮丧。那么，如果项目经理编写了测试，为什么还要打扰测试人员呢？
选项3：以上折衷方案。项目经理编写测试的子集。他与测试人员一起坐了一两个小时，以介绍该应用程序并在执行初始测试期间提供帮助。它们总体上对应用程序预期的行为有一些常识。测试人员的创造力仍然有一定的空间（探索，给出不同的测试场景），但是测试人员不再问“像这样工作是否正确？”这样的问题。如果测试不太详细或某些动作的预期输出尚未定义，会议（一次或多次，如有必要）将立即反馈给项目经理。附加值是测试人员可以接受有关应用程序的培训。当他稍后为客户提供应用程序支持时，这将很有用（是的，我们在组织中同时使用测试人员）。缺点是，这些会议花费了双方的时间。 br />选项4：自主测试人员小组。测试人员要掌握规范，并根据规范自行编写测试。这是理想的情况，因为他们有时间了解应用程序领域，同时仍然利用他们的经验来创建有用的测试。
如果您没有选件4的预算并且仍想比选件1、2和3做得更好，如何为测试人员编写测试？
#1 楼
您的问题似乎提出了两个问题：哪个测试过程最有效，哪个测试过程最令您的测试人员满意（或最不沮丧）？您可能认为这些问题之间的联系是如此紧密，以至于密不可分，但是您的管理层可能会有不同的看法。您说选项1不能给测试人员足够的信息来确定软件是否正常运行，而选项3则很耗时。您说选项2使测试人员感到沮丧（甚至侮辱），并且您为问题命名的方式增强了这种情绪。但是，您没有说选项2是否有效。如果选择2有效（如果发现了足够多的错误），那么您的组织可能需要测试人员，他们比目前的测试人员对猴子测试的满意度更高。如果选择2无效，请考虑您的时间限制，我很难对选项3进行改进。在某些组织中，测试人员会通过与项目团队其他成员参加会议来了解该应用程序。但是，如果Option 3的会议时间太长，我怀疑测试人员也没有时间进行项目会议。
您没有提及开发团队如何测试他们的工作。如果这四个选项都不可行和/或没有效果，则可能需要将更多的测试工作推回开发人员手中。以我的经验，这是一个较弱的解决方案-许多开发人员都不想进行测试，尤其是不定期进行测试-但在短期内可能会有所帮助，直到您可以雇用更多的测试人员或给现有的测试人员更多的时间来做他们的工作。
#2 楼
任何列出的方法都可以在适当的位置上与适当的人员一起使用。但是您需要了解的是，
通过详细的测试可以提供约100％的产品覆盖率如果做得对，则为全职职位（甚至2个或更多）。将这项任务分配给PM会浪费金钱。
资格过高的人很快会变得不高兴做猴子工作。
自动化测试套件是一个独立的项目，具有自己的bug / bug /发行版/路线图，这需要：
a。要求（主要是详细的测试用例）。
b。开发人员/操作员，他们将运行该套件以及一段时间内发现的文件/修复程序/修补程序/ hack实时变通办法问题。
c。编码技巧，以便在初学者退出后的第二天使用/修复/改进此套件。
因此，如果您有1个繁忙的PM和一堆中级测试人员，请考虑以下问题：
项目经理以简短的说明优先考虑这些功能。
在测试人员之间拆分产品模块，并让每个测试人员通过测试覆盖自己的模块。
当回归测试的时候到了，让测试人员测试其他人的模块。每次轮换作业。
这将产生一些结果：
项目经理有空的时间直接负责。
测试人员的创造力和快乐时光
和测试人员之间的反馈和知识转移，从而提高了文档质量。
评论
如果无法100％覆盖，则旋转+1表示测试仪旋转，并注意选择焦点区域。什么样的文件质量会提高？
– dzieciou
2012年2月8日在7:51
@dzieciou，因为承保范围是由具有不同技能水平和愿景的工程师分配的–在开始的测试用例中，文档看起来会非常不同。但是随着时间的流逝，团队的每个成员都将审核每个文档，并使用提议的建议进行更新。最终，好的部分将保留下来，坏的部分将消失，最终您将获得更好的文档和更好的团队。
– Misha Akovantsev
2012年2月8日13:35
#3 楼
听起来您在疯狂的土地上工作...我的第一个问题是测试人员的价格是多少？下午坐下来编写所有测试会便宜些吗，他没有要做的更好的事情（例如管理项目）吗？
听起来您需要有人坐在PM和测试人员（例如测试经理）之间，他们可以与PM紧密合作以确保他们将所有知识转移给了测试人员。测试经理还可以与开发团队联系，以了解他们已经实现了什么（可能与PM所设想的不一样），并且理想情况下，还是让用户确切地了解他们想要的东西（又可能与用户的想法有所不同）。开发人员和PM已经完成）。
一些肯定（可能不是全部）：
测试经理应该一直在为测试人员服务，而
/>由于角色的角色，PM将有有限的时间。
测试经理可以定期向PM提供有关PM测试进展的最新信息
，并且应该了解总体情况关于
产品始终与测试人员一起工作的状态
（对于可能没有真正感觉
产品好坏的产品经理来说，这是非常宝贵的由于接触有限，他们通常会进入测试团队。）
一些负面因素：
如果您遇到一个差劲的测试经理，沟通技巧，或想要向自己发送大量信息而不将其传递给您，这将遇到真正的问题（但此人首先不应该是测试经理）。
测试人员应该为回归包（甚至更好地实现它们的自动化，并使其在CI系统上运行），并执行尽可能多的探索性测试（因为这就是您发现真正的bug的地方）。
评论
您正在谈论理想情况。我们组织中的专用测试人员“处于灭绝的危险中”，因此价格昂贵。他们被委派给更紧急的任务，即在生产中支持我们的应用程序（处理来自客户的问题报告的第一行），并验证最终版本。让他们专注于一个星期的项目，阅读规范，编写好的测试是不可能的，因为它们一直在分散注意力。鉴于此，在这里PM通常会成为测试经理和测试人员，并且需要尽可能有效地使用测试仪，因为只有在这种情况下才有可能。
– dzieciou
2012年2月8日在7:50
我不同意，我谈论的是绝大多数公司的结构方式。测试人员和支持人员具有非常不同的技能，不一定可以互换。听起来您的问题比迄今为止共享的问题更根深蒂固...
– Ardesco
2012年2月8日在23:28
评论
谢谢。我需要在没有情绪的情况下更好地研究备选方案2的有效性。正如我在@Ardesco的回答下所发布的那样，测试人员在这里是昂贵的资源，因此必须在他们，开发人员和PM之间共享测试。
– dzieciou
2012年2月8日在8:10