People complain about ‘technology’ constantly, and some are even afraid of it. “It never does what I ask it to do!” “Why do I have to log in again?” “Why didn’t it save my last input?” Aaargh!

Whether we like it or not, all software has bugs. But we become less and less tolerant of them, since there are more than enough competitors out there willing to “help” the annoyed user with their new fancy-schmancy software or app.

Some think they can do better than others and start their own little software development company or write their own (local sports club) website. But once they are on the other side of the fence, it usually doesn’t take long to gain a bit more appreciation for the difficulty of creating good software that is bug-free and easy to use.

Software or code tends to absolutely refuse to deal with things that they weren’t taught to deal with explicitly … in the most annoying ways. Many times, it comes down to a single line of code with a teeny-tiny, almost insignificant, bug in it.

So, you absolutely need to hire testers, 1 for every 2-3 developers (more if the software contains a lot of complicated configurations or needs to work on multiple operating systems). The developers should work closely with the testers, providing them with new builds as often as necessary.

Your testers should be autonomous, unbiased, analytical, influential, persuasive, communicative, powerful, techie, … They preferably don’t report to a development lead, but to a test lead which has veto power over releasing any software that doesn’t meet a certain standard.

One would assume this is the most obvious thing in the (software development) world and every company that develops software has testers. Many do, but a surprising amount of them doesn’t. In fact, some of them don’t even believe in testing, even though managers today understand that having high quality products just makes good business sense. Still, they come up with lots of reasons not to hire testers.

Further below you can read about the most common excuses I’ve heard for not hiring testers. If you’re in a hurry, just skip the rest of this article and hire a tester for every 2-3 developers on your team. You can thank me later!

Here we go:

1. “Lazy developers cause bugs”

Ever heard arguments like these? “If we hire testers, developers will get sloppy and write buggy code. They won’t unit test or peer review anymore. If we don’t hire testers, we can force the developers to write correct code in the first place and focus on unit testing.”

Well, if you think this is true, you either have never written code, or you are strangely dishonest about what writing code is like. Bugs, by definition, leak out because developers didn’t see them in their own code.

Just think about the time when you’ve written an article, whitepaper or thesis, and you had someone reviewing it. I bet they found a few spelling errors or missed commas, even though you’ve read it over and over again yourself.

When it comes to using or executing software, everyone has his or her own habits. A tester has different habits than a developer, which quickly uncovers most remaining bugs. Often, reported bugs are things that have always worked for the developer. “Enter! You’re hitting the Enter-key instead of the continue-button on the screen! Why didn’t I test that?”

2. “Testers find too many bugs”

This excuse sounds absurd, but I agree that in some cases testers report stupid bugs. “If I look sideways to my screen, the button doesn’t seem to be in the middle of the screen.” Who cares? No user will ever complain about this. However, if you look at some of the issues users report, you’d be surprised!

If you think your testers are really reporting too many insignificant bugs, give them guidance. Don’t ridicule their effort or disregard their bug reports. Explain the requirements you’re trying to achieve and the known (and acceptable) limitations of the system.

3. “Our developers can fix bugs in a second”

Haha! OK, it’s somewhat true, bug fixes can be deployed much faster nowadays, but don’t underestimate the cost of fixing a bug.

First of all, you might introduce even more bugs while fixing the first one (regression). Secondly, every time spent on fixing bugs, is time lost for developing new features. And finally, don’t forget about the bad impression you will make, which leads to number 4:

4. “The users will test the software for us”

Well… what can I say about this one… Let’s just see how this might go down as a ‘testing’ methodology:

1. When development is about halfway done or they  say  they are done, release the software without any testing.
2. Repeat this step 8-9 times.
3. Call one of these versions the “final version”.
4. Release .01, .02, .03 versions every time a (embarrassing) bug is reported and/or going viral on twitter.  #whatweretheythinking

The only result you’ll get out of this is that the users will think the software is buggy and unreliable, even when you’re finally at a stable version. It’s not easy to get rid of this perception.

Besides, which company has the manpower to triage all the bug reports from the users and decide what’s really important? I bet most of these reported issues will cover the same 5-10 really obvious bugs and only 1-2 of them will be interesting, difficult-to-find, bugs. But since nobody is reading all these reports (quickly enough), it is either lost or fixed way too late.

So, the worst thing about this form of testing is the bad impression you will make. For the user it will feel like nobody has even done a minimum amount of testing, making sure the basics work. The low perceived quality of the product will turn them off, maybe for good…

5. “Good, qualified people, don’t want to be testers”

Auwch… Painful as it is, it’s indeed very hard to hire good testers.

The best ones are many times better than the average ones, and unfortunately, they might get bored after 6 months to 1 year and move on to another company, development or analysis.

The only thing you can do about this problem is to recognise it exists, and deal with it. Some suggestions:

• Treat testing as a serious career step in you company, a move up from e.g. support or any other role they did before. It shouldn’t be a step down, it should be a step up, at least horizontal.

• Look for people who have previously been testers for at least a year. Beware of recent graduates and others who will accept any position to just be able to start at your organisation. It won’t take long before they will ask for a transfer to a new role…

• Don’t treat testers as second grade developers who just weren’t good enough to be real. This will demotivate good testers who really just love to test software and are darn good at it! They won’t stay long when they’re not respected as an important key to your success…
• This also means you need to offer testers a competitive salary. If you pay your testers way less than your developers, your testers will request a transfer to development or again, might leave your company.
• Allow testers to develop their careers and technical skills by following e.g. programming language courses or test automation training. Encourage them to develop automated test suites using programming tools and scripting languages, install and configure test environments, … Nowadays, a tester can’t really do without these skills anymore anyway, everything needs to move faster every day. Plus, it’s a heck of a lot more interesting than testing the same thing manually over and over again.
• Hire experienced external testers to come in and bang on your software for as long as it’s necessary. These testers have very good testing and soft skills, and tons of experience in different environments, technologies and structures. They are coming to you with recent knowledge about the latest trends in testing, which enables them to work more efficiently. In any case, it’s interesting and inspiring for your internal testers!

And finally, the number one most wrong reason to not hire testers:

6. “Testing is expensive, I can’t afford testers”

This argument is the easiest to demystify.

No matter how hard it is to find testers, sadly enough, they are still cheaper than developers:

• If you don’t hire testers, you’re going to have developers, analysts or business doing all the extensive testing. And while they are testing, time and effort is lost on development, analysis or finance/hr/… for that matter. Let’s do the math in comparison with hiring just one extra tester…
• In reality, we notice that testing in such cases is often treated as a lesser priority by developers, analysts or business. Cause they rather do their own job, and who can blame them? Plus, they are not actual testers, so lots of potential hidden bugs remain in the software. The effort and cost created by these bugs, only found after go-live or in the latest stages of the software development life cycle, are very high and again eating away time, effort and money from development, analysis, … I’m not even talking about all the management overhead, recap meetings, discussions on “how this could happen?”, …
• And finally, if you think it’s bad when a tester leaves your company, just wait till you see how hard (and expensive) it is to replace a star developer who moved on to a more professional company, because he or she got sick of spending lots of time on extensive testing before release, and/or all the rework after.

Conclusion: saving on testers is not saving your company any money or time.

Feedback, questions or want to find out more? joke.gijsbrechts@brightest.be