Testing != reality
I've seen software fail. And inevitably, someone asks the question "why don't they test these things?"
But of course they are tested. Many companies spend incredible amounts of time and effort to test their wares before they ship.
The interesting truth is that testing is not real life. The old war truth says "no plan survives contact with the enemy", and role-players might say "no scenario survives contact with the players". Real life is just so full of variety, inventive people, even physical limits like dirt and grit that no amount of testing can truly represent real life.
Martial artists know that practice will help. But a real situation is always different. Practice too little and you're overconfident. Practice the wrong things and you're too rigid to adapt. Same with software testing.
When software ships, it goes to a battlefield. Many times it survives. But many times it does not.
Back to weblog
|"Main_blogentry_260310_1" last changed on 26-Mar-2010 21:34:47 EET by JanneJalkanen.|
CommentsYet somehow some software works almost without noticeable flaws, while the competitors consistently ship software that is full of the most inane bugs. If this can't be fixed by better testing, then what is the key?
I do believe that the quality of the programmers is one key thing. Another one is proper scoping - if you make your software do less things, there are less things to break. Especially companies that have a lot of legacy to deal with, it is sometimes really hard to make sure that all the old stuff works perfectly with the new stuff.
Many things. But more testing isn't necessarily the answer, since the more complex the codebase grows, the more complicated it is to test. And I think that testing also becomes heavier faster than what the codebase grows in complexity.
All the more reason to favor rewriting stuff all the time, rather than planning a lot for the future...
Indeed. Overplanning is one of the biggest sins.