Wouldn’t it be awesome if developers could just code a piece of software perfectly the first time around and there were zero bugs, the software working flawlessly, forever? Development time would be fast and customers would be assured everything would always work.

Well, that scenario is about as likely as spotting a unicorn trotting down the street.

Unfortunately, software development is difficult. Even tiny projects by one expert developer will have bugs - although if it’s tiny enough, these bugs may have all been resolved before the software is delivered.

Plus, the more complex the project is, the more developers and teams working on the project, the more likely it is that more bugs will arise.

That’s why it’s imperative that we conduct software testing. The goal of testing software is to find as many bugs as possible in the software before it is delivered. Bugs may still prevail - that’s why it’s important to install patches when they come out.

Software testing requires a thorough approach to ensure user satisfaction with the end-product. A haphazard approach will have more bugs slipping through the cracks, and in turn a lousy and frustrating end-product.

How do we conduct thorough software testing?

One of the ways to do this is by ensuring we have coverage of tests across each of the software testing strategies.

Each one of these strategies is critical to ensure software ships with the least amount of bugs possible, so let’s check out the basics of each.

Unit testing

Unit testing is where we test a single code module or function. This is a small unit (funnily enough) of code that (usually) performs a singular task.

For example, we could have a function to check to see whether a new password is greater than 8 characters long.

To test if the function performs as expected, we would need 4 test cases:

• Password length over 8 characters
• Password length under 8 characters
• Password length 8 characters
• No password entered (null input)

Integration testing

Integration testing is where we put different parts of the code together and check that they work together. This is often when an engineer is working on a particular part of the code, then wants to see if it works properly with the entire project.

Integration testing is made infinitely easier if developers use APIs for different parts of the code. This way, you can have a main module, with an API, and another part of code, with its own API - and the two can only communicate via these means.

If the API functions themselves work correctly (validated by unit testing), then integration testing is simply ensuring that the APIs are communicating the right data to each other (or that we are calling the correct API function). This can easily be verified.

Acceptance testing

Generally, acceptance testing is checking to see whether the user is happy with the product and that it does all that they want it to do. This includes beta-testing with the client, to see whether they’re happy with the product and it works as expected.

If not, then new requirements may be drafted, or in the case of errors, the software re-designed for compliance with current requirements.

System testing

This is where we test the software itself against the customer requirements to determine it does everything it is supposed to do.

For example, a functional requirement might be “The system will sound an alarm if logon is attempted after 7pm.” If requirements are succinct enough, then this should be easy enough. However, take a look at that requirement. It does not say the sound of the alarm, the noise level of the alarm, and where the alarm goes off. It also doesn’t say if 7pm is in a particular time zone…

A non-functional requirement (perhaps even part of a Service Level Agreement) might be that the system has a response time of <100ms, no matter the user load. This would need to be tested in a simulated environment.

If developers are picky and annoying during the requirements gathering phase, it’s just because requirements need to be that exact so that software revisions aren’t required after validation testing.

There’s far more to testing, too!

If you’re a developer and thinking, “Hey, they haven’t even covered system recovery testing!” - then it’s because software testing is its entire own practice. They don’t have QA (Quality Assurance) teams for nothing!

The main thing to remember with testing strategies is that all the strategies we mentioned above are included in the testing process. Without it, building a reliable, usable piece of software can be extremely tricky.

If you’re looking for a development house to create some reliable, usable software for your business then get in touch to talk about how we can build your project! Or, if you’re a developer who knows and uses best testing strategies, then maybe you’d like to join our team...