我是美国一家小公司的软件工程师。我们有一支离岸质量检查团队。在我们的组织中，我们拥有一套不全面的自动化测试套件，由开发人员拥有。我们尝试采用一种敏捷方法，最近从scrum过渡到了看板。
当我从“准备工作”中选取一个故事时，它必须具有一定的数据，包括接受标准。它必须确切列出它的工作方式，影响的对象等等。作为我工作的一部分，我编写了覆盖代码的单元测试，用于验证服务级别交互的集成测试以及使用Cucumber / Gerkin进行的行为自动化测试。我确保将功能部署到开发VM并通过自动测试以及一些基本的端到端健全性检查来运行。然后，一旦我对故事能够按预期进行了满意，并且故事成功通过了代码审查，就被传递给了质量检查人员。提供测试输入。“
我们的质量检查团队可以访问我所做的一切。所有相同的支持文档-设计文档，建筑文档，我所有的代码，开发VM，甚至我的小黄瓜功能。如果要设计一个测试用例，我将使用与它们完全相同的数据。
对吗？我应该给他们写一些测试案例，希望它们能死记硬背吗？是他们的责任，是我的责任，还是别人的责任？还是这因组织而异？
#1 楼
以我的经验，这取决于测试人员，原因是开发人员无法测试自己的工作。您找不到自己的错。就是说，我认为测试也不会对您造成伤害...但是您需要在某些地方划清界限。QA是独立的，而您正在努力相同的目标，应该有不同的方法。也就是说，您进行单元和单元集成测试，他们可以进行系统和系统集成测试-还可以像最终用户一样使用该应用程序，尝试破坏系统，考虑您本来不会考虑的测试，等等。
我以后可能会对此进行扩展，但是就个人而言，这听起来像是您在做他们的工作过多。 。如果您在TDD环境中工作，那么您将负责开发。
#2 楼
在我们公司中，我们相信“制衡”，因此整个过程是以下主要力量之间的平衡：业务管理，要求主要功能并设定优先级
了解客户需求和思维模式的业务分析师，编写故事要求，
开发人员，理解代码，还编写测试（单元，e2e等）
DBA和sysadmins
手动质量检查，确保所有部分协同工作并遵循流程（并不断努力改进流程）的人。
自动化回归测试器（也编写e2e测试）
我们（QA）强调所有（甚至次更改）至少要由来自不同领域的两名参与者进行审查。
因此，在OP的情况下，开发人员不应编写测试用例，因为这是未经检查的功能。如果开发人员误解了需求，然后根据这种误解编写了代码并进行了测试，将如何检测到它？
对于90％的错误/功能/变更，业务分析师会创建测试用例。通常它们对于实际测试而言不够具体，QA与BA合作使测试用例足够具体，经常要求开发人员提供一些可以观察到特定功能的特定数据ID（启用了受测功能的用户，等等）。在许多情况下，即使测试用例不是100％详细，QA也可以填补先前测试中获得的经验空白，并且只需通过BA确认细节（以确保QA不会引起误解）。
当然10％的更改足够古怪，必须以不同的方式进行操作：
太琐碎（例如，拼写错误，外部链接页面的URL更改了）
特定于DBA / syadmin（不涉及BA）
特定于dev（例如，库升级，不涉及BA）
但是对于大多数更改，BA都会打电话：决定需求，以及如何测试功能。有时，在开发人员实施提案草案之后，BA意识到他的理解还不完整，因此更改了需求，或者决定发布仅实现部分需求的产品（推迟第二阶段的休息）。这是正常的。
质量是整个团队（不仅是质量检查）的责任，所有参与者都在学习和提高与其他所有人的合作以提供最佳质量。
因此，您的外部质量检查人员需要“成长”，并开始积累有关如何测试以及如何找到他们需要测试的信息的知识。可以问一次，但第二次他们应该已经学习了，应该询问他们是否正确理解了。
他们还需要学习如何获取输入信息的方法，就像您一样能够找到它：与BA对话，查询数据库等。
#3 楼
Internet上没有随机的人可以告诉您对您所在组织的情况有意义的信息。这里是您找出对您的情况有意义的一种方法：
确定如何衡量成功。
选择一个策略（开发人员编写测试用例，或者质量检查人员编写测试用例，都编写测试用例，等等）。
衡量策略的运行情况。
确定您的策略是否足够成功。
如果您的策略没有足够成功，请对其进行更改并返回到步骤3。
#4 楼
谁拥有知识？而不是专注于谁负责某项工作。一个更重要的问题是-谁应该保留有关它的知识。这不是一个可以为您解决的问题，但可能需要考虑以下因素：
是否由外部来源（例如金融监管机构）设定了要求？如果是这样，也许您不希望开发人员成为维护知识的人-您希望测试团队随时了解最新法规，并将该知识应用于测试创建。
您是否正在测试您没有破坏某些功能吗？如果是这样，则可能是开发团队维护有关如何运行内部功能，使用内部上下文等方面的知识。对于开发人员自己而言，编写测试将是最有意义的-他们可以检查其是否仍然有效在为它们创建的预期范围内。
您是否创建了大量类似的产品？在这种情况下，每个开发人员可能只知道他们对当前项目的需求，而测试团队将面临大量类似的问题。测试团队保持对预期的错误的了解，并准备测试用例进行检查是很有意义的。
在大多数情况下，我建议您会发现没有一个错误可以解决。为您组织中的所有产品和测试提供答案。但是找出谁最有能力维护如何测试每个系统的知识也将回答谁最有资格使用该知识编写测试。
#5 楼
从我的角度来看，您已经在做很多事情来检查您创建的内容是否如您认为的那样有效。许多开发人员并没有做那么多...我希望QA团队（尽管老实说，我不赞成这种远程和分散的设置）调查自己是否你做的很明智，还可以。并且他们为他们认为缺少或无法满足您所构建内容的实际需求添加测试。这意味着他们需要了解交付的目的是什么。
对我来说，您的质量检查越位团队需要所有细节，以便他们可以重放您所做的事情。我也去过那个地方。那在我的书中没有增加任何真正的价值。
对您的问题：我认为它们是错误的，但是-我在这里做了一些个人假设-这可能就是它们如何工作的方式。他们向您核对您的工作。而已。
评论
老实说，我们（开发人员）过去只做单元测试。但是，由于我们与质量检查小组的持续困难，导致我们需要做更多的工作，包括接管曾经是质量检查部门权限的自动化测试。我感谢您的观点，这是他们习惯于工作的方式，并将与我的经理联系。
–罗迪
18年1月12日在14:55
就像我说的那样：我以前去过那里（为一家拥有离岸质量检查的大型银行工作）。我的经验是，这是浪费时间和金钱。我认为您的本地团队正在朝着“正确”（我认为）的方向努力，以完成所有工作。这可能意味着要添加一些测试人员。因此，您成为了一个真正的敏捷团队。我们采取了这一行动;-)
– Ray Oei
18年1月12日在15:02
有趣的是，我们曾经做过内部质量检查。大约三，四年前，我们搬到了一支离岸团队。
–罗迪
18年1月12日在15:04
另外要补充的是：由于离岸外包的问题，您显然正在内部处理大量工作：合理的是，如果您的管理层能够提供所需的东西，您的管理层也将显得至关重要。
– Ray Oei
18年1月12日15:04
离岸外包一直是个大炒作...但是，如果我看看我的国家正在发生什么：许多大公司要么“近在”支持，要么将其重新安置。同样是因为创建了真正的（例如，坐在同一个房间里一起）敏捷团队。
– Ray Oei
18年1月12日在15:06
#6 楼
通常，面向业务的测试应由测试人员设计，而面向技术的测试应由开发人员设计，假设测试人员仅参与黑盒功能测试，这可能会因团队而异。如果您敏捷之后，每个用户故事都应具有定义明确的接受标准，该标准应足以得出面向业务的测试。
评论
为自己，团队，质量保证人员和公司节省很多压力和技术债务。如果您在敏捷商店中，请进行测试驱动的开发。谢谢，但这不能回答我的问题，而且我当然没有权力在编程方法论上进行范式转换。
这是测试用例设计者的责任。通过这个答案，我的意思是，如果您没有这个角色，则需要有人担任，而可以是拥有知识/资源的任何人。我们可能会担任首席执行官。我想最常见的是质量检查人员和/或开发人员和/或产品负责人
答案不是很多，而是一条建议：我一直处于同样的情况，即离岸质量检查团队需要很多人手（但那时仍然没有完成任何富有成效的工作）。如果他们没有增加价值，但是需要开发人员做更多的工作，请跟踪您花费在内部QA团队过去做的事情上的时间，以及在沟通开销上花费的时间。拥有这些数据可以帮助管理层表明，离岸外包很可能是虚假的成本节省，因为这通常是离岸外包的主要原因。
如果您涵盖单元测试，集成测试，甚至是基于BDD的验收测试，那么质量保证还剩下什么呢？