Buzzwords, Part I

I've heard many buzzwords in my years of SQA and have come to realize that, while the basic ideas behind these buzzwords make sense, there are too many people who misuse or overuse these terms. I'm only including a few for now.

Unit Testing - This term is misused far too often. I've heard many QA testers talk about running unit tests when they're really doing black box testing. True unit testing is done in a development environment, using development code.

Unit tests are important, but the problem is that developers often write their own unit tests. If they make assumptions in the code, such as the inputs being fed to a function, odds are they'll make the same assumptions when coding the unit tests.

Effective unit tests should be written by a second developer or, ideally, a SQA engineer with enough development knowledge to read the unit of code under test. Even if QA can't write the test, somebody from QA should be looking at the specs and suggesting what the unit test should feed to the code.

Inputs and Outputs - When interviewing interns straight out college, these words come up all the time. When asked what method of software testing they would use if employed, I constantly heard things like, "I'd feed it different inputs and compare the output to the expected result." It sounded like I was listening to a textbook. This type of testing is important, but the inputs and expected outputs come from the product specifications. These are the same specifications that the developers used to write the code in the first place. If the tester and the developer interpret the specifications the same way, there could be missed bugs.

Sometimes, you just need to poke it with a stick in random places to find the weak spots.

Black Box Monkey Testing - This is really underused, not overused, but I wanted to include it anyway. I first heard this term when reading Visual Test 6 Bible by Thomas R. Arnold II. The concept is based on the infinite monkey theorem. Using automation (preferably) or a person, you start randomly typing and clicking, looking for bugs. A few years ago, when creating automation to test printer drivers, I implemented monkey testing code. It would open the printer driver properties and start doing random things. It might randomly move the mouse around. It could click in random spots. Or, it could pick a random field on a random tab and set it to a random value. We actually found a few serious bugs this way that may never have been found otherwise. Well, they probably would have been found, but by the users, which is usually not who you want finding bugs.

Of course, you still need targeted testing, unless you have an infinite number of computers running an infinite number of test plans and an infinite number of people to go through the logs to find out what caused the BSoD. It's still a very valuable method of testing. If done properly, a monkey test would continue to work, even after your GUI is completely changed.