QA角色-它到底是什么？
我已经见到过好几次，那些打算用敏捷开发的公司将项目里做自动化测试的QA角色，仅仅视为一个瀑布模型的测试人员。
我的意思是因项目需要做手动测试的人，也会看到测试代码（当然后者取决于很多因素）。
在我看来，这种描述对我所认为的QA角色在广度和深度上是一种伤害。我经常花费相当多的时间跟客户解释这个角色的其他方面，以及每一个方面带给团队和产品的价值。
这样解释了几次之后，我发现做一张（只有一页）图片有助于讨论。这对我的视觉提示是非常有用的。如下图所示，每一部分的描述都遵循该图：
标题
顶部和底部的文字是对一个QA所能带给项目的总结：“我们在开发正确的产品吗？如果是，那么我们开发的产品正确吗？”在这个角色里的人需要不断提问这个过程中的所有部分来确保团队在开发所需的产品。
我个人不建议在这里用“质量”这个词，而是用“正确”。通过使用“正确”，关于重点，我有了更好的想法。
有个例子是如果从美学角度来看，呼叫中心应用程序的用户界面看起来很恐怖-色彩图案使得边界难以区分，流程设计很差，需要大量的点击拖拽等。然而，在这个例子中对用户来说用Tab键移动光标是很完美的，因为那是唯一一种用户与界面打交道的方式，那么对客户来说，这就是正确的产品。
用“质量”这个词意味着多件事情对应多个人-用“正确”这个词最大限度地减少了一个团队里多种意见产生歧义的可能性。
原则
左上角的图片有助于讨论可维护测试框架的策略和建设，这个原则的体现就是测试金字塔。
右上角的图片通过一个接一个的用户故事表明了一个QA经常在想什么，和团队在讨论什么。这并没有体现出他们积极参与进所有活动中。
实践
中间的图片从一个QA的角度表明了一个用户故事的生命周期以及他们会参与的每一个点。
将一个故事生命周期里的这些点，与传统瀑布模型测试人员参与的自动化测试里的那些点比较，突出了这个角色额外的范畴。这个角色包含了寻找接下来会发生什么并且确保观点和描述充分，而不仅对一个已经建立好的东西进行评论。
环境
左下角的图片有助于从环境角度来解释，减少风险并通过开发正确的产品来帮助团队获取信心的活动。每一个环境都提供了平台来对产品做唯一验证，每一个环境都从不同角度对产品提供了益处。
这个角色的广度和深度
右下角的图片解释了没有QA角色是完全一样的。这个角色中的有些人对迭代经理的角色有深入的理解，如果项目需要，他们可以无缝进入这个角色。有些人可以在不需要任何培训的情况下做需求分析的工作，有些人可以担任用户体验的角色，有些人可以担任开发的角色。每一个人都有独一无二的这些能力的混合技能。
需要重点指出的是一个QA对团队里的每一个角色都有基本的了解，像这种“通才”一样。他们需要对这些角色的广泛理解来明白项目和产品是怎么运作的，因此可以对需要提升的实践、流程提供反馈。最重要的是，通知团队有关正在开发的产品是不是客户想要的。
希望这个图表也总结了你所认为的QA角色的实质，希望对你就该话题可能做出的任何讨论提供帮助。
【英文原文：https://www.thoughtworks.com/insights/blog/qa-role-what-it-really】
{测试窝原创译文，译者：思雨}
译者简介：思雨，从事软件测试7年，热爱自动化测试和手工测试
