问如何开发和评审测试用例？

EN

让审阅者执行测试可能会发现一些遗漏，但永远不会是100%。

手工测试不是由计算机执行的，而是由头脑清醒的人执行的。人类可以思考，学习，看到模式。计算机，没有那么多(他们可以，但它需要深入学习)。

差异是根据人类的经验(每个人都不同)所作的不明确的假设。对一个人来说，显而易见的事情对另一个人来说并不是显而易见的。

即使我为自己编写了如何执行步骤的指导，但当我试图在一年后执行这些步骤时，我常常发现我忘记了提到一些“明显的”步骤。所以我把它们加到我的指示里，一年后，有时它对我来说也不明显，我可能需要更多的调查。

相反的情况也是正确的:有时过多的细节可能会令人讨厌。就像那些“假人”书一样，当他们反复解释一些琐碎的细节时，即使我是在20页前学到的，就好像我真的是一个什么都不记得的傻瓜一样。

最好的测试用例为将要使用脚本的受众提供了正确的数量细节，但没有更多。

这让我想起了敏捷宣言：

过程和工具上的个人和交互

如果缺少的是“关键信息”或“重要细节”，那么您的方法似乎只是结果的补丁，而不是根本原因。当测试(甚至在开发阶段)缺少重要的细节时，这是一个需要团队解决的问题：

• 员工真的了解故事，它的好处和对系统的影响吗？
• 他们从一开始就意识到这个信息吗？
• 这些信息/细节在需求阶段是否清楚地传达，并记录在您使用的故事管理工具中？
• 等等-任何其他问题，以确定问题的根本原因。

如果答案是否定的，那么您就知道需要修复的区域，而不是额外的成本审查过程。你可以从团队那里得到反馈并不断改进。

如果这些问题的答案是肯定的，他们就会理解这个故事。细节是清楚的，沟通和记录的。我认为这类问题应该是小的。

然而，我仍然看到了审查测试方法、测试技术、带有角落案例的测试覆盖率或功能性/非功能性/安全性测试的好处，以获得更多对产品的信心，而不是故事中的重要细节。

希望能帮上忙

这种新方法有意义吗？

也许吧，但你怎么确定？测量一段时间内不完整的测试案例的数量。再次更改过程和度量。现在好多了吗？这可能有点费时，但您的团队可能已经对缺陷泄漏做了类似的工作。

最好是举行一次系统思维会议。考虑到当前的系统如何影响不完整测试用例的数量，寻找具有积极效果的循环，并试图使这些循环变得更好。定义一些行动和实验。监控你的过程/系统并不断改进它。这意味着在流程/系统中添加和删除步骤。

在您的过程中添加更多的门时要小心。你真的想让你的过程更加繁重和耗时吗？目标不是更好的测试用例，而是更少的缺陷在生产中，也许有完全不同的方式来达到你的目标。

我的建议是:不断地实验，评估，适应。开始尝试吧。使用PDCA循环。