Planning and Executing The Test: Software Development

Picture taken from freepik

When we make a software we surely want everything to go right. Everything in the system should be done correctly without any bugs. But well, bugs are there living their name, a bug. It’s bugging people out of nowhere and sometimes it is really big and hard to kill. When we can, we need to prevent it from coming to our software.

Figure Out What Might Go Wrong

If you have read my latest post, we already talked about usability testing. It is to test how well our software is working in terms of the UX of the software. There are way too many things to be tested. We need to test how much the server we have can handle, how much traffic it can contain, how fast the response time is, and of course if the software is working accordingly or not. The things we are going to talk about today is testing the functionalities. We will touch on the topic of Test Driven Development.

When we talk about TDD, we might think of unit test, but that’s not all of it. The thing about TDD is to plan the test before even making the product. When we plan to test a functionality of something, we must try to think about all the possible input from the user. When I say all possible input, I mean ALL possible input. That seems a lot and it is. We can not write all of the possible input but a lot of it can be summarized in several test cases. We don’t need to write all possible wrong password since it will not be enough. Just one will do.

For functions that we are going to write, we make unit tests. We need to make sure that every part of the function is covered. If there are branches, we need to make sure all of the branches are covered with at least one of the input. But what about the whole functionality?

Following The Critical Path and Deviate

Let’s give start with an example. The log in functionality. The way most people wants it to go is like this:

1. Go to log in page
2. Fill in the email with registered email
3. Fill in the password that corresponds with the email
4. Click log in

That is how the normal, critical way of doing stuff. But there are branches that we need to cover. For example, some of the branches will be:

1. What if the email is not registered yet
2. What if the user leave the email empty
3. What if the email put in is not even in email format?
4. What if the email is registered, but the password is incorrect?
5. What if the user is blocked from using the app?
6. What if the user repeatedly putting in the wrong password?
7. What if the user just logged on from a new place?
8. What if the user click on the icon to see the password before logging in?
9. What if, instead of clicking the button, the user presses enter?

All of this are some example of what might be the case before a user log into the software. We need to know what might go wrong to prevent it from happening. So then how do we know that we have covered all of the things that the software needs to do correctly?

The answer is: We don’t. There’s always room for bugs to come by even though we might think of all the possible stuff that might happen. For unit testing, it is a little bit easier since the input is quite limited. Humans are doing their best at being unpredictable, including me.

The other day I found a bug on the software I am developing. The bug is that once you clicked on the eye icon to see your password and the password is not visible anymore, you can not click on the eye icon again except you clear out the password. Now normally, not all people will click on the eye icon to see the password twice so it is not written in the case of what might go wrong. But I did do it and it didn’t work. So what should you do then?

Reporting The Bug

Bug reporting is done when you encounter the things that go wrong but you didn’t expect it. We can not test everything that a user does because that is outright impossible so this is very much needed. So how do we make it easier for us to be able to fix the problem? The simple answer is to describe it as detailed as possible. Do a step by step scenario of how to recreate the thing again. It’s simple but very much needed.

Once again, when I say do it as detailed as possible, I describe it as detailed as possible. Are you testing your stuff in the newer OS that may break the software? Put your test environment in there. Do you do something, logging in for example, that might contribute to the problem? When you found a bug, it is better to say the things that you do prior to that to make sure it happens only when you do that certain stuff.

At the end of the day, the thing that we can do to make sure our work has good quality is to know what the thing should do and the thing should do it well. This is why we need to make test scenarios that is filled with test cases that the user can bring to the table. This doesn’t mean bugs will not come into the room; it will come but at least it is not the big important one that is hard to get rid of.