Test Automation
The driving principal behind test automation in the DevOps way of working is to build quality in application rather than testing for it later. This reinforces lean principals, while also empowering the team to own quality rather than handing it off to an external team and disrupt flow.
"Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place." - Edward Deming
Quality Engineering¶
Challenges in testing¶
Customer demand for faster features to market is driving organizations to focus on Agile development practices. The demand for faster flow from “Concept to Cash” puts additional pressure on QA. Most organizations fail to make significant changes in speeding up the QA cycle. Meanwhile, ownership of quality has been siloed away from the team while the team's collaboration is a series of pass the buck between development, test, and operations.
To truly work in fast iterative development, teams need to work cross-functionally and adopt quality engineering. Testing can occur in-sprint through automation, while the new engineering capabilities of the team enable them to own the application's quality.
From QA to QE¶
Quality engineering impacts on the team's way of working and performance. There is a significant reduction in person hours per sprint while reducing manual testing roles altogether. Ultimately, high-performing cross-functional teams can automate all of their user stories during the sprint.
| Before | Now | |
|---|---|---|
| Focus | Process: testing for quality | Product: build in quality |
| Approach | Monitoring: manual, process-driven | Evaluation: continuous and unattended CI |
| Defects | Detected | Prevented |
| Controls | Preventative | Corrective |
| Ownership of Quality | External QA organization | Shared across team |
| Where does testing start? | Post development | Prior to development |
| Implementation | Primarily manual | Automatically on code commit |
Team's Ownership of Quality¶
Every member is responsible for quality. The team should be cross-functional and support one another in developing the application and building quality into the produce. Everyone should be able to swarm as issues and challenges arise, instead of siloing away the responsibility of quality.
Product Owner - Write user stories with the proper formed Gherkin formatting, with help from Three Amigos.
Developer - Focus on unit testing and code coverage and reduce technical debt.
Quality Engineer - Functions as a quality automation expert enabling the entire team as they build in quality.