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