“再看OA”系列讲座之八：100步的第99步
谈OA系统应用开发后的用户测试“OA系统建设普遍存在立项多、花钱多、鉴定会多，但真正受用户欢迎、有三年以上寿命的OA系统不多。我认为，在OA系统项目开发过程中，对用户测试重视不够、管理不力，是造成这种现象的基本原因之一。因此，OA系统成功应用的关键，在于最终是否满足了应用者的‘口味’，它是——”
黄延岭：现为中国国际信息信托投资公司（简称中信公司）管理信息中心OA处处长，参加了中信公司的三代OA系统的建设工作。从事OA系统建设工作20多年，参加多项大型OA系统建设项目，如作为项目组长开发第一代中国新闻记者网，获得国家科技应用三等奖。在OA建设领域有丰富的实践经验和深刻的认识。
OA系统项目无一不是源于管理改革的需求，有人说，建设OA系统可以做到“交钥匙工程”，我认为这只是一种市场炒作的说法。不同单位有不同的管理需求，必然决定了OA系统的个性化特性，不可能存在通用的OA系统产品，因而用户测试对OA系统项目实用化具有不可替代、不可跳越的关键性作用。
开发与应用“对视”
用户测试是处于系统测试阶段结束和系统试运行阶段开始之前的一个相对独立的阶段。测试的主体，由开发技术人员转为最终应用者。用户通过对OA系统全部功能和工作流程的亲手应用、测试，逐步全面了解OA系统是否完全实现了需求书的要求，从而接受和认可该软件，这是保证OA系统功能和流程正确性、完整性和实用性的关键。实践证明，只有用户试用，才能提出合理建议，促使软件实用化和产品化。因此我们把用户测试看作开发工作的继续，是用户技能培训的过程，是系统试运行所需要的设备、技术、组织和制度的准备过程，也是甲方、乙方和用户方相互理解、建立长期密切合作关系的过程。
准备好“行囊”
用户测试的开始，要有一些准备。首先进行评审，确定系统具备了用户测试条件，可以从开发阶段转换到测试阶段。其次，进行组织和制度准备。第一，确定项目方（甲方）和开发方（乙方）和最终使用者共同组成一个项目协调小组，主要任务是需求控制和测试协调。第二，甲方任组长，重点负责需求控制和项目监督。第三，乙方重点负责优化完善OA系统。需要注意的是，此阶段开发队伍不能解散或人员减少。第四，用户代表主要负责对应用软件所有功能和流程进行使用测试，并提出建议和意见。用户代表最好是了解部门管理需求和业务全局，并熟悉主要业务的骨干。第五，建立每周一次项目协调会制度。协调会要保持科学性、严肃性、权威性和民主化。项目三方要对协调会负责，协调会要对内联网工程领导小组负责。
选择好“目标和路线”
用户测试要制定相应的测试要点，如，先测功能后测流程；先测处室内部后测处室之间；先测部门内部后测部门之间（包括集团领导、其他职能部门和子公司）；最后进行集成测试和实战演习。同时，也要设计测试方案和选择典型案例，具体可以有如下步骤：
1、作为用户测试的主要基础数据的依据，要确立模拟实际工作的典型案例，尽量多地覆盖待测试功能和流程。一般由开发方提出建议，由甲方和用户方审定；
2、测试技术方案和技术文档主要由开发方准备；
3、全过程测试记录表主要由甲、乙方根据案例和流程设计制作；
4、集成测试时，有关部门、有关领导要亲自组织和协调；尽量用真角色、真数据，越接近实际使用越好；
5、测试记录表由甲、乙方跟踪记录；反馈表由参测用户填写；作为评价系统和优化完善系统的依据；
6、在测试开始时，开发方可以提供一个待测功能和流程的清单，方便初学用户测试；
7、用户测试一般要反复多次测试；我们的经验一般要经过3轮测试。
遇到问题困难时
用户测试初期，反馈表主要填写程序中的一些BUG，但经过一、二轮测试后，用户反馈的问题就集中到功能完整性和流程合理性方面，特别是联调或集成测试时，用户已熟悉软件使用方法，会更多考虑系统的适用性和易用性，这时的意见直接关系到系统的实用性和产品化程度，是十分重要和关键的。因此，每当用户完成一轮测试，协调小组都要认真进行一次需求控制讨论会。在测试中，也有一些意想不到的问题——
1、需求变更难以控制
项目需求调研阶段，用户因为没有IT知识，讲不清究竟要系统干什么，虽然用户需求书双方签了字，但在用户测试过程中，随着IT经验的增加，自然会发现一些不合理或不完整或缺少的需求，必然会引起需求变更。我们的经验是：需求变化是不可避免的，关键是做好需求控制。如果放任需求变化，完全用户说了算，项目可能陷入无休止开发或进度失控状态。但若把需求书看作不可更改的圣经，从表面上看是坚持了合同，但无数事实表明，整个OA系统却可能因此而最终失败。我们的体会是：需求变更控制管理，是项目管理的核心和关键。我们在实施中，设计了用户测试反馈表，让用户在测试中随时填写。然后在每次协调会上，研究反馈表中用户的意见和建议。针对用户意见，我们有相应的三种策略：首先，没有满足需求书要求、或达到需求但没满足用户合理使用要求的，乙方要尽快解决；其次，对用户提出的新需求，如果三方协商一致同意实现，则以书面形式以总需求附件形式，纳入项目开发计划，受合同保护；第三，如果达不成共识，则不受合同保护。对用户不合理的要求，要敢于和善于向用户做实事求是的解释工作，争取得到用户的充分理解。经验表明，与用户搞僵的，多是以自己为中心的技术型人员，这些人对用户业务十分缺乏理解。
2、技术开发的进度和成本难控制
需求调研不充分，或因为开发人员对用户业务理解有限，或因为种种原因产生用户需求变更等等，都会引起修改或新开发程序，甚至引起技术路线的改变，造成进度拖延，而进度延迟，必然造成成本失控，类似问题相当普遍。
3、数据导入工作的艰巨性难预测
对于旧系统遗留的历史数据，其结构的复杂性或不规范性、数据量之浩大等等，常常估计不足。一旦发现问题，开发管理人员认为，让编程序的人去导入数据不划算；业务部门认为“我们工作都做不完，哪有时间去导入数据？”因而出现相互扯皮，有的出现程序测试没有数据的情况。而数据在信息系统中的重要性日益受到重视，越来越多的人认识到，“信息系统建设中，三分技术、七分管理、十二分数据”。新一代OA系统的重要特点是打破传统的信息孤岛现象，建立统一的信息共享平台。其核心之一，就是要对数据资源进行统一的规划，并制定统一的数据标准和建立整个OA系统共享的中心数据库。为此，建议成立专门的数据项目组、单独立项、专业实施。
4、用户太忙，测试充分性难保证
用户本职工作很忙，经常和测试发生时间冲突，既影响测试进度，又影响测试的充分性，这也是很难控制的问题。实践证明，用户代表在用户部门内的组织协调能力，以及甲、乙方积极配合，是解决问题的根本办法。那种完全依靠领导的做法，只能管一时或影响有限范围。
由上可见，用户测试阶段是用户从使用角度，对OA系统进行全面检查和评价的过程。在这个阶段，用户可能提意见最多、最难听，也可能最不好理解，甚至有时为了搞清楚一个需求，还会发生激烈争论，但是，只有通过用户测试，开发方才能有的放矢地把OA系统优化完善成一个受用户欢迎的实用化的系统，它是100步的第99步。当然，用户测试不是要到项目开发全部完成再进行，也可以根据项目情况，进行阶段的用户测试。问题发现得越早越好。这也是用户测试需要注意的。
作者注：软件测试是一件很复杂的工作，而且包括很多方面，如压力测试、覆盖测试等等。本文仅阐述OA系统用户测试中的一些管理问题，欢迎交流。
相关背景：中国国际信息信托投资公司，在1986年成立信息中心后的十几年来，经历三代OA系统变迁。该公司OA系统应用软件开发采用外包方式，信息中心作为甲方，中信网络科技公司作为乙方。目前OA系统的全面用户测试在进行中。
