Software Testing · GitHub Portfolio
How to Showcase Software Testing Projects on GitHub Properly
Quick summary — showcasing testing projects on GitHub
A strong testing repository has a clear folder structure, a README explaining scope, setup and results, tests that run with one command, a CI pipeline that runs tests on every push with a status badge, readable test reports, and manual artefacts such as test cases and bug reports. Pin your best two or three repos.
In this guide you will learn:
- Repository structure — for automation projects.
- README sections — that recruiters read.
- CI pipelines and reports — that prove tests pass.
- Manual testing artefacts — on GitHub.
- Interview questions — about your GitHub projects.
SECTION 01Repository structure and setup
When a recruiter or interviewer opens your repository, the first thing they see is the file list. A messy root folder with random file names suggests messy work, while a clear structure suggests you understand how real test projects are organised. A good structure also makes it easy for anyone to install dependencies and run your tests. Use these guidelines:
| Item | Weak version | Strong version | Why it matters |
|---|---|---|---|
| Folders | All files in the root | tests/, pages/, data/, reports/ | Easy to navigate |
| Dependencies | Not listed | requirements.txt or package.json | Anyone can install them |
| Configuration | URLs hardcoded in tests | Config file or environment variables | Easy to change environments |
| Ignored files | Reports and caches committed | .gitignore for caches and secrets | Clean history, no leaked secrets |
ui-api-test-suite/
|-- README.md
|-- requirements.txt
|-- pytest.ini
|-- .gitignore
|-- .github/workflows/tests.yml
|-- config/
| `-- settings.py
|-- pages/ # page objects for UI tests
| `-- login_page.py
|-- tests/
| |-- api/
| | `-- test_posts.py
| `-- ui/
| `-- test_login.py
`-- docs/
|-- test-plan.md
|-- test-cases.md
`-- bug-reports.md
# config/settings.py
import os
BASE_URL = os.getenv("BASE_URL", "https://jsonplaceholder.typicode.com")
UI_URL = os.getenv("UI_URL", "https://the-internet.herokuapp.com")
TIMEOUT = int(os.getenv("TIMEOUT", "10"))
# pytest.ini
# [pytest]
# testpaths = tests
# addopts = -q
# markers =
# smoke: quick checks run on every push
SECTION 02README, CI and test reports
The README is your project's front page. Most visitors will read it and nothing else, so it must explain what is tested, how to run it and what the results look like. A CI pipeline that runs your tests on every push adds strong proof, because anyone can see that the tests actually pass. Test reports make results readable for people who will not run the code themselves:
| Item | What to include | Tool example | What it proves |
|---|---|---|---|
| README overview | App under test, scope, test types | Markdown | You understand what you tested |
| Run steps | Install and run in 2-3 commands | pip, pytest | Project actually works |
| CI pipeline | Tests run on push and pull request | GitHub Actions | Tests pass consistently |
| Report | Summary of passed and failed tests | pytest-html, Allure | Results are readable |
# UI + API Test Suite

## What is tested
- API: posts and users endpoints (status codes, fields, invalid input)
- UI: login page on a public practice site (valid, invalid, empty)
## Tech
Python, pytest, requests, Selenium, GitHub Actions
## Run locally
pip install -r requirements.txt
pytest
## Results
24 tests, run on every push. Latest report: see Actions artefacts.
## Manual testing docs
Test plan, test cases and bug reports are in /docs.
# .github/workflows/tests.yml
name: tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: pip install -r requirements.txt pytest-html
- run: pytest --html=reports/report.html --self-contained-html
- uses: actions/upload-artifact@v4
if: always()
with:
name: test-report
path: reports/report.html
SECTION 03Showing manual testing work on GitHub
GitHub is not only for automation code. Manual testing skills, such as test planning, test case design and bug reporting, can also be shown clearly with Markdown files. This matters for freshers applying to manual or mixed QA roles, where interviewers want to see how you think about coverage and how clearly you write. Include these artefacts:
| Artefact | What to include | Format | Tip |
|---|---|---|---|
| Test plan | Scope, approach, environments, risks, entry and exit criteria | Markdown | Keep it to one or two pages |
| Test cases | ID, title, steps, expected result, priority | Markdown table or CSV | Cover positive, negative and edge cases |
| Bug reports | Title, environment, steps, expected, actual, severity | Markdown | Use a public practice app |
| Traceability | Which test cases cover which requirements | Simple table | Shows coverage thinking |
| ID | Title | Steps | Expected | Priority |
|----|-------|-------|----------|----------|
| TC01 | Valid login | Enter valid user and password, click Login | Secure area page shown | High |
| TC02 | Wrong password | Enter valid user, wrong password | Error message shown | High |
| TC03 | Empty fields | Click Login with both fields empty | Validation message shown | Medium |
| TC04 | Password with spaces | Add leading space to valid password | Login rejected or trimmed as per spec | Low |
# tests/ui/test_login.py
# pip install selenium (Selenium 4 manages the driver automatically)
from selenium import webdriver
from selenium.webdriver.common.by import By
URL = "https://the-internet.herokuapp.com/login"
def test_valid_login():
driver = webdriver.Chrome()
try:
driver.get(URL)
driver.find_element(By.ID, "username").send_keys("tomsmith")
driver.find_element(By.ID, "password").send_keys("SuperSecretPassword!")
driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()
assert "/secure" in driver.current_url
finally:
driver.quit()
SECTION 04Testing repository templates
Use these templates to upgrade your existing testing repositories:
[ ] Clear name (e.g. ui-api-test-suite, not project1)
[ ] Short description and topics set on GitHub
[ ] README: what, tech, run steps, results
[ ] requirements.txt or package.json
[ ] Tests run with one command
[ ] CI workflow with status badge
[ ] .gitignore; no secrets committed
[ ] /docs with test plan, cases, bug reports
GitHub profile for QA freshers
- Profile README: 3 lines about you + links to best repos
- Pin 2-3 testing repos (automation, API, manual docs)
- Clear repo descriptions (one line each)
- Regular, meaningful commits (not one giant upload)
- Link your GitHub on resume and LinkedIn
Good commit messages
add API tests for invalid post IDs
move login locators into page object
add CI workflow with HTML report
document test plan scope and risks
fix flaky wait in checkout test
Avoid: 'update', 'changes', 'final', 'final2'
SECTION 05Tips for testing portfolios on GitHub
These habits make your testing repositories stand out:
- Make it run in one command — test it from a fresh clone before sharing.
- Add CI early — a passing badge is strong, quick proof.
- Document manual work — test plans and bug reports belong in /docs.
- Use practice sites — test public demo apps made for practice, not real sites.
- Fix flaky tests — unstable tests in a portfolio raise doubts.
SECTION 06Interview Q&A — testing portfolios
Q1Walk me through the structure of your test project.
Explain the folders, page objects, configuration, test data, CI workflow and how someone runs the tests.
Q2What is the Page Object Model and why did you use it?
It keeps page locators and actions in separate classes so tests stay readable and changes to the UI need updates in one place.
Q3How do you handle flaky tests?
Find the cause, such as timing or test data, use explicit waits, make tests independent and avoid fixed sleeps.
Q4Why did you add CI to your project?
To run tests automatically on every change, catch failures early and show that the suite passes consistently.
Q5How do your manual test cases relate to your automated tests?
Explain which manual cases were automated, why those were chosen and how you track coverage between them.
SECTION 07Test yourself — testing portfolios quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Should software testers have a GitHub profile?
Yes, it is strongly recommended. It lets recruiters see your test code, documentation and working style, which a resume alone cannot show.
Can I put manual testing work on GitHub?
Yes. Test plans, test cases and bug reports in Markdown show your test design and reporting skills.
How many testing projects should I pin?
Two or three strong, complete projects are enough. For example, a UI automation suite, an API test suite and a manual testing docs project.
Which website should I use for test automation practice?
Use public practice sites that are designed for testing and allow automation. Avoid automating real company or banking websites.
Do I need CI in a fresher testing project?
It is not required, but it is a strong signal. A simple GitHub Actions workflow is quick to set up and shows your tests run reliably.
SECTION 09Related reads
Classroom & online · Noida
Build a testing portfolio recruiters trust
Our Software Testing Training Course helps you build automation, API and manual testing projects with GitHub, CI and portfolio reviews.
Talk to a counsellor for current fees- Automation + API projects
- GitHub and CI
- Portfolio review
- Weekday & weekend batches