作为一个测试人员,在你提出问题之前请先想想如下问题

之前架构师米洛阐述了测试员报BUG的礼仪,并且引申出一个问题,该如何和程序员交往。其实,程序员群体,甚至推而广之的工程师群体,并没有那么的脾气大,对待测试人员还是挺客气的。

根据架构师米洛多年的开发经验,工程师还是希望通过解决一个接着一个的问题,来提现自己的价值。就像LOL中的推塔一样。

其实很多测试人员并不知道,出现问题之后,找程序员之前,该确定那些个问题,更能让自己的问题得到快速解决。

这里告诉测试员尤其是MM,你提供的信息越是多,越是全,程序员GG越是会觉得问题很容易重现,就会先去解决。当你的问题得到先解决的时候,你会感觉爽么?

呵呵,下面咱们来举几个例子,谈一谈测试人员在给程序员报告BUG之前,自己首先需要思考的问题。

(以游戏开发为例)

1. 这个问题是不是策划/产品需求?

某些 QA 看到一个功能和自己想象的不太一样,直接来找我,说这个有问题吧。我说策划就是这么设计的(当然我也未必赞同),然后让他去和策划撕(机智如我)。

2. 版本是否是最新?

这个开始的时候几乎每天发生,报过来一个问题,我想了半天问题出在哪,结果发现他只是版本没更新到最新,就很气,很蓝受。

后来我学乖了,每次接到问题先问下版本号多少,服务端有没有更新(我们有多个用于测试的稳定服)。当然 QA 也更机智了,现在每次提问题前都会告诉我已经全部更新了(斗智斗勇)。

3. 问题来源是否是配表错误,UI 工程问题,模型特效问题?

类似于护卫舰在6级的时候血量偏低,或者某个 UI 位置没有对齐,这种问题当然是需要策划 UI 先排查一下配表和工程,多半不是逻辑代码中的问题。

架构师米洛就之前见过一个程序员,帮测试员分析问题,每次都搞好长时间,第三次发现还是测试环境的配置错误,当场就骂了测试员一顿。因为测试员没有按照配置要求去搭环境,导致这种问题重复出现。如果测试员碰见那种忙得脚不沾地,脾气还有点不好的高级程序员,骂人还是轻的。

4. 问题是否能稳定重现?

这一条不是必须的,但是有当然更好。由于游戏开发的特殊性,很多BUG重现条件都极为苛刻,出现过两次以上即可认为是有问题了,这种情况下我也会去查。

基本上做到以上几点,说明这个问题值得一查,不是浪费时间,我都会认真去查一下。毕竟是团队合作,沟通也是开发过程中比较重要的一环。

那么问题来了,为什么我们在报BUG之前要思考这些问题?

我是架构师米洛,产品和技术经理,助你升职加薪。觉得文章有用,请点转载,赠人玫瑰,手有余香。

时间: 2024-08-06 16:03:40

作为一个测试人员,在你提出问题之前请先想想如下问题的相关文章

老徐杂谈:作为一个测试人员,思维比技术重要!

核心观点:作为一个测试人员,思维方式比测试技术更重要! 欢迎提出你的不同观点 正文开始: 任何事物都是相对的,老徐今天聊的这个话题,不是说测试技术不重要,而是哪个更重要的问题: 肯定有很多测试同学,极力反对老徐的这个观点 思维怎么会比测试技术重要? 不会测试技术,还做啥测试? 不知道测试理论,连测试点都设计不了! 等等 老徐想说的是: 测试的目的是什么?大家好好想想 很多同学, 测试理论一堆一堆的 设计的测试用例,看起来非常完美,天衣无缝 各种测试用例设计方法用的炉火纯青 但是: 然并卵 并不能

双11大促期间,作为一个测试人员的反思

双11大促,发现大部分测试人员只能做做功能测试. 但其实我们能做的很多,但是都是要求有一定权威性和执行力,我们所缺乏:1.针对免测情况的各业务风险评估--mike:目前的EOS权限控制在开发,RPM根本没有权限控制系统,所以测试环境部署确实,业务免测测试也经常不知道.这个问题已经在沟通解决了,会让运维开发RPM的权限管理系统,慢慢地把权限从开发人员收回,免测试发布一定要经过测试人员(部署测试环境这一环节,部署的时候由对应测试人员评估风险) --me:其实这个也不解决根本问题,就算把权限从开发收回

【敏捷测试】一个测试人员在参与敏捷测试的经验分享(2)

一个迭代开启时,PO划分完本次上线的功能模块,让相关开发测试等人员参加需求评审前的步骤: 1.PO和需求人员确定好本迭代需要完成的功能模块: 2.根据功能模块划分story: 3.每个story编写相关的AC条件: 4.以邮件的形式发送给开发和测试人员进行需求评审: 5.需求评审结束之后,PO再以邮件的形式通知到开发和测试人员参加PO讲story会议,此时敏捷小组的SM负责领取本次sprint可以完成的stroy. 名词解释: PO:Product Owner 产品负责人 AC:Acceptan

作为一个测试人员的素质(如何做好测试)

1.产品评审: ①发表自己的意见:②评审的时候不能只停留在ui,尽量让产品说清楚(交互,排序方式,刷新规则,分页处理) 2.测试计划,测试方案: 测试计划:描述了要进行的测试活动的范围.方法.资源和进度的文档.它主要包括测试项.被测特性.测试任务.谁执行任务和风险控制等. 测试方案:描述需要测试的特性.测试的方法.测试环境的规划.测试工具的设计和选择.测试用例的设计方法.测试代码的设计方案. 序号 角度 测试计划 测试方案 1 组织方式不同 管理文件 技术文件 2 目的不同 强调"做什么&quo

测试人员内功心法

转眼间2017已过了十天,中国传统的新年也马上来临.目前大家的状态应该是人在曹营心在汉,早想着回家过年的事情了吧?抢票,参加年会,中奖的高兴请客,没有中奖的替同事高兴,反正是不亦乐乎!由于最近一段时间比较忙,也没有写太多的东西出来分享给大家.不过在这新年即将到来之际,还是感觉应该写点儿东西的. 往期我分享的博文一般以技术偏多,要么就是一些儿个人心得,具有指导性的文章:不过这些都是比较具体的套路,就像武学上的刀法,剑法,棍法什么的,其实最重要的心法,我一直没有涉及过.原因是什么呢?中国人每个人都有

测试人员的核心能力与素质

声明:该文不是我的原创作品,是我的同事魏增艺的大作,独家授权我来进行发表. 在<测试人员的角色>一文的最后,我们相信优秀的测试人员是项目的前灯,是整个研发系统的反馈回路.那么什么是优秀的测试人员呢?具体说来,具备哪些核心能力与素质的测试人员才能胜任这样的角色呢? 对于能力模型,例如常见的"冰山"模型."洋葱圈"模型等,都将一个人行事的内在动机或价值观等置于核心位置.同样,对于一个测试人员,我们并非看他在进行什么活动,而是要关注他为什么要进行这些活动.本文

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

【转】 测试人员的职业规划 --整理标注

不同类型的软件公司,对测试工作的重视程度也有很大不同.建议测试人员选择一些业务持续发展的公司.做项目东一榔头西一棒的公司,是不需要高质量的测试的,他们需要的是尽快把软件交出去,却无法静下心来思考,怎么把质量做好.选择这样的公司,要冒相当大的风险. 接下来说一下大家关心的话题,如果选择了测试,怎么能从测试团队中脱颖而出呢?经常被提出的概念有“管理和技术两条路线”,这个概念太抽象,还是无法帮我们理清思路.有的观点认为,测试要学习开发技术,这个也没有说到关键点上.我认为测试人员的职业发展有下面两个,换

51Testing专访史亮:测试人员在国外

不久前,我接受了51Testing的访问,讨论了软件测试的一些问题.以下是全文. 1.史亮老师,作为我们51Testing的老朋友,能和我们说说您最近在忙些什么吗? 自2011年起,我加入Microsoft Office部门,参与了Microsoft Office 2013的研发,主要工作是测试Windows版本的Office产品.目前,我正参与研发下一代的Microsoft Office,主要工作是测试产品和开发测试辅助工具. 今年,我的新书<软件测试实战>问世.这本书基于一个很朴素的想法: