测试人员驱动开发人员，可否？（2010-3-3）（获奖名单已公布）

cangmang

这个命题比较有意思哈~
    首先，从目前国内行业的发展和地位来讲，开发是占据主导地位的。
    其次，测试的目的是 检验产品是否满足规定的需求或弄清预期结果与实际结果之间的差别。如此目的来讲，如何驱动？
所以我认为测试驱动开发是不可能的。

但是我想说的是，质量驱动开发
    质量其实就是产品或工作的优劣程度，也可以看作是满足顾客需求的能力。这就大大超脱了测试的范畴。
我们都知道QA、QC，这两个的区别不用细说，相信大家都了解。
    从QA的角度讲，要规范流程和各个里程碑、检查点，这些完全就是为了质量的目的服务的。而这些恰恰是约束开发、提高开发质量的工具。
以规范的流程、制度去约束开发必然会降低开发过程中的质量损耗。同样，质量也可以驱动产品。
    最后，借用质量管理大师菲利普.克劳斯比的一句话：质量的盈利模式就是第一次把事情做对。
所以我认为，质量驱动开发是行业发展的一个趋势。

8596991

其实测试是否驱动开发，需要关注两个问题：一是公司对测试的定位，二是这个“驱动”的真正含义
有些公司对测试定位，确实如大家所说的那种功能测试，系统测试，界面测试，很简单，所以大家都认为没有得到重视，也就是所谓的给开发“擦屁股”。这基本是整个中国测试行业的现状。
但有些公司，对测试的要求还是蛮高的，需要测试能够做功能测试，也能够有做性能测试，更有些需要做白盒测试。如果是这种情况，测试在整个的产品生命周期中，是起着关键性作用的。
在第二种情况的背景下，说说我个人对“驱动”的看法。这个驱动，当然是测试人员更多的去考虑产品的适用对象，在保证产品符合相关文档要求的情况下，去思考他们的使用方式以及他们的使用习惯。这种“驱动”，要求测试人员在产品需求阶段就参与进来，在以后的产品生命周期中一直跟进。在了解整个产品需求以及定位的情况下，多方面的去了解相关的行业的知识以及同行软件。这就与需求分析人员有了很大的区别，在一般的公司，需求分析人员都是市场部门的人，由他们去定位市场的需求，并提交产品部，在多个部门的配合下决定整个产品的框架以及产品的最终方案。
公司的目的是挣钱，测试人员保证的是质量。这样又有人问“QA”是干嘛的？QA负责规范流程以及里程碑，并对产品的结果做验收。测试人员保证的质量，不仅仅是功能正确，更重要的是功能好用。所以，个人理解的测试“驱动”开发，不是驱动开发去开发代码，而是提出BUG，驱动开发去完善代码与重构代码。开发人员，他们眼中只有二进制，你要他们过多的去考虑客户，那是不可能的；测试人员不仅仅按照功能流程做测试，检验功能性的BUG，也在不停的测试中，使用的常人的操作习惯，也能发现软件的易用性BUG；更有甚者，在多次测试中，发现软件的性能或者内存泄露的问题等等。诸多BUG的合成，就能促使开发人员重新考虑代码的可用性，他们会寻求更好的方式，去完善与重构自己的代码。难道这种不叫测试“驱动”开发吗？
另外说些题外话，与其说测试“驱动”开发，还不如我们怎么达到测试“驱动”开发这个层次。虽然现在中国的测试非常的不成熟，定位也低，但我们不能这么低的定位我们自己。在平时的工作中，我们需要接触更多的产品，因为有些行业，是你不曾涉及的，所以在需要的时候，了解相关行业的规则，多看同行的类似产品，就非常关键。
祝愿大家跟随测试行业的不断成熟，都有更好的发展

huxb_dowant

测试驱动开发的首要条件是测试人员对业务和软件设计模型都很精通，同时要对要使用的编程语言比较熟悉，还要有公司高层领导的绝对支持。
测试驱动开发说透了就像测试部门内部开发自己需要的测试工具一样；对需求及软件的目标有清楚和透彻的了解，在做事情以前，所有的东西都了然
在胸。
    做到测试驱动开发软件质量就能上去？没这么简单的事情。我认为测试驱动开发或开发驱动测试，都无所谓，真正提高软件质量才是真正的目标。
其实像国外的大软件公司微软，谷歌他们的软件开发流程就是很成熟的，但国内的软件公司如果把人家那一套搬过来，却不一定能达到好的结果，弄
不好甚至会倒闭。因为投入和产出是不成正比的，一切好的流程必须有好的经济基础和优秀的管理团队来作支撑。没有适用所有脚的鞋，所以每个公
司应该根据自己的实际情况找出一套适合自己的测试流程。   
    我们中国99%的公司说透了不重视测试，而造成这一结果的主要原因是90%的测试人员做的工作技术性确实没有开发强。如果一个测试人员干的活
真的很NB,那他绝对可以NB的炒掉任何一个老板，那他的地位怎么可能不高。经济社会是以创造的价值来说话的，你够强，你就有地位；否则，不要
怨天尤人。
    作为一个测试人员，我们应该要有很强的主动性、学习能力和发现问题根源的能力。有能力必然会有地位；成就是自己给的，不要奢望天上掉金子。
    本人的一点拙见，各位高手多多指教 。

shanxi

被骗进来了

还以为测试 驱动的开发呢

huogongyanchang

我感觉还是有可能，等到中国的软件正的发展的很好，还是有可能的，
如果软件测试人员水平真的很高，这是完全有可能的，
要知道其他的行业很多都是以检验员的标准生产产品

snbc

不存在谁驱动谁的问题；

测试和开发是一个团队伙伴的关系；

项目前期的方案和需求阶段，测试人员需要介入，未产品的方案设计提供评审和参考意见，此时可能重点是一些易用性、易维护性、从客户角度出发的一些功能需求等；避免到了后期测试时提出问题，导致产品有较大更改的风险；

后期测试过程中，测试发现问题，可以利用自己的经验进行缺陷定位或提供缺陷解决的建议措施等；共同提高产品开发质量；

ch2fjc

我们公司很大程度上是测试驱动开发的，很多开发工程师只了解该项目的一部分，或者说有时候不晓得具体要设计成什么样子，这就需要测试工程师去判断了

swordredlin

1、首先明确，测试人员职责是发现问题。
2、不管是系统本身的问题，还是用户体验问题，作为测试人员可以不经过开发人员甚至主管可以直接提到缺陷系统中去。
3、不管缺陷类型，测试人员发现的任何一个问题，甚至是建议性的问题都工作中的成果
4、测试人员除了跟踪Bug进度之外，对于上级不予修改的Bug，一定需要负责人尽可能的给出备注。
这样，测试人员首先完成了自己的职责，对于有些不在职责范围内的事情也可大胆的放下。

dennyqiang

感觉大家对这个主题都有很多想法，我觉得这是好事，起码我们在考虑这个问题了，起码我们引入了这样一种理念：一个软件产品的开发，有一部分是可以由测试人员来驱动的。

其次呢，感觉大家对题目的本意还是理解得不够到位，始终把测试和开发作为一个对立面来理解这句话，基于这样一种观念的话不管谁驱动谁都无从谈起，都只会变成抱怨和无奈。

其实，测试驱动开发为什么一定要把需求人员拉出来呢，为什么一定要想到那以后岂不是测试说了算呢，也不用担心以后前一阶段人的屁股没人擦，如果有这种假设，讨论该话题肯定跑偏。

谈谈个人的一些看法吧：
1) 需求人员是必需的，这毫无疑问，哪怕测试团队有一天驱动了整个项目，需求人员也是必不可少的。
2) 有需求人员就够了吗？测试人员只需要按照SRS文档和其它文档上的功能来测就行了吗？恐怕不完全是。
3) 测试驱动开发就意味着开发从此以后一定要听测试的吗？也不见得，但至少，测试人员应该更主动才对。
4) 我不得不承认，对软件测试行业的从业人员，技术水平与相应的开发人员是有差距的，道理很简单：很多人是因为做不了开发才做测试的，也有真正喜欢测试的，但不太多。
5) 但是大家可不要忽略一点：对一个软件产品的认知能力，测试人员可不一定比开发人员差，这个跟技术水平没有任何关系。
6) 在团队中应该形成这样一种文化，测试人员说了可以不算，但是你必须重视我说的。

以前我们使用ClearQuest系统跟踪缺陷，CQ对于一个软件产品的Enhancement有单独的管理，测试人员想往产品中新加一些功能时便会将建议提交于此，但是开发人员根本没有时间顾得上这些Enhancement，连基本的功能都没时间做，哪有时间Enhance呢，也对。但是这个归要结底还是由于老板没有把这一块做起来，缺乏管理层的支持的确是一个比较头疼的问题，我们也只能在此默默的呼吁一把了。

若干年前，XP这种开发模式就被大家所熟知，其核心就是“测试驱动开发”，只不过它叫Test-Driven Developement，既然大家能接受这种方法论，为何不应该认真考虑考虑真正意义上的测试驱动开发呢，它的英文应该是：

Tester Drives Development   (主 -- 谓 -- 宾)    或者Tester Drives Developer 也行，不过这个显得比较狭义。

[ 本帖最后由 dennyqiang 于 2010-3-8 10:50 编辑 ]

绯苍信

测试工作从需求开始的话就可以....如果只是做单元或系统测试，永远是擦PP的工作

wepheloo

首先大家应该明白测试部门不是质量管理部门，从根本上讲测试人员不需要对项目的质量负责任，他们紧紧是软件问题的发现者，是

尽量减少软件发布后由于软件缺陷而带来的损失而存在的；而质量管理人员需要对项目的质量负责任，他们是为了需求做得更好，为

了让开发写更好质量的代码，为了让测试发现更多的Bug而存在的。测试本身并没有对开发产生什么影响，他们两都从根本上是两权

分立。但测试与开发矛盾为什么会发生？本来当问题发生的时候，如，开发人员总是找测试人员帮忙重现Bug，一次两次大家都觉得

没有什么，但长期如下，矛盾始终会激发。那么这是谁的责任呢？我觉得从根本上讲是由于大家没有明确各自的责任，一方面认为测

试人员就是质量管理人员，软件有问题就不分是非地把矛头指向测试人员；另一方面质量管理人员都是公司的高层人员，他们可能由

于各方面的原因不可能会因为为那种不明不白的事而把责任扛上。于是就不声不响地让测试与开发去吵。而测试与开发即使知道真正

原因但即不敢向上头说什么。所以能驱动开发的不是测试人员，而质量管理

baobao72931

你姓张啊？

zhenni

软件测试群号：3611124  
欢迎进入交流！

NapoleonWang

基本不可行。
首先声明，我是测试人员，免得有人误会我。。。

这个观点应该是从“测试驱动开发”来的。 声明一下，测试驱动开发中的测试是“单元测试”，不是我们所讲的测试，区别有：

• 单元测试是由开发人员完成，而测试是由测试人员完成的。
• 单元测试的主要应用是支持代码的敏捷开发和改动，而测试是为了保证产品质量，根本目的有所不同。
• 单元测试只能完成简单的逻辑测试和功能测试，而无法像测试那样完成全面的功能、性能、安全、场景、安装、兼容性等等测试。

测试驱动开发可以看做是帮助敏捷开发的一种手段。

现在来说测试人员驱动开发人员：这个工作模型是完全错误的，其实驱动开发过程的既不是开发人员，更不可能是测试人员，而是项目经理或者产品经理，其实驱动开发过程就是要控制和平衡三个维度：

• Feature，翻成中文不太好说，就当功能吧，这东西论“个”，可数。
• Resource，主要包括人员和设备
• time，时间，主要是保证什么时候完成什么Feature。

这中间还包括和客户沟通，构思和实现公司的产品战略等等。这个工作是高风险、高模糊性的工作，而且很繁重，不可能交给测试人员的。

alice29funny

当然不行。如果这样也可以，那么项目组长做什么，不如直接叫测试人员做项目组长了。

wynpere

个人觉得测试只能在一定程度上驱动开发即可，比如测试过程中遇到争议的BUG，在测试人员确实了解系统业务及客户需求的情况下驱动开发执行问题修改
完全意义上的驱动似乎与需求人员、系统分析人员的工作相混，意义不大。

znhwj

发现有好多牛人,先向牛牛们致敬!我以前做过开发,后转为测试,我觉得测试和开发是合作关系,测试一定程度上驱动开发,同时,开会也会驱动测试,互相驱动的经果就是使得产品质量得到提升,最终满足客户要求.

zhenni

dsy851009

我怎么感觉你们把测试驱动开发的意思给理解错了呢？
测试驱动开发，并不是测试人员去驱动开发人员，而是开发人员在开始一个项目之前要先测试是否可行等。
跟测试人员似乎是没有必然联系的吧？

mx113040

个人认为：‘测试人员驱动开发人员这句话没问题’，
但解释好像不是说的这个意思呀
‘开发一个软件产品应该以测试人员的判断和期望为依据’这句话的意思好像在说开发一个产品的时候要根据测试人员对需求的判断和理解，如果测试人员理解有偏差怎么办？
另外，开发人员是这个产品的生产角色，测试人员则是这个产品的质检角色，两者是一种对立合作的关系，目标是一致的，所以测试人员和开发人员是互相驱动才对~~