5 Tips To Deal With Untested Code

As software testers, we deal every day with a lot of untested (or insufficiently tested) code. You might say “that’s a tester’s role, to find bugs in the code, is not the developer’s role” and I wouldn’t say you’re not right. But, you are partially right, though.

To easily get my point, please answer yourself to the following question:

“How many times it happened to me to wait for some functionality to be developed and after few days, when it got into testing, that newly functionality crashed when I did a couple of clicks?”

And you know well what it comes after this. The user story is rejected, defects are logged, developer gets his/her hands back on coding, fixes the defects, code gets deployed again, tester does the confirmation testing and hopefully, if no new defects are found, the user story will be considered as done. Doesn’t this sound like a bit of time wasting?

I truly believe in the following formula when it gets to the quality of a software product:

developers + testers + product people = quality

This being translated into the following: ensuring quality should be a common effort between developers, testers and product people (business analysts, product owners, designers). During my experience as software tester I have observed that when there was no clear boundaries between developers and testers, like “my job as developer is to code and my job as tester is to test” and when they tried to work together, quality got improved.

“How this can be done?” you might ask. Well, I’m going to give you some tips.

#1 Be proactive during planning/grooming sessions

Try to think to a number of scenarios that you would cover during testing. Thinking in advance at this kind of scenarios derived from the acceptance criteria might help the:

• analysts to realise that some cases were not clearly specified or not specified at all in the acceptance criteria;
• developers to take your scenarios into account when implementing the functionality and writing the unit tests. Your scenarios might include also some negative testing the developers usually wouldn’t thought of.
• the architects or technical leads, as your scenarios might reveal a poor architectural schema;

In this way, the tester sets the proper expectations with regards to what is he/she going to perform during the testing process and the whole team gets aligned to the same set of application’s behavioural expectations.

#2 Try to have early access to the code

I was writing here a list of benefits of having access as tester to the code as early as possible in the delivery process. This works when the developers you are working with are using feature branches where they commit their code. In this case, you can easily find a way of getting on your local machine the feature branch a certain functionality is developed on and try to build the code locally and do some early testing.

Having an early access to the code helps you giving an early feedback on what was implemented so far and spot any potential issues that later can be defects rejecting the user story. Also, this practice reduces the time spent sending back and forth the user story between testers and developers.

#3 Assist developers at writing unit tests

Unit tests are one of the most powerful “tools” in avoiding letting too many defects go to the testers. Usually, the unit tests are written by developers, even if I heard there are cases when testers are writing them too. But personally, I wasn’t in the situation of writing unit tests, so I cannot share any insight of this.

If you are in the first case, when the developers are writing those kind of tests, what you can do is to assist them and discuss the scenarios you as tester have thought of or to share the test cases that you have written to help the developer get a better coverage with his/her unit tests. This approach can improve a lot the code quality and give the tester the possibility to better focus on testing more complex scenarios or end to end testing.

As a bonus, this approach will also improve the team spirit and builds a stronger developer-tester relationship.

#4 Have a look at the pull requests

This might require a combination of a bit of coding knowledge, deeper understanding and some experience of the product you are working on. If you posses all of these, you can start having a look on the developers pull requests, read the code and while reading the code think to the scenarios you plan to test and see if there a match between those scenarios and the written code.

For example, if you know that the newly developed functionality has to deal with user roles and while looking into the code in the pull request you don’t see anything related to users, roles, no class containing user related code was modified, you might get to the conclusion that the implementation is incomplete. In this case you can massively reduce the time by confirming with the developer if the user roles were included in the implementation or not.

#5 Run automated regression suite on feature branches

Before code is merged in main branch.

If you happen to have on the project you’re working on an automated regression suite, I advise you to try to take this approach. This can be done as follows: after the developers finish their work on a feature branch and the unit tests and code reviews are done, you can run the automated regression suite on that specific feature branch, ensuring in this way that the newly code written does not affect any existent functionalities. After the automated tests run green, the code from that specific feature branch can be merged into the main branch.

This approach requires a bit of effort in setting up the environment and the automated tests to be able to run them on specific feature branches.

Take away :)

I couldn’t find a way yet to have a bug free code when it gets to testing, but let’s be honest, where would be the beauty of testing, if the code would be free of bugs?

As a conclusion, I would like to encourage every tester to work as close as he/she can with the developers and transform the quality of a product into a common effort and responsibility.

Photo by Helloquence on Unsplash.