I had my first class tonight, Software Testing Techniques. You know that dream where you have something embarassing happen on the first day of class — perhaps you show up and suddenly realize you’re naked. Oops! Well nothing quite that bad, but about five minutes before my class was to start I realized I was the only one there with a Programming Perl book. I had five minutes to find a course schedule and/or a computer to check my schedule. Thank god for the Heller school’s computer lab. Unlike bad dreams, I arrived on-time (and clothed but without the right book) to my quality assurance class.
It’s bending my mind, which is probably a good thing. I’m not the best at writing tests and even worse at figuring out what to test. Regression test or blackbox test — what’s the difference? But there are a lot of assumptions I like that this class seems bent on challenging.
See, I believe software can be free of bugs, whatever the size of the project. Good design and requirements, copious unit testing to ensure that individaul functions do the right thing, lots of automated blackbox / regression / negative testing, and complete code coverage (even if it means being biased by looking at the code) — along with high quality development processes — should find bugs before they ship. This requires enormous discipline and a lot of professionalism, exactly what I’m hoping to cultivate.
Our customers require bug-free software. When defects in your product can kill someone or cost billions of dollars or slow the pace of technological progress, bugs can mean legal liability. People are going to look back in ten or fifteen or twenty years and see our current software licenses which disclaim all risks and say that the product isn’t even guaranteed to do what it was advertised to do, and they’re going to wonder how we ever got away with it. But we’re in a sad place when customers expect low quality from software manufacturers, especially when the processes are there to do it right.
So, I’m going to hold on to that point of view while I learn the right way to approach test planning and construction.
One other thing, this course seems very biased toward interactive testing. “Testing feature X will require 120 person-days. . . . ” I wonder if that’s true. Automated testing is the only way to run thousands of tests. It’s scary what can be automated
And as long as I’m divulging biases, I should say that sometimes I have trouble trusting my instructors, especially when looking at overhead slides (overheads!) from 2002 that are contrary to a lot of what I’ve been reading in new books from industry experts. Graduate school is all about learning how to be better in our chosen profession. Whee! It’s an adventure.