问Scrum团队中的每个人都对测试用例进行了评估吗？包括开发商？

EN

使用测试来驱动代码设计.

这是使用测试作为质量检查，后开发，而不是使用测试来揭示和推动前面的设计之间的区别。

“测试本身并不能提高软件质量。测试结果是质量的一个指标，但测试结果本身并不能改善软件质量。管理无法管理的软件。--麦康奈尔

当您预先编写测试时，使用应用程序代码，可以创建可测试的代码。当你写测试之后，你没有。

为了利用这些知识来促进变革，我建议不要试图说服人们改变(通常不起作用)，而是开始推广和展示TDD和BDD

思考这个问题的一种方法是：“等等--开发人员在没有测试用例的情况下编写代码，以确保他们通过！天哪，他们怎么知道他们在编写正确的代码?因为他们是专业人员?因为我们信任他们?来吧，我们已经学习了一段时间了。”

预写测试！

另一个-他们已经在写单元测试了吗？你是在说UI测试吗？基于敏捷测试金字塔，也许您可以详细说明正在为Unit、Integrated和探索性测试做些什么。

使用三种Amigos方法

另一个好主意是使用三个朋友的方法。这样，无论何时提出、讨论、决定等新功能，您都有3种代表--产品、开发和测试。这样你就可以进行包括所有三方的对话。所以产品负责人可以说“不，我们不需要测试样例xyzabc (例如)，或者开发人员可以说，‘是的，我们已经在单元测试用例xyq123中讨论过了，测试人员可以问它是否包括条件A683，等等。

我亲眼目睹了两周的测试工作是通过6分钟这样的对话来确定的。

不过，不要在走廊的谈话中试图说服这一点。提供给管理层，确保入股，然后正式提交给团队.也可以在回顾展上提供。

当您觉得“我想让Scrum团队中的开发人员检查我的测试用例时。”认为“测试用例必须由Scrum团队中的开发人员检查”。只是要意识到，一个正式的实践将需要预先买进，而不是说服一个特定的例子。

我同意之前的回答--当我在一个Scrum团队工作时，我发现三种Amigos方法对于提出devs / test /产品所有者所认为不同的问题是非常宝贵的。

如果可能的话，把它作为一个专栏在你的董事会上，这样它就成为开发过程的一个正式部分。即使是非常小的问题，可能不需要它，必须通过专栏确保你考虑它。

除了上述答案之外，当今顶级软件测试公司也遵循以下方法:每当在产品中实现新功能时，产品所有者都会为更改创建一个设计文档，为QA提供将要实现的更改的详细信息！此外，在scrum中，因为我们每天都会有站立电话，询问有关新特性的问题肯定会有帮助。

此外，跟踪/日志工作的一个建议是，您可以要求scrum主创建一个QA分析任务，在该任务中，您可以记录花在浏览和理解新特性的设计文档上的时间。