Daniel Irvine 🏳️🌈In my last post I talked about ideas for convincing devs to do more testing. However, perhaps what I should have addressed is the topic of why do devs need to test at all?
In this post I’ll answer that question—and, just so you know, it’s not clear cut.
If software is your product
I’m a contract software developer who, like many other freelance developers, makes a career out of TDD, XP, quality, and so on.
For businesses like my own, for whom success is based entirely on the code they write, it makes total sense that they want to write the best code—for some definition of best—since if they didn’t they wouldn’t last long in such a competitive market.
Any time you read an article about refactoring, TDD, unit testing, anything to do with code quality, take a look at who the author is and what they do. Chances are they are a software consultant that’s really just selling their work. Either or that or they are very passionate, to an extreme level, about the code they write.
Throw it over the wall
Many devs have a “throw it over the wall” attitude to software testing. Meaning, let QA handle it.
In my very first job out of uni, I was hired into a company with a highly complex C++ Windows/MFC application. Since it was so complex, the grads weren’t allowed near it. Instead we were to spend the first year of our careers with the grand title of Software Engineer in Test, reporting to the head of QA.
It was this role that taught me how shockingly bad code can be.
It was also the first time I learned about the cost of fixing bugs depending on when you find them. The sooner you find a bug, the cheaper it is to fix.
Being in a QA team that found a lot of bugs, I knew that having QA find bugs was a serious waste of time and money for the business. The whole cycle of producing a build, QA testing it, finding a bug, writing a bug report, finding the developer responsible, communicating with them, having them fix it, all for the cycle to start again, takes a long time.
There’s a serious amount of process associated with QA and bug finding.
Now if the dev just does a little bit of testing before hand, they might find that bug and save all that hassle.
So this whole process taught me that the most cost-effective result for the business is if all bugs are caught before they make it over the wall.
(On the other hand, QA finding a bug is much better than a customer finding a bug.)
Better yet is if developers adopt working practices that avoid bugs in the first place.
Then QA can do exploratory testing, performance testing and all the other fun stuff, since they don’t have to worry about spotting our mistakes.
Newsflash: QAs are better at testing than devs are
There’s no replacement for a good quality tester. It’s so useful to have someone trying to break your code.
Unfortunately, having a QA team is a luxury that some businesses just don’t have access to.
So far, I count this as four reasons why you (as a developer) might want to test:
- Software is your product (you’re a consultant/contractor/freelance dev)
- You’re highly passionate about programming
- You’ve done a stint as a QA and you know how bad software can be
- You do not have access to a QA
What if you’ve answered “nope!” to all of those? Are there still any reasons to test?
There’s certainly one big one.
Tested code is simpler than untested code
I don’t have any facts to back this up, but the logic goes a little bit like this:
- In order to test, your code must have a clean, accessible API
- If you struggle to write a test, then you can think about re-designing whatever parts of the production code are giving you trouble
- Tests that break often or need to be changed often is a symptom of poor code design, too. So once you have a test suite, continued use of it will start to pinpoint where the design of your system can be improved.
- Untested code, on the other hand, can easily form into spaghetti code, which has a tendency to grow and eventually become a big problem, because spaghetti code eventually becomes too costly to maintain and build on top of it.
Let’s finish with the big reason why you wouldn’t want to test.
Ultimately, there’s no incentive for many developers to test
If you’re a permanent employee and your objectives are not based on testing, then why would you do it?
Many people will indeed having objectives of “fully tested solutions” but realistically, you’re getting paid to produce working software. If you produce buggy software that continually blows up in production then sure, you might have some questions to answer.
It’s relatively straightforward to produce working software without tests. Especially if you have a QA team to do that testing for you.
What would your future self want?
If you feel like you’re in this camp, then all I’d suggest is you think about your future career. Do you see yourself as a code champion? A thought leader? Someone who leads teams, someone who can work in all manner of environments? Then at some point you should consider getting good at testing. Even if it isn’t a necessary part of your job today.
Plus, I’m fairly confident your QA team will love you for it.
