What makes a software tester a good tester? Is it merely about having a relevant degree or certificate? Or are there other skills that are beneficial to becoming an invaluable asset in a software development team? In this blog post, I will answer these questions and give examples of how a tester can thrive in a dynamic organization. Note: this post is focused on the activities of a software tester and will not cover unit testing as this is predominantly done by developers.
In the world of testing, there are many relevant courses available. Most employers ask for the certificates based on these courses in their job adverts. At the time of writing, ISTQB and TMap certificates are considered as some kind of ‘proof’ that the tester in question has a basic understanding of what testing is all about. All it takes is passing an exam, and you will be the happy owner of a neat certificate. This is where the drawback arises because a certificate does not prove that you can put theory into practice. Of course, it is useful knowing all about test methods, strategies and how to report issues and test results. However, having some real experience is at least as important, if not more so! Another ace in the pack for a tester is having a Bachelor or Masters degree in the field of Information Science or Computer Science. Although the emphasis of these courses is on theory too, during most of these degrees the tester to-be will also do assignments or internships where they are able to practice the things that were learned. There are also testers that haven’t got a relevant degree or certificate and have become a tester by ‘accident’. Not having a technological background is not always a problem and can sometimes even be an advantage. This is where experience comes in.
Just like in any other job, having experience in the field of testing is key to doing well. Over the years, you will encounter many situations which require a different approach in how to test an application as well as using different techniques to achieve the highest level of quality. As a tester in the real world, you will see (and write) test visions, test reports, test scenarios, and test cases regardless of whether you have a technical background or not. The difference between these types of testers is the angle of their test approach. A tester with a technical background can usually read the developer’s code which means they can base their test strategy on this (white box testing) whereas a non-technical tester will focus their strategy on the functionality of an application (black box testing). A natural conclusion following this statement would be that having one of each on your team would be the best choice. In this scenario, the technical tester would focus on the more complex test scenarios such as integration testing or low-level test automation. The non-technical tester would then focus on validating the specifications or requirements, following happy and unhappy flows of an application.
Each team is unique and will have different needs regarding the testing of their software. Additionally, each tester will have varying technical backgrounds and personal interests. This can make it challenging to create a well-balanced team in which testing activities can be done in the most efficient way. Some teams may struggle with this in certain situations e.g. not having a tester with technical knowledge. To fill this gap, some developers will design and write the more complex test scenarios themselves. This can be disadvantageous as a developer is familiar with the inner workings of the application i.e. the source code. Subsequently, they will design their test scenarios based on the knowledge of what is actually coded. This may cause them to miss several test scenarios that may occur by actually using the application. Of course, having good specifications (requirements) before the coding starts can largely reduce this risk.
The table below outlines some of the advantages and disadvantages of the different types of testers mentioned in this blog:
To summarise, there are three aspects that should be taken into consideration when adding a tester to a team:
For a company, an all-round tester can be hard to find. By adding two or three testers to your team, you can cover most (if not all) test related activities for your project.