Building and Growing a Modern Testing Capability: A Testing Manifesto for Success
on Blog, Testing
Please note: I originally wrote this post for BJSS’ internal blogosphere. If you find this interpretation of what role testers play in software delivery appealing, then please get in touch. We may have a job waiting for you.
Introduction
This article is pretty much about building, and growing, a modern testing capability. My premise is that software testing will continue to grow, change, and that it’s not just a vocation but a craft.
Our greatest strength is our test community’s vibrant and diverse skills, backgrounds, and opinions. As coaches and collaborators, inspiring, supporting, and challenging everyone can be time-consuming. How do we continue to grow and hone our skills simultaneously?
BJSS is also a consultancy, which adds a unique view of the typical “testing landscape” into the mix.
Why bother talking about this?
If this capability was called “quality assurance” or “test” then talking about this would be overkill, we’d do things the same way every other company does them. But internally, we refer to our capability as Test & Assurance. Many have joined BJSS from elsewhere, where the culture is not the same as ours, so this is also an article about culture.
Testing is an assurance activity, but it is not the assurance activity. We put ourselves wherever we need to be to speed up, facilitate, and support the delivery of robust and predictable software. We do this in various ways, but most obviously through continual experimentation and learning (in various forms).
Who is Responsible for ‘quality’?
Note the quotation marks, they denote scepticism (I’ll explain why later).
• Not testers, devs just need to stop writing buggy code
• Not devs, BAs need to just do more comprehensive analysis
• Not BAs, DMs just need to give more time
And everyone just wants the client to figure out what they want!
The problem with this kind of thinking is that it only works if everyone’s roles run continuously, unblocked, until the end of time, but even then, we will still have bugs, because no software is without bugs. But most importantly, nothing would get delivered.
The only answer that makes sense is that ‘quality’ must be an issue of collective concern and we must develop a pragmatic, but delivery-focused approach to defining what that means in practice.
What’s the Capability all about, anyway?
This capability has one fundamentally distinguishing feature: every member of the capability is unique and views their contribution in a different way.
The perception of testers as ‘quality’ guardians, bug finders, dealing with software in a black box way, ‘test automators’ is increasingly becoming old-fashioned, but not entirely gone. We deal with many people, and many clients, and for some things this may well be what’s needed.
The alternative is something we are equally keen to embrace: the start of building an assurance community, i.e. a “consultancy to a process” model. Stuff like coaching, accelerating the delivery team, continuous improvement, helping the team adapt and optimize in order to succeed (rather than providing a safety net to catch failures), caring deeply about the quality culture of our team.
We lead, and nurture, the team towards a quality culture that is more mature and, of course, adding and promoting testability and bug advocacy. It’s about expanding testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.
The Core of Both Approaches
Software testing is more of a philosophy and an art than something concrete and quantifiable. Therefore, the words we use are loaded and often need explicit definition.
‘Quality’ is a big, relevant example. A consultancy like BJSS deals with clients. A client arguably doesn’t want “software”, they want their problem solved. They have clear indicators of what is “good” and “bad” that are unique to them. For us, “quality” is therefore whatever the client defines it as being. Our knowledge and experience is used to provide information to enable others to make informed decisions. We may also help clarify what that vision of “quality” using the same knowledge and experience.
So What Does Success Look Like?
Nothing I have talked about so far is incompatible with anything else. This is what we have in common, I’ve mentioned it before: we are working as a team for the continued delivery of predictable and robust software.
We are always looking for ways to do things better, drive forward change, learn and explore new technologies, share our knowledge with others through informal sessions, and actively engage other disciplines to improve the understanding and effectiveness of how we work together to build better solutions. That is success.
A Testing Manifesto
We all know the Agile Manifesto and If we accept it, how does this look in testing?
“We are uncovering better ways of testing by doing it and helping others do it.
Through this work we have come to value:
Testing throughout over testing at the end
Preventing bugs over finding bugs
Testing understanding over checking functionality
Building the best system over breaking the system
Collective responsibility for quality over individual responsibility
That is, while there is value in the items on the right, we value the items on the left more.”
Actions that aim to follow a manifesto like this can happen anywhere not just by testers, and not just at the end. Embracing that is going to be part of what forms this mature assurance culture.
Implementing a Pragmatic Testing Manifesto
In order to improve our approach to testing, it is important to have both heuristics and a methodology. One highly effective methodology that I have come across is The Way of Testivus: Less Unit Testing Dogma, More Unit Testing Karma. By reading this, many aspects of testing can become significantly clearer.
