How the Testing Manifesto is going to change development
Thinking about software quality and testing is happening too late in the process. The antidote is a new set of guidelines that will change how everyone thinks about testing.
In a similar vein to the very well-known Agile Manifesto, allow me to introduce you to the Testing Manifesto.
This manifesto -- formalized in 2013 -- is the brainchild of Growing Agile, an Agile consultancy in Cape Town, South Africa. I have used it in my slides and talks for years now.
The Testing Manifesto applies to every member
in
a team, regardless of whether or not it has dedicated testers. While we might already be comfortable with how this applies to Agile software development, let's take it a step further and talk about how this possibly applies also to Agile infrastructure.
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.
Prevention, responsibility, cooperation: This is the future of software testing.
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 "
Built-in Quality,
" or "Shifting Quality Left" (of an Agile wall). You cannot test in quality. Rather, the Testing Manifesto focuses on building in maintainability and quality from the outset.
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.
Testing understanding
OVER
checking functionality
The truth is that shared ownership results in higher quality.
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
of
Built-in Quality. Through various forms of automation -- continuous integration, automated testing, build pipelines, intelligent monitoring, etc. -- we make Built-in Quality more attainable than trying to whack-a-mole all the bugs at the end.
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
in an earlier post
,
"QA testers do not provide assurance; they help provide analysis and feedback." With every developer writing and running meaningful tests with all their commits, they show ownership. With the team caring about the state -- green/red, broken/passed -- of the build, they show ownership. With intelligent monitoring and logging built in, used early and continuously, the team then owns quality. Through a continuous-improvement mindset applied throughout the lifecycle of a system, we demonstrate that ownership of quality.
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.
