在信息技术外包世界，对一个公司拥有它的应用程序和被其他人开发或者维护的框架是普遍的。当销售商完成这个生意，一个普通的实验是把测试过渡活动当成是一个整体。你如何设计一个传统实验的可接受标准以至于它可测试并且被清晰沟通？
作为测试，我们通常讨论当一个应用程序被创建时如何接近测试并且被在我们自己公司内的团队维护，但是我们很少讨论当从一个外包供应商到另一个变化时发生了什么。
在信息技术外包的世界，对一个公司拥有它的被其他人开发和维护的应用程序和架构是普遍的。当销售商完成这笔生意，有合同涉及组建管理，实时服务水平，关于发布内容的委员会，等等。一个普通的合同部分是测试交换活动作为一个整体，都为了架构和应用程序。
客户想要的是将服务和他们需要的解决方案合成文档的能力便于他们能外包他们流程的一部分，经常是为了更高的价钱或者更好的策略契合，没有打扰到商业。
近来我是一名在有这个挑战的应用程序过渡项目的测试经理。被另一个90后公司维护的应用程序并且我们继续维护和开发这个应用程序。但是在我们能做以前，合同定义了一个我们不得不通过的"传统实验"。我的任务是制定关于传统实验可测试和可被清晰沟通的可接受标准。
那封邮件是什么呢？
应用程序过度实验中的测试
在这种测试内容里有一些特殊术语。这个合同把它定义成一个实验--而不是一个测试或者检测。
一个实验在测试和质量保证方面有很多相似性。我们被提供一些高水平可接受标准并被问及确认和整理文档以使这些事情实际上发生。一些特殊可接受标准能实施一些系统简易变化，升级文档，并且创立循环合作会议。
和传统软件研发可接受标准工作，我们期待可接受标准能关于应用程序的功能性和业务-支持活动。但是这儿可接受标准被认为测试下的一项目，所以我们不得不相应地搭我们的实验测试用例架子。
其中一个合同需求是系统文档的升级。这被以下实验测试用例捕获了："系统描述文档被升级了吗？"我们不再深入一步且没有期待的或者实际结果。它决定测试去评估假如文档确实被升级并且为客户改进以至于我们提供一个升级文档。
注意到我们使用开放问题去允许测试成为一项活动和一个性能，并且测试活动本身可被纲要和检查列表支持而不是详细的脚本。它正是一个"每一个公平的事物"和"没有其他坏事情发生（我们所知的）"的大事。
可接受标准没有详细说明关于文档是否被升级或者其他任一细节。我们能做的是以原先版本为基准然后是升级的版本并且看变化，至少在作者部分里。再次，测试准备是一个在执行不明确需求的实验并把它们重写进可测试的活动中。
读到合同发布了65个活动或者文档的一个组织，并且没有附加测试管理工具的要求，我建立了每一个作为在一个电子表格一行的开放问题。然后我以一个看板版建了4列：要做的，进行中，已做的，和已归档的。公司的内容和传统是我们不得不为每一个测试活动提供证据和文档。
即使有传统方法去测试分析和测试用例管理，很多团队成员发现一个测试用例不覆盖其他的而是对应用程序的功能性代码是一个挑战。即使做一个简单的对系统的改变的活动从来不是一个变化本身的测试--它可以是关于给应用程序刷成粉色，对于所有事物。测试实验更多的是关于有能力交付一个改变而不是变化自身。
期待看到更多过渡实验
外包项目的测试实验正越来越普通，不仅考虑到应用程序，还要为信息技术架构，信息技术支持，和很多其他想法。有一个明显的趋势是Linux，Windows，Oracle，和其他技术现在被要求至少一些在使用前发布它们的它们的配置和标准化的测试。
这些技术通常看着测试为一个确定活动，并且它们趋向于使用软件开发的V-模型，每一个开发阶段有一个相应的测试阶段。好消息是测试是一个被要求的事项，并且我们可以开始讨论关于这些如何测试，如何测试工作作为一个活动我们能学习到不仅是应用程序而且架构的技术。
传统可接受标准的实验将越来越频繁。作为测试专家，我们需要熟悉测试一个应用程序和工作一个在传统实验下的应用程序的区别如此我们才可能恰当地交付一个无缝转换。
源自《51测试天地》(四十六）期投稿
