虽然做测试工作的时间也不算太短了，但是之前一直都是在做自己的部分，只专注自己负责的部分。最近有了一次不同，作为测试负责人跟踪、把控了整个迭代的工作，本次迭代接近尾声，特此做一下总结。
1、需求原型问题列表：
项目首先要从熟悉需求开始，你会发现这是一个重头戏，对于需求的梳理很重要。后面的开发测试流程能不能顺利稳步进行，这一步很关键，能越早发现问题对以后迭代产生的成本就越低。
因为原型出来后所有项目参与人员都会看原型并站在各自的角度去提一些问题，为了方便收集整理大家问题，我们可以在协同办公软件（wiki）上创建一个问题列表，让大家把各自遇到的问题写在问题列表中。而作为测试负责人，就要关注问题列表，整理问题并将问题反馈给产品，待产品作出回答后再去提醒大家去查看。
2、编写用例过程中你还会有一些问题：
在原型可以达到写测试用例和进入开发的标准时，测试人员会开始写测试用例，这时对于原型的理解会进一步加深，就会衍生出一些新的问题，一般是一些较细节的问题，测试人员将问题汇总在问题列表中，负责人将这些问题再去反馈推动来完善原型，推动原型封板。
3、同步并把控进度
问题总会是有的，任何一版需求和原型都不可能完美，但是不能无休止的将需求完善下去，这样你会发现没完没了。
我们不仅要保证产品的质量，也要对迭代周期进行把控，只要现状达到了原型给出的预期结果，没有什么大的出入，一些之前没有想到的细节上的问题可以记为改进优化或记为优先级较低的bug，在下一迭代中再去完善，任何一款产品都不能可能一次性做到尽善尽美，都是在时间和经验的积累中完成升华。
4、开发过程中你仍然会遇到一些问题：
没有进入开发之前，人的想象力有时不能完全覆盖可能出现的问题，也就是说有一些问题在开发之前是没有预估到的，只有在开发中遇到了才会去考虑。也许是技术实现有难度或产品需求不合理，这时候就要产品、测试负责人和对应开发去讨论出一个合理的方案，这时测试负责人是一定要去主动参与的。一则，三者分别站在各自的角度去共同考虑这个问题会更全面更合理。二则，在开发过程中负责人也可以对变动更熟悉，从而对后面的开发、测试工作有一定的评估，做到心中有数。
5、合理分配测试资源，高效合作：
进入开发一段时间后，就会有陆续的提测了，作为负责人，对整个迭代和测试任务的熟悉程度应该都是最高的，如果有一些测试任务袭来时，负责人就要根据任务的一些复杂程度或关联性来合理的跟测试人员沟通测试任务，达到质量高、效率高。
6、服务端上线：
测试环境的测试工作完成以后，我们肯定要进行线上环境的测试才能发版，这时需要注意的一点是，一定要及时和服务端或前端确认上线时间以保证后面测试工作的顺利进行，否则就会导致人员的闲置和后面工作的压力。在客户端具备了线上测试的条件时，负责人就要及时的通知到相关服务端和前端的小伙伴上线啦，因为上线也需要一定时间，所有一定要及早通知，不拖沓。
7、发版：
不发版一刻都不能松懈，iOS直接就一个渠道直接发版就好。安卓就要注意了，分为应用内升级、官网和渠道包（各应用商店）。而且发版之后要进行发版后验证即冒烟测试。一般来说安卓发版顺序应该是应用内升级– 官网 – 应用商店。
总结：
总的来说，测试负责人就是开发、测试和产品之间的桥梁，这个角色贯穿到迭代的每一个环节，是项目的有力推动者。
网友评论