This content originally appeared on DEV Community and was authored by edno
The title "Cargo Cult Quality" is inspired by Professor Richard P. Feynman's Caltech commencement address in 1974 titled "Cargo Cult Science."1
Even if my younger self didn't know about software testing, I always wanted to be involved with quality and software engineering.
During my university years, I was fortunate to do a thesis on testing an automation testing tool - my answer to the chicken or the egg question for testing tools. That was my first encounter with software testing, and thanks to my background in metrology and instrumentation, I was already familiar with concepts like quality and rigorous processes.
Software testing then seemed like the ideal fit as the solution to quality for software, or so I assumed.
I know now that it may be about software testing, but quality is more than that.
In the past 20 years, I have been lucky enough to work in many countries with great people from every continent and various cultures. I have been and am still learning, sharing, discussing, and experimenting with approaches to quality for software products - or digital user experiences. And, I came to see that many organisations suffer from the same shortcomings or false beliefs about quality.
Here are the most common false beliefs I have encountered and my take on those.
Teabag
It is maybe the most prevalent belief I have faced in my career, and any resemblance to reality is not pure coincidence.
In my career, I happened to be some companies' first tester - or whatever job title was popular then. Those companies have been releasing products for years successfully. Now, they were suddenly in need of a tester. Why so?
Similarly, I have been hired as a consultant to help companies with products on the market for years to improve testing practices. Why so?
The traditional response from those companies was that they needed to improve the quality of their existing or future items. However, while I was still in my early twenties and short of experience, I was just given the simple instruction: test the product to make it better (or, as it's often shortened, find the bugs).
Then to my amazement, we did not necessarily fix more bugs, and the development team was not necessarily working differently from before. And the need to demonstrate quality was such that now it could impact the timeline. The testing was now a bottleneck. Why so?
That is where the teabag belief comes into play. Too many businesses believe adding one or more testers will enhance quality. Some management teams think of a good tester as a Lipton tea bag in a cup of water, adding value just by dipping it into the company - with or without milk and sugar.
Testing or quality specialists are not magicians, but they can help organisations see their products and processes from different angles. As observers of quality culture, their concerns and recommendations are worth listening to.
One size fits all
The second false belief is that there is a single definition of quality, a single approach to quality.
I want to share two anecdotes that enlightened me about the various definitions and perceptions of quality.
The first happened in France, working for a major telecommunication company in charge of accepting the software developed by a third party.
After rejecting several deliveries in a row, with a colleague, we requested to have a demonstration by the third party on their premises. After all, we assumed that they were not delivering broken software on purpose. The demonstration included a presentation of the quality process. Their testing strategy was that previous successful regression results were considered valid and not retested but directly reported as successful.
From their point of view, the quality was about fixes and new features; no need to worry about existing features. Once this was clarified and they changed their approach, we got better and more regular delivery fitting our quality expectations.
The second happened during my time in India as an offshore test automation team lead.
My team was struggling to deliver the level of quality I was expecting. The automated tests ran most of the time successfully, then broke all of a sudden. But still, the team seemed to do its best and did not see any real problem. After all, flaky tests can be blamed on test data and the environment.
It was then when my 1-year-old AC broke in my apartment - New Delhi without AC can be sizzling - and to my surprise, my colleagues, praised the AC since it was successfully fixed - by a local crafty handyman. I then realised that I'd been out of alignment with my teammates about how each other perceived quality. I was expecting the tests to be robust and maintainable, and they were mainly worried about having tests that work at least once and are fixable.
After aligning our definition of the quality, despite the project's challenges, we improved the robustness of our tests significantly.
We need to be aware that the definition and perception, or expectations, of the quality, differ from one company to another, from one industry to another, and more importantly, from one culture to another.
Cargo cult
From my experience, it is the most common software pitfall. It's an extension of the two prior ones.
Cargo cult2 is from Western anthropology and refers to religious practices in a developing society in which followers attempt magical rituals to bring modern goods from a more technologically advanced culture.
In several companies, I have encountered a similar belief where an organisation decides to go through a transformation, hoping it will lead the organisation to deliver faster and better. They do every ritual they have read about, and yet, in the end, they do not end up with better results. But instead, they have new problems to solve. Why so?
The reason is that most organisations concentrate on the symptoms (reactive) rather than the causes (proactive) of their problems:
- too long release: agile will solve it
- deployment takes too much time: DevOps will solve it
- too many issues raised in production: testing team will solve it
- testing is too slow: automated tests will solve it
Companies then implement these as if they were silver bullets. Those are excellent ideas, and we should all strive for them. However, there are no cookbooks since they deal with quality culture.
An organisation can't improve its culture's quality without undergoing a cultural transformation.
As a tester, you have the power to improve quality and make people's lives easier. However, as soon as your job becomes about checking off boxes instead of finding problems or making things work better for users, that starts spinning in circles which doesn't help anyone! You need to see yourself as someone who makes changes happen faster rather than waiting around thinking "We'll get there eventually."
Remember that as your organisation grows, its culture and definition of quality will transform. So, whatever position you hold in a company, from C-level to junior level, you should regularly reflect on:
- Identify how you may help to improve quality (definition) and how you might assess it (perception).
- Determine how you can be an accelerator of quality. Why not question any process or tool that isn't a lever?
Cover image from the short film Cargo Cult by Bastien Dubois.
This content originally appeared on DEV Community and was authored by edno
edno | Sciencx (2022-06-18T09:04:12+00:00) Cargo Cult Quality. Retrieved from https://www.scien.cx/2022/06/18/cargo-cult-quality/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.