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