Please note: this post was originally written for BJSS’s internal blogosphere. If you find this interpretation of what role testers play in the delivery of software appealing then please get in touch as we may have a job waiting for you.
This article is pretty much about building, and growing, a modern testing capability. The premise is that software testing will continue to grow and change and it’s not just a vocation but a craft.
Testers are a vibrant and diverse bunch with countless styles, backgrounds, and opinions; this is our greatest strength. But can we maintain growth and hone our skills at the same time? Especially when coaching, supporting, inspiring and challenging everyone can also sometimes be time consuming.
BJSS is also a consultancy, which throws 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 is overkill. We’d do things the same way everyone else does them. But internally, we refer to our capability as Test & Assurance. Many have joined BJSS from other companies 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 place ourselves wherever we need to be to accelerate, 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 because they’re pretty important: they denote scepticism (but more on this later).
So who is responsible for this thing we call ‘quality’?
• 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
This kind of thinking only works if everyone’s roles can go on continuously, unblocking, from now until the heat death of the universe, but even then, we’ll still have bugs, because no software is without bugs and, most importantly, nothing will get delivered.
The only answer that makes sense is that ‘quality’ must be a collective responsibility and we take a pragmatic, but delivery-focused approach.
What’s the Capability all about, anyway?
The number one thing that this capability embraces is that everybody in the capability is fundamentally different and – to a greater or lesser degree – views their contribution to the capability differently.
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 all sorts of people, and all sorts of clients, and for some things this may well be what’s needed (if necessary).
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 a bit loaded and often need 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 fundamentally 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 the context of 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
we need heuristics but also a methodology. The best one I have ever seen is this: The Way of Testivus: Less Unit Testing Dogma, More Unit Testing Karma. If you read and understand it everything becomes a lot clearer.