小白成长建议(5) 缺陷与管理-云层

缺陷管理

缺陷管理是最开始也是最基础的测试必备技能。在工作了很多年后仍然会发现大量的测试人员没有办法合理的做好缺陷管理。

在我眼中的缺陷管理包含以下几层概念:

1.缺陷的描述

2.缺陷的定义

3.缺陷的跟踪

4.缺陷的度量分析

也许你觉得作为测试提一个缺陷很简单,但是要提一个好的缺陷其实是非常难的。在这里其实还有个隐藏的属性,叫做缺陷的概念,也就是说什么是缺陷?

一般来说缺陷有两种情况,一个是违反了所谓的规则,还有一种是我们无法接受这样的情况。比如对于美来说,每一个人心目中都有一种对美的定义,你会觉得她很美,但是换个人来看待就未必。所谓的情人眼里出西施应该是指个人需求下的狭义定义。而大众情人就是那种所谓的约定俗成的广义规则。

我们做一个软件面向的对象是不同的,甚至我们需要超出用户需求来做一点东西的,所以对于缺陷的判断成为了一个非常困难的事情,这里只能说对于缺陷这种东西,不要用肉眼去看要用心眼去看。

缺陷的描述

关于缺陷的描述,无非就是当别人看到你写了一堆关于这个缺陷的巴拉巴拉后,是不是明白了5w1h,然后能够根据你的建议开始进行缺陷的修改。本质上有一点就是缺陷的描述就像议论文,一定要有说服力。如果你写出来的东西都不能让别人觉得有道理,你又怎么让别人愿意按照你的逻辑去修改这个缺陷呢。

为了方便把缺陷写的更容易理解,所以现在无论是Excel的记录方式还是使用系统的记录方式,我们都会将一个缺陷分割为很多个属性,来便于管理和理解,常见的属性包括:

标题,详细说明,版本,环境,发现人,发现时间,修复人,修复时间,修复说明,状态,严重级别,优先级别等。

本着不浪费笔墨和浪费阅读者理解的前提下,缺陷应该是写的越简单越说明问题是最好的。但是在我遇到的大多数情况下,作为小白写出来的缺陷往往是无法阅读和理解的,因为小白总会觉得自己写出来的东西别人肯定看得懂,而忽略了很多背景或者参考的说明,常见的问题无非是:

我的xx功能出错了;点击某个按钮无效果;无法启动软件等。

包括在各个QQ群的提问,也经常会出现这样的无头无脑,毫无内涵的提问,让别人完全无法回答。甚至常常让我想当你在工作几年后开始学习自动化或者性能测试的时候,连一个问题或者缺陷都无法合理明确的描述出来,你做自动化和性能测试能靠谱么?能解决问题么?

但是写好一个缺陷又不是简单看几个例子就行的,它需要时间和足够多的练习才能做到,让别人看了会明白what、why、where、when、who以及how,甚至还能明白什么是对的,并且应该做成什么样。

如果想要提升自己的缺陷描述能力最简单的方法就是学会吐槽,而且要吐槽吐的到位,那么你就能在生活中反复的锻炼如何使用最精简的语句来说明问题的关键,而不是总在问题的外围徘徊;而同样命中靶心的另外一个要素就是你能从本质知道这个问题的“身世”,就像你手中的一个小骰子,只能有这样几种结果。

等你能够通过吐槽收集能量让你的呆毛蹦起的时候,你就能完成让别人俯首称臣,乖乖改你的BUG了。

缺陷的定义

在这里缺陷的定义主要是指如何判断缺陷的严重级别和优先级别,而不是这个问题是一个建议还是一个缺陷?请注意我用了建议和缺陷来区分问题的两种情况。这和前面说到的有类似之处到底你确定了这是一个问题,还是你觉得这样可能不太合理。

当一个问题被提出,该问题必须要让别人非常明确的看出它到底会带来什么后果,需要在什么样的时间内修复,这样才能有效的让别人重视它。看过蝴蝶效应的朋友应该知道,一个问题如果被轻视,那么随着放大后其结果可能是非常严重的,也许只是一个很小的疏忽或者不重视。

对于提交缺陷的我们来说,需要有能力去评估一个问题的优先级(是不是应该立即修复)和严重级别(它会带来什么样的后果),而优先级和严重级别之间又不是完全强联系也并非完全没有联系。

或许大家对优先级和严重等级的概念会混淆,觉得有点模糊。一般大家会觉得严重等级高的BUG,优先等级一定为高。但这仅是一个包含于的关系,会存在这样一种情况严重等级低(或许只是小的界面问题,例如图片在页面的位置不精确),但优先等级高。或许这样说比较抽象。那么我们来举个例子,INTEL 对于企业LOGO 的精确度要求很高,因为这代表了企业形象。所以有关于LOGO 的相关BUG对于系统的严重等级为低,但优先等级都是高的。缺陷的属性与你所属的行业以及公司文化也是息息相关的。

当没有经验的时候,或者你无法知道该问题是否在关键路径以及影响的后果时,问问有经验的人是比较好的方式。而这也是测试人员的一个基本功,能够分清楚轻重缓急。

缺陷的跟踪

可能大家对缺陷的跟踪相对来说比较熟悉,因为基本上如果工作了都在使用缺陷系统,不断处理着缺陷的生存周期(new,fix,reopen,close等等),缺陷生存周期的目的是为了方便我们跟踪一个缺陷的不同状态,判断其所在的阶段。

而在不同公司,不同的流程下,该流程也不尽相同,合适自己公司的才是最好的。好比缺陷跟踪就像是快递跟踪一样,以前我们发一封邮件,完全不知道对方什么时候收到,现在这封邮件到哪里了,而现在我们可以非常方面的在网站上随时查询得到该快递所在的具体位置及签收过程。

那么对于小白来说首先要理解缺陷跟踪及状态的原理,进一步还要能配置管理这样的系统,帮助公司完成这样的管理工作。

缺陷的度量分析

在有了好的缺陷描述,好的定义和跟踪后,那么基本上缺陷已经可以很好的在某个系统内运转起来了,接着我们要做的事情说得好听点就是大数据分析了。从这些项目数据中,我们要分析出一些藏在数据后的规律,比较常见的包含:

1.常见缺陷导致的原因

2.常见缺陷被修复的时间

3.系统每天新增或修复的缺陷数

4.缺陷的收敛情况

这些数据可以有效的帮助我们看出一些以前看不出的问题,但是这个在中国效果并不明显,因为我们的数据进入就存在不少的国情,而在分析及结果处理上也存在着相应的国情,所以一般公司在做度量分析的时候,往往是越做效果越差,吃力不讨好。但是不得不说不能因为它效果不好而不做它,如何正确的采集、分析数据,需要一些时间和团队成熟度后,才能发挥其效果的。

对于缺陷管理这次我提的内容会比较概念点,因为缺陷本身的例子外面很容易查找到,而大家也会有一些自己比较成熟的看法,让我想起如何拍一张好照片的问题了,答案是啥呢?

如果你想拍一张好照片,请先拍1000张照片,选最好的哪一张作为参考!

如果你想写一个好缺陷,请先写1000个缺陷,选最好的哪个

时间: 2024-12-28 16:07:06

小白成长建议(5) 缺陷与管理-云层的相关文章

小白成长建议(7)-蛛丝马迹-云层

配置管理 从某个角度来说,我一直觉得配置管理才是软件开发的最基本内容,注意这里我说的是软件开发的基本,不是测试!那么和测试有啥关系呢? 在解释这个问题前,我还是想先聊点别的,最后大家自然就知道答案了.配置管理到底是啥,简单来说就是版本控制和回溯,虽然这个概念说出来其实不太对,但是对于大多数情况来说确实就是这么回事. 在配置管理这个话题上可以说的很大,但是也可以说的很小,我觉得这么抽象的一个理论还是用个简单的例子来说明吧. 图书馆大家都应该知道,如何保证图书馆内的书被有效的借阅.订正.标记?这个和

小白成长建议(1)-深思熟虑-云层

前言 在群里有很多人问我这个问题,我是个小白怎么能够进入软件测试这个行业,今年本来我也准备写点关于入门的内容,于是这篇连载就诞生了,估计章节应该会超过20章,每章大概2000字左右,希望大家能够喜欢. 测试工作 在第一章我觉得首先应该谈的就是当你准备进入测试工作的时候,你应该先问自己几个问题: 1.我了解测试工作么 2.我适合测试工作么 3.我能做好测试工作么 因为选择第一份工作是很重要的,当然如果它是你转行之作也是非常重要的,因为只有在一个相关行业有一定的沉淀和积累,那么才能让这个工作变得有成

小白成长建议(8)-知己知彼-云层

需求管理 需求管理我放在了理论的最后一部分来说,也是我觉得最难的地方.需求管理的难在于它对测试很重要但是又离测试工作很远.在前面我们说过用例,特别是系统测试用例非常依赖于需求文档,因为用例的期望值也就是最终结果,是通过需求来确定的.所以用例是否正确其实很多时候依赖于需求是否正确. 记得有这样一句英文非常的经典: Are we build the right product? Are we build the product right? 这里可以很好的说明到底用例重要还是需求重要.优秀的测试人员

小白成长建议--小白如何提问

人类最高级的智慧就是向自己或向别人提问——苏格拉底. 我曾经思索过一番有关提问与回答的不同.在我看来,回答是面向过去的,是被动的,是过去式:而提问则是面向未来的,是主动的,是现在式,它往往意味着对现状的不满,意味着有新的发现.千百年来人们都对苹果落到地上习以为常,但牛顿却对此提出了疑问,也就在那一刹那间,一个崭新的世界已经展现在了他的面前.所以说,好的提问往往比答案更有力量,更能给人以启发! 长期在各个QQ群和网站社区上回答问题,久而久之就开始不太淡定,按照某些人的说法就是“你对我这样一个新人怎

小白成长建议(4) -从头开始-云层

测试入门 从这里开始我们正式来谈谈关于具体的测试技术,我先列一下目录,以便大家知道后面几章的内容: 1.测试基础及测试方法 2.缺陷管理 3.用例管理 4.配置管理 5.需求管理 6.单元测试 7.集成测试 8.系统测试 9.自动化测试 10.性能测试 这些是我觉得比较基本所需要知道的测试技术,而相关的一些开发.数据库.环境搭建等都应该在这之前基本具备的,我也不专门写点啥来解释了. 首先我们先来谈一下所谓的测试基础和方法. 测试基础 其实一说到测试基础能谈的东西特别多,但是理论性又很强,让我消化

小白成长建议(6)-测试的灵魂-云层

用例设计与管理 如果前面说的缺陷管理是作为测试最基本的要求的话,那么用例的设计与管理就是真正成为测试工程师的核心技能. 为何说用例设计与管理是测试工程师的核心技能的,而不是大家所关注的什么技术方向.首先技术方向是手段,但是任何的技术手段都是为了测试目的而服务的,如果这个目的出了偏差,那么所有的手段都无法达到预期的目的,或者就算达到了目的也并没反馈你所希望的效果. 例如我们需要测试登月车在月球上能否正常工作,那么你拿什么技术去测试呢?本质上还要换个角度从测试的思路上改变,在地球上模拟一个类似月球的

小白成长建议 (3)-看书和选书-云层

测试入门 在有了对这个行业的一个了解及需要具备哪些基础后,我们就来谈谈测试入门.那么测试到底是啥,简单说来就是通过一定有效的方式来模拟用户运行软件,证明软件能够达到一定质量水平的手段吧.这里我用的话语很通俗并不规范,其实大家也不用太在意测试的某些概念具体怎么说,总的来说就是better more better,说到这里我想先提一下关于大家总关心的测试入门看什么书的问题. 怎么看书和怎么选书 在谈具体推荐什么书前,我不得不再好好的把怎么看书和怎么选书说一遍.其实在我看来书本无好坏,一本书不可能烂到

小白成长建议(2)-扎实基础-云层

测试基础 不知道在看完上一章之后你是否还有勇气继续选择测试这个工作,或者对这个工作有了一定的了解.那么在进入正题前,抱歉我还是要再做个铺底.就是我们的第二章测试基础. 测试需要基础么? 需要,很需要,甚至我觉得都需要一点点天赋!就像不想做厨师的会计不是好司机一样,测试是一个非常需要跨行业跨领域跨传统思想的工作.想要做好测试,那么你必须啥都会一点,而且为了说服别人,你还得啥都比别人厉害点,这样别人才会服你. 比如你告诉别人乱穿马路是不对的,这是没用的,因为别人不一定明白道理.如果你让他作为司机感受

小白成长建议(9)-苞丁解牛

单元测试 估计对于小白来说,一提到单元测试就是开发.开发.开发,好深奥.好难.但是我想说,单元测试可能是所有测试中最简单的了,想反系统测试可能是最难的,只是所谓的开发门槛让测试人员有些抵触而已. 为何说单元测试是最简单的内容呢,我们先来看一个例子: 有一个人去医院看病,然后医生问了一下病况后直接让你先去抽血,根据抽血的结果告诉你你是感冒了,给你开了一些感冒药.在这个情况下你觉得医生有多少的技术在里面? 另外一种情况,还是去医院看病,病人刚进来还没说话,医生就已经准确的说出了病人的病情和对应的诊疗