InfluxData sponsored this post.
Software testers travel a varied road. Some love writing code and automating otherwise tedious testing tasks; while others enjoy strategic exploration of software to find the trickiest bugs, doing things that “no user would ever try.” Many enjoy a balance of both. But almost all software testers suffer in one area: a living portfolio of work that they are able to present and discuss with hiring managers.
Developers have a lot more visibility in the GitHub ecosystem to build a portfolio. Their work necessitates frequent interaction with the platform, and developers have more obvious choices when it comes to showing their skills in the GitHub medium. Many job postings for software developers and software testers ask for the applicants to share their GitHub username so that hiring managers can review their portfolio. Software testers are asked for this information, but the path forward (What should be included? What matters? Where do I even begin?) is daunting, at best.
I know, because I was one of those testers. I had heard, mostly from developers, to “go look for a project and find a way to contribute.” But when I was a software tester, I couldn’t readily determine what contributions would be helpful to a project.
Now, as an engineering manager on a large open source project, I can see immediately the places where software testers can add value while enhancing the overall health and stability of my team’s project. If you are a software tester, I hope you’re asking “What do I do next?” If you’re an engineering manager or developer, I hope you take these steps into consideration as you work to engage software testers in your open source communities.
What to Do Next: Software Testers
Deciding where to begin is the hardest part. Answering the following questions will help you narrow the scope of your search for the right project to contribute to.
- Look for something familiar — is there an open source project that you like to use, or that is already in use at your company?
- Look for a project where the setup and debugging require skills that you have and/or would like to learn. For example, have you always wanted to try Docker? Find a project that uses Docker containers as part of the setup. Bonus points if you document your learning and contribute that documentation to GitHub for future testers and developers.
- Start before the issues. Most advice for software testers is to find and try to reproduce bugs. Yet on projects that are diverse, running on multiple operating systems/platforms, or on different protocols with third-party dependencies, you can start by following, testing and debugging the setup documentation. Is that documentation incorrect? Submit a PR to correct it. Is the documentation missing details that would help others to get going faster? Submit a PR to make sure all the details are available for future users.
- Show off your cross-platform chops. In projects like Telegraf (the project I manage), there is a need for cross-platform testing and multiple protocols on cloud and physical devices. With all of that complexity comes security and performance concerns. Each of those areas is a separate discipline in testing; and once you have a solid setup for the project, you can use the project as a way to build skills in any testing domain.
- Exploratory test planning, strategy and reporting. This is one of the trickiest things to discuss in an interview because exploratory testing sounds simple but is one of the most complex acts in software testing. There are ways to use GitHub to show exploratory testing work while adding tremendous value to a project. Submitting a PR of your testing reports to a welcoming project repository lets developers and testers know exactly how something was (or wasn’t) tested, and provides a starting point for future work. This same PR also provides a direct link to the kind of software testing work that you do, allowing for a shared understanding of your work to be established and more thoughtful, targeted discussions during the interview process.
What to Do Next: Open Source Engineering Managers
Provide clear contribution steps. If your project is large with many contributors, it is likely you have unit and integration testing; as well as other quality checks in your delivery pipeline. It is equally likely that you are unable to test every single community contribution in the way that you would like to. Provide clear steps for open source testers to set up your project and highlight what you’d like to see in GitHub issues. Would you like someone to try out some automated UI testing? Maybe you are looking for better documentation around Docker setup? Or perhaps you have tested everything on Linux, but you’d really love some Windows users to dig into your project and give it a spin.
If you have a wish-list of things you’d love to see for your project, share it. I have found the open source community to be incredibly kind, generous and responsive, and I expect open source testers looking to gain real experience and make valuable contributions will react in the same way.
Building an open source testing program levels the playing field for software testers, while improving the robustness of a project’s quality. As engineering managers, we can do a service to our projects, our developers, our community contributors, and to the field of software development, by providing simple but effective ways for software testers to contribute to open source projects.
For software testers, you can build a portfolio that reflects your skills and doesn’t live behind the private-repo wall, making your work and skills more visible to employers in a crowded marketplace.
Feature image via Pixabay.