Testing is not necessarily a team responsibility
Nowadays, it is more and more common to agree that quality is a team responsibility. Something I don’t argue with at all.
As a consequence, we might also concur that quality assurance must be a team responsibility. So far, so good.
Thus, it looks like testing too has to be a team responsibility, doesn’t it?
No, not necessarily.
First of all, because testing is not quality assurance.
Secondly, because, considering that not everybody is skilled at coding, likewise not everybody is skilled at testing.
Last but not least, because, as obvious as it gets, testing falls under testers’ responsibilities.
Let’s go a little deeper into these points.
testing is not quality assurance
Let’s assume we are talking about an Agile team which is working within a Scrum framework, for example.
To me, in this case, the concept of quality assurance has definitely more to do with the team’s definition of done than with their testing activities (if any).
After all, what the team can assure is, for example, that they have performed code reviews and they have followed the standards they agreed upon, that all the requirements are linked to test cases —nevertheless, I wouldn’t rely too much on a traceability matrix—, and, at most, that all their (likely automated) checks (that is, the mechanism the team has in place to demonstrate that the product they are building does what it is expected to do) pass and the corresponding acceptance criteria are fulfilled.
As brilliantly pointed out by Michael Bolton, “the trouble is that people often assume that demonstration is all there is to testing; that checking and testing are the same thing. They’re not.”
In fact, (automated) checks have nothing to do with real testing, that is, the act of exploring a system to learn how it actually works and under which circumstances it might fail.
Which leads to the second point under discussion…
not everybody is skilled at testing
According to my experience, the average programmer is usually more skilled at and focused on proving that their code does what it is intended to do, than on investigating how it might not work and on making sure that it doesn’t do what is shouldn’t do.
In other words, should a team only be composed of programmers, they might not be performing any (real) testing at all.
So, how could testing ever be a team responsibility?
Which leads to my last point…
testing falls under testers’ responsibilities
If you agree that programming falls under programmers’ responsibilities, it shouldn’t be hard to understand why the same rationale is to be applied to testing.
The problem is most people still confuse testing with quality assurance, to such an extent that they wrongly call testers QA.
The funny thing is that, at the end of the day, quality assurance has more to do with programming and management than with testing.
So, if anybody should be named QA, they should rather be the programmers or the managers*.
By the way, I find it interesting that, when thinking about quality assurance, the first person who comes to mind is never the one who sets the quality standards.
None among project managers, product owners or delivery managers seem to take the hint either. How come?
All in all, how about making concepts and responsibilities clear for everybody and letting testers do their job?
(*) Please, the next time someone talks about a QA or, more specifically, about hiring a QA, try to envision a programmer or a manager fulfilling that need. I can assure you that it might be fun…
Thanks for reading this article.
Feel free to recommend it or to add a comment.
Should you have any doubts about Software Testing, please contact me: I will be glad to help you.
By the way, have you heard about my practical and dynamic workshop on Software Testing?
If it sounds interesting, please get in touch!
On the other hand, if you want to get notified about my blog posts, please sign up through the BLOG > SUBSCRIBE TO THE BLOG NEWSLETTER menu.
2 thoughts on “Testing is not necessarily a team responsibility”
Hi Ileana you bring up a great point that I’ve done a lot of thinking about: that testing is not a team responsibility, it requires a dedicated role.
For a while, I was grappling with the idea that I *seem* to spend so much of my time finding issues that it *seems* developers should be able to catch if they do some minimum quality assurance on their work. Therefore, it *seemed* like you could make an argument to not even have a testing role.
However, sparing you the details, I eventually hypothesized that the mental burden of a software development team needs to be spread among these three role types, like branches of government: product management, development, and testing. To add the mental burden of testing to either of the other roles would exceed my mental capacity, and maybe others’. There are unique skills and mindset inherent to each of these roles that require full attention and application of skill, thought, and focus. I’m hoping to write about this more myself.
Thanks for your comment, Nicholas, and especially for emphasizing that, even though it’s usually a good idea to make programmers check that their code does what it is supposed to do, real testing (that is, the act of exploring how a system actually works and investigating under which circumstances it might fail) requires specific skills and focus.
I’m happy to see we are on the same wavelength and I look forward to your next piece of writing on this topic.
Comments are closed.