关于QA与RD之间的互动


这也是我在多年前针对公司的一些研发与测试之间的各种状况而发表的一点个人看法,原先po在我的另一个网站:http://www.rosoo.net/a/200909/7475.html。而事实上对于这个话题其实一直以来都是一个很大的课题,而且每个人,或者每种角色对此的看法都不尽相同,同时我相信这个话题也会一直延续下去,不管是数十年前,还是现在,亦或数十年后,永远都不会停止。同时,在这几年来又有持续出现一些与这个话题相关的讨论,如:“单元测试要做多细?”一个测试人员的反思!,当然,还有更尖锐、直白的一个讲法:我们需要专职的QA吗?
这都说明了同一件事情:测试很重要,但具体测试的该怎么做?甚至谁来做?我们需要持续的、不断的探讨。另外,我还需要再声明一下的是,我讲的只是基于我个人所在的环境及当时的经历,在不同的环境,不同的经历,不同的时间,都会有不同的结论,简单讲就是:这一切都没什么对错,你只需要找到最适合你现在的状况的一种做法。

以下为原文:

------------------------------------

鉴于公司目前的QA没有一个是拥有RD的背景,且在submit defect & bug的时候经常会出现一些非常低级的描述错误。

举个最简单的例子:
       a) 看不到图像。QA submit一个bug说是看不到图像,但基本上没有一个QA会在bug现象里说明看不到图像的时候,Server有没有流量?Client有没有流量?相反许多时候,加了说明可能又是错误的。
       b) PTZ不Work or delay。
       c) 没有收到警报。几乎从来没人会认真的去观察哪底是哪一段的错误导致没有收到警报,是设备没发出来?还是UniArgus Server的几种可能性?
       ….
当然,我这么说并不意味着我作为UniArgus整体产品开发的RD主要负责人想推卸责任,我只是觉得如果把所 有的责任都推到RD的身上,所有的问题都是由于RD在开发时没有做好测试而导致的这种说法感觉有些不能接受。可以肯定的是RD的确需要加强 integration test,但还有很多时候QA的整体能力和素质也有待提高,UniArgus的产品就这么一些功能,QA每天都很辛苦的重复重复再重复的测试,对于许多问 题其实我觉得他们早就应该很有“经验”了(QA应该早已很清楚出现一些常见的问题的时候可能是什么原因导致的,应该怎么去确定,也即诸如之前一直在上海强 调的FAQ管理),不过话又说回来,如果我是一个QA的话,每天就这么“机械的重复”,也是很容易会麻目的,所以坦诚的说,事实上我也很难去怪QA(因为 其实在这一点上,RD和QA是完全一样的),更何况UniSVR的QA就这么几个人,他们每天都那么忙,而且以目前的状况他们不可能把对Program的 理解上升的RD程度。
因此,考虑到实际的状况,我的观点是:
1. 测试规则的制订
如果要定测试规则的话,应该是由RD和QA一起来定才会比较合理,QA会告诉RD他们是怎么进行测试的,而RD 则可以真正的将所有功能的关联起来,因为RD可以将功能直接细到哪几行Code,而这些Code可能会影响到其他哪些功能,这样的规矩才是真正完善的规 矩,同时这也有助于提升QA测试的完美程度。
2. RD和QA需要定期or 不定期的保持沟通
这一方面是由于目前的UniArgus整体产品并没有真正定型,所以有时候的一些修改可能是颠覆性的修改,那样的话,与此相关的功能肯定需要重测,同时测试规则也可能需要重新定义。
另一方面,RD应该保持对QA做一些基础的、必要的training,并整理和完善与产品相关的一些FAQ。
3. 规则外的一些测试
RD的优点是对整个产品的流程比QA更清楚,但有许多许多时候这个优点其实是最大的一个缺点。就是因为RD太清 楚一个大功能的每个步骤,第一个做什么,第二步做什么,最后才能做什么,常常有状况是RD自己测没什么问题的功能,一到了QA就问题百出,所以,在测试上 还必须加入并加强规则外的一些测试。
4. 最后当然是政策的执行

Leave a comment

Your email address will not be published. Required fields are marked *