Friday I saw a tweet by Andreas Prins. Since they are in Dutch, I will translate them here.
His tweet: Question: is this statement correct? # The quality? We will #test that in!
My reaction: Can I have a bucket? RT @ andreasprins: Question: is this statement correct? # The quality? We will #test that in!
After replying, I saw that Jan Jaap Cannegieter also replied with this tweet: @andreasprins statement: “quality, we will test it in” is true, it’s just awfully expensive and time consuming.
I couldn’t believe my eyes. So I replied: @jjcannegieter @AndreasPrins No, never true …. You can’t test quality in, you /build/ it in!
After a while Andreas replied: @huibschoots @jeroenro Thanks clear responses, I share your opinion, you’re really together responsible, but how do you do that?
I replied: By working together! Testers help developers to improve quality. Too long for a tweet. Want a blog?
Andreas asked his questions because he was preparing a column for TestNieuws, a Dutch website on testing. In his post he sums up the reactions and he concludes:
Having thought about this, we can conclude the following:
– The quality of testing afterwards is not possible because the product is there already
– Early involvement can prevent deterioration
– We need a new way of thinking where we not only feel responsible for providing insight into the quality but we also feel responsible for the quality itself. The moment we as testers also feel responsible for the quality, and we are a team, so testers are actually responsible for the quality, then we will also be asked to work to together to achieve this quality.
No, no and no again! Testers can test as much they want, the /tester/ will not improve the quality. The developer does, to the software, at least. Perhaps a semantic discussion as Jan Jaap calls it, but still very interesting! Because the statement is fundamentally wrong! And with these statements perceptions and fallacies are born. The perception of the organization is often that testers will test the quality in. Or even worse: the regression test will find the major bugs, so why test early?
Making testers responsible for quality is also fundamentally wrong. Even as part of a team, testers are still not responsible for quality. Testers are there to help others, with their service of testing. Which is a sapient activity, questioning the product. Helping the team (or our client) to make informed decisions about software by critical thinking (see: RST by James Bach and Michael Bolton).
To be continued!
Actually, testers ARE resonsible for quality! Quality of doing a hell of a job in informing decision makers, by bringing them valuable information which might influence their decisions to take action or not. To accomplish this, testers ARE responsible for thinking through, to collaborate and to communicate… why and why not, what and what not, how and how not, when and when not, etc… to test.
True! I fully agree! I was talking about product quality, not process quality (by which I mean: the quality of your own work)…