Have you ever been in a position where writing tests for your code made you wonder what is the point of it all? Or moments when the tests you wrote seemed to bring no extra value and thought they were a waste of time?
Probably the most common situation that creates the biggest frustrations when writing tests for your application is whenthe code works well but the tests fail. This could be due to the fact that they were not written well or they were no longer updated to reflect the current version of the software.
In this article, we'll go through the most common mistakes that software testers make and show you how to avoid them.
Looking at tests from the wrong perspective
This was the biggest mistake I made as a beginner. When you first start out, you'll quickly find out that sometimes you need to write more code to test the code that you just wrote. That can be confusing and it might seem pointless at first.
It is easy for someone to see the value of a test suite only as a check of the implementation they've made for a particular problem and the time gained at the expense of a manual test. With the latter, you'd have to insert different values either from the code or through the interface of the user.
But that's not why tests are important. Let's look at the following scenario.
Usually, when we create a new function, we do a few basic manual tests at the same time, just to see that what we are doing is correct.
In most cases, when we add something new to our application, we already know that everything is working fine without having to write a test suite for this new functionality.
The problem arises when you go back to that implementation after some time and make changes.
If you have already written some tests for this code that you are going to modify, then you are covered. After you make the changes, all you have to do is to run the tests to see that everything is still working as expected.
Nothing complicated. But if you didn't have any written test suite, then you have to enter all the data from the beginning manually and follow all those steps to see that everything goes well. Things will be even worse if you have to modify multiple parts of your application and you have to wait to test them all again manually.
In other words, the value of a test suite and the time gained by this technique is not found at the time you write the test, but in the future when you make some changes or new implementations and you can run the tests and see in a few seconds if you broke something or not.
Not Enough Tests
When writing tests or while testing some parts of the application, it's easy to come to the conclusion that you've tested enough and that everything is going well too soon.
The problem is that we always start with the most obvious parts of our code and we mainly focus on them.
Check this code for example:
This function will check if a given number is prime. At first look, you may think that it's working fine and even if you write a test for it, it may tell you that it's all working as expected. In fact, it will work for all numbers except for one. This function will also return true if it will receive the number 1 as parameter.
The idea is that, in most cases, it will work well for 99% of cases, but in this 1% is where you will find the bugs, in the corner cases.
One thing that can help you here is to check the test coverage. This value is a good indicator from which you can find out if you have missed some scenarios.
Too Many Tests
The opposite of what we saw earlier is writing too many tests. Writing too many tests is just like writing useless comments that no one needs.
*<!-- begin::Sidebar -->*
<**div** class="sidebar"></**div**>
*<!-- end::Sidebar -->*
This problem usually happens when the test scope isn't clear.
There are different types of software testing, Unit Testing, Integration Testing, Regression Testing, E2E Testing and so on.
Each of this type is used to validate a specific part of a code. For example Unit Testing will be used to check at the unit level. In other words, you test a function and you only test the things that you implemented by mocking any other relation to other units or external function calls.
Without any prior experience in this, one might forget about these boundaries and test the same thing in different test types without even realizing it.
Not Enough Automation
Most of the web applications that we write today have users and user-generated content. If there's something I've learned over the years as a web developer, it's that if something can break, then the user is going to break it.
No matter how many weird things they need to do to break them, be sure that the users will do these things and crash the application. E2E tests are an important part of test suites and their purpose is to validate different flows that a user might take within an application.
Hypothetically, a tester could pretend to be the user and manually go through all the possible actions each time a code version is deployed on the server. But this can be a tedious process.
The workaround is to hire a software tester that has code experience as well and can write and maintain E2E tests. Not only is this combination is hard to find and expensive, but there are better ways to do it.
The solution is to use tools that can automate the test flows. Instead of imitating the behavior of a user every time we have to test the application for new updates, we can use such a tool that can, for example, record our actions and then automatically replicate them. In this scenario, all we have to do is configure these actions to expect certain answers.
One of these tools is TestCraft and it leverages the power of AI to improve the experience with test automation.
Not testing the important parts or useless test cases
Another common scenario is to forget your test plan or not have one.
We write test suites to improve the user experience and save development time by capturing bugs before they reach to users. Therefore is important to create a white paper, where we must define what the things of interest for us are, our application and our users.
This is mostly present in UI testing.
Imagine a scenario where we have an SPA and we move from home page to signup page. Nothing complicated here, just two inputs and a submit button.
One may test here if the button is in the correct position (left, center, right), if the color is the right one and if the label text is correct.
But is this really necessary? Isn't it more important to check that that button is really visible and that users can use it?
I know that writing UI tests can be a pain and they may be the hardest to write. That's why it is important here to focus only on the things that matter. On top of this, UI will be the part that will suffer the most changes in your application.
Conclusion
Testing can be hard, but the benefits that it brings are worth paying for.
If you ever feel in a position where software testing seems to be intimidating then maybe you should spend more time to better understand it and how it should be done.
Try to better understand each type of test. It'll help you avoid these common mistakes.
Cover Photo by Shahadat Rahman on Unsplash