问题描述：测试人员驱动开发人员，可否？

精彩答案：

会员 rolei ：

　　1、测试和开发什么关系？

　　独立？依赖？

　　合作，才是正道。

　　软件过程发展了这么多年，每一个岗位的职责定义已经很详尽，如何何作也有详细描述。

　　为什么执行的不好？为什么让测试做的如此痛苦？

　　不是谁驱动谁能解决的，只是岗位职责下的奖惩措施不明确，缺少必要的约束。

　　2、你想管理开发吗？

　　也许你会说，测试只是督促，只是希望开发的质量更高一些。

　　如果你没有管理权，能否驱动的了开发。

　　从合作到管理，这种关系的变化，测试自己是否能接受。

　　测试不需要驱动开发，只能驱动自己。

　　痛苦不可怕，找到原因改正。

　　不要抱怨，不要等待。

　　期待和争取更多支持的同时，还要自己不断前行。

　　质量不是测试一个人或几个人的事，质量是团队共同努力的目标。

会员 carina2010 ：

　　测试能不能代表用户，其实有很大的局限性。

　　如果是网站，大家还可以站在普通用户的角度测试一把，要不然一些专业一点的软件，都有一定的行业特征，拿功能测试来说：

　　例如电信方面的软件，你必须知道电信人员是怎么工作的；

　　如果是财务软件，你就要知道财务人员是怎么回事情，你才是真正的站在用户的角度；

　　但是现在大多数的测试并不知道自己的用户是做什么，甚至不知道用户怎么用软件去工作。

　　站在这个角度驱动开发其实没有多大的驱动力。

　　至于性能测试等等，就更别提了。自然更加复杂。

　　然后很多测试不懂开发，所以提不出有关性能或其它的建设性意见，只能是开发怎么做，测试怎么测，顶多就是提点界面的问题啊什么修改（有时候这个，开发有可能也会不理睬），SO,不受领导重视，地位低下的评论就出来了。

　　测试就是一个怪圈，在中国来说都是属于不含多少技术量的职位，其实测试真应该多一些代码，架构以及需求方面的特长或知识，这样才能真正挖掘软件的BUG，但是有这个技能的，都不会去做测试吧，哈哈。

　　所以说，要测试驱动开发人员，有几个条件：

　　一、测试懂你要测的软件的功能实现的目的，这样才能了解软件功能的实用性和写测试用例的完整性；

　　二、测试要能全程参与需求，这样才能评估开发的功能是否满足客户所需。减少返工次数和提升客户感知度；

　　三、测试懂一些代码，不懂代码也要懂逻辑。这样才知道业务是怎么通过软件实现的，然后可以挖掘出更深层的BUG。

　　等真正实现这个的时候，估计你在公司也是大牛一只了，驱动开发人员，那是当然的啦。

原帖地址：http://bbs.51testing.com/thread-183882-1-1.html

版权声明：本文由会员rolei，carina2010首发于51Testing软件测试论坛每周一问活动（10-03-03）。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。