First, I would like describe what, in my opinion, are the most important responsibilities of a tester:
There are a lot of software test types, and many ways to subdivide them. Our task as a tester is to select and use the different types of tests in such a way to test each functionality of the product to the the greatest extent possible.
According to a syllabus issued by the International Software Testing Qualifications Board, tests can be categorized based on their type and their level. So in this section, let’s describe in a few words what those types and levels are, who can use such tests and what benefits can be expected from them.
In considering the different types of tests, we should keep in mind that their division is based on the different goals they are meant to achieve. Below I have described the 5 most familiar types of tests.
Concluding the list are 2 types which I could potentially put under one group, but it is important to show the differences between them. I’m talking about regression tests and confirmation tests, also known as re-tests.
In the second part of my article, I would like describe tests categorized by level, subdivided into: module/component testing, integration testing, system testing, and acceptance testing. What are they?
Module testing (or component testing) aims to verify each module or component of our software separately. In this model of testing we only work on single parts of the software, testing them in isolation from the rest. Early and thorough module testing can save you time and money because the later you find an error, the more it will cost you.
Occasionally, when dealing with dependencies between components, we can use mock-ups which allow for faster module testing. As an example, when we want to verify if our door can open and close while the door is not placed in a door frame, we can use a temporary frame as a ‘mock-up’ for testing purposes.
Another important aspect of testing is integration testing. Thanks to integration tests, we can check how two components work together. These tests verify the correct integration between elements of the system. Perhaps it’s best if I refer back to my example with a door: if we have a security system in place that signals when the door is not closed, we may check if the signal and the door interact correctly in every scenario. That’s an example of 2 components of our system working in integration.
System testing can prove challenging because we test the whole system to check how it works from the user's perspective. In this case, we verify if our system works according to our initial assumptions and goals. These tests are performed by the potential user.
The final test level which I’d like to mention is acceptance testing. From the perspective of a client hiring a software development team, these tests are the most important. Acceptance testing means that the client checks if the software follows the previously established assumptions, and if they want to prolong the cooperation either by continuing work on the current project or starting the development of a new product.
The first value of testing, and the most important for some, is that it saves you money.
But wait, how can I talk about saving money if you need to pay your tester?
That’s because a bug found at the development level is less costly to fix than one found in a live production environment (remember the rule of 1:10:100).
Additionally, putting a manual tester to work on quality assurance frees your developers to do what they do best - create code.
On top of that, the experience of a tester can also be helpful in establishing acceptance criteria for the software components. In any team, you probably can’t find a person who knows the product as intimately as the tester. The tester must check every functionality of the product, so they have a chance to learn the software inside and out.
In the end, what projects can get the most value from the services of a manual tester?
A manual tester can perform almost every type of test by themselves. However, any repeatable test can also be automated. Most manual tests can be automated if you’re willing to make the initial investment in the early stages of the project.
Meanwhile, tests that call for programming language knowledge can’t be implemented by most manual testers. Such tests fall squarely the domain automated testers.
What this means for you is that manual testing can be an efficient solution up to a certain scale, after which you might wish you’d started with automated tests right from the get go.
With that said, there are cases where manual testing will serve you better. Their main advantage is flexibility. Even if a manual tester verifies software functionality following a certain script, they are able to spot errors which are not strictly related to their given test case.
Moreover, an intelligent manual tester will take additional steps that the testing script may not have predicted and try out different datasets so that the product is thoroughly validated.
I hope this article helped you get a more complete picture of the role of a manual tester in the development team.
There are more test types we could talk about, but for the sake of brevity I chose only the most important ones in my experience.
If you ask me, having a tester on your team simply means that you care about the quality of your product. Nobody likes bug-ridden software.
But manual testing is not the end of story. Automated tests and unit tests can help your software product be truly airtight. Additionally, some issues can be detected even earlier, on the design level. Here’s where you can read more about each of those:
Thanks for reading!