|
1、PRD review
PRD是测试执行的源头,我把它比喻为生命的源泉,只有源泉干净清晰,才能保证身体的健康;同样,只有PRD业务描述清晰、完整、正确才能保证整个测试流程的“生命”,否则整个流程都会紊乱;所以在prd出来后做review工作是非常有必要的,每个测试人员都应该负责的去review 需求人员编写的每1个字、每1张图、哪怕是每1个标点;但是这种review不是做文字差错,更多的我们应该关注业务、流程、逻辑;查漏补缺
2、PRD 更新、跟踪
当然,水不一定非常干净,我们需要做一些过滤;PRD肯定有一些不完善的地方,我们也会遇到PRD的更新、修改;但是我们1定要保证这些更新修改是在前期进行的,且测试人员一定要跟踪PRD的更新,特别是测试TL;否则我们只能为自己的错误在测试后期买单了;
3、PRD细节理解
有些业务只有不断的推敲才能发现更多的测试用例,甚至是不合理的地方;测试人员除了文字上理解PRD以外,需要进行自我修炼,去考虑更为细节的部分,也许这部分是PRD没有写到的,需要我们刨根问底;
4、测试任务分配
测试TL要知道,测试任务分配的合理性对测试进度影响是非常大的,所以任务分工一定要合理;
所以首先要做的工作就是自己已经在全局上把握、理解了PRD这样才能将所有业务融汇考虑从而进行任务分配;当然,有些PRD出来后并不是那么容易从全局上把握的,这就需要TL有灵活应变随时调整任务分配的能力;
5、每日问题汇总,stand meeting
每天自己、测试小组以及每个组员的问题,都应该搜集起来;
6、进度掌控(用例、review、测试、回归)
编写用例、review用例、测试执行、回归执行都需要多长时间,且多长时间是合理的,需要自己能把握好;否则比例失调对测试的质量将会有很大影响;
7、用例review、执行、执行结果跟踪
用例review效果怎么样,如何review?需要测试TL专门组织人员1对1的进行review,且必需出review结果;
用例执行必须反馈到testlink上;
8、jira bug和任务关注
随时关注bug管理系统上各自名下的任务和bug。1个bug最好不要跨版本遗留
9、沟通
和BA、开发master之间的沟通要多,且最好face to face;然后将沟通结果分发到组内;
10、异常流程考虑
业务异常流程普通测试人员有可能考虑不充分,测试TL需要在此方面多进行考虑; |
|