动手做automation之前的那些事情

发表于:2012-04-09来源:Csdn作者:superqa点击数: 标签:automation
automation对于QA的测试而言毋庸置疑是很重要的一部分,这也是一个很大的领域,有非常的多的东西值得去研究,作为一个QA的整个career path估计也不为过。

  automation对于QA的测试而言毋庸置疑是很重要的一部分,这也是一个很大的领域,有非常的多的东西值得去研究,作为一个QA的整个career path估计也不为过。

  说到automation,特别是对于一个刚开始的项目而言,很多时候我们第一反应就是现有的框架或者技术能不能实现我这个产品所要的一些操作,可不可以做automation。这样的思考本身没有问题,因为很可能会有技术上的障碍或者很多的东西要去准备。但是基于这样的思路,最近却遇到一些问题。经过其他同事的提醒和自我反思,现在对于automation在项目中的开展有一些和以前不同的体会。也许下面提到的一些东西你之前早就想过或者对你们的项目根本不适用。

  背景是这样的,最近在做一个新的产品,有client和server端,而且是不同的平台。因为是新的产品,所以automation的framework需要准备,当然有很多的组件是可以借用自其他现有项目。于是一开始我们就在基于框架的能力来讨论automation要如何去开展,包括负责开发framework的QA, 产品feature测试的QA,还有对应的developer lead。经过几轮反复的讨论,基本的architecture倒是有了,看似主要的功能也可以做了。但是某天项目经理们(JM)过来问了几个问题,发现还是有很多的地方不清楚,比如下面的问题。

  1. 基于这样的框架,有哪些产品需求里面定义的模块可以被automate?

  2. automation rate估计可以到多少?

  3. Automation framework有哪些具体的item要准备,什么时候可以ready?

  4. 对产品和developer的dependency (比如stub)有哪些?

  ...

  因为和automation QA有几次讨论,开始我还自以为心里比较有底,讲了一通,结果到后来谈到这些具体的问题,发现很多地方还是不太清楚。结合大家的意见,包括来自项目经理,以及developer team的问题,加上项目的现状,仔细思考之后我觉得可能需要一些和之前不太一样的做法。

  1. 从产品出发而不是测试框架出发

  之前我们很多的讨论都是从framework或者technical的角度来看哪些能做哪些不能做。后来觉得这可能有些本末倒置,就想做一个产品,应该是先看我们要做成什么样子,再去想技术上要怎么准备,虽然技术上的实现也可能影响到产品的设计。就想做饭应该是想要吃什么,而不是因为只有绿豆和大米,就只能绿豆稀饭之类的。基于这样的考虑,我们先把framework的技术问题放到一边,先把所有的功能列出,并且向下细分到大的功能点,然后问自己几个问题:

  a. 这个功能点我们准备automation吗?如果不,为什么?

  b. 如果要automate这一部分,产品方面需要哪些support,需要操作暴露接口或者提供stub等等?

  c. framework,或者说将来的automation程序,需要针对这一部分做什么?

  基于功能点的list,针对上面的每一个问题,我们可以做一个matrix,然后一个个来过,这样思考的点就会具体很多,也避免遗漏掉。

  2. automation不只是QA的事情

  之前的一些潜在的观念会觉得developer,甚至项目经理都不care QA怎么做automation,甚至不care你多少要做automation。粗浅的来说,看似有道理,反正我们到时候都测到不就行了。但是这种思路是不对的,因为

  a. Developer care automation,因为他们首先也想知道哪些会被automation cover,将来很容易做regression。另外,他们也想在早期的时候知道哪些部分需要为QA的automation做一些支持,留好相应的接口,而不是等到后期被要求加东西。

  b. JM也care automation。因为这个会影响到项目的进度,而且对新项目而言,automation本身就是很有风险的事情,需要投入多少人力和时间,预期和实际的收益是怎样的。而且和developer一样,JM也想弄清楚需求里面的哪些部分会被automate,这对于风险的评估和控制也是很重要的。

  3. 要做就需要明确的task breakdown和时间点

  这个其实不只是对automation,所有的task都是这样的,这也是我从JMs身上学到的东西,确实是如此,特别是一个团队很多人一起做事情的时候,如果大家一开始对要做成什么样子,会用什么样的方案,以及预期的时间点没有很清晰,是很难得到预期的结果的。

  4. 哪些假设真的成立吗?

  在做一些设计和判断的时候,我们明确的或者隐含的做了很多假设,假设这一部分是这么做的,介绍那个东西肯定会有的,甚至包括假设对某个东西别人和你有一样的理解。很多时候,如果不detail的拿出来review,你会发现别人的想法可能真的和你不一样,或者你了解到的状况是有偏差的。

  这些都是这一两周关于项目automation的一些教训和思考,记在这里和大家分享,也是给自己提个醒。因为是个人经验,所以不一定完全正确,欢迎讨论。特别感谢一起讨论的几位同事,包括他们的耐心。

原文转自:http://www.ltesting.net