The resume signal almost nobody has
A merged pull request to a real testing project proves what an interview cannot. Here is where to start, what to contribute, and how to land your first PR.
A merged pull request to a real open-source testing project is one of the strongest signals on an SDET resume — it proves you can read an unfamiliar codebase, work to a project standard, and ship. Yet almost no candidates do it, which is exactly why it stands out. Here is where to start and what kind of contribution to aim for.
Where to make your first contribution
Ordered roughly by how approachable they are for a first pull request.
| Project | Difficulty | Type of contribution | Time to first PR | Resume impact |
|---|---|---|---|---|
| Selenium WebDriver | Medium | Documentation, example fixes, small bug fixes, test improvements | 2–4 weeks | VERY HIGH — 'I contributed to the tool all SDETs use globally' |
| RestAssured | Medium | Documentation improvements, example updates, issue triage | 1–2 weeks | HIGH — shows API automation depth |
| TestNG | Medium | Bug reports with reproducible examples, doc fixes | 2–3 weeks | HIGH — shows framework depth |
| Cucumber-JVM | Medium | Documentation, Gherkin examples, issue reproduction | 2–4 weeks | HIGH — BDD contribution is rare for freshers |
| Allure Framework | Easy | Documentation, translation, example fixes | 1–2 weeks | MEDIUM — reporting framework contributor |
| Appium | Hard | Documentation, example tests, plugin contributions | 4–8 weeks | VERY HIGH — mobile automation expertise |
| k6 (Performance) | Medium | Documentation, example scripts, community answers | 1–2 weeks | HIGH — performance testing expertise |
| OWASP ZAP | Easy | Rules, documentation, issue triage | 2–4 weeks | HIGH — security testing expertise |
| Playwright | Hard | Documentation, example tests, issue reproduction | 3–6 weeks | VERY HIGH — modern automation framework |
| Testing Library | Easy | Documentation fixes, example improvements | 1 week | MEDIUM — shows frontend testing awareness |
How to actually land your first PR
- Start with docs and tests — fixing a doc gap or adding a missing test is the fastest accepted first PR and teaches you the codebase.
- Read CONTRIBUTING.md first — every project has standards; following them is half the battle.
- Pick "good first issue" labels — maintainers tag these specifically for newcomers.
- Engage before coding — comment on the issue, confirm your approach, then submit. It dramatically raises your merge rate.
Turn it into interview material
An open-source PR is portfolio and behavioural gold.
Portfolio Projects → STAR GuideFrequently asked questions
Should SDETs contribute to open source?
Yes — a merged pull request to a real testing project proves you can navigate an unfamiliar codebase and ship to a standard, which very few candidates can demonstrate.
What open-source projects can an SDET contribute to?
Testing tools and frameworks are the natural fit. Start with documentation or test contributions on projects labelled "good first issue" before attempting features.
How do I make my first open-source contribution?
Read CONTRIBUTING.md, pick a "good first issue", comment to confirm your approach, then submit a small, clean PR — docs or tests are the easiest to get merged.
Does open source help an SDET resume?
Significantly — it is concrete, verifiable proof of skill and gives you a strong behavioural story about working in an unfamiliar codebase.
Open-source projects and their issue labels change — confirm a project is active and beginner-friendly before starting.