peshkova - Fotolia
The Testing Manifesto applies to every member
Testing throughout OVER testing at the end
We exponentially increase the amount of rework when we try to find and fix bugs later in any lifecycle. That's why we test early and test often. This applies to automated testing (also known as automated checking), to user experience research, to human cognitive software testing, to A/B testing -- to all forms of testing. As early as you could possibly start testing, do so. And continue to do so.
If you are a systems engineer or any member of the team looking after the maintenance of a production system, you will certainly appreciate the proactive thinking applied to early and continuous testing.
Preventing bugs OVER finding bugs
We also call this "
In addition to commercial considerations and delivery dates when designing a system or an application, discuss how to measure and continuously monitor quality from the outset. In other words, think of the end state -- think of the system in production and those who need to care for it then.
Yes, we need to check functionality. There is always that. But in addition to checking functionality, let's proactively consider how well each member of the team understands the system or application we are building.
Through all forms of feedback -- pair programming, code reviews, continuous integration feedback tools, continuous monitoring in production -- we continue to test and adjust our understanding of what we're building. Understanding leads to improved ownership.
Building the system OVER breaking the system
The Testing Manifesto is about a proactive approach
Team responsibility for quality OVER tester responsibility
Every team member is responsible for quality through mutual ownership of the product we are building. We may or may not have a dedicated tester on the team. If we do, we cannot abdicate our responsibility for quality by making the tester a crutch for the team to lean on.
As I mentioned
And the truth is that shared ownership results in higher quality.
I hope that I have sparked the connection that DevOps, testing and quality and, thus, this manifesto, all dovetail. And I hope I have also given you a tool to use in any conversations you, too, might be having with anyone who wants to understand this connection better.