The Twitter debate: Do testers improve quality, help improve quality, or only pass info to others who do so?
Lately, I’ve been closely following a super interesting Twitter discussion about whether or not testers improve software quality. Yes, we find the bugs, but are we just the messengers? Or are we active participants in the construction of great digital products?
I’ve never liked the characterisation that a tester doesn’t actually improve quality, they provide information that can be used to improve quality. It’s too much of a hands off, not my problem, abdication of responsibility attitude and it has never reflected the way I work.
— Gregory Paciga (@GregPaciga) October 13, 2019
Basically, Paciaga complains about what is often said that testing does not really improve quality, but the objective is to give information that can be used to improve quality. It’s like washing your hands, taking the responsibility and passing it onto another (to developers, a PM, the CEO, etc.).
In this sense, and according to much of what several people have said in the chain of tweets, I loved the quote that Enrique Almeida tweeted that Monica Wodzislawsky from CES shared during her talk at the JIS.UY 2019 conference in Uruguay:
“El mejor tester no es el que encuentra mas bugs, sino el que logra que mas bugs sean arreglados”. Lo dijo Mónica Wodzislawski en el https://t.co/fLIJb5TDVz y estoy 100% de acuerdo.
— Enrique Almeida (@ealmeida) October 4, 2019
The quote is in English originally by Cem Kaner:
More so now thanks to the world of agile development, where we are all responsible for quality, testers are also part of the decisions made in the team such as what to focus on, whether or not to release a functionality, how to solve things, and much more.
Some time ago, I’d been philosophizing about this with Gabriel Montero (of Peregrinus) when we were preparing our talk for Argentesting 2018 by reviewing Cem Kaner’s famous definition of testing, “Testing is an empirical technical investigation done to provide stakeholders information about the quality of a product or a service. ”
That definition says that once the service or product is done, you have to test it and provide information. At the time, we discussed how we felt that testing should have another focus, not only to detect and report errors, but to prevent them.
Hence it makes sense that testers participate from day zero, since in the requirement definition meetings (user stories, use cases, etc.) the tester will ask questions thinking about how he or she will conduct testing later, which gets the developer already thinking about how to solve the possible problems that might arise and code for testability, which will surely help to avoid many bugs. This way of planning is more cost effective than testing at the very end waiting for someone to finally detect, report, correct and verify bugs.
In addition there is another problem with Kaner’s definition: merely providing information leaves us testers out of the decisions, taking away our responsibility. We must have a more active role and contribute to quality and take responsibility, together with the rest of the team, for product quality.
I believe testing is not about delivering information to a developer to then do what he or she wants with it or for a Project Manager to decide whether to deploy a new feature into production or not.
In today’s world, testers have the goal of responsibility for quality and our participation in these important decisions should be reflected in the definition of testing.
What do you think? Do testers improve software quality?
Are you on Twitter? Let’s connect – @fltoledo and @AbstractaUS
Recommended for You
Why Software Testing is Necessary for Delivering Excellent Customer Experiences
Testing as the Driver of a DevOps Culture
30 Days of Testing Challenge Reflection
#30DaysofTesting As I announced month ago, our testers joined in on the challenge 30 Days of Testing Challenge by Rosie Sherry from the Ministry of Testing which involved a different testing activity for each day of July. Here I’ll share mine and my colleague’s experiences over…
5 Things We Learned from TechCrunch Disrupt SF 2015
A recap of the best moments from TechCrunch Disrupt SF 2015 We can’t help but reflect upon all of the amazing things that happened last week at TechCrunch Disrupt aka, the “Startup World Series.” We are excited to see what happens in the future to all…
Abstracta
Great post, Federico. It made me reflect on this subject, and got me thinking for a while.
If we’d see the quality of a product as a person’s health, then the traditional tester, who just receives the finished product, and tests it reporting the problems detected, would be the equivalent of a physician to whom one sees under a medical condition, or for a check up. She could help by analyzing, prescribing studies, medications, and advice on how to solve the problem.
On the other hand, a physician who has known us personally for a long time, who has diagnosed all the illnesses we once had, but also constantly advises us on actions to preserve our health, has a much more active role in the improvement of our quality of life.
The tester described by Kaner, is the circumstantial doctor, the one who merely informs a diagnosis to the patient “or other relevant stakeholders”.
The tester we all want and need, is that family doctor who knows us since childhood and advises us throughout life.
Greetings.
Love it! thanks Ariel!
Could not agree more that testers should do something more with preventing any kind of errors not just detecting or reporting them. If possible, it’s going to help us a lot. Thank you for this interesting article!
Testing is part science, part art, and all fun. The best defects are those you stumble into after completing the basic functional checks demanded by the user story. Machines don’t do edge cases and they can’t be creative (for creative, read Evil).