Self-taught QA engineer

I'm Gavin Griffith. I learned test automation by doing it, and this page only claims what my repository can prove. Every line below links to the code behind it.

Found a bug in an open-source project, confirmed by its maintainer Navidrome issue 6310
Tests at every layer: unit, API and browser Game Library test suites
Browser automation in Python and in TypeScript Python suite TypeScript suite
Every push runs the suites in CI GitHub Actions runs
This page is tested too Tests for this site

Projects

Navidrome

Python, pytest, requests, Playwright, Docker Compose

Navidrome is an open-source music server, so this is testing from the outside: all I had was the running app and its API. The suite starts a throwaway server, fills it with generated audio, then runs more than forty API and browser tests against it.

What the tests found

Confirmed, fix in review
Adding tracks to a playlist counted track IDs that don't exist as added. The maintainer confirmed it and opened a fix, which I verified against the patched build. Read the issue
Documented
The API creates playlists with no name, which the web form forbids.

Navidrome test code Navidrome CI runs

Game Library

FastAPI, SQLite, pytest, Playwright in TypeScript

A small game tracker built to be tested, with a written spec and four bugs planted in it, unmarked. Because the app's code is in the repository, it is tested at three levels: more than eighty unit tests on the rules, API tests that run the app in-process, and more than fifty browser tests.

What the tests found

Planted, found
A title of exactly 100 characters is rejected, though the limit is 100. An off-by-one at the boundary.
Planted, found
The duplicate check misses the same title in a different letter case.
Planted, found
After cancelling an edit, adding a new game overwrites the game that was being edited.
Planted, found
The count under the list shows the games on the page, not the total.

Game Library code and tests Game Library CI runs

Skills

Each one links to a file where you can see it used.

Test design: Boundary value tests on every field limit

Negative tests for missing and invalid credentials

Fixtures that create and clean up their own test data

Expected-failure tests that pin a known bug until it is fixed
API testing: pytest and requests against a live REST API

In-process API tests with a fresh database for each test
Browser testing: Page objects with Playwright in Python

Shared helpers with Playwright in TypeScript

Accessibility checks with axe
Tooling: GitHub Actions pipelines for each project

Docker Compose for a repeatable test server

Seed scripts for test data
Bug reporting: Write-ups with steps, expected and actual results

An upstream issue with a minimal reproduction, confirmed and fixed

Background

I don't have a computer science degree. I taught myself testing the way I'd want any tester to learn it: pick real software, try to break it, and write down exactly what happened.

The repository is the record of that. It started as a few scripts and grew one step at a time, and the commit history shows each step.

Plain Python scripts that called an API and printed what came back.
A pytest suite, with fixtures and assertions that can actually fail.
Browser tests with Playwright and page objects.
A test server in Docker Compose, and every suite running in GitHub Actions.
A bug found in Navidrome and reported upstream.
An app with planted bugs, tested at unit, API and browser level.
This site, with tests of its own.

Contact

The quickest way to see how I work is to read the code. To talk, message me on LinkedIn.