没有需求，我们仍然要测试

    早期，我们确实遇到了“烂”项目……
    我们的项目有时候是在非常态下进行的，这个非常态是指项目在没有文档化需求或需求以格式文档的形式描述，项目经理以口头的形式描述系统需求，并要求开发人员在短期内完成代码开发。接下来，开发人员在模棱两可的状态下别扭的编写代码，测试人员前期也无从介入，更可怕的是，积极性欠缺或责任心不够的项目经理不但前期没能与客户细致的沟通需求，在系统开发过程中，也没有进行有效的项目进度、质量控制，连起码的阶段成果评审也没有做。之后的系统开发成什么样子已经可想而知了。
    原来能忽悠客户搞好客户关系的项目经理，不一定搞得定系统开发过程。这个时候，去追究项目经理为什么是他已经来不及，因为开发人员说他的代码已经开发完成了……
    怎么办？贸然接收测试？没有明确的需求，测试依据呢？开发成什么样就是什么样？在研发中心的最后一道关口，测试人员不能掉以轻心，但真的开始了，那纠缠不清的功能需求争论将陷入无休止。
    为了测试的兄弟们，为了自己的测试工作更加顺利，在测试过程中有章可循、有据可依，减少无效沟通，我们唱起了主角。
    我们主动与开发人员沟通，跟踪开发过程，在项目的各个里程碑阶段（开发完成了一个完整的功能模块或业务子系统），主动建议（实际上是要求）项目经理或开发人员演示系统，同时邀请客户支持人员、测试人员、市场人员参加，在演示过程中，将各个功能点、功能模块或业务流程所要实现的功能、业务明确，尤其是通过测试人员的提问，引出可能存在争议的业务或功能设计，甚至现场与客户电话沟通，并以会议纪要的形式的记录下来，以并得到相对明确的测试需求。迭代反复，直到抽取整个系统的测试需求。
    测试需求抽取是艰苦的过程，但不做这一步，我们可能更艰苦。有时候，会议中定下来的需求不一定真实，但起码项目各干系人了解到了一致的项目状态，后续即使客户方有变更，项目组也能够更快的响应变化。
    有了需求，后续的测试工作就顺利多了。
    我们做了两个这样的“烂”项目，之后的变化是，无论是否有明确的需求文档，开发完成之后，都有一个步骤：以系统演示会议的方式对完成代码开发的系统进行预评审。再后来，大老板开始强制性的要求推动需求分析工作……