Open Source as an Opportunity for QA Engineers

Disclaimer. I'm not a mentor, and I don't claim to have an objective understanding of the current job market. Everything I'm sharing below is based on my personal observations and experience. I can't guarantee that this approach will help anyone find a job, but I believe it could be valuable for professional development.

It seems to me that finding a first job has become increasingly difficult for aspiring QA engineers.

Junior positions used to appear regularly on job boards. Now they seem to come up only occasionally. It also feels like more opportunities are found through personal connections, making it harder to discover suitable openings through public job listings.

For someone just starting out, it seems natural to follow a few bloggers or experts who talk about QA and promote their courses. Perhaps read a book or two, if you have the patience, take a few courses, or watch a series of educational videos.

But where does the actual practice come in?

Source: ProgrammerHumor.io

Some courses provide practical assignments. Sometimes private mentoring sessions help. Others find QA exercises online and practice on their own, although there's no guarantee that those exercises are still relevant.

And so, after investing time in learning materials and courses, an aspiring QA engineer faces a question: where can I gain experience that I can demonstrate during a job interview and include on my resume?

From Practice Exercises to Real Projects

I think there are several options.

The first is probably the simplest, and it's often recommended by both paid and free courses. You can publish your practice assignments in a public GitHub repository and share the results of your exercises.

However, the chances of someone actually looking through this work may not be particularly high. To engineers interviewing a junior QA candidate, the results of typical training exercises may be less interesting than work done on a real project.

The second option, somewhat closer to real-world practice, is to work on assignments provided by a mentor or a course, tailored to the student and aligned with current industry expectations.

This can provide more focused practice and help develop specialized skills. But even if gaining experience becomes easier, demonstrating its value to a potential employer may still be challenging.

Sometimes mentors provide tasks from real, actively maintained projects, but I suspect that's more of an exception.

And finally, there's a third option, perhaps the most difficult one: Open Source.

Where Do You Start with Open Source?

The sheer number of open-source projects can be overwhelming for a beginner. Where exactly should you apply your skills? What should you test? Which tools should you use?

This is where all that theory from courses is supposed to help. This is where theory should finally meet practice.

But where do you begin? How do you choose a project?

Probably the most logical approach is to find an established project with an existing user base, a history of commits, and some GitHub stars.

I'd even suggest starting with projects that interest you beyond testing itself.

Maybe you're interested in AI agents or web scrapers. Perhaps you enjoy applications with a web server and a graphical user interface.

Once you've found something understandable and interesting, you can approach it from several directions.

For example, start with functionality. Look at what's advertised, what's covered in the documentation, and what's missing. That's a form of testing in itself, by the way.

You can also explore the existing test suite. It's a great opportunity to gain exposure to how testing systems are organized and, over time, develop a sense of what works and what doesn't. What are the strengths and weaknesses of the current approach? What's missing?

This is how you can gradually develop a systematic approach to analyzing an open-source project.

How to Eat an Elephant

Comic by Robin Cain — Mindzai Comics

Of course, all of this may seem incredibly difficult, or even impossible, at first.

There's an expression I like: you eat an elephant one bite at a time.

It may take a while just to look around, assess the project, and get comfortable with the idea that, well, there's an elephant in front of you.

Only after you've developed some understanding of the project can you start breaking it down into smaller pieces.

Naturally, having a mentor can make this process much faster. An experienced engineer can suggest where to begin, what to pay attention to, and which details aren't worth getting stuck on.

I'd even say that this exercise can be useful not only for beginners but also for experienced QA engineers who feel stuck in their professional development. It happens.

From Exploring to Contributing

At some point, you might find yourself wondering: why was this part of the project implemented this way rather than another? Surely there's a better way to do it.

And that's where you can begin contributing to open-source projects.

Of course, nobody promises that your changes will be accepted or that the process will be quick.

But if you manage to improve even something small, you'll have a real contribution to talk about.

And in my opinion, that kind of experience carries considerably more weight than simply completing a practice assignment and uploading it to GitHub.

You can describe this experience as participation in a real engineering project, explaining the challenges you encountered and what you actually did.

I've even come across job opportunities at companies that build open-source products. They might monetize a cloud-hosted version of their software while continuing to develop the open-source version.

And they need people to develop and test those products too. Sometimes they're willing to pay engineers to do exactly that.

AI as a Guide into Open Source

Everything I've described so far has been possible for quite a long time. Open Source existed long before today's AI assistants and has always offered opportunities to gain real engineering experience.

But for years, contributing to such projects could feel like climbing a mountain that only a few people would dare to attempt. Simply because the field is so broad and can require substantial knowledge.

A lot has changed with the arrival of AI assistants. Today, even relatively modest models can significantly expand what people are capable of doing in areas where they have little or no expertise.

In that sense, an AI assistant can act like a friend or a guide: someone who offers advice, makes suggestions, and helps you figure things out without claiming to be an unquestionable expert or the ultimate source of truth.

It can help you understand an unfamiliar project's structure, documentation, architecture, and existing tests. The important thing is to understand what you want to achieve by participating in the project and to formulate your request accordingly.

Of course, AI can't fully replace a mentor. Its recommendations need to be checked, and its proposed solutions need to be understood rather than blindly accepted. But sometimes even that initial guidance can be enough to help you move toward your goal.

Working independently with an AI assistant allows you to explore different parts of a project, understand how it's structured, and try tasks you might never encounter while working within a narrow specialization at a company.

And that experience can be invaluable in your future professional life. It broadens your perspective and gives you a better understanding of how real projects work and how people contribute to them.

But my main point is something else.

Today, taking that first independent step has become much easier. Don't be afraid to try. In a sense, you're just one prompt away from getting started.