微信号:grzlwx

介绍:光荣之路官方资讯

挨踢项目求生法则——测试篇(终)

2015-05-01 21:42 光荣之路


只想做测试的测试不是一个好测试,

只想做开发的开发不是一个好开发;

总想做测试的开发不一定是好开发,

但,想做开发的测试一定是一个好测试!

----《光荣之路语录》

法则1
测试必须具备“基本技能要求和“进阶技能要求”

先举两个测试人员因为不具备相应的技能而导致问题的例子。

1)例1:我无法开展测试

某测试人员的工作一直不能开展,我很郁闷,他解释:这个“增加”功能一直没有做出来,虽然“修改”和“删除”功能做出来了,但因为没有“增加”功能可用,所以……

听了后我有点恼火:为什么你不能到数据库中添加一条记录,然后你不就可以去测“修改”和“删除”功能罗!

他不好意思地说:我没玩过数据库……

2)例2:需要程序员帮忙的测试

我有事找某程序员,但他不在座位不知道干嘛去了,后来我了解到原来他去帮助美女测试了,他帮忙设置测试环境,包括:安装服务器的操作系统、安装数据库、安装程序、设好配置文件等等。

我觉得他做得挺好的,大家就应该互相帮忙嘛。但下一个版本,他又重复做类似的事情。

我问:上次你没有教会她吗?这次让她自己搞定就行了。

他说:她好像不太愿意学……

类似的事情我遇到的不少,由于测试人员掌握得知识太少了,以致很多工作都需要别人准备好安排好他才能做。而更让我气愤的是,有些测试学习的欲望很弱,而且对测试工作的认识很肤浅。一些测试认为:测试工作就是软件做好能见到界面后,我在界面上点鼠标和敲键盘就可以了,高级一点的测试工作就是能用LoadRunner之类的工具来做性能测试。

其实大部分测试都是追求进步的,“学习欲望弱”很可能是没有认识到自己需要学什么,没有打牌自己固有的思维框框,没有能发挥自己的强大潜力。要改善测试工作,作为测试人员的你首先应该自我检讨,看看有什么可以改善的地方。

“图1:测试人员应该具备的技能” 中列出的要求,你必须至少要达到“基本技能要求”和“进阶技能要求”这两个层次。只要你有心去学,只需要3-6个月你就可以基本满足这两个层次的要求。而 “高级技能要求”难度有点大,一般没有3年以上的相关工作经验是很难满足的,你可以考虑将这方面列为你的发展方向。只要你达到“基本技能要求”和“进阶技 能要求”,你的能量将会成几倍爆发!


法则2
拒绝二手需求

“二手需求”就是项目经理获取需求后,将需求传达给测试,这样就变成二手需求了。

但这只是理想境界,通常是项目经理将需求传递给开发,然后开发告诉测试你怎样测就可以了。所以实际情况是,我们测试得到的是三手甚至三手以上的需求!

让测试获取一手需求的做法:

1)测试人员参与到需求调研中来,甚至让测试成为需求负责人;
2)需求文档不要等全部写好才给测试看,每写一部分就要与测试沟通。


法则3
测试至少要成为第二熟悉需求的人

项目中最熟悉需求的人通常就是项目经理,或者是需求分析师(产品经理)。

测试至少要成为第二个最熟悉需求的人,并且要争取成为第一位,将项目经理“干掉”!

法则4
拒绝半个人

不少项目后期才安排测试人员进入,而且测试人员还需要同时负责另外一个项目的测试,你最多只能得到“半个测试工程师”。

测试需要从项目的一开始就介入,并且每个项目至少要配备一名“完整”的测试。


法则5
是不是缺陷,测试说了算!

有一个缺陷,测试认为是缺陷,但开发认为不是,并且用一堆测试听不懂的话来解释这不是缺陷。

这种状况很常见,你们会用哪种方法裁决?

A)测试因为听不懂,所以最终被开发“说服”,这个不是缺陷。
B)交项目经理裁决,项目经理通常是开发出身的,所以最后就会变成这个不是缺陷。
C)交客户裁决。
D)少数服从多数。测试一定是少数,所以结果你懂的……

我以前的做法就是交项目经理裁决,后来觉得可以做得更好,我将做法改成:其他人可以提建议,但是不是缺陷的决定权在于测试!

我这样做是因为:

1)测试的角度更接近客户,他的判断更靠谱。
2)测试因为有这样的一个责任和权力,他工作会更投入,会更加努力提升水平。
3)“是不是缺陷”和“能不能按时发布”,两个问题要分开处理。不能因为要按时发布而掩盖质量问题,有质量问题也可以按时发布的嘛,但如果缺陷被掩盖掉了,就相当于埋下定时炸弹。

法则6
测试获取开发代码

请先看一个案例。

案例:需要界面规格说明的测试

某测试提出这样的要求,希望开发人员能提供界面的详细规格说明,以便可以开始准备测试用例,为正式测试做好准备。

开发人员反对这样的要求,因为这事情太浪费时间了,而且界面经常会变和调整的,这个文档我岂不是要天天改!

这是事情解决起来很简单,每一位测试的电脑上都装上开发工具,每天测试就好像开发一样去获取代码,测试每天干这些事情:

1)编译代码,检查是否编译通过。如果发现编译不通过,项目小组发达了,今天有人请吃饭,请客的人就是让代码编译不通过的代码提交者。
2)如果编译通过,那就进行“冒烟测试”。冒烟测试干的事情就是将主干业务流程走一遍,将所有能点的按钮和菜单走一遍,看看会不会出错。如果出错,那恭喜你,又有人请吃饭了!
3)对照需求检查程序是否在正确的轨道上,及时提出易用性方面的改进建议。

这样干其实就已经做到测试前置了,这样做就不会出现直到正式测试阶段才能见到软件庐山真面目的情况,问题不会在最后才爆发出来,前期已经发现并避免了。

要做这个事情,测试并不需要懂开发,会用开发工具,会编译软件就可以了。有条件的时候,测试还可以去学习代码,甚至逐步开始写一些测试代码呢!


法则7
人人都是测试

一般软件公司开发与测试的人数比例,大概是 4-8:1,当然也会有比较悲剧的公司是 20+:1 的。

我觉得比较合理和比较符合现实的比例也就是 4-6:1。我们就是按这样来配置的,但仍然会出现测试人数不够的情况,那是不是需要招聘更多测试呢?

如果已经做到法则6,测试的工作已经前置,那么到正式测试阶段,测试工作量峰值将会下降不少,但仍然是不够人数做测试的,这个时候本法则“人人都是测试”就适用了!

测试要实现做好测试方案,到正式测试阶段,将测试方案中的工作分派给开发,让开发也带上测试的帽子进行测试,记住基本原则就是不要让开发测自己负责的模块就行了。

法则8
测试设计的难度不亚于软件设计

我将测试方案及工作的规划,称之为“测试设计”。

如果测试只懂业务是很难胜任测试工作的,请看以下案例。

案例:某技术要求高的系统

该系统有几个技术难点和测试难点:

1)B/S架构,但界面的易操作性要求很高,写了很多JS脚本。系统需要在IE6、7、8上能正常运行。
2)系统需要部署在网络负载平衡的环境上。
3)系统有很多Windows Service服务,要定时生成很多数据。
4)系统需要满足一定的并发访问量要求。

如果不具备“图1 测试人员需要具备的技能”中的“进阶技能要求”和“高级技能要求”,你将会对这些测试难点素手无策。

当时我们的测试没有这么厉害,我相信很多项目的测试也不会这样厉害,而很多项目其实是有很多技术要求和测试难点的,那我们该怎样办?

记住“法则7 人人都是测试”,项目经理或项目的技术大牛就应该承担起测试设计的工作,但要注意要带上测试一起来做,训练测试逐步掌握这些技能。

法则9
不需要写面面俱到的测试用例

曾经见过某领导对测试的要求很“苛刻”,他要求测试无论事无大小必须写出面面俱到的测试用例。比方说一个登陆系统的功能,如果按照该领导的要求,要将所有测试数据都写清楚,那么写出来的测试用例至少需要10页以上的A4纸。

这是一个比较极端的真实案例,稍微没有那么极端的情况是,要求所有的需求都需要对应有文档化的测试用例。

在软件开发工作当中,其实有些工作是属于“常识性”的,你闭着眼睛也会做的,这些内容就没有必要文档化。

比方说我让你写一个吃饭说明,你会这样写吗?

1)用一只手拿起筷子;
2)用另外一只手捧起碗;
3)用筷子将碗中的饭扒到嘴中,记得要张大口噢;
……

你看了上面这段描述,不知道吐血了没有?

我们只需要对比较复杂的、容易出错的、有难度的地方,写出相应的测试用例,测试用例的描述在于描述清楚测试思路,不需要事无大小都写下来。

当条件成熟的时候,公司可以逐步建立测试用例库,对常见的情况建立测试指南,让所有的测试人员去学习和参考,项目中遇到类似的情况就可以直接参照用例库了,不需要再写一次测试用例。

法则10
测试也是开发,开发也是测试

当我是一个人写程序的时候,我就是按照“法则10”来干的;当我和另外一位程序员负责一个软件的时候,那三年时间我们基本上也是按照“法则10”来干的。

当我做的项目的人数是几个人以上后,这个“法则10”就很难实施了,不是我不想实施,而是因为各种客观条件并且我的领导不同意。

我的观点是:一名优秀的测试同时也应该是一名优秀的开发,一名优秀的开发同时也应该是一名优秀的测试!

但目前常见的现状是:

1)能做好测试的优秀开发有,但数量不多;更多的是没有测试意识,代码质量很差的程序员。
2)测试大部分是不懂开发的,我们认为优秀的测试往往也是不懂开发。

我曾经想尝试这样的管理模式:

1)开发必须每年有一段时间换岗做测试工作。
2)测试也需要每年有一段时间换岗做开发工作。
3)干脆就不招聘测试,只招聘开发,但要求该岗位也要负责测试工作。

第1)点很难实现,因为开发基本不愿意去做测试。

第2)点基本无可能,因为测试编码基本功通常为零,而且很多测试是因为不喜欢编码才做测试的,悲剧!

对于第3)点,我承认,我是在“痴心妄想”!

现实可行的做法可能是这样的:

1)让有培养潜质的开发带上测试的帽子,负责某些项目的测试工作。该方法能提升开发的编程素养,也可以培养综合性人才。
2)让具备条件的测试在某项中带上程序员的帽子,让他写代码。

我一直没有能在我管理的公司中尝试这样的管理模式,但我相信这样的管理方法一定会极大的提升公司的生产力和战斗力,看你敢不敢和能不能去尝试了?

小结summary

要改善测试工作首先要从思想上重新定位:

1)测试并不是一个低技术含量的工作,相反,测试工作重要性和难度并不亚于软件设计。
2)测试并不是项目后期才开展的工作,而是从头到尾都需要的工作,是保证项目始终在正确轨道上的重要工作。

如果你是测试工程师,提升你的水平,发挥你更大的能量,这是你的当务之急。想别人和公司重视你,是靠你自己的实力去争取的!

如果你是项目管理者,你要注意的是:

1)项目管理者最优先要做的事情就是保证大家都在做正确的事情,你要从测试的角度从项目一开始就进行监控。
2)给测试工程师权力和成长机会,帮助他们成长,让测试工程师分担你更多的工作。
3)测试其实是一种帽子,其实谁都可以戴,要善于安排测试人力资源。

如果你是程序员,你需要多从测试的角度来检验自己的工作,你的工作目标就是不让测试工程师测出任何缺陷,将测试工程师“废掉”!


(作者:张传波 来源:http://www.cnblogs.com/umlonline/p/3485631.html)

光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499



 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 五幅图演示ASP.NET编译过程 天赋是牛人的基因? 聊一聊那些神一样的程序员们(中) 为什么你应该尝试全栈 “天猫·喵葩”电商互动生态共创论坛-北京站