我们的团队有一个任务系统，我们在其中发布分配给每个开发人员的小增量任务。
每个任务都在自己的分支中开发，然后在合并到主干之前对每个分支进行测试。
我的问题是：一旦任务完成，谁应该定义应该在这个任务上完成的测试用例？
理想情况下，我认为该任务的开发人员本人最适合这项工作，但我遇到了很多开发人员的反对，他们认为这是浪费时间，或者他们根本不喜欢这样做。
我不喜欢我的 QA 人员这样做的原因是因为我不喜欢他们创建自己的工作的想法。例如，他们可能会遗漏那些测试工作量太大的东西，并且他们可能不知道所需的技术细节。
但同样，开发测试用例的开发人员的缺点是他们可能会遗漏他们认为会破坏的东西。（甚至可能下意识地）
作为项目经理，我最终自己为每项任务编写了测试用例，但我的时间被占用了，我想改变这一点。
建议？
编辑：通过测试用例，我的意思是在分支合并到主干之前应该对分支完成的各个 QA 任务的描述。（黑盒子）
如果缺陷传给了客户，那是团队的错，因此团队应该编写测试用例以确保缺陷不会传给客户。
项目经理 (PM)应该比团队中的任何人都更了解该领域。他们的领域知识对于拥有对该领域有意义的测试用例至关重要。他们需要提供示例输入并回答有关对无效输入的期望的问题。他们至少需要提供“快乐路径”测试用例。
开发人员将知道代码。您建议开发人员可能最适合该任务，但您正在寻找黑盒测试用例。开发人员提出的任何测试都是白盒测试。这就是让开发人员创建测试用例的优势——他们知道代码中的接缝在哪里。
优秀的开发人员也会向 PM 提出“什么时候……应该发生什么？”的问题。– 每一个都是一个测试用例。如果答案很复杂“如果a则x，但如果b则y，星期四除外”——有多个测试用例。
测试人员 (QA)知道如何测试软件。测试人员很可能会提出 PM 和开发人员不会想到的测试用例——这就是为什么你有测试人员。
我认为项目经理或业务分析师应该编写这些测试用例。
然后，他们应该将它们交给 QA 人员进行充实和测试。
这样，您可以确保规范与实际测试和交付的内容之间没有遗漏。
开发人员绝对不应该这样做，因为他们将测试他们的单元测试。所以这是浪费时间。
此外，这些测试将发现开发人员永远不会发现的错误，因为它们可能是由于对规范的误解，或者没有经过深思熟虑和正确实施的代码中的功能或路线。
如果您发现自己没有足够的时间，请雇用其他人或提拔某人担任此职位，因为这是交付出色产品的关键。
我们尝试将开发人员与 QA 人员配对，结果非常好。他们通常“保持彼此诚实”，并且由于开发人员有单元测试来处理代码，她/他已经对这些更改非常熟悉。QA 人员不是从黑匣子方面来的。两人都对完整性负责。正在进行的审查过程的一部分有助于发现单元测试的缺点，因此我知道没有太多事件是我知道有人故意避免编写 X 测试，因为它可能会证明存在问题。
在某些情况下，我喜欢配对的想法，并认为它运作良好。可能并不总是有效，但让来自不同领域的玩家互动有助于避免经常发生的“把它扔到墙上”的心态。
无论如何，希望这对您有所帮助。
根据过去的经验，我们非常幸运地在不同级别定义测试以测试略有不同的事物：
第一层：在代码/类级别，开发人员应该编写原子单元测试。目的是尽可能地测试单个类和方法。这些测试应该由开发人员在编写代码时运行，大概是在将代码归档到源代码控制之前，如果正在使用持续集成服务器（自动），则应该运行这些测试。
第二层：在组件集成级别，再次让开发人员创建单元测试，但测试组件之间的集成。目的不是测试单个类和组件，而是测试它们如何相互交互。这些测试应该由集成工程师手动运行，或者由持续集成服务器自动运行（如果正在使用）。
第三层：在应用程序级别，让 QA 团队运行他们的系统测试。这些测试用例应该基于产品经理提供的业务假设或需求文档。基本上，就像您是最终用户一样进行测试，做最终用户应该能够做的事情，如文档中的 int eh 要求。这些测试用例应该由 QA 团队和产品经理编写，他们（大概）知道客户想要什么以及他们应该如何使用应用程序。
我觉得这提供了相当不错的覆盖率。当然，理想情况下，上面的第 1 层和第 2 层应该在将构建的应用程序发送给 QA 团队之前运行。当然，您可以将其调整为适合您的业务模型的任何内容，但这在我上一份工作中效果很好。如果在构建/集成过程中其中一个单元测试也失败了，我们的持续集成服务器会向开发团队发送一封电子邮件，以防有人忘记运行他们的测试并将损坏的代码提交到源存档中。
我不喜欢我的 QA 人员这样做的原因是因为我不喜欢他们创建自己的工作的想法。例如，他们可能会遗漏那些测试工作量太大的东西，并且他们可能不知道所需的技术细节。
是的，你需要对你的 QA 部门有更多的信任，或者一个更好的部门。我的意思是，想象一下你说过“我不喜欢让我的开发人员开发软件。我不喜欢他们创建自己的工作的想法。”
作为开发人员，我知道编写自己的测试存在风险。这并不是说我不这样做（我这样做，特别是如果我在做 TDD），但我对测试覆盖率没有任何幻想。开发人员将编写测试来表明他们的代码按照他们的想法做了。没有太多人会编写适用于手头实际业务案例的测试。
测试是一种技能，希望您的 QA 部门，或者至少该部门的领导者，都精通该技能。
“开发人员认为这是在浪费时间，或者他们根本不喜欢这样做”然后奖励他们。让他们创建测试用例需要什么社会工程学？
QA 能否查看代码和测试用例并说出“没有足够的覆盖范围——需要更多用例”。如果是这样，那么立即拥有“足够”覆盖范围的程序员将是 Big Kahuna。
所以，我的问题是：一旦任务完成，谁应该为这个任务定义“足够”测试用例的目标？一旦知道“足够”，您就可以让程序员负责填写“足够”，让 QA 负责确保完成“足够”测试。
很难定义“足够”？有趣的。可能这首先是与程序员发生冲突的根本原因。他们可能会觉得这是在浪费他们的时间，因为他们已经做得“足够”了，而现在有人说这还“不够”。
QA 人员，连同“客户”，应该为每个任务定义测试用例[我们在这里真的混合了术语]，并且开发人员应该编写它们。第一的！
选择（不仅仅是随机挑选）一两个测试人员，让他们编写测试用例。审查。如果处理任务的开发人员查看任务的测试用例，它也可能很有用。鼓励测试人员提出改进和增加测试集的建议——有时人们害怕修复老板所做的事情。这样你可能会找到擅长测试设计的人。
让测试人员了解技术细节——我认为敏捷团队中的每个人都应该拥有对代码和任何可用文档的阅读权限。我认识的大多数测试人员都可以阅读（和编写）代码，因此他们可能会发现单元测试很有用，甚至可能扩展它们。确保测试设计人员从开发人员那里得到有用的答案，如果他们需要知道一些事情的话。
我的建议是在合并代码之前让其他人查看测试用例以确保质量。当然，这可能意味着一个开发人员正在忽略另一个开发人员的工作，但第二组眼睛可能会捕捉到最初没有捕捉到的东西。初始测试用例可以由任何开发人员、分析师或经理完成，而不是测试人员。
QA 不应该编写测试用例，因为它们可能是未定义预期结果的情况，此时，如果每一方都认为他们的解释是正确的，那么在 QA 和开发之间可能很难有人裁判。这是我见过很多次的事情，但希望它不会像现在这样经常发生。
我将我的测试松散地分解为“开发人员”测试和“客户”测试，后者将是“验收测试”。前者是开发人员编写的用于验证其代码是否正确执行的测试。后者是开发人员以外的其他人编写的测试，以确保行为符合规范。开发人员绝不能编写验收测试，因为他们创建正在测试的软件假定他们做了正确的事情。因此，他们的验收测试可能会断言开发人员已经知道是真实的。
验收测试应该由规范驱动，如果它们是由开发人员编写的，它们将由代码驱动，因此由当前行为驱动，而不是由期望的行为驱动。
敏捷规范是您应该（至少）有两层测试：开发人员测试和客户测试。
开发人员测试由编写生产代码的同一个人编写，最好使用测试驱动开发。它们有助于提出良好的解耦设计，并确保代码按照开发人员认为的方式运行——即使在重构之后也是如此。
客户测试由客户或客户代理指定。实际上，它们是系统的规范，并且应该以一种既可执行（完全自动化）又可供业务人员理解的方式编写。通常情况下，团队会在 QA 人员的帮助下找到让客户编写它们的方法。这应该在功能开发时（甚至之前）发生。
理想情况下，QA 在合并之前要做的唯一任务是按下按钮运行所有自动化测试，并进行一些额外的探索性（=非脚本）测试。您还需要在合并后再次运行这些测试，以确保集成更改不会破坏某些内容。
测试用例首先在故事卡中开始。
测试的目的是将缺陷推向左侧（在软件开发过程的早期，当它们更便宜且修复速度更快时）。
每张故事卡都应包括验收标准。产品负责人与解决方案分析师配对以定义每个故事的验收标准。此标准用于确定故事卡的目的是否已达到。
故事卡验收标准将确定开发人员在进行测试驱动开发时需要编写哪些自动化单元测试。它还将推动由自动化测试人员实现的自动化功能测试（如果使用 FIT 等工具，可能还需要开发人员的支持）。
同样重要的是，验收标准将推动自动化性能测试，并且可以在开发人员分析应用程序的配置文件时使用。
最后，用户验收测试将由故事卡中的验收标准确定，并应由业务合作伙伴和/或用户设计。遵循此过程，您可能会发布零缺陷。
除了在较小的团队中，我很少听说或见过项目经理编写测试用例。在任何大型、复杂的软件应用程序中都必须有一个真正了解该应用程序的分析师。我曾在一家抵押贷款公司担任 PM - 我是否了解次级贷款、利率等？也许在肤浅的层面上，但真正的专家需要确保这些事情奏效。我的工作是保持团队健康，保护敏捷原则，并为我的团队寻找新的工作机会。
系统分析师应该审查所有测试用例及其与用例的正确关系。另外，分析师应该执行最终的 UAT，这也可以基于测试用例。所以分析师和质量专家正在进行同行评审。
质量是在构建测试用例时审查用例，而分析师在编写测试用例后和执行 UAT 时审查测试用例。
当然，BA 是领域专家，而不是从技术角度来看。BA 了解需求，并且测试用例应该映射到需求。开发人员不应该是编写测试用例来测试他们的代码的人。QA 可以根据要求编写详细的测试步骤。但是编写需求的人应该指定需要测试的内容。测试用例到底是谁写的，我不太在意，只要测试用例可以追溯到需求。我认为 BA 指导测试方向或范围是有道理的，而 QA 编写细粒度的测试计划。
We need to evolve from the "this is how it has been done or should be done mentality" it is failing and failing continuously. The best way to resolve the test plan/cases writing issue is that test cases should be written on the requirements doc in waterfall or the user story in agile as those reqs/user stories are being written. This way there is no question what needs to be tested and QA and UAT teams can execute the test case(s) and focus time on actual testing and defect resolution.