Why do we need software testing?

More often than not, software testing is perceived as necessary evil by developers. Coding new features is more fun and is also often thought to require more skill than testing, which is why in many projects, senior developers are the ones to focus on the production code, while writing tests is left to the junior developers and interns. But testing code and automating things should require the same care and skill as working on your product — at least if you do not want to end up in a maintenance nightmare that tempts you on a daily basis to delete those failing tests instead of fixing them.

Another common example for software testing being disregarded is that it is often only an afterthought in project planning especially if schedules are tight.Let’s admit it: we’ve all been at a point where testing was the only thing we could skip to still keep up with our deadlines, but we all know it’s necessary. How else would we know for sure whether our code actually works?

In addition to being just a necessary evil, we also have to consider that testing is directly related to your software’s success. Without it, it’s impossible to produce a product that is fit for end users — so with that in mind, let’s take a look at how software testing evolved alongside software development best practices over the last decades, and see how a good testing strategy can ease your daily development tasks.

Why Software Testing is essential for successful software projects

The most rudimentary form of software testing is to simply try out the code after writing it. Let’s say we’ve built a login form for a web application: it’s only natural to try it out at least once, to see whether it actually works. Deploying code changes, on the other hand,without ever checking whether they actually work as expected is either a sign of great bravery or a bit of insanity. Even changing just a single line of code could potentially break something.

When working on a small to medium sized project, it may be possible to keep track of your changes and the testing required to make sure your adaptations make sense. But as a project grows, it might get progressively harder and harder to keep track of the required testing steps, especially when working on a code base together as a team. Simply applying ad-hoc testing soon proves to be less than enough, and a more structured way is often needed to know what and how to test, which brings us to test management. New occupational groups have formed around this topic, including certified testers as well as certified test managers. They basically answer questions like:

• “What needs to be tested?” by defining test cases that should be run to verify whether the expected behavior is met.
• “What has already been tested?” by keeping track on which tests have been run, as well as their success.
• “When does a test need to be re-run?” by defining which test suites have to be run after a certain component has been worked on by a developer.

Up to now we focused on functional testing, i.e. checking whether the implementation actually fits the specification — but it is also essential to take a step back and check whether all involved parties have the same understanding of what should be built in the first place. This type of testing is called requirements testing.

Failing at an early stage of development by misunderstanding what your customer actually wanted to have built results in the greatest waste of effort possible. Pictures like the one below depict a fun way how such misunderstandings can manifest, but it’s rarely a fun occasion. Having to throw away months of coding effort is always incredibly demotivating for a team, and can even result in the complete failure of a project.

Most of the time, there are several non-functional requirements that a developed software needs to fulfill. Sure, testing them could be skipped, but with that come the risks of having some nasty surprises later on in your project. Typical testing types for non-functional requirements include load testing to determine how much pressure a system can withstand, or usability testing to ensure an enjoyable experience for the users.

Most of the above testing types can be done manually or in an automated way. Oftentimes, people tend to do things routinely and forget to ask themselves whether the thing they did was really necessary, or if the steps taken could be automated. Manual testing brings a huge number of disadvantages with it.

First and foremost, it is a clear waste of human intelligence — there is no reason to spend time and effort on tasks that could be easily automated. Second of all, manual testing means immediate release is not an option, since it’s reliant on all tests being manually executed, which could take even months when it comes to larger projects. Last but not least, rapid feedback during development is vital, and waiting for a manual tester to verify all changes can be tedious, to say the least — it’s way easier to do it with a push of a single button.

In addition to these points, it’s important to note that manual testing approaches are highly incompatible with today’s modern software development. The goal should no longer be to release new versions of software annually or quarterly, but instead, continuous delivery that ships new versions several times a day, which is impossible to do with manual testing.

In a well set-up development environment, all of these problems can be solved with automation: whether it’s functional testing, requirement testing or test management, once automated tests are implemented, developers can have a much more streamlined workflow, and save significant time and effort in their work. This is the kind of environment we want to provide for everyone with our solution at Symflower, which makes sure that every code change is tested automatically, and isn’t reintegrated without making sure it’s perfect.

Testing can be fun, especially if done right. If you have any thoughts or questions, please feel free to drop us a line at hello@symflower.com . If you haven’t read it yet, check out the previous article of this blog series for an overview of a complete guide on software testing. Also don’t forget to subscribe to our newsletter, and follow us on Twitter, Facebook, and LinkedIn for more content.