On this sweet Sunday morning, came across this article on software bugs and their impact on people’s lives. We have all heard about these before many times in the course of years, but this article still worth a read which summarizes many aspects like shift-left, independent QA function, user acceptance tests, formal verification of software, etc.
The article offers a mix of developer-done unit tests and integration tests, an independent QA function, and user acceptance tests as the best combination for preventing bugs. It is context-sensitive to put together the correct mix for the situation at hand, but generally this seems to be a good idea. I would be careful not to visualize this as a ‘quality pyramid’ like being referred in many instances, and the pyramid should only be useful to visualize increasing costs and efforts to fix issues as you go near the top, and not to represent the amount and categorization (human vs automation) of tests involved. I will have human oversight and inspection at all functions across the board, because that’s the key to Quality, while machines (automation) aiding the checks for us.
I could very well relate to what the article states about Quality as an organisational problem. Most of the times, it is. The developers and testers can have all the bells and whistles, but if the management and leadership are not quality-minded, and if there’s no one North Star as to what the teams together are trying to achieve, all we would have a plethora of metrics in various colorful dashboards and no Quality at the end.
There is a reference to ‘writing code to test’ as Software Testing which is amusing, and I think the author mentions that in the context of not to have test code to do all the testing. Again, Software Testing is not completely about automation, and there are any number of instances where automation has fallen short of catching the bugs.
The references of Toyota’s production line in the context of Software Quality should stop. Software is much more complex than a manufactured product. One aspect to it is that you can see and inspect a manufactured product either with a human eye or with an automated system, but in Software, you can only have expectations of how the product will behave based on the results that you get when you do the tests. On the same lines, references to the quote during manufacturing era by Deming that ‘quality should be built-in’ as an excuse to eradicate post-development software testing should be stopped.
To design the appropriate Software Testing and Quality systems for your project(s) or your organisation, feel free to set up a free initial consultation with me. Happy to help!
