需求阶段
-
用户需求说明(用户故事)
- 此内容无,建议给出相关文档,使大家明白产品设计初衷。
-
需求文档
- 目前只产出简单功能原型图,无详细产品设计文档,仅定义了该模块主要功能,模块间的关联未定义或者无细节说明,存在不确定性,影响测试计划的准确性;原型图阅读后无法明确用户需求,描述无序且功能散乱。建议花更多时间完善需求文档(内容及形式)。
- 上下游系统交互功能,产品之间未有效积极沟通,测试时才发现设计问题,后期返工再设计影响项目进度。
-
需求评审
- 目前无评审环节,产品直接把需求给到开发,开发过程遇到问题再改需求;无产品--测试--开发三方共同沟通评审环节,无法提前发现及避免产品设计的缺陷,以致后期返工且质量不可控。建议不要忽视评审工作。
- 评审后对需求文档变更部分进行整理总结经验,提高以后的产品设计质量。
- 需求定稿后,不得随意更改。
-
需求版本控制
- 目前无版本控制处理,也无需求变更流程(需求随时更改,想起来就QQ私发下),需求管理过于混乱。建议增加版本控制(通过SVN等工具管理),需求更新后对更新内容进行明确并且及时通知到测试。
-
工时评估
- 对于需求按功能点统计,估算各功能开发用时,产出开发计划书,以供测试计划参考。
开发阶段
- 开发依据需求文档,产出开发文档,开发经理/产品经理评审通过。
- 开发文档/数据库设计文档同步测试。
- 开发完成后,开发经理评审,抑或是单元测试通过后再评审。
- 开发环境自测通过,一般就转交测试了,个人觉得可以由产品经理进行冒烟测试,验证下开发的主要实现是否与自己设计想法一致。
- 对于测试测出的bug进行分析归类,形成规范文档,避免以后再犯。
- 对于bug处理按照优先级进行,不清晰或无法重现的问题找测试沟通;对于bug闭环流程与测试达成一致。
- 代码版本控制需要加强,开发修复bug提交新代码,需要提供变更代码的差异文件,以供开发经理评审。
- PS:目前项目组无技术/开发经理,开发较为随意,并无代码评审及单元测试环节,也无规范文档,质量无法保证。
测试阶段
-
测试计划
- 依据需求文档及开发计划书,合理安排测试人员用例设计/评审及执行时间,产出测试计划文档。
-
测试用例
- 测试人员依据评审并修改后的需求文档编写测试用例,依据内部标准规范(通用设计方法、Checklist等)编写。
- 内部进行用例评审及对应。
- 外部评审(产品、开发参与)及对应。
- 用例定稿。
- 用例管理及更新(需求变更以及测试过程中发现用例遗漏或错误及时更新)。
-
测试执行
- 冒烟测试,依据内部标准评定,不通过则拒绝测试,可以避免无效测试以及提升开发质量意识。
- 测试人员依据测试用例执行并标记执行结果,统计测试结果并进行分析总结,对于多发性问题形成文档,给至开发负责人。
- bug记录,依据内部规范记录bug至管理系统上。
- bug沟通及回归,统计bug数据,对于经常出现低级bug的开发人员进行提醒。
- 依据内部规范对bug进行闭环。
- 一轮测试完成后,进行组内交叉测试以及随机测试(猜错法)。
- 产出测试报告。
-
测试发版
- 系统发版应严格有效控制,勿随意过多发布,任意发布严重影响测试结果的有效性,增加了测试风险。
-
联调测试
- 目前联调测试执行混乱,各方未有效协调,建议协调好,产出联调测试计划。
- 产出联调测试场景及验证点而后开始测试。
-
测试总结
- 依据统计的bug分析需求及开发方面存在的问题,周知相关人员。发现测试流程中存在的问题,与各方讨论并优化流程,提升项目质量及效率。
- 编写操作手册,也是对系统的再次验证。