如何保证提测质量

近期我们有多个项目都存在延期问题，提测质量反复被测试部门同事吐槽。昨晚测试跟我们分享了下如何进行自测，也对目前存在的一些问题进行了讨论，这里做个记录。

提测前，先让组员到我这里演示一遍

这是最直观的检查开发质量的办法。类似几年前，当时我的头儿的头儿也这样弄过，每次我完成开发，准备提测时，去他那边演示都是战战兢兢的，也因为知道必须经过这个环节，所以对自己做的东西都很仔仔细细的进行了自测。实际效果也很好，一般提测都不会有很明显的BUG。

另外，这也能帮助我自己熟悉我们的产品(现在开发的东西多了，有的同事做的产品我不了解)。

开发分解文档里面，将常见BUG的自测加进去

比如分辨率、黑白样式、兼容性、边界值、自适应、业务规则(比如股票池一般不出现新股、停牌股、ST股；数据计算选择前复权)、点击量统计等等，这些是问题高发区，也是每个项目都要测试的，这部分提前写入分解文档，让开发在初期就关注到。

将开发的分解文档和测试的测试用例文档合二为一

现在测试都是在开发即将结束的时候才提供测试用例文档，而用例又比较多，这个时候即使发现问题，开发也没时间精力改了。因此我们要把开发和测试的联调给提前。

可以做一个类似xmind的工具，将开发人员的分解文档和测试人员的测试用例合二为一，每天更新，这样既方便了自测，也可以用来了解项目实际进度。

培养开发负责人

开发负责人应该对整个项目负责，而不是专注于某一块功能。即使问题不在我们这边，开发负责人也需要去推动和跟进解决。

我们需要培养更多这样的人才。

现在开发人员普遍有一些错误的观点，是我们要予以引导修正的：

1、其他部门接口出问题了，是其他部门的事情；虽然我调用了这个接口，但是我不用管这个问题

2、提交测试，只需要我自己写的功能OK就行了；项目整体能不能跑起来，和我无关

3、我自己测不测试无所谓，反正后面有专门的测试人员会做测试工作的

4、每天过进度，只要问一下每个开发人员就行了；他们具体进度怎么样、有没有风险，和我无关

5、时间观念无所谓，做不完就延期，反正延期对我也没什么影响

落地动作：上面这些问题不是态度问题，是机制问题。可执行的做法是——提测前”演示过一遍”作为硬卡点（不过不放行）；常见 BUG 自测清单写进开发分解文档模板，新建项目自动带上；开发和测试用例合二为一的文档，作为每个需求的默认产物而不是可选项。机制挡在前面，开发负责人才推得动。