Infoq发布了文章,这里我还是吐槽原文,未修改的,让大家品味下:

 

2、无悔选择测试之路-路上的抉择、进取

 

 

有了流程规范,接下来是实施和持续改进,运用在一个项目上,先做了三个月吧,不停地测试,编写功能测试用例,也走了2条弯路:

 

 

1、用例花了大量时间编写,就连:打开浏览器,输入xx,点击登录,这个也记录了(这种是早期状况)。

 

 

2、我居然还请缨加入开发,因为看到一些任务完成不了,后来雷叔也指明,测试做测试应该去做的,如果我当时帮忙做开发,那么很多测试都完成不了,一样保证不了质量。

 

 

所以,测试人员除了要了解业务之外,使用简单、清晰的语言结构来进行测试之外,还应该准确定位自己,明白自己在整个版本迭代中,控制质量的位置!

 

 

大家可能想知道,那段日子锻炼了什么?那三个月无法忘记,每天高强度测试,用的最多的就是,功能测试:边界值、场景法;白盒测试。其实就是锻炼了测试的基础技能和流程管理。

 

 

后来测试管理逐步建立,但是在测试过程中,应当如何提高代码质量,也参考了敏捷开发中高质量 Java 代码开发实践:http://www.ibm.com/developerworks/cn/java/j-lo-agile/,做了一些适合团队的改进:

 

 

wps_clip_image-4142

 

 

6点不言而喻,这种迭代版本中java代码质量提升的模式,已经采用了将近一年,非常有效果。

 

 

   同年Q2,对测试管理进行了改进,其中是受到,@段念-段文韬,组织敏捷测试(http://www.infoq.com/cn/news/2011/01/dn-agile-test-3)影响,采用类似“一页纸计划”的测试文档(在此要感谢@段念-段文韬)在redmine进行管理,之前每次整理测试计划,发送给开发人员,实际上耗费了一些时间,并且成效不大,现在的任务:需求、开发、测试,全部交给redmine管理,所有事情一目了然,对任何人都是可见的,有没有完成,进度如何,非常清晰。

 

 

ok,之前不是讲过检查表的做法吗?虽然覆盖了不少范围,用了一段时间,收效不大,决定改进,变成季度性检查,包括的方面比较多。

 

 

后来为了规范整个开发测试流程的管理,包括开发、测试的交互,又制定了SQA框架,轻量级的:

 

 

wps_clip_image-8251

 

 

图 最初制定的SQA框架(2011331日)

 

 

后来发生了比较大的变化,做的更好、更轻量级,无独有偶,买了一本@朱少民老师,的:《全程软件测试》,发觉这个SQA框架也是渗透到目前的每个环节,更适合目前团队的scrum模式,在此也要感谢@朱少民老师,真是相见恨晚,不然可以少走很多弯路!!!

 

 

大家可能会问,scrum模式,有很多用户故事,测试人员怎么利用?为什么想到这个,当知道遗漏了测试场景,会很不爽,怎么避免呢?加上@Aullyxiao的《软件测试之魂》提到分层测试的想法,想了想,还可以结合这么整:

 

 

 

 

wps_clip_image-26797

 

 

对于目前的开发架构来说,一个用户故事,或许涉及这四个点,可以从这个四个点入手来进行质量保证,如何做呢?单元测试就开发人员处理了,代码审查,测试人员可以参与和监督,其实就是要保证将:开发任务与提交到svn的代码进行关联,这样子,当测试人员检查开发任务的时候,就可以找到改变过的代码,曾经试过从这些代码里面查看逻辑,找到分支场景,补充到测试用例里面。当然,在此期间,看过@架构师Jack,《功能测试用例基础设计模型》,也采用了其中一些;还有@季哥来自淘宝,的探索式测试,我觉得自己还需要时间来消化。