Software Testing as a Job to Enter the Tech Space

Software testing is a tech job that doesn’t get as much attention as it deserves. It’s critical to keep customers happy while the product they are using is actively developed; nobody would be pleased with new features if each release breaks something else in the software.

Testers play an important role in software development, and you can consider it in one of two ways:

• as a career of its own—especially if you can give a lot of attention to detail and don’t mind repetitive tasks
• as an entry job in tech that you will be able to leverage to achieve your long-term career goals

Over the course of my career, I’ve seen few people using software testing as a solid base to expand their work profile.

Entry-level: manual testing

At the most superficial level, testing is using the application the same way the users do and checking whether it behaves in an expected way. The skills you need to do it successfully are as follows:

• You need to know the application as a user. You will have to know how to understand the application’s domain and how to use the interface. For example, if you work on logistic software, you will need knowledge of some basic concepts and terminology of that industry.
• Analytical skills—how you report a bug makes a lot of difference. “Something is off” is more difficult to follow than “as a user X, I do A, then B, then cancel C midway, and on the screen 1, we get value M when I expected T.”
• Writing—for every bug you find, you will need to communicate it to the development team. Your communication will be performed most likely with text—messages, emails, or tickets. If you want to learn a few things that will make you better at communicating in writing, have a look at this article.

The good thing is that all those skills are necessary for any IT role.

Acceptance testing

Acceptance testing is one of the things that people usually do manually. It’s not necessarily a separate role—I’ve seen or heard about:

• agencies using their client as a tester—so if the customer accepts the application, then it means it’s correct
• product companies deploying changes very fast and monitoring for sudden changes in user behavior patterns

Those are some options, but it often makes sense to have a dedicated tester go through all tickets before they are closed and double-check that they are indeed resolved. In a team, you can expect one tester for a few developers.

Regression testing

Besides checking what’s meant to be changed, it’s necessary to monitor for unintentional changes— regressions. Every codebase that is actively maintained receives countless changes:

• an update to framework or third-party-libraries
• code reuse can create coupling of different parts of an application—so a fix for one use case can cause issues in another

To make sure that those changes are not breaking the application, the best approach is to check all the existing features of the application and ensure that it still works as expected. That’s a lot of work. When it has to be done manually, you’ll most likely just focus your effort on the most critical operation that the application has to support.

In case of more systematic efforts, there will be testing scenarios written down for you to follow. In this way, the team has ensured that each testing session is the same—regardless of who executes it.

Automated testing

Automated testing is another step up from formalized testing scenarios—here you are writing the scenarios as executable code. In the context of the web, you often hear them called End-to-End (E2E) tests because the goal is to test everything from frontend to backend.

Test automatization allows you to benefit from the strengths of computers:

• they provide faster execution time
• they never get bored
• they are very precise

In exchange, your job goes from clicking through the application to maintaining a suite of automated tests.

In my career, I mostly worked on frontend JavaScript, but I did a good deal of test automation as well. It’s sometimes challenging, as:

• the original setup can be time-consuming—especially when you have no previous experience
• low-quality tests will fail randomly—giving false-negative results and undermining trust in the testing
• writing E2E often feels like a chore

On the other hand, automation allows for speeding up quality assurance, and it lowers the cost to the point where every commit can go through a complete verification. If you are interested in adding E2E to your project, you can check out this article.

What you can learn as a tester

Whereas some people enjoy testing and making it into a career, this job gives you countless opportunities to build skills that will be useful in other paths as well.

Testing gives you a great opportunity to learn about the company. If you weren’t working in tech companies before, you would have a possibility to get your foot in the door and access insider knowledge. For example, you will be able to learn the following things in practice:

Process

Creating software is more art than science, but successful teams share numerous similarities in their workflow. The best way of learning about it is to participate in that process yourself. Many companies are using some form of Agile methodologies. For example, in my case, I spent the past 10 years in teams that use Scrum methodology.

Scrum is relatively rigid—it defines plenty of meetings, roles, and expectations. One can learn it on a job, but I find that there are questions about familiarity with it during interviews. Not knowing it shouldn’t be a dealbreaker, but it’s always reassuring to learn that some join with some previous experience in Scrum.

Tooling

For someone coming from an entirely different industry, getting familiar with the tools used in the company can be valuable. To give you the context, the tools that I use every day:

• Slack—team messaging application
• Jira—bug tracking software
• GitLab—git hosting provider
• Google Meet—online meetings

You can expect every company to use different tools providing similar functionalities. None of them are challenging to learn, but knowing them can save you time.

On a code level, just knowing the frameworks of dev teams in the real world can help you choose the right one to learn. You’ll see a lot of buzzword-driven advice online—where new and shiny things are getting disproportionately more attention while work mules of the industry are overlooked. Knowing that at least one company in your area is using framework X in production can be a strong indication that learning this framework is a good investment for you. This knowledge is especially useful as you can easily check if they have openings in that technology and how difficult it is for them to find people with that skill set.

Mentoring opportunity

A good company should be interested in supporting your professional growth. If you are lucky, you’ll have the possibility to establish a mentoring relationship inside the company, for example:

• if management supports the direction in which you want to develop, you can try getting an official mentor to help you with questions as they appear, or
• a friendly colleague who is willing to guide you through your learning process, or
• code review where your colleagues give you feedback on your changes—you can always go the extra mile to process the feedback and learn the reasoning behind it

Progress options

Assuming you want to use software testing as a trampoline to different parts of tech, what are your options?

Programming

If your long-term plan is to become a programmer, you can use testing as an opportunity to build your muscles. Test automatization is programming: the only difference is that you program the test cases, not features—and that you learn test frameworks and not application frameworks.

Because automated E2E tests are code and are often run on every commit, you should be able to find support from developers on your team to create good quality tests. If there is a code review process in place, then putting tests through it makes complete sense too. Those can be very valuable experiences for you, and it can speed up your learning.

Product development roles

These roles represent another direction that you could choose. As you do acceptance testing, you are given the client requirements and check whether the program is fulfilling it. You are naturally placed between the client and the dev team. There are other roles that sit in similar places:

• product management
• product designed
• UX design

For those kinds of jobs, you will need to get to know customers well, and learn how to resolve issues they are facing with the technology your company is building. As a tester, you will be frequently in the loop as the requirements are defined—especially if there is nobody else whose job is product design. If you develop skills needed for those roles, you should be able to leverage those opportunities to move in this direction.

I know a few people who went this path, and it looked very natural—the duties simply shifted more and more toward figuring out requirements and less on checking them. Finally, they were spending most of their time working on the product instead of testing it.

Scrum master

Another non-obvious job is becoming an internal expert on Scrum methodology and helping out your colleagues to be as productive as possible. This role is part of Scrum methodology. Not every company uses it, but Scrum is popular enough for this to be a valid career option. It’s most likely not a full-time position. In a team with a handful of people, you will not have enough issues or blockers to keep you busy—but it can still be an interesting addition to your skill set and daily duties.

Supply issue

Not many people are willing to do testing as a job. The problem is:

• technical people look down on it and would rather build applications and not test them, and
• non-technical people are not aware of them or simply don’t consider applying there.

I cannot guarantee that landing a job in testing will be easy — I have only worked in programming— but I’m sure it can be an interesting option to consider. It should have a lower barrier to entry than many other IT roles.

Also published here