从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。

原文地址:https://www.cnblogs.com/wintersun/p/9277233.html

时间: 2024-08-30 07:28:42

从QA到工程能效团队的相关文章

【评分】集美大学软件工程1413班工程项目管理团队作业1

一.作业要求 团队项目作业1-团队展示与选题 二.评分标准   项目 分值 团队展示 队名和队员学号(标记组长) 0.5   团队项目描述 1   队员风采 1   合照 0.5   特色描述 1 选题要求 确定选题 0.5   内容的真实.可用.有价值 2   预期的用户量 0.5   团队项目Git仓库 0.5 团队计划 每周进度表 1 团队成员绩效评估方法 成员贡献分分配标准 1   每个成员的计划,如何帮助团队完成任务 0.5 附加项目 博客互动 1   有情怀 1 三.成绩展示 团队名

2018年博客总结

前言 2018年还有几天就结束了,回顾一下今年的博客blog-posts, 简单整理一下 行业与软件过程(Software Industry & process improvement) 关注软件过程改进到效能改进,除了软件开发,还是软件测试.全球Scrum在应用中,全球软件测试行业演化:不必多说,研发总监与架构师都必须懂软件测试,软件过程.技术前瞻性,今天的智慧城市,行业巨头早已入场. 2017年IT行业测试调查报告2017-2018年Scrum状态调查报告IT企业级应?开发模式演化工业4.0

大道至简—实践工程者的编程思想

大道至简—实践工程者的编程思想 提到编程,很多人都会发怵,是一门高难度的工作,当然我也不例外,这可以说是没有清楚地认知编程其中包含的思想,还没有真正地入门.程序是什么?是要写的一大堆复杂的代码?是熬夜通宵也弄不出来的东西?其实,就我而言,我认为程序的根本在于思想,只有想明白了才能写出来,想不明白自然就写不出来,正如<大道至简>这本书所写的,要把东西简化,这样使人才能一目了然. 愚公移山都不陌生,其实从这中间可以提炼出有关项目的实际执行,这其中有原始的需求:“惩山北之塞,出入之迂也”: 项目沟通

逆向微创新在小创团队中的意义

创业团队初期,规则小,对开发人员的能力需求其实很苛刻.然而,能够建立团队的人员无非来自两个方面,要么是新手或其它公司能力稍欠缺的,要么是大公司挖来的(还有一定低几率的野生大神). 而无论是哪种人员构成,按他们的经验,在面对早期项目开发时,为了快速验证主流程,架构设计特别是组件的技术选型无疑都是采纳熟悉的.主流的.通用的框架.随着功能需求的丰富,就会发现这种通用越来越不能适应业务的变化了,项目的架构反而受到厚重组件的制约?: 1.组件的通用特性几乎用不到,试想对于早期产品来说,比如使用ORM是为了

读《大道至简》第六章有感——从编程到工程

语言只是工具,在学习编程的过程中,我们不断接触多种多样的语言,学习并且运用它们.我们会因为无法精通某种语言而着急,而担忧,当然也会因为对某种语言的了解而兴奋,而激动.但逐渐的,我们忘记了学习语言的最终目的,编程和工程不同,我们可能在编程中用不同方法解决问题,可能因为哪种方法的更巧妙或者技术方面的问题和自己的伙伴产生矛盾,产生争论.这样的争论在学习研究过程中是件好事,多学术的进步有着帮助,但是在工程中就不同了,工程的进行可能会因为这样的争论而拖延工期,最后可能并没有什么改变还拉长了工程时间.作为一

研发团队中引入变化的思路和模式

过程改进是研发管理的本质性工作,如果过程要改进通常意味着我们要引入变化,尤其对当前研发管理工作和流程尚不规范和完善的团队而言,引入变化是必须走的一步.但个人在实践过程中体会到引入变化有时候是一项非常有挑战的事情,如果把握不好可能反而会起到反作用.本文从研发团队如何有效的引入变化的角度出发,对思路和模式进行探讨. 关于团队引入变化,业界也有一些主流方法论,其中受Mary Lynn Manns和Linda Rising两位博士的著作<Fearless Change: Patterns for Int

我们需要专职的QA吗?

[ 引用评论里的一句话:hurt but true 抛开作者某些偏激的想法外,作者暴露出来的问题还是需要测试思考的: 1.TestCase,TestData,TestConfiguration 没有进行版本控制,凌乱,覆盖补全,参考意义相当低,但耗时却很高. 2.TestCase的设计,只根据需求,未兼顾到系统实现,且因为对系统实现不够了解,导致用例覆盖不全 3.除功能测试外,测试还能做什么? 4.测试对于开发.以及整个团队的帮助在哪里?仅仅是工作流最末端的查缺捡漏吗? 5.如何提高开发测试时间

特来电混沌工程实践

一.导语 随着大型分布式系统架构的演进和广泛应用,软件工程的最佳实践也随之改变.我们通过分布式.服务化.DevOps.敏捷开发,快速响应业务的需求变化,支持大规模分布式应用.但这些做法带来效益的同时,也带来了另一个紧迫问题:我们到底有多少把握来确保线上复杂的系统能够正常工作呢? 即便是分布式系统中每个独立的服务都正常工作,服务之间的相互调用也仍然可能造成不可预期的结果.这些结果在现实中可能很少发生,但是一旦发生就会影响整个生产环境,使得整个分布式系统变得混乱不堪,甚至出现服务雪崩.系统全面宕机.

spoon+robotium+jenkins进行自动化持续回归测试

自动化测试的意义: 别说是外行人,即使是正在从事自动化测试工作的人来说,现在或曾经都或多或少有过这样的疑惑,辛苦写了自动化测试用例,却基本发现不了问题,其意义何在?在说明这个意义前先看下质量的定义. 质量的定义: 维基百科中对于品质(Quality)的定义:中国大陆亦称为"质量",可指物品的特征.品性.本质,也可指商品或服务的水准.质量. 影响品质的要素包括物品的可靠性.安全性,功能上是否完备,能否满足需求, 等等. 对于软件质量的定义:软件质量,是指软件系统或系统中的软件部分的质量,