加班到0点才回的家，预计接下来两天，也会是这样的状态，因为已经定了16号的上线deadline。然后，从头来说吧。

1. 项目的流程：需求评审——技术评审——开发——测试用例评审——测试——上线——复盘

入职后的一个月时间，我就大概经历了这样一个阶段，并没有什么不妥。可是现在经过最近的两个项目，我最大的感受是测试应该早一点介入前期的流程。熟悉的过程点：

• 需求文档并没有详细流程，一般就是列下功能点。需求评审的形式，大概是把内容读一读，然后可能当时看到有什么问题就当场提一下
• 新项目开始时，一般上一个项目还在收尾工作中，让所有相关人员提前多了解需求并不是很实际
• 需求评审和技术评审的中间间隔时间并不是很长，难免开发对于需求的理解不是很充分
• 在上一个版本的测试中，花了一天时间验出一大堆"bug"，可其实是两个人对需求中的一句描述有不同理解（并没有对错）
• 在测试用例评审时，居然发现需求和用例有出入。同时，居然开发还会对某块需求有不清楚的地方。于是，只能当场口头说说
• 测试用例评审的形式就是把所有的用例读一遍，不过，好像大家都不是很关注
• 在测试过程中，常会听到熟悉的语句：需求上没写，需求上写了，我没注意到，让产品经理来。。。好像都是“需求”的锅

2. 我想在流程中可以把测试用例评审提前一点

• 不意味着把所有用例都提前写好，而是说重要的功能模块。在需求评审阶段，大家可以把认为重要的点划出来，然后在技术评审前后将这些功能的用例拿出来理一理
• 用例评审的目的是什么？我想除了帮助测试人员理清流程外，还可以借它来帮助开发、测试、产品经理三方统一认识

3. 这个项目有点乱

• 这是一个重点项目，可是并行的还有另一个重点项目。更悲剧的是，后面还有其它要做的项目
• 项目多了，人员不够。于是只能“拆东墙补西墙”。开发人员一会儿在这个项目，一会儿到那个项目
• 项目被标成重点了，于是相关人员也成了“重点”对象，大家集中到一个小房间“闭关”。“隔离”时间久了，感觉会有些怪怪的
• 再大的人有时还是会有点像“小孩”，会有小脾气。项目经理那么早就走了（这个项目的pm是测试主管），我们没人管了（老大们很少来小房间），怎么又开会呀。。。
• 人一多一急，沟通时就容易带情绪。可是对解决事情没有什么帮助。在小房间里面讨论问题，同时有两三个问题就能让房间“爆炸”

4. 结果：加班

• 我并不十分排斥加班。互联网行业，慢了一步可能就输了市场，没有了先机，错过最佳时间，也许公司就很难出来了吧。所以，必要的加班是应该的
• 加班时，不要过分放大问题。 就出包这件事，因为一开始要花的时间比较长，于是测试主管、技术主管、端主管、老板，每个人都来说了一遍。在我的认知里面，没有太大必要吧。说一次就好，因为大家已经意识到，而且已经开始解决问题。此时放大问题，只能让大家心情更糟，效率更低
• 加班时，尽量不要抱怨，心平气和地才能更好地解决问题。旁边的人一直散发负面情绪，自己很容易受影响
• 多做些前期工作，来减少项目后期让需求“背锅”的必要