近期工做中的问题总结

       问题1：对于项目开发时间节点的分歧

       当咱们一块儿开项目立项会议时，开发人员每每根据代码量来评估时间节点，给出的解释通常也是技术上是否有难度，代码量是否大，而测试人员是从测试的复杂度来 评估，因此有时候会出现比较大的分歧。好比开发人员认为工做量很小，而测试人员认为业务复杂，和别的模块交互比较多，测试工做量大。

       解决方案：

       团队内部须要评审测试用例，这样开发人员能够理解测试的工做量。而做为测试人员，应该在闲暇时间积极的补习coding方面的知识，尽量地去理解并参与到团队的讨论中。

       问题2：敏捷式开发的弊病

       敏捷式开发的一个原则是但愿团队集中在一个或两个功能模块上，完成后再转移到下一个功能模块，争取价值的最快交付，但带来的问题是每一个模块之间，彼此之间有依赖关系，你们不得不等待。而对测试人员来讲更是痛苦，须要测试不少中间产物，测试量显著增长。

       解决方案：

       版本控制与项目时间节点的掌控应该更加严格，好比某个时间节点应该完成那些功能须要严格的执行，测试应该在功能完成的时候开展新一轮的测试，功能没有完成以前，更多的应该是对于已经实现的功能的回归及验证。

       问题3：每一个迭代周期后期，滞留大量测试任务

       目前常常出现的状况是每一个迭代周期后期，滞留大量测试任务。若是这个时候发现了不少问题，开发人员也不得不加班修复。为了解决这个问题，一方面整个团队要 慢慢培养一个共同的意识：只有测试工做结束了才意味着这个用户故事真正结束了；另外一方面，若是一个用户故事计划用少于一周的时间能完成，但实际上在第5天 站立会议上评估仍然完成不了，就要加派人手，集中力量保证它的进度。若是是由于技术难题陷入困境，能够留下一个或两我的员继续攻坚，其余人员就要及时撤离 出来，以保证其余的用户故事能正常进行。

       解决方案：

       为 了解决这个问题，一方面整个团队要慢慢培养一个共同的意识：只有测试工做结束了才意味着这个功能模块真正结束了；另外一方面，若是一个功能模块计划用少于一 周的时间能完成，但实际上在第5天在晨会上评估仍然完成不了，就要加派人手，集中力量保证它的进度。若是是由于技术难题陷入困境，能够留下一我的员继续攻 坚，其余人员就要及时撤离出来，以保证其余功能模块能正常进行。

       以上为工做中遇到的问题，而对于创建QA部门以后测试工做如何高效的开展有如下几点建议：

       1.测试在需求确认以后就开始介入，根据项目经理肯定的计划时间节点作出合理的测试计划，在单元编码阶段完成测试用例的编写及评审。

       2.经过禅道与内测分发平台进行版本控制，开发人员须要3天提交一个新版本（须要与开发人员商议决定版本迭代时间，理想为3天）。

       3.新版本提交以后，测试人员须要完成对新版本bug的验证，测试用例的执行及新版本bug的发现工做（在下一版本以前完成）。

       4.测试人员须要推进研发进度，严格按照项目时间节点完成任务。

       5.测试人员跟进的项目不宜过多，才能保证测试的质量。

       6.在后期给客户提交版本时，应该对总体流程进行测试，保证不会出现显而易见的问题。

       7.提交bug时，务必选择正确的模块类型和bug类型以及bug严重等级，便于bug管理及研发肯定解决bug的优先级。

       8.测试过程当中要作到"五个大于"，即计划大于执行，覆盖率大于执行率，记录大于操做，再现大于发现，评估大于总结。

       最后，总结起来，测试在工做上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施。