Web-Books
in the Austria-Forum
Austria-Forum
Web-Books
Informatik
The Future of Software Quality Assurance
Page - 29 -
  • User
  • Version
    • full version
    • text only version
  • Language
    • Deutsch - German
    • English

Page - 29 - in The Future of Software Quality Assurance

Image of the Page - 29 -

Image of the Page - 29 - in The Future of Software Quality Assurance

Text of the Page - 29 -

Testing in DevOps 29 2.3 End-to-EndResponsibility Responsibility can give teams positive satisfaction in the work they do. It is one of the motivators for work as described by Frederick Herzberg [5]. As part of the two-factor theory, Herzberg distinguishes motivators and hygiene factors for job satisfaction. Within DevOps, there is an End-to-End responsibility for the service(s) a team delivers. That implies that teams are accountable from “concept to grave” [3]. Teams are responsible for the entire SDLC and they should be aware and act on all changes the service undergoes. Security and performance, for example, could becomeahigherpriority for the team,because theyare responsible formaintaining the service. Security, performance, and all other quality attributes are not the responsibility for specialistsanymorebutshouldbebuilt in theSDLCprocess from thestart by theentireDevOps teams. This responsibilitycanmotivate teamsand lead topositivesatisfaction. 2.4 Cross-FunctionalAutonomousTeams In DevOps, teams should be cross-functional and autonomous. All the skills and knowledge to deliver and maintain a service with End-to-End responsibility should be available within the team. This doesn’t mean that engineers should be superhumans and should be able to perform every task available. The skills and knowledge of an engineer can be linked to the T-shaped model [6]. The T-shaped modelconsistsof twobarswhere theverticalbar stands for thedepthofknowledge and skills in a specific area. The horizontal bar shows the knowledge and skills in many areas where the engineer is no expert. This should make it possible for an engineer to pick up simple tasks in their team from outside their expertise.Sharing withintheteamis importantbecauseitwillallowengineerstogrowinthehorizontal bar of the T-shaped model due to the knowledge and skills of their team members. This however is only possible with the vertical bar of the T-shape from other team members.There should be expertise available in depth to be able to share this with other teammembers. 2.5 ContinuousImprovement New customer demand and changes in the environment are reflected in the work a teamneeds todo.Teamsneed tobecontinuouslyfocusedon improvementsin their service. This is implemented by the “The Second Way” from The Phoenix Project [7]. “The Second Way” is about implementing a constant flow of feedback. As a teamyouwant tohaveasmuchfeedbackaspossible, assoonaspossible.Customer collaboration helps with the feedback of the customer. Testing and monitoring is
back to the  book The Future of Software Quality Assurance"
The Future of Software Quality Assurance
Title
The Future of Software Quality Assurance
Author
Stephan Goericke
Publisher
Springer Nature Switzerland AG
Location
Cham
Date
2020
Language
English
License
CC BY 4.0
ISBN
978-3-030-29509-7
Size
15.5 x 24.1 cm
Pages
276
Category
Informatik
Web-Books
Library
Privacy
Imprint
Austria-Forum
Austria-Forum
Web-Books
The Future of Software Quality Assurance