在敏捷开发中,谁应该编写测试用例？

Question

我们的团队有一个任务系统,我们发布分配给每个开发人员的小型增量任务.

每个任务都在自己的分支中开发,然后在合并到主干之前对每个分支进行测试.

我的问题是:任务完成后,谁应该定义应该在此任务上完成的测试用例？

理想情况下,我认为任务开发人员本身最适合这项工作,但我认为开发人员有很多阻力,他们认为这是浪费他们的时间,或者他们根本不喜欢这样做.

我不喜欢让我的QA人员这样做的原因是因为我不喜欢他们创造自己的作品的想法.例如,他们可能会遗漏那些测试过多的工作,他们可能不知道所需的技术细节.

但同样地,开发人员做测试案例的部分是,他们可能会遗漏他们认为会破坏的事情.(甚至下意识地也许)

作为项目经理,我最终自己编写了每个任务的测试用例,但我的时间已经征税了,我想改变它.

建议？

编辑:通过测试用例我的意思是在应该合并到主干之前应该对分支执行的各个QA任务的描述.(黑盒子)

Answer 1

团队.

如果缺陷发生在客户身上,则是团队的错,因此团队应该编写测试用例以确保缺陷无法到达客户.

1. 项目经理(PM)应该比团队中的任何人更好地理解域.他们的领域知识对于拥有对域有意义的测试用例至关重要.他们需要提供示例输入并回答有关无效输入期望的问题.他们需要提供至少"快乐路径"测试用例.

2. 开发人员将知道代码.您建议开发人员可能最适合该任务,但您正在寻找黑盒测试用例.开发人员提出的任何测试都是白盒测试.这是开发人员创建测试用例的好处 - 他们知道代码中的接缝在哪里.

   优秀的开发人员也会向PM提出问题"当......会发生什么？" - 每个都是一个测试用例.如果答案很复杂"如果a那么x,但如果是b然后y,除了星期四" - 有多个测试用例.

3. 测试人员(QA)知道如何测试软件.测试人员可能会提出PM和开发人员不会想到的测试用例 - 这就是为什么你有测试人员.

Answer 2

我认为项目经理或业务分析师应该编写这些测试用例.
然后他们应该将他们交给QA人员进行充实和测试.

这样,您就可以确保规范之间没有漏掉的差距,以及实际测试和交付的内容.

开发人员肯定不会这样做,因为他们将测试他们的单元测试.所以这是浪费时间.

此外,这些测试将发现开发人员永远不会发现的错误,因为它们可能是由于规范中的误解,或者通过代码的功能或路由未经过深思熟虑和正确实现.

如果您发现自己没有足够的时间进行此操作,请雇用其他人,或者提升某人担任此职位,因为这是提供优质产品的关键.

Answer 3

根据过去的经验，我们很幸运地定义了不同级别的测试来测试略有不同的东西：

第一层：在代码/类级别，开发人员应该编写原子单元测试。目的是尽可能测试各个类和方法。这些测试应该由开发人员在编码时运行，大概是在将代码归档到源代码管理之前，并且由持续集成服务器（自动化）（如果正在使用）运行。

第二层：在组件集成级别，开发人员再次创建单元测试，但测试组件之间的集成。目的不是测试各个类和组件，而是测试它们如何相互交互。这些测试应由集成工程师手动运行，或者由持续集成服务器（如果正在使用）自动运行。

第三层：在应用程序级别，让 QA 团队运行他们的系统测试。这些测试用例应基于产品经理提供的业务假设或需求文档。基本上，就像您是最终用户一样进行测试，做最终用户应该能够做的事情，如需求中记录的那样。这些测试用例应该由 QA 团队和产品经理编写，他们（大概）知道客户想要什么以及他们希望如何使用应用程序。

我觉得这提供了相当好的覆盖范围。当然，理想情况下，上面的第 1 层和第 2 层应该在将构建的应用程序发送给 QA 团队之前运行。当然，您可以根据自己的业务模式进行调整，但这在我上一份工作中效果很好。如果其中一个单元测试在构建/集成过程中失败，我们的持续集成服务器会向开发团队发送一封电子邮件，以防有人忘记运行测试并将损坏的代码提交到源存档中。