项目背景：

此项目的客户是一个英国的软件公司，他们主要做设备管理系统、地产管理系统等，这一次是为Hertfordshire政府做一个软件用于各服务点（service point）的数据收集、整理、评估，以前他们是用Excel来处理这些数据的，现在需要将其自动化。后来客户决定将这个软件项目外包，我们公司争取到了这个项目。

情况介绍：

这个项目主要包括两个部分：前台的Web端，主要用于数据收集处理；后台管理端，用于管理用户、制定数据计算标准、导入数据等。

我们公司是将其作为一个加班项目来处理的，所谓加班项目也即也是说在每工作日规定的８小时内，不得做此项目，需要自己安排晚上或时间来完成任务。若有问题需要与项目成员沟通，则一般采用邮件形式，或者是在中午以及临近下班的时间开小会。在来这个公司前，对此我是闻所未闻的，后来了解到，大约这在外包公司比较常见，项目多任务紧时，为了压缩成本（大概也为了日后考虑），并不会立即招人，而是将部分小项目以加班项目的形式分配下来，当然，项目奖金也是很可观的。然而加班项目无论在成员沟通、时间进度把握以及项目成员的心理认知都会存在一定的问题，所以，这也为项目后来的进展埋藏了不少的隐患。

还值得一提的是，公司的很多项目都是以ODC报价，可是这个项目却采用的是固定报价形式，不管你花多久的时间做，终成功交付了，才能得到所有钱。这种形式本身没多少不对，可是，有时在一种心理的影响下，可能会令项目进入一个恶性循环。

我是今年６月中旬应聘进入公司的，从另一个测试人员手上接手了这个项目的测试任务。当时了解到，按照初的计划，还有一个月的时间该交付系统了，而此前交付某一部分时，因为延期，使得客户很不满意，而原因是初低估了工作难度而致实际使用时间大大超过预算。我进入项目组时，成员是这样的，有一个项目经理，一个测试人员，五个开发人员，不过，几天后我明白了，实际只有三个。当时之所以有五个，是因为其中两个才开始介入，为另两个的退出作准备。后来，基本上是一个负责Win Form，一个负责Web，另一个技术比较牛、负责的项目多，只有当Web有难题时，会找他出山。在我加入前，包括测试人员的所有项目成员都是把它当作加班项目做的，我因为没有其他项目，所有当作正常项目来处理了。

在正式介入测试之前，我大概花了三天的时间理解需求，毕竟产品已基本成形，可以一边用一边读需求，直观容易多了。但即使在这种情况下，我在后来的测试中还是渐渐发现当初对很多数据处理的细节方面是没有理解透彻的。那时，摆在我面前的难题有三个：一是所有项目文档都是英文，报告bug也要用英文，尽管我自诩英文读写能力不错，可还是花了好些时间才适应；二是尽管项目已进入中后期，除了mantis上的bug，没有任何测试方面的文档产出，包括测试计划、测试用例等；三，内部成员之间的沟通不及时，因为加班项目的特殊规定，有问题只能等到中午或下午下班后才能沟通，这种情况下，不可避免地会影响测试及至项目进度。

但是后来渐渐发现，问题远不止这三个。由于是外包，我们的直接客户却并非终客户，这有两个问题，一是我们提交版本后，他们要测试，然后还要交给终客户测试，这使得每次反馈的时间拖长，由于没有新需求做，所以这边只能处理等待状态；另一方面，终客户反馈回来的bug，好些都是颠覆了原来的需求，更有甚者，有的还会改过来又改回去如此这般地往返几次，虽然客户不乏真诚地道歉，但是打击项目成员的积极性是不可避免的，同时，以后对于客户再提出的bug，不免报怀疑态度，大大降低了我们对客户的信任度。而对于用户的需求，又只包括了功能方面，对性能等方面的需求，没有在前期沟通确定，导致项目待结束时，客户突然提出，这种性能是不可接受的，我们不得不对Web部分大刀阔斧地进行修改。而后导致的一系列问题的处理，大大延迟了项目的进度