项目背景:
我们这个项目周期比较长,我是半途加入的,至今即将2年了,而这之前都已经启动了快1年了。运行组织结构是开发、测试、需求三权分立,微软好像也是这样。需求给出定义,开发做出东西,测试检查质量。如果发现需求没有的则提交需求bug促使需求新建或变更原有内容,互相促进。总的来说运转还不错,当然过程中也有很多问题,解决了不少,但总还是有问题的。这里就不多说了,毕竟要说产品发布前的故事嘛 :)
我们定下了最近的一个日期发布产品(具体日期不便透露),所以大家都比较忙碌、紧张,作为测试部分的一员,我们已经好几周晚上和周六加班了。下面就这里开始故事。
故事一,突然增加的需求。
大约还有1个月的时候,市场部突然提出此次发布的版本一定要有用户认证功能,主要是收集用户信息。似乎时间还够,但实际上对我们来说是不够的。首先我们要保证当前每周2个版本功能稳定,其次需求要重新根据要求制定详细到出错的每个提示。再有需要与其他部门配合(提供服务器数据库) 事实上因为拖延,该项需求负责人弄出的需求内容还不如开发与测试提出的疑问多,这就半个月过去了;与其他部门的配合工作也没有个总协调人来跟进,互相之前都在假设别人的工作做好的前提下进行的;除了在线认证还有离线认证,这部分的接口人和工作流程还没有确定。等等一系列问题需要解决,作为具体测试,坚决把所有可能出现的问题(包括需求没有明确的)一一提出来,这时候是没有测试用例的,你对界面规范、用户操作的习惯、当前功能的目的等等的理解就是你工作的保证。
最终结果还好,虽然还有一些不如人意的地方(有时候为了向市场或开发的部分妥协,如果坚持可能会付出更大代价),总算这个功能稳定了下来,出现的bug数量大约70多个。
故事二,与其他部门产品的矛盾。
因为公司的其他产品是依赖我们这个产品的,就是说如果我们的卖不掉,其他的跟进产品也无法生存,有时候我们的产品甚至是搭送的。 这次因为我们最新版本做出了一些标准化的东西,另一个部门解析我们文件的产品就需要我们进行保护,即我们的软件输出的文件只有他们部门的产品解析,但这样一来我们的文件就不是那么标准了。另外因为我们这次新增加的一个功能可能绕过另外一个部门的产品,这就会影响他们的销售。
可能还有一些,这些矛盾可能影响产品的发展策略,影响产品的功能变更,虽然测试可以不用管这些,但是从公司、产品、项目角度来看,值得我们思考的问题。
故事三,没有得到通知的功能变更。
上周五是计划确定版本的日子,一段时间以来各个功能都比较稳定。大家思维估计都僵硬了,简单看过基本功能后,我用了一下别组的功能,非常简单的一个操作,忽然发现多了个提示信息,与功能对应不上,马上咨询别组的负责人,她说不知道,然后找开发、需求,转了一圈原来是之前要做,但是没说这时候做,开发把这个做完认为没什么大问题就把代码放进来了,结果出问题。