问题描述:测试人员驱动开发人员,可否?
精彩答案:
会员 rolei :
1、测试和开发什么关系?
独立?依赖?
合作,才是正道。
软件过程发展了这么多年,每一个岗位的职责定义已经很详尽,如何何作也有详细描述。
为什么执行的不好?为什么让测试做的如此痛苦?
不是谁驱动谁能解决的,只是岗位职责下的奖惩措施不明确,缺少必要的约束。
2、你想管理开发吗?
也许你会说,测试只是督促,只是希望开发的质量更高一些。
如果你没有管理权,能否驱动的了开发。
从合作到管理,这种关系的变化,测试自己是否能接受。
测试不需要驱动开发,只能驱动自己。
痛苦不可怕,找到原因改正。
不要抱怨,不要等待。
期待和争取更多支持的同时,还要自己不断前行。
质量不是测试一个人或几个人的事,质量是团队共同努力的目标。
会员 carina2010 :
测试能不能代表用户,其实有很大的局限性。
如果是网站,大家还可以站在普通用户的角度测试一把,要不然一些专业一点的软件,都有一定的行业特征,拿功能测试来说:
例如电信方面的软件,你必须知道电信人员是怎么工作的;
如果是财务软件,你就要知道财务人员是怎么回事情,你才是真正的站在用户的角度;
但是现在大多数的测试并不知道自己的用户是做什么,甚至不知道用户怎么用软件去工作。
站在这个角度驱动开发其实没有多大的驱动力。
至于性能测试等等,就更别提了。自然更加复杂。
然后很多测试不懂开发,所以提不出有关性能或其它的建设性意见,只能是开发怎么做,测试怎么测,顶多就是提点界面的问题啊什么修改(有时候这个,开发有可能也会不理睬),SO,不受领导重视,地位低下的评论就出来了。
测试就是一个怪圈,在中国来说都是属于不含多少技术量的职位,其实测试真应该多一些代码,架构以及需求方面的特长或知识,这样才能真正挖掘软件的BUG,但是有这个技能的,都不会去做测试吧,哈哈。
所以说,要测试驱动开发人员,有几个条件:
一、测试懂你要测的软件的功能实现的目的,这样才能了解软件功能的实用性和写测试用例的完整性;
二、测试要能全程参与需求,这样才能评估开发的功能是否满足客户所需。减少返工次数和提升客户感知度;
三、测试懂一些代码,不懂代码也要懂逻辑。这样才知道业务是怎么通过软件实现的,然后可以挖掘出更深层的BUG。
等真正实现这个的时候,估计你在公司也是大牛一只了,驱动开发人员,那是当然的啦。
原帖地址:http://bbs.51testing.com/thread-183882-1-1.html
版权声明:本文由会员rolei,carina2010首发于51Testing软件测试论坛每周一问活动(10-03-03)。
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。