无规范的测试对质量保证部门来说通常是一个主要的挑战，QA部门无法意识到一个项目已经接近尾声，并且没有时间来处理未预料的事情。从涉及全部范围来看，这直接的反应是带来接下来提出的问题：

　　不能再来一次。
　　没有规范我怎样预设测试？
　　交付期是什么日子？
　　让我们开始。

　　不管这些回答如何，应用程序必须被测试。接下来我们可以处理以下这些问题：缺陷防止、初期质量评价中包含的位势值、以及这些是怎么产生的，除此之外，至今为止我们拥有一个需求去开展测试，对于这点来说可能是我们拥有的需求。

　　没有QA 部门的预先计划，普通的测试过程必须以一些文档编制任务而先进行，而这些文档任务通常将是把工作转交给QA 组的必要条件。接下来的步骤是从收到将被测试的工作开始，通过编制文档这些步骤，然后到不同类型的测试上。

　　第一步：创建功能说明
　　第二步：排列工作量（写规范）
　　第三步：为管理供时间评估和测试覆盖率
　　第四步：回顾需求并开始管理项目
　　第五步：自动化测试决定
　　第六步：其他准备

　　方法和程序的变化对于每一个测试项目来说是会发生的，但是对于一个特殊的工作来说是极少的。因此，寻找共性来确定早先的测试材料和计划是否能被从重新使用以便更容易的处理意外的工作。

　　第一步：创建功能说明

　　对于刚刚开始的测试要抵住诱惑。这一步骤充满潜在的危险。团队将是成功完成这个项目的关键，好的第一步是排列这个项目，并且确定哪些东西是我们期望从测试过程中应得到的。这将理所当然，给应用程序创建说明书是必要的。很明显这个工作应该由某个人早先完成，并且现在需要非常努力的去做它，但是这才是第一步。

　　如果没有编写规范将导致怎样的结果？如果你依然在考虑这个问题的话，考虑如下内容：

　　● 对目标没有一个明确的说明。

　　● 不能确定项目的测试将持续多久。（尽管你已经得到交付产品的交付日期。）

　　● 不清楚谁应该被分配到这个项目中。

　　● 除了无完整的信息而进行测试这一所知的风险外，提供其他任何准确的风险评估变得十分的困难。

　　● 一部分或全部进行自动测试变得不可能。

　　● 通过一个没有文档说明的系统来解决长时间的维护和系统升级这些问题，将变得很复杂。

　　● 我们可能不知道测试什么时候完成。

　　如果被测试的应用软件是一个简单独立的系统，涉及到的列表则比较冗长 。但如果我们准备在客户端/服务器这样的环境中进行测试，这将变得更加复杂。要将测试这类应用软件的不充足性相关的风险做一个简短的说明呈交给管理者。同时也有必要提醒网络小组并且让他们参与测试系统的通讯方面。

　　测试客户端/服务器应用软件的其他复杂性将使测试计划的风险和意外事故部分是冗长的。（确认这一信息非常接近计划的实质，以便让它在检阅中不被忽略掉。）

　　“没有时间做计划，我晚了，我晚了。”

　　如果毫无疑问的要马上开始的话，至少你要努力回答以下问题：

　　● 项目的经营目标是什么？

　　● 客户是谁以及他们的期望是什么？

　　● 客户的经验水平是什么？

　　● 客户支持将愿意准备回答这些问题吗？