When speaking with people who enter IT, I often mention manual testing as an option for an entry-level job. In this article, I’ll explain what manual testing is, how it fits into the development process, what skills you need, and how this skill can help you on your path to other jobs in tech.
Manual testing is testing done without any automatization tools. The tester opens the application and checks it using the same interface that the user would use. The main advantage is the ease of setting up this test—if you can use the application, you can test it. There are no specialized tools involved or any programming. The only issue you might face is having all the necessary edge cases available in your test database.
Manual testing is the easiest way of ensuring the quality of the software. For that reason, it can be used in many situations, such as in the following.
Something I especially like as a developer is having someone going through the tickets I worked on and checking whether the application after my changes behaves in the way that was requested. It can catch many types of issues:
- obvious regressions in the feature I changed—for example, I could focus only on step 3 of some operation that the user would do and miss the fact that I broke the first step necessary to get there
- places where I misunderstood the requirements, so my changes miss the point
- cases where the code works OK on my dev environment but fails to integrate correctly on the test server
Besides that, a fresh pair of eyes can often bring a new perspective on the feature we work on.
Another use case for manual testing is going through the whole application and checking whether the most important features are working as expected. I’ve seen testers developing whole testing documents with step-by-step instructions for testing and description of expected results. If the technology that your application is based on lacks the tools for automated QA, then this will be the most formalized testing you can hope for.
In the case of web applications, we have many tools that make writing automated tests possible, and even pleasant. So, the formalized testing instructions mentioned above are a nice starting point for writing test automatization.
On a very basic level, the main skills you need for testing are:
- using the computer applications and
- following the instructions.
Of course, that is not enough—there is more you will find helpful to be productive in this role.
As a tester, using the application you test will be a big part of your job—even more so than normal users using it. Users tend to repeat similar operations over and over again, whereas testers go to every dusty corner of the app. Luckily, nobody will reasonably expect you to know the app before you start the work, but with time, you will be expected to become a true expert in it.
As soon as a tester finds an issue, they need to report it. This is where communication skills become important. The quality of your bug report will make the difference between the developer jumping directly to resolving the issue or spending hours trying to figure out what is wrong or reproducing the issue.
As a developer, I like to issue reports that contain the following:
- information on where the bug appears—exact URL
- clear, step-by-step description on how to reproduce the issue
- some screenshots to provide context
- information about what behavior is expected instead
Finding bugs takes a bit of creativity. Even the simplest operation could fail with some edge-case inputs or steps that were not accounted for in development. A good example is in this joke:
Software tester walks into a bar and orders:
- a beer,
- 2 beers,
- 0 beers,
- 99999999 beers,
- a lizard in a beer glass,
- -1 beer,
- "qwertyuiop" beers.
Similarly, other operation can be sensitive to unexpected user behaviors:
- reloading the page,
- re-login as a different user,
- finish the operation in some other tab,
To build a truly stable software, your team needs to find and polish all those edge cases.
A tester that can help with troubleshooting of the issue is a great help for the team. Sometimes something as simple as opening the dev tools and checking the back-end–front-end communication can speed up work a lot. If you can pinpoint the issue enough to know whom to write a ticket, you can speed up the solution for days, if not weeks. On the frontend, it’s frustrating to see tickets sitting in our queue for a long time, just for us to identify it as a backend issue within 15 minutes of debugging. This is where a tester with more curiosity and troubleshooting skills can help a lot.
I mostly worked on some content websites or business applications where necessary domain knowledge is limited. If you test an application used by highly specialized professionals, such as
- healthcare providers,
then it is likely that you will need to understand the broader context to know how the software is used and how it’s supposed to behave. If you are to transition to IT from other fields, domain knowledge could be an advantage if you stay near your area of expertise.
Manual testing can be a valid career choice for some people, whereas others can look at it as just a step on a path towards another tech job.
Test automation is writing programs that execute your test scenarios and verify the results on their own. Test automation is programming. If your long-term plan is to become a programmer, then manual testing is a great starting point if you are still working on skills needed for test automation. With a bit of luck, you may find a company that will be happy to hire you to do manual testing, and help you grow.
Effective testing requires understanding the product, as well as how users are using it. This means you will be communicating a lot with both sides—the development team and the people who design the software behavior. The communication skills and connections you develop while working as a tester will be very helpful if you decide to direct your career toward product design or management. During my career, I’ve seen testers being pulled into product roles: especially in small teams, where there were no dedicated roles focused on product, and the tester had the best overview of the situation.
If you are interested in getting updates when I publish IT-related content, you can sign up here.