编译：TesterHome
原文标题：UI Testers Can Be a Developer’s Greatest Asset — If You Let Them
作者：Tammy Xu
本文作者 Tammy Xu 是 Built In 的前员工，报道整个科技行业的软件开发和趋势。她曾是陶氏的软件开发人员，拥有伊利诺伊大学厄巴纳 - 香槟分校的计算机科学硕士学位。Built In 是一家成立于美国芝加哥的在线社区，主要服务初创企业和科技公司。
以下为作者 Tammy Xu 的观点，来看看在美国，他们怎么看待开发人员和测试人员之间的关系。
“分享知识可以促进一种更有成效的关系。”
软件开发人员和软件测试人员有一种共生的关系 -- 好的代码需要彻底的测试，而没有任何代码，测试就无法进行。
然而，在实践中，这两个角色有一种踩到对方脚趾的方式。开发人员在公司里往往比测试人员更有威望，他们有时很难让开发人员认真对待他们的建议，或者发现他们的关切被推到了项目优先级的底部。
但是测试人员说这两个角色可以有效地共存。测试的工作看起来与开发人员的工作有很大不同，特别是在用户界面（UI）测试领域，双方可以从对方那里学到很多东西。以下是 UI 测试人员希望给他们的开发人员同事的建议。
来自 UI 测试人员的建议
因为 UI 测试的重点是用户界面，所以它看起来与其他类型的测试有很大不同。除了担心错误之外，UI 测试人员还要考虑用户体验因素，例如产品对最终用户来说是否直观。
KBR 公司的 UI 测试工程师 John Hill 说，开发人员可以把 UI 测试人员作为产品的一般用户群的代表。
"一个 UI 测试人员也是一个系统的用户，"John Hill 说。"你可以利用他们来获得一些很好的建议和反馈。"
这是因为 UI 测试大多由广泛的、系统级的测试组成，这些测试在项目或代码的工作单元结束时运行。UI 测试可以是自动化的，也可以是手动的，用来验证所有的代码是否正确地协同工作，程序是否按照预期运行。
"如果任何基础性的东西出了问题，你有一个巨大的堆栈 [正在测试]，试图钻研和隔离到底发生了什么。"
由于 UI 测试位于测试金字塔的顶端，它们很容易受到金字塔较低层次的不完整测试的影响，这包括单元和集成测试。
MathWorks 公司的 UI 测试工程师 Steve McClure 说，在把代码交给 UI 测试之前，其他测试人员和开发人员必须进行彻底的单元测试，以确保所有单独的代码组件都没有错误。
Steve McClure 说："在这一点上，如果任何基础性的东西出了问题，你有一个巨大的堆栈 [正在测试]，试图深入了解并隔离到底发生了什么 -- 这应该在单元测试的早期就被发现，"。"'缺陷定位'和分流的时间在系统级测试中是很重要的，所以最好从底层开始沿着金字塔的方向工作。"
因为公司一般将 UI 测试人员作为共享资源，为许多开发团队分配一个测试人员团队，Steve McClure 鼓励开发人员自己运行一些 UI 单元测试 -- 这为 UI 测试人员节省了一些时间，使他们能够专注于更多开发团队的大局。
测试人员与开发人员关系紧张是工作性质的结果。测试人员指出开发人员代码中的问题，然后开发人员必须花时间来修复它们。这本身并没有什么问题，但是当测试人员和开发人员对某些东西是否真的需要修复意见不一致时，就会引起紧张。
UI 测试特别容易出现这种不确定性，因为 UI 测试的重点是用户体验，而这是主观的。
John Hill 说：“当采取某种行动时，某样东西应该如何表现是有争议的，因为这取决于个人体验。”
不过，这并不意味着每当出现分歧时，开发人员和测试人员就应该举手投降，宣布陷入僵局。开发人员可以通过在开发过程的早期让测试人员参与设计对话来防止这些问题的发生。
文档可以帮助测试人员在代码库中更好地定位自己，特别是如果开发人员努力给测试人员提供大量的信息，而不是仅仅列出需要测试的内容。当测试人员能够获得更多关于什么需要测试和什么不需要测试的信息时，他们的工作就更容易了。
测试人员和开发人员一起工作并有一个良好的关系是很重要的，因为如果有相互尊重和合作的历史，就会更容易就测试人员发现的错误的严重性达成协议。
与其他类型的测试相比，运行 UI 测试更难获得一致的结果，因为 UI 测试比后端单元测试暴露于更多的外部因素。
"我们总是希望我们的测试能够为我们提供有用的信息，但是 UI 测试就是不那么确定，"Extend 公司的首席测试工程师 Colin Cahill 说。"我们正在处理网络请求、页面渲染、内存 -- 我们正在处理所有这些其他的事情，这些事情往往会使测试不那么有用，使信息不那么有意义。"
特别是在像网络开发这样的领域，软件产品会受到外部因素的影响，这些因素可能会改变一个 UI 测试在不同实例中的结果。
Steve McClure 说，这是因为 UI 测试经常依赖于发生在互联网上的通信。功能被触发的时间可能不同，这取决于用户离运行代码的服务器有多远。虽然在编写代码时可能假设事情是以特定的顺序发生的 -- 一个函数调用另一个函数，然后再调用另一个函数 -- 但实际顺序在不同的场合可能是不同的。
"用户界面是出了名的异步的 -- 不稳定的测试，零星的失败，诸如此类的东西，"Steve McClure 说。"如果你在你的网页上点击一个按钮，它将不得不与几层对话，回到服务器，往返于视图，说，'你已经点击了我一次。所有这些补丁，它们都是一种链式的，等待着回应回来。如果你允许它在五秒钟内作出反应，你就没事；如果你催促它，只允许 0.1 秒，偶尔你可能会去验证它是否被点击，但它看起来并不像。"
"加剧松散性，只是为了确保它在规模和压力下工作。"
这种松散性引入了另一个不确定性因素，使我们更难弄清代码中的什么东西导致了意外行为，以及如何修复它。减少这种不确定性的另一个原因是，在将各个部分送去进行 UI 测试之前，要对它们进行彻底的测试。开发人员可以通过同步运行单元测试，例如模拟出异步代码的部分，并确保个别组件按照预期的方式独立工作。
一旦单个组件被测试，下一步就是对网络延迟进行压力测试，以发现异步问题的不同表现方式。
Steve McClure 的公司使用一个自动化系统来测试重度网络负载下的代码。他还建议开发人员通过远程运行他们的代码而不是在他们的本地机器上进行测试，并将他们正在构建的组件与另一个开发人员的代码配对，以找出由互动引起的意外行为。
Steve McClure 说："在典型的开发模式下，一个往返可能需要一秒钟，所以我就等两秒钟，我就安全了。但在现实世界中，每个人都有一些滞后的网络。偶尔，它会是 5 秒或 10 秒，或 30 秒或 1 分钟。你需要优雅地从中恢复。"
软件开发进展相当快，新的库、框架甚至新的语言不断涌现。对开发人员来说，要跟上时代的步伐是很难的，但测试人员要跟上变化，同时还要受到变化的影响，就更难了。
这些变化绝对会对如何编写 UI 测试产生影响。通常情况下，开发人员会知道这些，但这些工程师和测试工程师之间不一定有沟通的渠道......这是一个共享知识的好机会。当我们正在处理最近的变化，这些变化会破坏代码或需要改变，这种信息对测试人员是有用的，因为他们有更多的信息来写测试。
另一方面，开发人员可以通过向 UI 测试人员学习，获得对应用程序可能破坏的方式的高度理解。
"不是每个开发人员都能看到每个 bug，但每个测试人员都会看到。"
测试人员可以看到所有的错误 -- 从导致生产失败的严重错误到可以忽略的琐碎错误 -- 因此他们很快就能了解哪些是优先事项。开发人员接触并学习测试人员的经验，可以帮助这两个小组制定一套更相似的优先事项，并缓解因对测试人员发现的问题的重要性存在分歧而造成的任何紧张。
"如果开发人员和质量保证部门能够就绝对的严重程度达成一致，那么这种争论就会消失，"John Hill 说。"这实际上会使大家更容易确定优先次序。"
