Skip to main content

Unit Tests Don't Find Bugs: the Death of QA

Unit tests don't find bugs. They find regressions. This is a painful lesson I learned when I first started doing TDD (test-driven development), and it's well known among most TDD circles.

TDD's goal is to prevent programmers from introducing new bugs into working code. However, when you're writing code from scratch, your tests won't help you find all the bugs in your code. That's because you can't possibly write tests for all the ways your software will be used (or abused). When I first started doing TDD, I had really good tests, but I was too tired to do much exploratory QA. However, my boss wasn't, and I was very embarrassed to find that my software had lots of bugs. Simply put, he used my software in ways that I hadn't intended.

I've seen a lot of companies that don't bother writing any tests or doing any QA. They just let their users find all the bugs. Needless to say, I've never had respect for those companies.

However, it's growing more and more popular to destaff the QA department and just require engineers to write lots and lots of tests. Often, these are in the form of unit tests. Even though integration tests can conceivably catch more bugs, they take much longer to run. Hence, even integration tests are often deprioritized.

What I'm discovering is that a lot of projects have both lots of unit tests and lots of bugs. These are bugs that could have been found manually by a QA engineer, but it seems that manual QA testing (i.e. exploratory testing) has gone out of vogue.

I used to think that code that was well-documented, well-styled, well-tested, and code reviewed would rarely have bugs. Sadly, I no longer believe that to be the case. I think we need to go back to the days when we had decently-sized QA departments, perhaps in addition to all the other things we do.

To tweak what Knuth said, "Beware of the above code. I have only tested that it works. I haven't actually tried it."

Comments

Anonymous said…
Great post. I like it. Just want to add, that in my experience, I found that QA guys also don't find all the bugs. When they have to do the same thing every day, they tend to do it the same way over and over. They find bugs in the first few runs, those bugs get fixed, then QA manual tests turns from explanatory to regression. :)
- Mykola
jjinux said…
Good point. Thanks Mykola ;)
Anonymous said…
I think it's a mistake to imagine that any process could identify all of the bugs in a piece of code. Other than design flaws that prevent the execution of expected use cases and simple mistakes made while writing, most bugs are cases of unexpected inputs generating unhandled states. Unless the code you've written can be deterministically and exhaustively exercised, something that's really only possible at the unit level, the accretion of units of that size will generate untestable complexity very quickly.
Bug of this sort are only bugs in the particular context of a user having produced such and unexpected use case. Testing, by devs or QA specialists, can only hope to mitigate the risk of these inevitable outcomes and protect you from the known knowns. Intelligent testing is the practical management of risk. As a QA professional, I feel well trained to provide that service, but I've met plenty of developers who do that well, and lots of QA staff who don't.
I also agree with the above post that QA staff left to rot in mindless repetition of mechanical tasks are probably less useful than well written unit and integration tests. Still, any QA manager worth the name will find the means to prevent this abuse of his staff's faculties, and more effective use of their talents.
Anonymous said…
By writing tests first you were supposed to be able to write the bare minimum of code necessary to do the job. Less code equals less bugs, at least in theory. Depending on the technology at hand you might be able to restrict your code to how it is used in the unit test. So if a new use-case pops up, additional tests and code have to be written. Wishful thinking, I admit.
As soon as the code base grows larger, regression will provide a better safety net for refactoring than no tests at all.
The lack of automated QA testing is frustrating and a waste of money. QA tackles a completely different class of bugs due to use-case based testing. And even it turns into regression at some point, it will at least improve the safety net.

Frisian

Popular posts from this blog

Drawing Sierpinski's Triangle in Minecraft Using Python

In his keynote at PyCon, Eben Upton, the Executive Director of the Rasberry Pi Foundation, mentioned that not only has Minecraft been ported to the Rasberry Pi, but you can even control it with Python. Since four of my kids are avid Minecraft fans, I figured this might be a good time to teach them to program using Python. So I started yesterday with the goal of programming something cool for Minecraft and then showing it off at the San Francisco Python Meetup in the evening.

The first problem that I faced was that I didn't have a Rasberry Pi. You can't hack Minecraft by just installing the Minecraft client. Speaking of which, I didn't have the Minecraft client installed either ;) My kids always play it on their Nexus 7s. I found an open source Minecraft server called Bukkit that "provides the means to extend the popular Minecraft multiplayer server." Then I found a plugin called RaspberryJuice that implements a subset of the Minecraft Pi modding API for Bukkit s…

Apple: iPad and Emacs

Someone asked my boss's buddy Art Medlar if he was going to buy an iPad. He said, "I figure as soon as it runs Emacs, that will be the sign to buy." I think he was just trying to be funny, but his statement is actually fairly profound.

It's well known that submitting iPhone and iPad applications for sale on Apple's store is a huge pain--even if they're free and open source. Apple is acting as a gatekeeper for what is and isn't allowed on your device. I heard that Apple would never allow a scripting language to be installed on your iPad because it would allow end users to run code that they hadn't verified. (I don't have a reference for this, but if you do, please post it below.) Emacs is mostly written in Emacs Lisp. Per Apple's policy, I don't think it'll ever be possible to run Emacs on the iPad.

Emacs was written by Richard Stallman, and it practically defines the Free Software movement (in a manner of speaking at least). Stal…

JavaScript: Porting from react-css-modules to babel-plugin-react-css-modules (with Less)

I recently found a bug in react-css-modules that prevented me from upgrading react-mobx which prevented us from upgrading to React 16. Then, I found out that react-css-modules is "no longer actively maintained". Hence, whether I wanted to or not, I was kind of forced into moving from react-css-modules to babel-plugin-react-css-modules. Doing the port is mostly straightforward. Once I switched libraries, the rest of the port was basically:
Get ESLint to pass now that react-css-modules is no longer available.Get babel-plugin-react-css-modules working with Less.Get my Karma tests to at least build.Get the Karma tests to pass.Test things thoroughly.Fight off merge conflicts from the rest of engineering every 10 minutes ;) There were a few things that resulted in difficult code changes. That's what the rest of this blog post is about. I don't think you can fix all of these things ahead of time. Just read through them and keep them in mind as you follow the approach above.…