Here it is in short… Software engineers must write automated test cases. You can have your QA group, too, but a quality assurance does not mean people who write tests because your engineers are too lazy.

I’ve worked for a few small software groups. Some had QA, some didn’t. Sometimes the QA group did stress, load, and unit testing. Sometimes they did manual testing all day. Sometimes they just sat around and waited for the day to end. I’m not trying to say anything bad about QA here — I just want to point out the fact that within the software industry, QA tends to be approached differently. The one thing that QA always did was give the developers an excuse to not write test code.

This sucks for engineers. They don’t know it — they claim that they loathe test writing. In fact, that’s probably true. Regardless, you must make them write tests. They will hate you for it at first, but eventually they’ll come around.

Writing test code makes engineers think about how what they wrote will fail. That’s the whole point of the testing; you have to make sure that what you wrote won’t fail, so you have to think about failure situations. It will lead to fewer bugs in the future.

Writing a few lines of code and being done just isn’t good enough. Nine times out of ten you’re nowhere near done. Here’s an example:

int factorial(int number) {
    if (number < 1) {
        return 1;
    } else {
        return factorial(number-1) * number;
    }
}

This code is complete. It works just fine for all sane input. Anyone who uses this function can use it and get a result they expect. It’s even safe for negative numbers. The problem is that factorial is undefined for negative numbers. If I call factorial(-1), what should I get? Does it matter? Should an exception be thrown? Should I just get 1, 0, -1?

You can document the function with this information, but writing a test is a better way to keep your function working as designed. If someone comes through and “fixes” the method, your code could break. If you wrote a test, though, someone else probably won’t come through and re-factor both your method and your tests so quickly. They’ll ask you about it first.

It doesn’t matter if engineers write the tests before or after writing the actual code. Writing tests beforehand is often-times better, but sometimes it might not feel right. Your QA group can write some more tests, too. The point is that engineers really need to write tests themselves.