The Futurology of Software testing, part 2/2
3. One super-discipline: UX plus RE plus QA plus QC
Sometimes, while explaining the intricacies of 2-switch coverage in state transition testing to some poor victims of HR departments’ ISTQB obsession, I get a very good question: “how does the choice between 1-switch and 2-switch coverage translate into customer satisfaction?”.
Needless to say, my answer is “it depends”, and depend it does, on what is important for customers, and for which customers, and to what extent, and how much this “what” would be enhanced by a higher N-switch coverage, and how much achieving this coverage would cost… Teaching people technicalities makes no sense unless they (people, not technicalities) have access to the information necessary to be able to make informed decisions regarding which technicalities to use. Otherwise, it is like teaching Latin to people who want to learn Dutch, which means totally useless unless you want to engage in scientific research.
Yes, what I am saying here is to some extent the same that context-driven school (11) has preached for years now – that the choice of test cases and test techniques and test methods depends on business context, and that you must “explore” the reality in order to discover this context, and that actually executing tests is a good way to explore and discover what has not been properly established during business analysis, nor during requirements analysis, nor during architectural design. Right, except that a far better solution is to put these disciplines together instead of delaying them into last resort “exploratory testing”.
4. When everything changes, nothing changes
I jumped the band-wagon of conscious testing in 1994. Before that, I had tested a lot as well: either my own software, or other people’s software, or hardware and software together, but I had not treated this controlling activity as a separate mental discipline, worth paying special attention to.
One of the first things I learned as a budding tester was, that testing was often not considered important enough and therefore neglected. Ten – twelve years later, surfing the giant wave of agile movement, I experienced the same again: testing not considered necessary by some sophomore agile teams.
Now, twenty-two years later, as you know very well, this attitude is gone – everybody understands, that… oh no, I was going to tell a lie. This is still the same – the happy-go-lucky attitude “it shall be all right” is still here with us, and I believe always will.
In 1996, I read about keyword-driven testing and thought “wow!”. Much, much later I met people explaining to me how unique and novel FitNesse and Cucumber approaches were; people who had not even heard the term “keyword-driven testing” and were not aware that FitNesse and Cucumber were fine implementations of it.
In 1980:s I met Simula programming language (12) and thought “wow!” again, only to learn C some time later and then again C++ as a “new” approach. I survived the OO-hysteria in late nineties, when God Himself was thought to be OO, and now listen to 20-years old guys telling me how great C# is. Not much has changed.
When I discovered Boris Beizer, Bill Hetzel and Glenford Myers and felt like a million dollars, it was a kind of anti-climax to find some seemingly obsolete books on informatics from 1970 and reading there about the very same principles of testing applied on some stone-age programming languages running on completely Jurassic machines. Tempora mutantur, but do really nos et mutamur in illis? (13).
And reading – with burning cheeks – “Agile Manifesto” in 2002, I couldn’t help the feeling of déjà vu… because of my knowledge of Tom Gilb’s EVO (“Evolutionary Project Management”) approach, first published some 25 years earlier.
So, in spite of Moore’s law, which obviously applies to electronics but not to development methods, not much has changed in testing during the last 20 years, so you need not expect any radical changes in the coming 20 years, either. Actually, not much has changed since 1628!
In the summer of 1628, the captain responsible for supervising construction of the ship, Söfring Hansson, arranged for the ship’s stability to be demonstrated […]. Thirty men ran back and forth across the upper deck to start the ship rolling, but the admiral stopped the test after they had made only three trips, as he feared the ship would capsize. […] Fleming remarked that he wished the king – who had been sending a steady stream of letters insisting that the ship put to sea as soon as possible – were at home. (14)
—————–
Sources:
11. Or exploratory, or rapid, or SBTM, or jamesbachis, or cenkanerish…
12. Simula was created much earlier than that, in 1960:s
13. Tempora mutantur, nos et mutamur in illis means “times change, and we change with them”
14. https://en.wikipedia.org/wiki/Vasa_(ship)#Construction
