解放QA的唯一途径是"干掉"QA
来源:互联网 发布:nba2k14 for mac 迅雷 编辑:程序博客网 时间:2024/05/22 02:06
在整理资料的时候翻出了一位大神曾经转发给我的分享《从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。有就说明这个项目病了,得治啊!
- 解放QA的唯一途径是"干掉"QA
- qa是
- "抱怨"的人永远是"打工"的命
- "不要自己发明轮子"与"了解轮子是如何发明的"
- "不要自己发明轮子"与"了解轮子是如何发明的"
- 成为"天才"的必要条件是"刻意练习"…
- QA
- QA
- QA
- qa
- QA
- $("#id").val()取值textarea是""
- 真的是"关心"?请别传递…
- "不公平"是如何毁掉一个人的生活
- "git rm" 和 "rm" 的区别
- 比较两个整数的大小,不能使用 "if", "?:", "switch" 等
- qa和测试是不一样的。
- QA的职责是人还是流程
- Android数据存储之SharedPreference
- Assertion failure in -[MASViewConstraint install],/xxx/Pods/Masonry/Masonry/MASViewConstraint.m:338
- 每天一个小题目——约会
- 我要开写了
- Maven 常用技巧总结
- 解放QA的唯一途径是"干掉"QA
- 单例模式
- networkx库中常用网络演化模型
- Java 利用枚举实现单例模式
- C++:用CreateDirectory创建文件目录
- 程序员面试流程
- 如何实现道路沿线标注的效果
- linux安装单机版solr
- WEB之浏览器使用入门--chrome扩展插件安装及好用的扩展插件小集合