QA测试规范–流程图
PS:任何因需求、质量等引起的delay/block 风险问题,QA必须及时关注跟进,推动协调接口同学解决,及时邮件通告。
1.需求MRD评审
PS:需求MRD评审,接口PM/RD评估需求复杂度与风险。分析需要QA测试把关的需求,应主动提前邮件通知QA同学,QA同学提前阅读MRD文档熟悉需求,需求评审中提出测试建议。
2.需求排期
PS:需求排期,明确RD、FE排期及QA测试排期,邮件通告各接口人,QA需有owner意识去推动各角色尽快确定排期,以便安排QA资源。
3.设计评审
PS:设计评审,需提前通知QA,QA提前了解背景及设计内容,参与评审,对数据库结构、架构设计合理性等维度,提出可测性建议,发现数据库及架构设计等底层问题。
4.Case 设计
PS:Case 设计,参考MRD文档理解需求业务,设计业务场景Case,参考接口文档理解接口功能与参数意义,设计接口测试Case,优先覆盖接口核心逻辑,关注边界和异常逻辑。强化接口Case 设计,弱化业务场景Case,注重接口case的自动化设计。
5.测前沟通
PS:提测前,QA主动发起与接口RD、PM的测前沟通,如:Case Review 补充遗漏及更新Case,明确测试重点,模块代码改动点,关联影响模块功能,梳理一份测试checkList。
6.准入测试
PS:a.准入测试,QA和接口RD/PM确认需求可正常提测后,梳理提测邮件,提供准入Case,明确RD/PM的准入Case测试通过标准。如:P0 Case 通过率 >= 90%,P1 Case 通过率 >= 80% 。
b.PM准入验收测试时,除基本需求逻辑外,需关注UI交互设计、文案方面。
c.准入测试不通过的需求项目,QA总结质量风险问题,邮件通告驳回,RD修改解决问题且自测通过后,再次重新提测。QA同学必须对需求提测质量做严格把关。
7.系统测试
PS:a.需求通过准入测试后,QA同学合理安排测试排期时间,做2-3轮系统测试,及时同步Bug问题至接口RD,修复后做及时回归验证。每天必须梳理总结当日测试进度、质量风险问题等,群同步或邮件通告各方向接口角色。
8.Mirror回归(预上线)
PS