从QA到工程能效团队
Engineering Productivity
Productivity is our job; testing and quality are the job of everyone involved in development. This means that developers own testing and developers own quality. The productivity team is responsible for enabling development to nail those two things.
Engineering Productivity team is kind of extension which allow companies to focus on quality from start of Software Engineering process (often called 'left') to the product release and live maintenance/monitoring ('right' - Testing in Production).
Engineering Productivity的目标
a) 软件能尽可能快的发布。software is released as fast as possible
b) 软件是高质量。software has the highest quality possible
c) 软件在生产环境正常工作。 software works correctly on production
测试工程师的职责转变为
a) More focus on test frameworks, internal consulting and coaching
Demanding business realities usually mean that developers have to write tests. To be fully effective They need guidance & tools provided by experienced testing specialists.
EP team should also provide correct guidelines. For example 100% unit tests coverage probably won't detect performance problems. Limited testing effort should be used in correct place.
b) Shift left in software engineering process
Obviously testing at the beginning is the cheapest. Spending time on things like IDE plugins, unit tests, code coverage tools, effective code review, OWASP secure coding practices usually have high ROI (Return of Investment). EP team should also make sure that no failures are allowed to move downstream on Continuous Integration process.
c) Shift right in software engineering process
Successful release doesn't end EP team duties. They need to constantly monitor how their application perform on production.
d) Need for speed
EP team should make sure that testing doesn't become a bottleneck and it doesn't slow down developers. For example if Selenium E2E run too long at some point they will stop giving any feedback at all, because people won't run them.
从QA与EP简单点说:
Reduce the time from concept to deliverable by providing our product development teams with the tools, practices and support to increase their productivity while maintaining high quality standards
还有些目标:
Goal #1: Provide an easily maintainable and extensible framework that enables scrum teams to add and remove tests. This is not just the what, but the how. What are the strategies and guidelines? How do we decide to include tests? How do we maintain them? Are teams clear on our vision of testing? If teams don’t understand, how can they be successful?
Goal #2: Enable the automatic and early detection of failures within the software under development. I always talk about failing fast and a “shift left” mentality for quality (testing as early as possible). We all should know by now the cost savings of finding a defect earlier rather than later (thousands). By enabling teams to do this more easily, the engineers get faster feedback on their code. When we first started, we were running tests at merge. Now, we will be running at every pull request.
Goal #3: Prevent the source of detected failures from moving any further downstream. It’s not enough to just detect the failure—You have to prevent it from making it to production. We work very closely with the CI team to ensure our gates are in place. It should be no surprise if we do not distribute a build if our tests failed. Teams start to see the importance of being in a releasable state, and ensuring their code changes result in passing tests.
Goal #4: Accommodate all of this without impacting the engineers’ time. This is not easy work, but we want to provide everything without really impacting the engineer. It doesn’t mean that an engineer is not involved in the testing—It simply means we help them adopt the culture of delivering with high quality, which becomes ingrained in the entire Scrum team.
Engineering Productivity Team的角色
a) Test Engineers (TE)
Testers with broad product & business domain knowledge who focus on what should be tested. They drive test strategy and help to identify product risks. Usually aligned in Scrum Team.
b) Software Engineers in Tests (SETs)
Software Engineers (developers) interested in testing domain who build frameworks and tools aiming to speed up software engineering process.
c) Software Engineers, Tools & Infrastructure (SETI)
d) Release Engineers, CI Engineers, DevOps Engineers, TestOps Engineers
Highly technical role which focuses on Continuous Integration, Continuous Delivery and whole release process automation.
e) Site Reliability Engineers, Software Reliability Engineers (SRE)
managed systems and data centers 24x7. reference book: https://landing.google.com/sre/book/index.html
f) Product Owner, Product Manager
Generally speaking he should make sure that EP team goals are aligned with business goals.
今天先到这儿,希望对您过程改进,技术领导力, 企业管理,系统架构设计与评估,团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变
如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯,请关注我的微信订阅号:
作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
从QA到工程能效团队的更多相关文章
- 干货|什么是特性团队/功能团队(FeatureTeam)
最近一直在思考如何做团队组织能力建设和如何进行决策.执行产品研发策略.因为自己一直在研发效能领域,所以来谈谈什么是特性团队(FeatureTeam), 怎么创建特性团队以及在日常工作中如何结合 Scr ...
- 我们需要专职的QA吗?
[ 引用评论里的一句话:hurt but true 抛开作者某些偏激的想法外,作者暴露出来的问题还是需要测试思考的: 1.TestCase,TestData,TestConfiguration 没有 ...
- [转]资深CTO:关于技术团队打造与管理的10问10答
一.你如何衡量软件工程师个人的工作表现?如何衡量整个工程师团队的工作表现? 主要从两方面: 这个员工做的工作是不是他同意做的或者应该做的?(What) 他们是如何完成自己的工作的?(How) 任何绩效 ...
- DevOps 工程师实际上是做什么的
DevOps 工程师实际上是做什么的? 我们之前已经讨论过许多关于DevOps和DevOps世界的最新趋势了.但是DevOps工程师到底是做什么的? DevOps工程师以最纯粹的方式弥合了软件开发和运 ...
- 华为精益敏捷专家:DevOps转型中的那些坑
陈军--原腾讯高级项目经理.华为精益敏捷专家 DevOps是现在非常流行的一个词,很多人都在提DevOps,在往那个方向去转,但转的时候坑特别多. 现实是很理想的,大家都觉得做了DevOps之后就会非 ...
- 微软发布 Windows Server 2016 预览版第三版,开发者要重点关注Nano Server
微软已经发布 Windows Server 2016 和 System Center 2016 第三个技术预览版,已经提供下载.Windows Server 2016 技术预览版第三版也是首个包括了容 ...
- 深入Docker
深入Docker 作者:ramanallamilli 随着持续交付等新型开发方法的兴起,工程师再也不会凡事靠运气,希望提交代码上去后,它能在未知环境正常运行.我们可以看到业界这样的转变——开发,质量保 ...
- 国内技术管理人员批阅google的“春运交通图”项目(大公司下的高效率)<转载>
在整理一份报告的时候,偶然看到2008年春节期间google推出的“春运交通图”项目建设历程报道,很受启发,随以国内的技术管理人员眼光批阅了这篇文章,同时也是自嘲吧. 以下黑色字体是原报道,红色字体是 ...
- 【腾讯Bugly干货分享】移动互联网测试到质量的转变
本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/57ee0934b690d84c3188d7c7 Dev Club 是一个交流移动 ...
随机推荐
- Charles模拟网络请求页面的网络超时测试
正常情况下网络连接超时可能的原因有以下几点: 1.网络断开,手动的关掉了网络的连接 2.网络阻塞,导致你不能在程序默认等待时间内得到回复数据包. 3.网络不稳定,网络无法完整传送服务器信息. 4.系统 ...
- asp.net core系列 45 Web应用 模型绑定和验证
一. 模型绑定 ASP.NET Core MVC 中的模型绑定,是将 HTTP 请求中的数据映射到action方法参数. 这些参数可能是简单类型的参数,如字符串.整数或浮点数,也可能是复杂类型的参数. ...
- 《Jave并发编程的艺术》学习笔记(1-2章)
Jave并发的艺术 并发编程的挑战 上下文切换 CPU通过时间片分配算法来循环执行任务,当前时间片执行完之后会切换到下一个任务.但是,切换会保存上一个任务的状态,一遍下次切换回这个任务时,可以再次加载 ...
- 设计模式 | 模板方法模式(template method)
定义: 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤. 结构:(书中图,侵删) 一个定义整体框架的父类 若干不同具体实现 ...
- 教你如何一键反编译获取任何微信小程序源代码(图形化界面,傻瓜式操作)
一键获取微信小程序源代码 Tips: 一键获取微信小程序源码, 使用了C#加nodejs制作 直接解压在D盘根目录下后就可以使用 将小程序文件放到 wxapkg目录下3 这个目录下有一些demo 可以 ...
- Snapde一个全新的CSV超大文件编辑软件
今天介绍如果数据量超过104万行Excel无法打开了,用什么软件可以打开呢?Snapde,一个专门为编辑超大型数据量CSV文件而设计的单机版电子表格软件:它在C++语言开发的Snapman多人协作电子 ...
- sublime实现markdown浏览器预览
效果预览 实现 首先下载插件OmniMarkupPreviewer 方法:ctrl + shift + P 安装完成后搜索'OmniMarkupPreviewer'双击即可 下载完成后新建.md文件 ...
- eclipse代码提示设置过常用字符还是不起作用的解决方法
问题:重装eclipse之后发现没有了代码提示,一般情况下在设置中添加自动提示的字符之后就可以了,设置如下 如上图,初始的时候是只有一个点号,并没有字符,输入26个字母的大小写后点击Apply and ...
- CSS Sprites(基本写法,怎样使用)
版权声明:本文为博主原创文章,未经博主同意不得转载. https://blog.csdn.net/XTQueen_up/article/details/37601361 说白就是用样式表切一个大图片 ...
- CAP 2.3版本发布,支持 MongoDB
前言 经过2个月的调整及测试,CAP 2.3 版本终于发布了,这个版本最大的特性就是对于 MongoDB 的支持,感谢博客园团队的keke同学对于 MongoDB 支持所提供的 PR,相信随着博客园的 ...