Challenges Faced by Manual Testers

Here’s an important fact: manual testers are often caught in dead loop cycles, not just manual testers, but also product managers and project managers. They are always in endless release cycles and get overwhelmed. But why are testers the worst affected? Think about the continuous integration, continuous testing, and continuous delivery processes that companies try to push as the “shift left” concept. QA manual testers, or quality assurance engineers, are still the major bottleneck. Why? Because they get stuck in this testing death cycle – meetings, planning, being part of the release team, doing regression testing, and so much more.

Manual QA Day-to-Day Activities

You have to draft test cases, plan during the testing cycle, work with developers, sync up continuously to get requirements, run the regression, be part of release and post-release checklists, file bug reports, ensure the bugs are not stale, conduct bug triage with teams, and more. This is just the tip of the iceberg for what manual testers do today. And you don’t do it just once; it’s a daily, weekly process without room to breathe. As projects grow, new features are added, meaning more testing, and it never feels like there are enough resources. In Silicon Valley, they say there’s never enough testing.

The Endless Cycle of Manual Testing

How Many Testing Types Do You Do as a Manual Tester in 2024? The types of testing you conduct are extensive: functional UI, exploratory, analytics, localization, accessibility, API testing, and more. This is not a comprehensive list. You cannot free yourself from all these activities. You have to test all of it. The outcome of this process is burnout. Many folks I’ve taught complain about getting burned out in just months. They start missing facts, don’t have time to learn new skills, and can’t learn things like test automation. Basic skills like Linux, networking concepts, and others are essential, but how can you learn if you’re caught up in these daily activities?

How Do You Get Out of This Loop?

So, how do you get out of this endless release process and non-stop action? The answer is to switch to a different role. As a manual tester, you cannot get out of this loop ever. That’s what I figured out in 2011 when I was a manual tester at Barnes & Noble, testing the digital e-reader Nook. I realized that if I didn’t do anything about it, I would be burned out and quit. So, in 2012, I started heavily investing in coding and tried to learn test automation as soon as possible.

But how can you learn something if you’re already stuck in these endless processes?

Automation Engineering as a Solution

Hard Commitment and Soft Commitment Roles

Why call an engineering job a soft commitment? Because there’s also what’s known as a hard commitment job, like software developers. Developers have to develop features and fix bugs, and if they don’t do that, it’s very visible. The project manager assigns a certain number of story points to develop a feature, and if you’re not done, you have to work overtime to finish it. So, there’s always a hard commitment and a burden on your shoulders to deliver something on time. An engineering job, like an SDET (Software Developer Engineer in Test) or an Automation Engineer, is a soft commitment. Here’s why this is the way to get out of the manual testing trap.

Who Is an SDET?

An SDET is more of a technical role of a software developer rather than a QA. You’re not going to be a quality assurance engineer anymore; you’ll be a developer, only working on the testing infrastructure. You will be the facilitator, not the executor. This means you’ll work on your backlog of automation, which will come from the manual testers, not from the product team.

You’ll estimate your tasks, putting the estimates you want. Say it’s going to take you three or four story points, or if it’s in hours, you make your estimates. You will make your automated tests in CI and fix them if they get broken. You’ll work on isolated pull requests for your tests, not for the code of the application. So, you can be your boss in what you do with that PR.

Usually, pull requests for SDETs are very rarely checked by developers, so most likely other SDETs will check. There will be automated checks like all tests are supposed to be green. But again, you’ll be your own boss.

Manual testers, again, should be your major clients. You will talk to them all the time about what should be automated to make their life easier. You’ll write automated tests once and run them after each pull request merge or pre-merge, depending on your setup. But there’s no more manual regression. This is basically going to run as often as the changes from the development team. Every time they open a pull request with some feature changes or a bug fix, it’s going to trigger all their tests. So, you don’t have to do it manually.

You’ll perform bi-weekly demos of automation tests for the engineering team. This is the way to be transparent, like, “Okay, guys, here’s what I’ve done, here’s the test I’ve automated, do you want to see that?” Manual testers and the product team engineers can be the judge. Again, you’re going to run your own world and slowly exit from this non-stop action because manual testers will continue to do that, and you’re just basically helping them reduce manual regression by automating a lot of things.

What Is the Scope of SDETs Responsibilities?

When it comes to automation, many people immediately think of Selenium WebDriver, but that’s just a fraction of what SDETs do. SDETs handle various tasks, including functional automation, UI automation (like using Apple tools), localization, and accessibility testing. Manual testing of analytics is cumbersome, so automating this process can significantly reduce the workload. SDETs are also involved in backend development, including API, microservices, databases, and backend analytics.

Now, let’s address a common issue: how can you become an SDET if you’re stuck in an endless loop of manual testing?

Transitioning out of Manual Testing

No Time to Sharpen You Saw

This is a dilemma many face. You’re busy but need to learn new skills. My advice, based on personal experience, is to communicate your intention to learn new skills to your leadership team. Propose dedicating a few hours each week to learning and set the expectation that you’ll show results for the time given. This approach can convince leadership to support your learning journey.

Ways to Start Automating at Your Current Job

If you’re feeling overwhelmed in your current team, consider moving to a team with fewer commitments. Some teams, like those working on experimental features, might offer more flexibility for learning and experimentation. If you’re struggling to find a project for test automation, start with your current work tasks. Don’t wait for a perfect project; be proactive.

Once you successfully complete an automation project, it can lead to promotions or better job opportunities. Emphasizing the skills you’ve gained is more important than the number of jobs you’ve worked. It’s about how you manage your roles and what you learn from them. The goal is not just to work multiple jobs but to excel in your career and achieve a work-life balance.

Do I Have to Learn the Programming Language First?

A common pitfall is trying to learn an entire programming language before starting automation. This approach is impractical. Instead, focus on learning the basics to get started. Set a reasonable goal, like automating one test case in a month, and work towards it. Remember, you’re not alone. Collaborate with developers who know the programming language better. They can help you improve your automation scripts.

Your Next Steps

Instead of a motivational speech, I’ll leave here the checklist of things you have to do to Optimize a Manual Tester’s Overwhelming Work Schedule in 2024. I know how overwhelming it may seem if you don’t know where to start. So embrace one point at a time. Good luck!

1. Decide to switch to an automation role
2. Explore transitioning to roles like SDET or Automation Engineer, focusing on more technical, independent work.
3. Start Learning Coding and Basic Automation: – begin with simple test automation projects, enhancing skills through collaboration with developers.
4. Discuss learning goals with management, proposing dedicated time for developing new skills.
5. Look for roles or projects within your organization that allow for the practical application of automation skills.
6. Regularly showcase your automation work and actively seek feedback for improvement.
7. Continuously evaluate your progress and leverage new skills for career advancement while maintaining a balance between work and personal life.