搞定难搞的项目测试

项目A

   由于同事休婚假，一周周五临时接受了***项目测试任务。由于工期已经接近尾声，下周一是发布时间，组长、项目经理指明下周一要发布，因为本来已经延期了。当时压力有点大，手头没有测试用例，不了解项目情况（不知有多少坑），并没有给与回答。现在回想当时的状态是闭口不语，实际上已经心乱如麻，于是回复了会抓紧测。实际上应该说明需要评估一下。好在当时没有妄加承诺周末加班完成，主要是周末加班也完成不了的。跟测试人员类似，前端开发同学A要离场，新的开发人员要交接上来。

周五开始冒烟测试，跑了个流程，基本跑通，把其他公共组件的问题也找出来了。与家人简短地沟通后，周六还是加了个班，加班写测试点。如果不写测试点则测试重点不明确，也无法评估测试时间。当时算出来的测试时间是2天。实际上测试了3天半。测试过程中发现需求不明确，找业务确认时，发现原系统流程在pass环境上也有问题。这就意味着有需求风险。最后用processon画流程图，不断地与业务、开发沟通。前端开发A同学直接将bug回复为不予解决或设计如此，前端开发B同学说需要重新看代码，后端开发C同学说催也没有用...

在写好测试点之后，对这个项目的功能基本了然于胸，这个时间紧问题多的项目有些挑战亚。本着质量为重的原则，按部就班地稳步测试为主吧。将测试场景详细考虑，流程图绘制发给开发B看，积极地与开发B沟通，尽量描述清楚问题，做好复现工作，明显地，后端开发C慢慢地也配合了。项目发布后，倒是开发C更配合了，熟络了也建立了战友关系~

项目B

这个项目逻辑不是很复杂，表单的新增、修改、删除，有审核流程，审核通过后在台账页生成记录。由于前一个项目——项目A的教训，在测试前把老系统流程跑了一遍，所幸没有发现明显报错的遗留问题。

由于仍然是项目人员要离场，采取的沟通策略是在办公室人员（后端）沟通，不在办公室人员（前端）禅道上描述清楚问题，力争定位准确，助力bug修改。

也是在这个项目测试过程中向组长提出了跟开发要送测单，明确测试目标，是一个里程碑。