传统QA是如何拖慢开发效率的

这是我的亲身工作经历。。。就前几个星期的事情。。。。。

 

有一个项目A，比如在5月1号，PM已经确定好了MRD，然后大家用3天的时间来评审，然后确定好排期了。RD需要5天，FE也需要5天，可以并行开发，然后QA需要3天。这样也就是5月10号提测给QA，然后5月13上线。梦想总是美好的。

 

在开发的过程中，总是有不断出现的细节调整，或者咨询。然后，在5月10号的时候，还在调试和改bug。最终RD或者FE为了表示自己完成任务，就会勉强上线(在这里，任何不以上线为目的的提测都是耍流氓。)，然后QA测试的时候，发现有好多好多的问题，然后，RD或者FE不断的修改，然后，QA又测试，又发现有BUG或者有MRD不明确的地方。最后，定的3天测试时间，用了5天的时间，甚至更长的时间。

 

这就是，我工作中遇到的真实的项目，相信很多同行也有类似的经历。先说说危害：

1.时间不合理的分配。在前10天开发的时候，QA是空闲状态的。

2.因为定好排期，RD或者FE急于上线，提测的质量不符合要求。然后，进入一个恶性循环了。

 

在这里面，有这么一个博弈：RD和FE想着，自己开发完了，反正有QA测试，随便就提测了。却不考虑，如果有问题，这个一个反复的成本是不低的。所以，QA的存在就是让RD和FE有了偷懒或者低质量代码的理由。

 

而在复杂点的项目中，Qa的回归成本是很大的，而且，又不能够保证测试的覆盖面是非常完整的，因为极有可能在某个地方漏了。这就会是一个非良性的循环。不能够按照排期走是正常的。

 

所以，对于互联网的前端开发(PHP以及)，就应该走敏捷。把QA角色给去掉，然后，加强代码质量，提高自动化测试的水平。这便是一个很好的开发模式，整体的开发效率也会提升上去。传统的QA，已经跟不上互联网的前端开发节奏了。