产品发布前的故事不想说什么规则、流程，因为相对来说我们公司的流程还是可以的，但是总有那么多事情无法避免。对于在发布产品之前的忙碌，我希望用文字描述出来一些场景，来借鉴、备忘、总结，一切都为了将来做的更好。

项目背景：

    我们这个项目周期比较长，我是半途加入的，至今即将2年了，而这之前都已经启动了快1年了。运行组织结构是开发、测试、需求三权分立，微软好像也是这样。需求给出定义，开发做出东西，测试检查质量。如果发现需求没有的则提交需求bug促使需求新建或变更原有内容，互相促进。总的来说运转还不错，当然过程中也有很多问题，解决了不少，但总还是有问题的。这里就不多说了，毕竟要说产品发布前的故事嘛 ：）

      我们定下了最近的一个日期发布产品（具体日期不便透露），所以大家都比较忙碌、紧张，作为测试部分的一员，我们已经好几周晚上和周六加班了。下面就这里开始故事。

故事一,突然增加的需求。

    大约还有1个月的时候，市场部突然提出此次发布的版本一定要有用户认证功能，主要是收集用户信息。似乎时间还够，但实际上对我们来说是不够的。首先我们要保证当前每周2个版本功能稳定，其次需求要重新根据要求制定详细到出错的每个提示。再有需要与其他部门配合（提供服务器数据库） 事实上因为拖延，该项需求负责人弄出的需求内容还不如开发与测试提出的疑问多，这就半个月过去了；与其他部门的配合工作也没有个总协调人来跟进，互相之前都在假设别人的工作做好的前提下进行的；除了在线认证还有离线认证，这部分的接口人和工作流程还没有确定。等等一系列问题需要解决，作为具体测试，坚决把所有可能出现的问题（包括需求没有明确的）一一提出来，这时候是没有测试用例的，你对界面规范、用户操作的习惯、当前功能的目的等等的理解就是你工作的保证。

    最终结果还好，虽然还有一些不如人意的地方（有时候为了向市场或开发的部分妥协，如果坚持可能会付出更大代价），总算这个功能稳定了下来，出现的bug数量大约70多个。

故事二,与其他部门产品的矛盾。

因为公司的其他产品是依赖我们这个产品的，就是说如果我们的卖不掉，其他的跟进产品也无法生存，有时候我们的产品甚至是搭送的。 这次因为我们最新版本做出了一些标准化的东西，另一个部门解析我们文件的产品就需要我们进行保护，即我们的软件输出的文件只有他们部门的产品解析，但这样一来我们的文件就不是那么标准了。另外因为我们这次新增加的一个功能可能绕过另外一个部门的产品，这就会影响他们的销售。

    可能还有一些，这些矛盾可能影响产品的发展策略，影响产品的功能变更，虽然测试可以不用管这些，但是从公司、产品、项目角度来看，值得我们思考的问题。

故事三,没有得到通知的功能变更。

    上周五是计划确定版本的日子，一段时间以来各个功能都比较稳定。大家思维估计都僵硬了，简单看过基本功能后，我用了一下别组的功能，非常简单的一个操作，忽然发现多了个提示信息，与功能对应不上，马上咨询别组的负责人，她说不知道，然后找开发、需求，转了一圈原来是之前要做，但是没说这时候做，开发把这个做完认为没什么大问题就把代码放进来了，结果出问题。

    测试任何东西都不要依据以前的测试结果来判断当前的状况，但是可以作为参考。不要认为任何稳定的东西就不会出错，因为我们不确定这其中发生了什么。

故事四,即将定版本时发现加密方案要改变。

    接上面的，几个问题改好后，连续给了几个版本，整个产品功能表现出了一片稳定的态势，到晚上7点多的时候我们已经认为就是这个版本了，都开始谈论下周可以轻松过了，至少不用加班了。忽然接到一个邮件说，为了加强加密能力，加密锁方案变更，所有我们正在用的加密锁全部要升级。一片绝倒，早干什么去了？

    抱怨是没用的，这样版本确定就拖延到了周一（7月30日），天晓得周一会发生什么。开发负责人又保证说只改这个地方对功能影响不大，保证周一没问题，我看肯定是有问题才对，因为每次他进行保证后都会出问题，这都成规律了，呵呵。 

    对测试来说，这些突发事情很难预测，也希望做项目的朋友能对各个方面进行考虑。发布产品并不只是发布程序软件那么简单，还包括很多东西，一切都在公司发展策略这个大棋盘上。

故事五，重新来过后出现了一些新问题？

    周一的早上，我们更新了所有加密锁，如愿拿到了新版本。在冒烟测试的时候发现了很多新问题，原因是加密方案改了，但是某个解释程序挂接的还是之前的版本。开发负责人的保证果然让版本出现了问题，呵呵。一直到现在还在等待版本中......

系列故事会待续发展，直到产品发布。希望这些能给大家一点提示，一点体会，哪怕是一个新方法。