QA到UAT移交过程？

Question

我们为一家银行工作，我们的团队负责在我们的移动或网络银行系统中对产品或功能进行UAT测试。通常，IT处理开发，然后发布给QA ( it的一部分)进行测试。现在，这些测试对于我们的UAT团队是不可见的，因为我们编写了自己的测试。

问题是，在大多数情况下，QA交付不符合UAT的预期标准，我们最终发现了在QA过程中应该发现的问题，导致我们花费了更多的时间和精力。

你会推荐什么作为移交过程？我们应该从质量保证中得到什么可交付的成果？测试用例列表？一份调查结果清单？通过/失败方案？你有什么推荐的？

Answer 1

显然，我们不能远程解决这个问题，我们需要和他们的团队一起坐下来，一起思考为什么测试不是应该的(不管它在您的上下文中意味着什么)。这就是关键所在，沟通，谈论他们做什么，他们不做什么，为什么和需要做什么，以提供一个更好的产品。这是一个团队的努力，而不是一个人，一个经理，甚至一个团队在这种情况下的努力。你需要把人们聚集在一起，并把它作为一个问题来处理，而不仅仅是他们和我们之间的问题，这创造了一种指责文化，但从长远来看，这很难帮助你提供更好的产品。

你会推荐什么作为移交过程？

没什么。从长远来看，更正式的规则不会有多大帮助。合作，配对，更多的沟通将有所帮助。我知道，这比对他们施加更多的规则并命令他们遵守规则更困难，也更难。

我们应该从质量保证中得到什么可交付的成果？测试用例列表？一份调查结果清单？通过/失败方案？

测试是一种性能，而不是一种东西，一种状态，一种文档等等。想想看:你要求他们给你一个测试用例的列表。你肯定会得到一些，特别是当他们很想失业的时候。但是它并没有说明测试用例在上下文中是否合适。因此，它不会对你的整体素质有所帮助。

我认为您所描述的是团队的一个典型问题，他们现在以敏捷的方式工作，而是拥有自己的部门和严格定义的角色。这就造成了这样的情况:人们彼此之间不经常交谈，互相指责，甚至不知道其他人做什么等等。作为一种(部分)补救办法，我建议：

• 和他们的QA团队坐下来，试着理解他们做什么测试，他们不做什么，为什么，如果他们缺少什么东西(也许你没有为他们提供足够的业务背景，所以他们不知道什么是对业务人员重要的事情)
• 尽量多交谈，也许你可以带他们去参加你的会议或会议(如果有的话)，你可以一起计划测试，一起创建测试数据。
• 您可能会在测试时与它们结对，这可能是找到它们运行的测试以及它们如何设计和执行它们的最直接的方法。

我甚至觉得这不需要缓慢或冗长的改变。如果人们愿意一起工作，你可能很快就会解决这些问题。维持(一些)这些变化将更加困难。

Answer 2

问题的第一部分是QA测试用例确实缺少了您的团队目前正在UAT中验证的内容。造成这种情况的原因有多种。

1. 谁是测试谁没有结束的理解。他们只从组件测试的角度来思考他们的测试。
2. QA可能对测试中的功能了解较少。
3. 没有或更少的测试用例审查是从业务或产品所有者进行的。
4. QA env不是为端到端测试设置的。
5. UAT团队不参与QA活动。

你能做什么来解决它..。

1. 让UAT团队参与QA周期。
2. 应该与UAT团队一起召开测试用例评审会议，以关闭缺失的案例。
3. 任何端到端测试下的障碍都应该被移除。
4. 回归测试应自动化，并应定期更新，并应作为退出标准提出。

希望这有帮助..。