QA(测试) 工作准则建议
身为一个专业的 QA 当然需要有自己的测试原则,这些测试原则不仅可以帮助我们提高产品质量,对外还能体现出我们的专业性,从而让合作方后续还有意愿和我们合作。
1 测试前
1.1 需求评审
必须参与,有问题随时提出,如果涉及到相关背景信息,让相关同学同步一下背景信息。
1.2 技术评审
不管能否听懂,必须参与。
1.2.1 测试排期
在研发同学技术评审完之后,研发同学基本上可以预估自己需要多长的开发时间,所以往往技术评审会上会给出开发排期和提测时间点,这时需要我们给出我们 QA 的测试排期,下面是一个我根据经验总结出来测试排期策略:
1、以研发同学的总开发工时的一半为基调,比如如果前后端同学排期加起来 10 天,那我们的测试时间就折半,初步定在 5 ~ 6 天
2、考虑需求的复杂程度,复杂程度从两方面体现,一是前端跟后端的改动比例,二是修改的链路长度,如果大部分是后端改动或者修改的链路较长,排期可以稍微多一两天,反之,如果大部分是前端样式的改动或者改动的链路较短,可以适当缩短排期或者维持排期不变。
3、考虑业务风险程度,对于涉及到风险程度较高的功能需求,比如涉及到账单结算这样的需求,可能排期会稍微多一两天。
4、结合开发同学一贯的提测质量,如果提测质量一贯较高而且改 bug 一直都很高效,这时可以适当缩短排期或者维持排期不变,否则适当加长排期估时。
5、想想自己在测试过程中还有哪些事需要并行的做,大概会占用多少时间,在初步确定的时间上进行调整
注意:排期不要定得太紧张,给自己留点 buffer,特别是当自己不是全人力都在当前需求测试时,更需要考虑到这方面,尽可能把排期时间加长一些。遇到特别没把握不确定的,可以先说第一次测这块业务或者这段时间还有xxx事在并行地做,估时先估这么长时间,后面如果提前测完则提前上线,但也不要估时太长,这样会让开发和产品同学觉得你能力不行。。。
1.3 编写checklist
1.3.1 checklist 模板
checklist 文档格式推荐使用思维导图。比如 MindMaster 和 processon。我喜欢用这些平台或者软件的思维导图大纲模式来编写 checklist。
包含的内容:checklist 最重要的当然是测试用例,除此之外,附上相关依赖文件和测试数据,包括:prd,技术文档,测试账号,测试数据,测试平台,测试环境,图例(用红色背景标记出 P0 的冒烟 case,蓝绿色标记 checklist 评审时新增的 case ,疑问用黄色背景标注,深蓝色标记checklist 评审后决定删除的 case )等等。checklist 编写指南
注意:多想想需不需要验证数据库或者查询日志关键字来验证链路节点的正确性,而不仅仅是关注黑盒入口数据和返回数据,这种是冒烟case 的测试过程,但是对于正式测试来说这不够精细。
![image-20220202193926899](/Users/bytedance/Library/Application Support/typora-user-images/image-20220202193926899.png)
1.3.2 checklist 编写时间
如果上个需求测试过程中研发同学改 bug 的时间较多导致我们需要断断续续地测试,那可以在闲暇时间熟悉下个需求并输出 checklist,如果上个需求研发同学改 bug 的时间较少,对我们来说主要是连续的测试,可以在上个需求的测试过程中暂停半天或者一天,输出 checklist,尽量在需求提测前写好 checklist,这样主要是为了不让写 checklist 的时间占用提测之后的测试时间。
1.3.2 checklist 文件的位置
checklist 放在统一公共文件夹下,便于后续维护管理。
1.4 checklist评审
评审之前先确认下自己是否真的准备好了怎么确定自己的测试准备工作已经做好了?,提高评审的效率和价值。并提前在 checklist 上用红色背景高亮标记出 P0 的冒烟 case,疑问用黄色背景标注。
评审内容:
与研发和产品同学核对测试用例、测试环境和测试数据等,用蓝绿色标记 checklist 评审时新增的case,深蓝色标记 checklist 评审后决定删除的 case。
如果有疑问可以在这个会议上统一问
声明需要研发同学把冒烟 case 自测通过后才能提测。否则提测打回。
评审时间:尽量在研发同学提测前评审完。不必等 checklist 完整写完再确定评审会议的时间,因为等checklist 写完后可能刚好这两天研发同学和 PM 在日程上很难凑到一块去,这就会导致评审因为没有合适时间而延后,需要尽量避免这种情况。我们可以提前确定评审时间,比如你预估 checklist 一定可以在某个时间点完成,那么你可以尽早拉会,先把研发和产品同学的这个时间点的日程占上,然后继续 checklist 的编写,这样可以更加高效一些,最大化利用时间。
1.5 show case
show case 的意思是研发同学投屏把 P0 的 case 当场演示一遍。涉及前端改动,或者业务方较多的需求,需要让研发同学 把主流程演示一遍,演示通过才开始测试。
2 测试中
提测前观察流程管理平台该需求的状态,叮嘱研发更新状态改为「提测」,开始测试后先检验冒烟 case ,如果冒烟 case 未通过,直接打回提测,建议提测打回前先跟业务的测试 owner 说一下,让他帮你评估一下是否有必要打回。
2.1 高效提问
什么情况下发现了什么问题,理论上应该是怎么样的,实际上是怎么样的。配图用特殊标记和醒目的框出需要重点关注的区域,如果想更清晰一些,可以附上箭头。特别说明:截图截大一点,如果截个小小的局部图,别人很难知道你是从哪截的。
2.2 沟通过程
需求问题尽量不要私聊产品和研发同学,有问题直接在需求群里抛出,艾特指定的产品或者研发同学,这样沟通效率最高,不用你反复转述别人的意思给其他人,且能让其他同学明确知道目前这个需求遇到了哪些问题以及目前的一个大致测试进度。
新同学刚接手的一段时间建议每次拉需求测试群的时候都把业务的测试 owner 拉上。如果碰到无法解决的问题,可以随时艾特或者私聊测试 owner 。
沟通时不卑不亢,千万不要研发同学说不是问题就认为不是问题,被牵着鼻子走,要带有质疑精神,如果你觉得不合理或者可能不符合产品预期的时候及时在群里艾特 PM 出来确认需求。不要担心研发同学不耐烦或者发脾气,遇到这种情况只能说明这个同学的研发素质还有待提升,记住你帮他找出 bug,是在帮他,不是在求他。
2.2 每日进度同步
每天都需要在需求群周知测试进度,让大家明确知道当前的测试进度和遗留的问题,尽量不要等产品或者研发同学来问进度时才说,这样体现出我们不专业,也不利于合作。
进度同步除了告知目前测试进度和延期风险外,最好还简单罗列一下目前遗留的问题并艾特到指定的研发同学,并周知 pm,然后附上缺陷列表链接,把整条消息 Pin 住。
下面是一个比较好的进度模板:
![image-20220203152619097](/Users/bytedance/Library/Application Support/typora-user-images/image-20220203152619097.png)
2.3 注意事项
及时同步 delay 风险。任何可疑的情况都抛出让研发或者产品同学确认,宁可多花点时间确认,不可放过一个 bug 。
2.4 上线前回归和线上验收
上线后回归主要功能,上线后及时验收。验收完毕及时在流程管理平台更新需求状态,并在群聊中周知所有产品和开发同学。
3 测试后
更新流程管理平台上该需求状态为「测试完成」。如果需要填测试报告则填写测试报告。
4 工作过程的提问
有同学可能会有这样的想法,就是自己问问题太多会不会让别人觉得自己能力不行,所以尽可能少提问。这里我澄清一下:
工作中会遇到两种问题,一种是业务问题,一种是技术问题。业务问题独立思考的时间可以稍微短些,甚至直接请教询问都没关系。技术问题可以猜测和探索,独立思考的时间允许稍微多些。
无论是技术问题还是业务问题,在知道自己无法解决后果断询问,不要一直卡在一个地方导致拖慢进度。独立思考的目的一个是培养自己独立思考和独立解决问题的能力,另一个也是节约别人的时间。
QA(测试) 工作准则建议的更多相关文章
- 团队工作准则&贡献分配规则
团队工作准则&贡献分配规则 NewTeam 2017/10/24 v1.0 工作准则及内容 全体成员 所有成员在接受任务时应结合自身情况考虑,如果认为任务内容或时间有不合理之处应当立即提出修改 ...
- 特效TD 的工作准则
特效 TD 的工作准则 作者:Hammer Chen / 转载自 http://hammerbchen.blogspot.com/2013/07/vfx-td-td.html 一直以来都想写这样的文章 ...
- [置顶] SpecDD系列:6个确保您执行“充分”QA测试的技巧
确保团队执行 “足够的” 测试覆盖面是非常困难的,尤其是对敏捷开发团队来说.对于初学者而言,一个开发Sprint中要完成多少的质量保证工作才够呢?我们知道,敏捷的标准是在开发Sprint结束的时候要完 ...
- Hbase的安装测试工作
Hbase的安装测试工作: 安装:http://www.cnblogs.com/neverwinter/archive/2013/03/28/2985798.html 测试:http://www.cn ...
- 测试工作中ADB命令实战
作者:TT,<测试架构师>微信公众号作者 大家能点击进来,说明还是对ADB有所了解或听说过的,可能也会比较熟练的掌握了这些命令,下面描述如有不对的地方,欢迎指正和交流学习,请多指教! 一. ...
- 测试工作中经常用到的几个Linux命令(第一弹)
自己平时测试工作中经常要在Linux下搭建测试环境,有涉及到启动/终止服务器,修改tomcat配置文件,偶尔碰到端口被占用... 这时就不得不需要一些基本的Linux命令来处理遇到的这些问题(顺便迈向 ...
- 大数据项目测试<二>项目的测试工作
大数据的测试工作: 1.模块的单独测试 2.模块间的联调测试 3.系统的性能测试:内存泄露.磁盘占用.计算效率 4.数据验证(核心) 下面对各个模块的测试工作进行单独讲解. 0. 功能测试 1. 性能 ...
- 测试工作中经常用到的一丢Linux命令
自己平时测试工作中经常要在Linux下搭建测试环境,有涉及到启动/终止服务器,修改tomcat配置文件,偶尔碰到端口被占用... 这时就不得不需要一些基本的Linux命令来处理遇到的这些问题 1.cd ...
- 10个在UNIX或Linux终端上快速工作的建议
你有没有惊讶地看到有人在Unix/ Linux中工作得非常快,噼里啪啦的敲键盘,快速的启动命令,飞快地执行命令? 在本文中,我共享了一些在Linux中快速.高效工作所遵循的Unix/ Linux命令实 ...
随机推荐
- 【LeetCode】378. Kth Smallest Element in a Sorted Matrix 解题报告(Python)
[LeetCode]378. Kth Smallest Element in a Sorted Matrix 解题报告(Python) 标签: LeetCode 题目地址:https://leetco ...
- 【LeetCode】228. Summary Ranges 解题报告(Python)
[LeetCode]228. Summary Ranges 解题报告(Python) 标签(空格分隔): LeetCode 题目地址:https://leetcode.com/problems/sum ...
- HDU 6470:Count(矩阵快速幂)
Count Time Limit: 6000/3000 MS (Java/Others) Memory Limit: 65536/65536 K (Java/Others)Total Submi ...
- CS5266替代AG9311设计TYPEC转HDMI带PD3.0音视频拓展坞方案
CS5266替代AG9311设计TYPEC转HDMI带PD3.0音视频拓展坞方案台湾安格AG9311是一款TYPEC转HDMI带PD3.0的音视频转换芯片,它主要用在USB TYPEC拓展坞或者USB ...
- JSP、JSTL标签、EL表达式
JSP.JSTL标签.EL表达式 1.EL表达式:${} 功能: 获取数据 执行运算 获取web开发的常用对象 2.JSP标签 例如: jsp标签还有很多功能,这里只列举出一种. <jsp:fo ...
- MySQL数据库报错 > 1366 - Incorrect string value: ‘\xE6\xB1\x9F\xE6\x96\x87‘ for column ‘Teacher‘ at row 1
数据库报错这个多半是数据库在创建的时候没有选择字符编码,导致输入中文的时候出现报错. > 1366 - Incorrect string value: '\xE6\xB1\x9F\xE6\x96 ...
- Java EE数据持久化框架 • 【第2章 MyBatis实现DML操作】
全部章节 >>>> 本章目录 2.1 标签 2.1.1 标签简单应用 2.1.2 使用JDBC方式返回主键自增的值 2.1.3 使用标签返回普通主键的值 2.1.4 实践练 ...
- 深入 Laravel 内核之观察者模式
装饰模式核心内容: 观察者模式又称为发布订阅模式,定义了对象间的一对多依赖关系,当一个对象状态发生改变时,其相关依赖的其他对象都能接收到通知: 观察者模式的核心在于目标(Subject)和观察者(Ob ...
- redis持久层设置
1.默认为RDB存储方式,每次修改数据库,需要输入指令save才会存入磁盘的dump.rdb文件里,相当于备份快照,下次开启服务后会自动缓存于内存里.当然,满足下面几个条件也会自动保存到磁盘:save ...
- PPT制作图片磨砂玻璃艺术效果
如果图片损害,点击链接:https://www.toutiao.com/i6488928834799272462/ 选择"插入"选项卡,"图像"功能组,&quo ...