Zero to Manual QA Roadmap

Zero to Manual QA Roadmap

You don't have to be a Computer Science major.

You don't have to know how to code.

You don't have to be a genius.

Anyone can become hirable as a QA Analyst at a software company.

Here's my roadmap for you based on the skills I developed in my 1st year as a QA Analyst.

But first, full transparency from me of what I had going for me before I got my 1st QA job.

What I Had to Offer Before Joining QA

  • Nothing about QA

  • 6 months working at the same software company doing email customer support (internally transferred to my 1st QA job from here)

  • Basic web development (HTML/CSS/JS/React/some Node)

    • made 15 front-end projects & a portfolio website from self-educating on freeCodeCamp

    • made 1 basic Node.js web service following along with a course

  • Agile methodologies theory (from an audiobook)

  • Customer service

    • Some app-based or tech-related customer service:

      • Shipt Shopper grocery delivery

      • Walgreens photo kiosk customer assistance

    • Some phone-based customer service

      • Taking calls at a bowling alley for FAQ & scheduling birthday parties

      • Helping customers who called into Home Depot asking if a product was in stock

    • Mostly in-person retail customer service

      • Cashiering at Walgreens

      • Helping customers on the floor at Home Depot & Walgreens

      • Coordinating with vendors & remedying customer service failures

  • Bachelor's degree - Spanish Education

    • Spanish-speaking skills from studying in Spain for 105 days

    • No teaching license, but lots of education classes

  • QA Mindset

    • Detail-oriented

    • Curious

    • Collaborative

The Roadmap

There are resources out there like this QA Roadmap that, I think, overcomplicate the requirements to landing your 1st QA job:

https://roadmap.sh/qa

But they're still helpful if you read between the lines, pick out what's useful & discard the rest. So, yeah, check that one out.

For my roadmap, I want to keep things simple.

1 - Experiment with QA

You want to go out and test something for fun first.

Your assignment:

Choose your favorite app, website, API, anything, just needs to be a software application. Then:

  1. Choose a feature of the application to focus on.

  2. Write down the steps a user goes through when using the feature correctly.

  3. Imagine how the user could use the feature incorrectly, either on purpose or on accident, maliciously or innocently, on different devices or browsers, with different environment variables coming into play. Get creative with how many ways you can use the same feature. Note any strange behavior that arises out of this experiment.

  4. If you find a bug or something about the feature that doesn't feel good as a user, or something that could be improved about the user experience with the feature, use that to write a small report requesting a bug fix or a small improvement to the feature.

  5. Send them your feedback. Write into their Support team if they have one. Otherwise, figure out who the developer is for the application. If it's a company, search on LinkedIn for 1 person who works there and may help maintain this part of the application. For example, if it's a frontend web feature, look for a web developer who works for that company and message them.

After you finish this assignment, check in with yourself.

  • How did this feel?

  • What part did I like the least/most?

  • Could I see myself doing work like this for a full-time job?

If you had a bad experience with this activity, you may not enjoy QA as a career. This was an oversimplification of QA, but it captures some of the key tasks a QA is entrusted with:

  • Smoke testing - testing the expected user journey

  • Writing test cases - recording the steps of scenarios we're testing so we can repeat our testing efforts in the future (regression testing); this is how we can confidently say something is now broken that once was working properly

  • Exploratory testing - looking for problems with the user experience using an unscripted, creative approach

  • Writing bug reports - communicating in writing how to reproduce a bug we have found in the application to help the developer fix it more quickly

  • QA/Dev handoff - communicating directly with the developer to let them know we have found a bug

2 - Study QA Theory

Here's a list of concepts to learn. Read 1 blog post or watch 1 YouTube video about these. Don't overdo it, just get a good idea of what these mean and how they relate to each other:

  • Agile Methodologies -- scrum & kanban, especially

  • Regression Testing vs. Smoke Testing vs. Sanity Testing vs. Acceptance Testing

  • Test Plans/Test Cycles/Test Cases/Test Suites

  • Black-Box vs. White-Box vs. Gray-Box Testing

  • Manual Testing vs. Automation Testing

    • What is the purpose of test automation in QA?

    • Why to learn manual QA before QA automation

  • Software Development Lifecycle (SDLC) vs. Testing Lifecycle

  • Test Pyramid

  • Dev Mindset vs. QA Mindset

  • Frontend vs. Backend applications

  • QA Best Practices


I won't provide links to resources because:

  • the best resource is always changing

  • there are plenty of resources out there on all these topics

  • you may resonate with different resources than me

  • resources don't always stay around forever

  • you should be committed to finding your own information if you want to succeed in the tech industry -- even the seniors are googling stuff all day

3 - Diversify Your QA Experience

Use what you've learned about QA theory & best practices to start gaining experience.

Use my starter kit to begin testing 1 of each type of application:

  • Mobile app - even better if you have access to both Android & iPhone, but you only need 1

  • Static website - informational websites, no user accounts or anything fancy

  • Web application - sites where you can create your own account & save data, stuff like that

  • API - free public APIs are available on the internet, see my other blog post

If you don't know where to start, find a resource on the internet for the specific type of app you're testing.

Remember, don't overcomplicate this. You're the user. What features make up this application? What am I supposed to do with each feature? How could I misuse each feature? How would I record my testing so anyone could retest the same things a month from now? How would I record my bugs so a developer knows exactly how to reproduce the behavior on their device?

4 - Create a portfolio of work

You must build in public in 2023 if you want to be competitive.

Make a website on Squarespace or some other website builder so you don't waste time creating it with code.

Post your QA adventures & knowledge sharing in a Projects section:

  • Blog posts about QA theory

  • Tutorials for how someone can recreate your testing activities

  • Test cases you've written for real apps

  • Bug reports you've written for real bugs

Create a social media account on X or LinkedIn and talk about QA:

  • Short-form posts about QA theory & your testing activities

  • Long-form threads about QA or share your blog posts & videos from other platforms

  • DM people who also find QA interesting to build your network

  • DM devs who are building an app to see if you can test it for free to get practice

5 - Explore Automation

Yeah, I know what I said. You don't need to code or learn automation to get a job as a manual tester/QA Analyst.

That doesn't mean it won't help you get your 1st job.

In fact, you don't need to know manual QA to get a job as a QA Automation Engineer, either. But, same thing applies: it helps!

If you know how to code, look up:

"QA Automation test framework <programming language you know> <type of application (web/API/mobile/etc.)>"

That should give you a few options.

If you don't know how to code, look up:

"QA Automation no-code test framework free"

and you should find some.

You'll want to learn a programming language, though, for the sake of this roadmap. Yeah, yeah, there's no-code and low-code tools out there, but you don't want to be limited by your inability to write code as a QA Automation Engineer. It's going to keep you stuck at a junior level forever because you can't build any custom infrastructure to solve unique business problems not covered by those no-code and low-code tools.

Trust me, just learn 1 of these:

  • TypeScript (first learn JavaScript, then add TypeScript)

    • You'll be able to use this for any automation tools that support Node.js
  • Java

  • C#

  • Ruby

  • Python

Most test automation tools support these languages. You'll see everyone saying their language is the best one, but I've worked with TypeScript, Ruby, and Python for QA Automation and they all have their pros & cons. Just choose the one you think is easier for you to learn. I'm personally a fan of TypeScript, and most of the industry seems to be focused on Java, but there is a job to be found for all 5 of these languages. What matters is not the language, but your ability to use it to solve business problems.

Automation is something that should be on your radar. Love it or hate it, but senior QA roles tend to ask for at least some automation knowledge or experience, because that's where the industry is going. Manual QA will ALWAYS BE NEEDED, but more and more of the mundane testing can be automated as technology evolves. At the very least, you'll be able to multiply your efforts by automating some of your own testing, even if it's not formally in your job description.

And, ya know, it's a competitive advantage to know automation in 2023.

6 - Apply, Network, Build

At this point, you know what to do. You've got the skills, you've got the concepts, you've got the theory & experience to know how to build your own roadmap.

Make your connections on social media.

Fine-tune your resume with the help of career coaches or career advice YouTubers & bloggers...and AI.

Apply to jobs you meet 50% of the qualifications for in terms of things you've had practice with or understand.

Show off your work & knowledge on your portfolio. Keep adding to it til you get a job.

Create content to organically build a network of people who may have job opportunities for you. Collaborate with other QA, have coffee chats over Google Meets or Zoom or whatever, provide value however you can.

Whatever you do, DON'T:

  • Stop building

  • Stop talking to people

  • Stop believing you have a shot at being a QA

  • Stop advertising your value in public

It's a long road, not a short one. But in my experience, it's a shorter road to QA than to Dev right now, and almost nobody's doing the "build in public" thing, so you'll have a massive advantage if you follow this guide.

It's tough out there, but you got this.

Find me on X if you have any questions. Link's on my Hashnode profile.