What Are the Best Testing Methods?
Testing is a crucial part of software development. There is the obvious reason for testing which is to ensure that what we build works. We also need to make sure that what we produce meets client requirements. What often gets forgotten about is security and user acceptance. Our application could be brilliant and do everything we need it to do but it is worthless if the end user can’t use it. What happens if the software works perfectly but the APIs in the back end have a bug which means someone is being charged 10 times more than what they should? This is where we must not only ensure users can do what they set out to do, but we must also ensure that our software is not leaking money or causing some serious security vulnerabilities. We now know that we have a range of issues we are trying to prevent (Bugs a user can see, bugs that users can’t see and poor usability). To catch all these issues, we must use a diverse set of testing strategies.
Code Analysis
Code analysis is a testing method that just makes sense, and it is one we should always do first. Developers should read the code they have written and often should get other developers to read what they have written. In doing so, we are thinking logically what the code will do, and we think about the different scenarios that our code will encounter. This allows developers to spot bugs before they even happen. There have been many times that I have read my code back and thought something along the lines of “What happens if the user does not fill in x field, my code is just going to save it anyways and it will be incomplete”. This process also allows us to refine our program by removing redundant or poor logic and make the end solution run faster. It can also highlight security issues where we notice something has not got strict checks on it.
Unit, Integration and System Testing:
We can help make testing less overwhelming by breaking it down. This testing methodology only works if we have planned what units are from the beginning of development. A unit could be something as small as a function or it could be an entire controller. Whatever the unit is, it is vital that we test it in isolation. Why is it so important to test in isolation?
- Reinforce the idea that everything has a purpose and is responsible for that purpose only.
- Makes bugs that appear in later testing much easier to solve.
- Units should not be reliant on each other to function. If they are, there is an issue. A wheel of a car should spin no matter what is pushing it.
Once we have tested our units in isolation, we can now test how they integrate with one another. If unit testing has been done well, we know we should not get any bugs from the units themselves. Bugs at this stage will only happen because of a poor connection from one unit to the other. It might be that the output of one unit does not properly match the input requirements of the unit which is next in the line. The best way to imagine this is like a conveyor belt in a factory. One unit will build the car chassis, the next unit will add the doors and so on. If the chassis does not fit the doors, there is an integration bug between those units. In this scenario, we can simply change the output of the first unit to build the correct doors.
Finally, we can test the system as a whole. At this stage, we just want to click every button and fill in every form. We are actively trying to break the system as bugs we find is bugs that the end user will not find.
Requirements Testing, Black Box Testing and User Acceptance
Unit, integration and system testing is great but its missing something very important. It is not checking that the requirements have been met. We are just checking that our code is working without errors. That is where it is really important that we implement this last testing method. This testing method allows us to make sure that what we are producing is user friendly, serves the purpose that was set out from the original specification and every point that was in the brief has been achieved.
Sometimes when planning a project, we may have user stories which detail how someone might use the system and what they hope to achieve. In requirements testing, we perform these user stories to make sure that as a user, we can use the system to achieve what we want and do it easily.
As developers, we can have a bias when testing as we know how the code works, and we might not use the system as a normal user would. This is where black box testing comes in. Black box testing is getting someone to test software who has no knowledge of how it works. This is great as they are acting as someone who has never seen this app before. This means that we can get real feedback as to how easy the app is to use and if there are any frustrations.
Once all internal testing is complete, we can allow the client to try the new website or app themselves and see if it is something they are happy with. This is what’s known as user acceptance testing. We are making sure that the end user is happy using the new system. At this stage we often will get feedback on what to change or improve.
Summary
From everything discussed, we can see that testing is not as simple as we like to think. There is a lot we need to take into consideration and no one testing method will suffice on its own. We must mix testing methods to get the best results. It’s also important to remember that it is impossible to catch every single possible bug. At the end of the day, you never know what the end user is going to do. The important thing is that we catch 99% of errors so that the end app meets the requirements and functions smoothly. This will mean happy users and a successful application.
If you’re looking for help with getting your software tested, then Twilo is here for you – Contact us today.
