解放QA的唯一途径是"干掉"QA

标签: 解放 qa 唯一 | 发表时间:2014-06-10 22:45 | 作者:草料场
出处:http://www.iteye.com

        在整理资料的时候翻出了一位大神曾经转发给我的分享《 从QA到EP》。联想到最近发生的事,又颇有感慨。

        已经有很多前辈对QA的工作职责,现状及演变方向做了分析。对很多评论,我也是深有同感。

        以下观点只针对部分QA,但国内几乎绝大部分QA都类似。
        个人感觉QA都是苦逼的手工测试者,没什么技术含量,入行门槛极低。
一般用人单位所招QA多是毕业于计算机相关专业或被测系统所处领域的相关专业。但他们的工作内容所需计算机和特定领域的知识少之又少。可以说他们的工作和所学专业不对口。不写代码,不搞领域相关专业研究。自然专业都白读了。 工作内容决定了QA工作看不到 未来。

        其实不应该设立专职的QA。这是解放QA的唯一途径。

        不做测试的开发是不合格的开发;测试没有架构话语权的项目是不合格的组织。
        测试的工作应该让开发自己来做。开发没时间?难道QA就有时间?开发做测试和QA做测试哪个成本小?绝对是开发来做更划算!如果测试工作多到需要专职的手动测试人员参与,这个项目问题大大的,绝对需要改组!
        测试必须自动化! 自动化包括三个层次:单元测试,Service层和UI层。开发在提交代码前肯定要保证功能可用。再加上必须的单元测试,手动测试部分就很少了,开发绝对能顺手做掉。
        Service层的自动化依赖于架构的良好设计。而设计架构(或实施架构)的人必出自开发,当然有架构话语权。让非开发的“外人”,QA,来做这一层的自动化测试绝对是愚蠢至极。
        UI层的自动化代价很高,必须要少而精。BTW, 现实中QA团队没有技术含量,也少有眼界合格的领导。也就只能在这一层做点努力,导致这一层所占比例极高,甚至会出现“UI自动化100%”这样的目标。
        以上三层所占比例一般是 单元测试70%,Service层占剩余的大部(20%-25%)

        再到前面提到的那篇《从QA到EP》。作者在文中提到用高技术含量的特殊团队来替代QA,以及一些组织架构上的见解。我觉得如果有专门的团队来替代QA,那么 这支团队在 整个项目中的地位必须非常高,不仅仅是尊敬,而是对开发团队的绝对领导权。EP成员的 各项福利(薪水,奖金,升职空间)必须出自开发团队,优于其它开发人员。EP的工作非常重要,但又不是在所发布产品中能直接体现的,容易受委屈。当然要让他们拿头一份。其实EP应该由架构师,项目导师级别的人组成。具体如果有编码工作可分配给底下开发。


        还有就是,我非常赞同作者提到的项目Owner制度!这个 扁平化的组织管理结构是必须的。不然就会出现明显的子团队,子团队之间各种不合作。这Owner的综合能力也必须非常强大, 必须非常熟悉项目各项任务,又能为项目争取到该有的资源。除了程序员,没人能管得了程序员。这个 Owner必须是大神级的程序员。统帅无能,累死三军这种事很常见。慎选Owner啊!

 

        正常的项目就不该有专职QA。有就说明这个项目病了, 得治啊!



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [解放 qa 唯一] 推荐:

解放QA的唯一途径是"干掉"QA

- - 研发管理 - ITeye博客
        在整理资料的时候翻出了一位大神曾经转发给我的分享《 从QA到EP》. 联想到最近发生的事,又颇有感慨.         已经有很多前辈对QA的工作职责,现状及演变方向做了分析.         以下观点只针对部分QA,但国内几乎绝大部分QA都类似.         个人感觉QA都是苦逼的手工测试者,没什么技术含量,入行门槛极低.

Scrum中的QA(一)

- - ITeye博客
来自“Priyanka Hasija”的经验,她认为QA在Scrum中要做到:. ① 不仅仅是完成test case,还可以作为Product Owner的代理,完成Acceptance test,在PO没有时间的时候代替PO和团队沟通,甚至通过质疑各种假设等方式帮助PO明确需求. QA在复杂的用户场景和异常流程方面更有感觉,这些可以帮助开发人员做估算时不仅仅考量“happy path”.

文章: QA部门将会消亡

- - InfoQ cn
工业革命始于250年前,在工厂中、农田里、矿井上,机器开始代替人类进行生产劳动. 这在极大的促进了经济增长的同时,也深深的伤害了那些技能一般、无法找到新工作或者没有足够知识去转行的人,这与目前QA所处的境地有着惊人的相似. 上世纪九十年代,由于互联网泡沫的出现,对软件开发的需求急速膨胀,这就需要大量QA来进行测试,以保证软件能够顺利发布.

Git branching strategy integated with testing/QA process - Stack Overflow

- -
In case a feature would not be accepted after testing but we would like to release other features already merged on develop that would be hell. This is a tricky step, I think the best way to avoid it is to keep features as small/specific as possible.

《我眼中的百度QA》:百度QA的特点与核心价值

- - 百度质量部 | 软件测试 | 测试技术 | 百度测试
作者:百度质量部测试架构师 董杰. 个人博客:可百度:“架构师Jack”.       来百度工作有些日子了,在未进入百度之前,由于一直以来百度质量部在业界都是比较低调的,外部的测试同行很少能了解到百度的QA们是如何工作的,如何来应对互联网的研发节奏和质量的平衡. 因此我来百度后互联网上经常都有测试工程师找我打听百度的QA是如何做测试的.

新时代的QA角色:IT全能战士

- - 透明思考 - Thoughts
故事开始于客户告诉我的一个反馈:ThoughtWorks成都的一个项目组,最近这段时间开发工作量变多,于是担任QA角色的某同学自动转入开发模式开始写代码. 不仅自己写,还拉上远在墨尔本的客户QA一起远程结对. 两个QA结对开发,效果出奇的好:代码质量毫无问题,而且对需求理解充分透彻,story完成得又快又好.

从 TikTok“重 QA 轻测试”来看中美软件开发之间的差异

- -
感觉整个一个高级黑啊,看起来像夸实际上是在吐槽. 完全就是靠堆人力成本来弥补软件工程上的不足. 原始视频链接:http://t.cn/A6671nbi. 第一点:很多西方企业都会写单元测试,每个人都知道这是非常基本的事情. 但这里的中国工程师们不需要编写单元测试. 每项代码提交都指望 QA 部门的手动测试,团队在提交之前手动测试每个 code commit 提交.

解放南朝鲜

- 三目艮 - 不许联想
2012年1月1日,全世界的人们都迎来了一个特殊的年份:传说中的世界末日,但这并没有丝毫影响人们辞旧迎新,世界各地的民众以不同方式聚会在一起,迎接新的一年到来.

编程巨星的唯一秘诀

- Ken - python.cn(jobs, news)
# 本文是从 The Singular Secret of the Rockstar Programmer 这篇文章翻译而来. 别以为是那些软件开发定律,别以为是开发出那些特殊用途的软件,别以为是软件设计技术本身. 只有一条真理决定了一个软件程序员的成功还是失败. 由于坚持这个真理,一个资深的程序员能在一天的时间里学会一门新的编程语言,而由于不坚持这条真理,一个初级的程序员用十年时间也只能挣到一份糊口的钱、永远是来实现别人的设计、永远不够优秀而得不到晋升的机会.