Why should testers care about open source software (OSS)?
Contributing to open source has helped me to build experience in many skills. I have learnt how to communicate effectively and respectfully. It has built my confidence around people. And even though I do not write code, I have gotten really comfortable using GitHub and command line interfaces in terminals, a skill you can only learn by doing it. Open source provides this opportunity.
What is open source and how does it work?
The source code for open source software is openly and freely available to anyone to use and modify. This means anyone is welcome to work on it, from building new features to writing documentation… and testing. Working on a group project tends to bring people together, thereby building a community for the project. Open source contributors work together to enhance, maintain, and modify the software. What is it they say about raising a child? It takes a village.
Mautic, Linux, Firefox, Cypress, and WordPress are some examples of popular open source projects.
Open source thrives on collective effort and its success depends on diverse talents like developers, testers, designers and others. And this is where you can come in and make a contribution.
Open source code is usually stored in a public repository on a platform like GitHub, where anyone can access the code for use or contributions.
How will working on open source software help you as a software tester?
Here are some reasons you should contribute to open source:
Build your testing portfolio
Since open source contributions are public, you can showcase your contributions on GitHub. You can add your GitHub URL to your resume, MoT profile, and LinkedIn profile to let hiring managers know what you are doing and make your resume stand out.
Elevate your technical and soft skills
Whether it is coding, reviewing code, answering questions, writing doc, you get a chance to improve on existing skills or build on them. And for people in tech, soft skills can never be overemphasized. Open source offers opportunities to learn people skills: communicate, collaborate, boost team spirit. Personally, I am now very comfortable using GitHub! I can create and review pull requests (PRs), submit well-written issue reports, triage issues, and more.
Find mentors
Let's say you have been looking for someone who is very good or an expert in test automation or in a specific programming language. Open source project work allows you to meet experts like this who can support you on your journey. It is easier and quicker to approach experts if you're working with them on a project instead of sending "cold" emails or private messages that they may never see.
For example, I spoke to the project lead about wanting to contribute to their test automation suite. She directed me to a Google Summer of Code intern who was leading the automation effort. She guided me on how to set up the project locally and start contributing. Making these contacts took almost no time at all, and I was soon in business learning how to automate a real-life project.
Find employment
I have seen people land jobs in open source. Project owners advertise open roles to their communities first before advertising them publicly. If you're already involved in open source, especially on the project where the job is available, you stand a better chance than average of getting one of these jobs. And since you may already know about the product, the onboarding process will also be easier than usual.
Build your network and get references
In open source communities, you can meet people with similar interests. I look for software testers in these communities and quickly connect with them on LinkedIn. This has helped me to expand my network and make new friends. These people often share QA tips on their personal websites and write blog posts on Medium and LinkedIn. By interacting with fellow testers, you can establish yourself in the testing community.
Also, if you are applying for a job, the people you work with on open source can write a reference or recommendation letter because they know your work. It is good to have people that can vouch for you.
Skip the time and trouble of looking for an internship
Open source work has some clear advantages over looking for or working on an internship:
- You won't have to compete for the role with hundreds or thousands of other candidates. Open source projects welcome contributors at all levels. You don’t need to wait for approval, just find a project you like and start contributing.
- You can choose exactly what you want to work on, and when. With volunteer open source contributions, there's no requirement to work in an office or for a set number of hours. You can work as much or as little as fits your availability.
- There's typically more of a supportive community vibe in volunteer open source work than there is in a lot of tech jobs.
- Your contributions are publicly visible on GitHub, serving as a portfolio that can impress future employers more than a traditional internship.
Is open source contribution for me?
When people hear the phrase "open source contribution", many assume that it means "writing code." No, you don't need to know how to code to make a contribution.
I used to think that way too. And my first two attempts to contribute to open source seemed to fail. Each time, I felt I had no value to offer since I didn’t know how to code. And I couldn't find any information online about how TESTERS could contribute to open source projects.
Then last year, during Hacktoberfest, I stumbled upon a LinkedIn post calling for software testers specifically to make their first contributions, I jumped on the opportunity. I believed that this time around, I was going to get all the help I needed to get started, and so it was.
The support I got was mind-blowing. The community was very welcoming and the maintainers were readily available to answer questions, review contributions, and address any concerns promptly. They had a separate repository for low or no code contributions from designers, testers, technical writers, and more. In that repository, you could choose the issue you wanted to work on.
And that's how I learned that open source contributions are for everyone. So, as a software tester, your skills and passion can significantly enhance the reliability and quality of open source projects.
Here’s how you can contribute.
What you can do in open source projects as a software tester
Manually test or review a pull request
As a tester, you can test pull requests before they are merged into the repository. This helps to ensure that the quality and functionality of the project remain reliable.
My first try at testing a Hacktoberfest pull request didn’t go well. I picked a "good first issue," but I couldn't replicate the bug because the steps weren't clear. They just said "create a contact" without explaining how. I had never used the software before, so I couldn't follow the instructions. The steps weren’t clear enough for a newcomer like me. I struggled on my own, trying different pull requests, but still made no progress.
Hacktoberfest contributors were expected to make at least four contributions in four weeks. The first two weeks passed without my making a single contribution, because I didn’t ask for help. But I didn’t want to give up like I had in the past. So I shared the pull request link in the Hacktoberfest Slack channel and tagged the project lead for help. She asked the PR owner to rewrite the steps, breaking them down into smaller actions like “go to settings,” “click the plus button,” and so on.
And suddenly, everything clicked. I tested three PRs that week just by asking questions. After testing, I learned to leave a clear review: comment, approve, or request changes.
If you're asking for changes, adding a screenshot or video screen capture helps the developer see what you mean. And always be polite in your feedback: a simple “thank you” or “nice fix” can go a long way.
Report issues
If you're new to an open source project as a tester, you can start small and help report issues. Test the software thoughtfully and report any issue you encounter. If you are already a user of the software, you can report issues you experience while using the software. In both scenarios, you will be doing the project a load of good because defects will be fixed before other users encounter them.
On one of my open source projects, I had never used the software before. And so there were times when I thought I had caught a bug, but when I raised the issue in the product channel, I was told, “oh, that’s how it is supposed to work” with an explanation as to why it wasn't a bug. After a few rounds of that, I learned to discuss anything I thought was a bug with the maintainers or core leads of the project BEFORE I logged an issue. If the maintainers or leads agreed with me, I would then log it as an issue on GitHub. That way, I wasn't raising any false alarms.
In other cases, I didn't have all the procedural information I needed to log an issue in GitHub. On one project, issue logging required the addition of labels and tags. I did web searches and watched YouTube tutorials, but I still couldn't add labels and tags. Little did I know, before I asked in the Slack channel, that I had to be added to the triage team first. Once I was a member of the triage team, I could add the labels and tags required.
Asking questions and seeking support as a first time contributor cannot be overemphasized. If you don't ask questions and look for support, you're likely to struggle and eventually give up. So, please, always ask questions.
Create or update project documentation
If an open source project is in its early stages, testers can contribute by writing the readme file and by creating tutorials and guides for testing. You can also update the existing documentation if needed.
I often had issues with project documentation, specifically the testing tutorial when I wanted to make my first contribution. I followed every step outlined, but was still unable to make progress. I had to reach out to the project lead for assistance, then she said "Oh, this has changed now. Use this instead." At that point, I thought about updating the documentation. Making sure that documentation is up to date can help new contributors succeed more quickly and can be of use to everyone on the project.
Respond to questions in the forum
Every open source project needs people who can assist new team members with how to install and use the software. So if you are an experienced user or member of the community, you can answer questions in the forums. You can even blog about the software. This is another way to make an impact that does not involve coding.
Translate project documentation
Not everyone who uses open source software understands English. So the community usually needs help with translation of documentation into a variety of languages.
If a language other than English is your first language, or you are fluent in a language other than English, you can help translate open source project documentation into that language.
Write test cases
As a tester, you can write test cases to ensure the software works as expected and to improve test coverage over what is covered in unit tests. You can submit them as pull requests to be added to the documentation of the project's test cases.
Orienting yourself in an open source project
Understanding the team structure of open source projects
Open source projects are organized similarly to traditional organizations, with defined roles and responsibilities. Understanding these roles can help you navigate the community and contribute effectively.
Teams in an open source project typically include the following roles:
Maintainers: These people are the leaders of open source projects. They are responsible for overseeing many aspects of the project like releasing new versions, code review, community management, and making product decisions. They are also contributors.
Contributors: These are people who have contributed to the project one way or the other. They include testers, developers, designers, event organizers, technical writers, and more. Everyone who contributes, no matter how small their contribution, is considered a valuable part of the project.
Community members: These are people that use the project. They provide valuable feedback about the software, report bugs, and express their opinions on the project.
Key documentation for contributors
Before diving into an open source project, it’s essential to familiarize yourself with its documentation. Otherwise you might end up wasting valuable time.
I once spent hours setting up a project locally only to realize I never needed to do that as a low / no-code contributor. As a tester, the best way to do my testing was through Gitpod. I missed out on that important information because I didn’t take my time to read the documentation.
So, as a newbie, ensure you go through the documentation in detail as much as possible. Don’t just skim through like I did.
Here are some key documents you’ll often encounter:
LICENSE: Open source software is typically licensed. This license outlines the legal terms of use and contribution.
Code of conduct: Because a community has been formed around a particular open source software, it is essential to have a code of conduct put in place to ensure a safe space for the contributors and the community. The code of conduct outlines expected behavior and guidelines for all participants of the project. The aim is to create a positive, inclusive and welcoming community, where everyone feels safe to contribute regardless of their background or experience level. It typically addresses respectful communication, prohibits harassing behaviours and discrimination, and ensures that everyone feels valued and respected.
README: A readme file is typically the first thing you want to review. It contains essential information for visitors to understand what the project is all about.
CONTRIBUTING.md: This document explains how and where to report issues and how to start contributing, with links to needed resources.
Other documentation: Projects like Mautic have additional documentation, such as video tutorials for testers on how to test bug fixes and features.
Tools for communication
In open source projects, to ensure collaboration between the leadership team and the wider community of contributors, there is usually a central means for communication. These platforms may include:
- GitHub, where you submit and review pull requests and report issues.
- Slack or Discord: Some projects use these tools for asynchronous communications. It's best to communicate in public channels and keep private messages to a minimum.
- Forums: Some projects offer discussion forums where you can have conversations about product ideas and feature requests, troubleshooting, technical support, and more.
Finding suitable projects to contribute to
Now that you have an idea of how open source projects work, your next step is to find a project you can contribute to.
Select the following resources to explore projects. Search with keywords related to testing to find projects you can contribute to
If you're like me, you may find a project in another way. Until Hacktoberfest, I never found a project I was truly keen on. But thanks to Hacktoberfest's call for testers as contributors, I found the Mautic project, to which I am still contributing. So, if you would like to start your open source contribution during Hacktoberfest, feel free to look out for projects on LinkedIn , BlueSky, or X by using the hashtag #hacktoberfest.
Here are some tips to find projects that will likely be best to contribute to:
- Look out for the things that make the project a solid open source endeavour: the license, readme file, code of conduct, contributing.md and the activity.
- Make sure the project is active. Click on the activity link to see when the last commit was made. That will help you know an active repository.
- Open pull requests to see the reviews. Are the maintainers reviewing pull requests? That means the project is active and worth contributing to. If you don't find reviews and interactions between maintainers and contributors on a pull request, that means you probably won't have any help while trying to contribute. Don't waste your time.
General tips for success in open source contributions
- Communication in an open source community is mostly done asynchronously. Maintainers or contributors are not always at your beck and call. You have to be patient when you ask a question or need a review on your contribution. They are not ignoring you and so don’t feel bad. You’ll get a response once they are available.
- Unless you are sharing sensitive information, it is advised to keep all communications open and public.This way, other members can learn from your question or the conversation.
- This is a personal tip from me, if you go through all the documentation but still don’t know how to figure it out by yourself, I advise you to reach out to someone who has contributed already to ask for support. I did the same when I was trying to make my first contribution. People who successfully get their pull requests merged get a shoutout in the channel, and that was how I reached out to one of them “Hey, I see you have successfully made a contribution. Please walk me through it." She kindly showed me around via a Google Meet and I was able to pick up from there and make my first contribution. If you learn quicker by watching someone else do it, don’t hesitate to reach out to others to show you around.
- Look out for volunteers in the community who arrange meetings via Zoom or Google Meet to onboard new contributors. Attending these sessions two to three times will help you get started easily.
To wrap up…
Open source contribution has been a game-changer for my career as a software tester. Today, I continue to contribute to Mautic by testing new features, improving documentation, and mentoring new testers who join the community. I have also gained new skills and perspectives that directly improve my professional work. I have become more confident and effective while collaborating with my team mates at work.
Beyond technical growth, I have learnt the power of community. I have built friendships with testers worldwide. It has given me the opportunity to work with people who can speak about my work and even make recommendations for me.
For more information
- Beating The Odds In A Competitive Job Market: Top Tips For New Software Testers, Mirza Sisic
- 99 Second Talk: Sharing Knowledge with Junior Testers, Sunjeet Khokhar
- How to Become a Software Tester Without A Computer Science Degree, Cassandra H. Leung
