TAG:
|
鉴于公司目前的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. 最后当然是政策的执行
|