What Do You Get When You Hire a Manual Software Tester?

First, I would like describe what, in my opinion, are the most important responsibilities of a tester:

• Perform tests according to acceptance criteria that the client and the Product Owner established earlier (if those two roles are involved in the project). If you want to broaden the acceptance criteria, you should go ahead and report your idea to the PO or client.
• After each test you perform, you should create a testing report describing which components were tested, what test cases were considered and specifying their status: OK or FAILED.
• The last thing which a good tester should do is give feedback to the developer about his task. When we find a bug, it is our duty to report this bug using tools such as JIRA and to explain to the developer where we found it and how they can reproduce the issue.

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.

Software tests by type

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.

• Functional testing verifies the compatibility between a given functionality and the specification of the functionality. In other words, we check what exactly a module does. This type of test is based on the black box testing techniques, meaning we don’t see what the code looks like inside the program. It’s simple, really - if we want to perform functional testing on a door, we check whether we can open and close the door.
• Non-functional testing allows us to verify ‘how’ the components work, meaning that we test the safety, reliability and efficiency of the code, and also check whether excessive system load will cause errors. A good example would be verifying if the mechanism opening the door always works in the same way, or whether using the handle will always open the door. This testing type also uses mainly black box techniques.
• Structural testing - this type of test requires some knowledge about the programming language used in the app, because the basis for structural testing is the program’s source code (in other words, it falls under white box testing). Looking at the structure of the code, we verify if all the individual methods, functions and classes work properly, testing them against Python coding standards. The way structural testing focuses on single meaningful portions of the code makes it similar to the way unit tests work. Since programming knowledge is needed for this type of testing, it is not intended to be performed by a manual tester (unless he happens to know the language used).

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.

• Regression tests are a group of tests where we check if changes we made to the code in the current Sprint did not break the other functionalities of the system. We should also check if new bugs haven’t occurred that have to be fixed before we finish the Sprint. Coming back to my door example, we expect that each time we add new functionality to our door, it may affect previous features. If we want to add the possibility to open the door using a remote control, we should also make sure that we can still open the door using a door handle.
• Re-tests (or confirmation tests) are performed to check if our module works correctly if we found a bug earlier. We should always use this type of test when we found a bug in a test case to see if the fixes implemented in the software actually worked.

Software tests by level

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?

• Fast-moving projects where requirements and functionalities are rapidly changing,
• Startup projects, for the same reasons as the above,
• Low-budget projects where an automated tester would be too expensive. Even if automated testing is not an option, each project should have a manual tester as a bare minimum.

A word on manual testers vs. automated testers

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:

• The Measurable Benefits of Unit Testing
• Software Product Design: What Is the ROI of Good UX?
• How Can Your Software Benefit from Automated Testing?
• The Business Manager’s Guide to Software Testing and Quality Assurance

Thanks for reading!