QA Analyst (Part-Time) – Manual + Playwright UK PropTech SaaS Start-up | Fully Remote

Salary: TBC

The role
You’ll test everything the team builds before it reaches customers. Two people build and both ship every week: a senior engineer who owns the foundations, and a co-founder who builds screens using Claude Code. You’ll check both of them.

You’ll own the release checklist, the regression run, bug reports and fix verification. You’ll test by hand first and keep the automated end-to-end tests running. You’ll report to the founders rather than the engineer, so the person who wrote the code doesn’t decide whether a bug matters. Your first big job is testing the migration of 60 customers from GoHighLevel onto the new platform.

What you’ll own

• Exploratory testing of every feature before it goes live, across the main browsers and on mobile

• The release checklist and regression run on every release

• Maintaining the Playwright end-to-end tests: updating them when screens change and adding cases for bugs you find

• Clear bug reports with steps, screenshots and severity, and verifying fixes once shipped

• Testing the money paths every time: Stripe subscriptions, credits and financial calculators

• Checking data separation between customers (one customer must never see another’s data)

• Testing the GoHighLevel migration so every customer’s data arrives complete and correct

• Keeping test cases and known-issues documentation up to date

What you’ll need

• 3+ years testing web SaaS products, including at least one role where you were the main or only tester

• Risk-based test planning: you decide what to test first when there isn’t time for everything, and can explain why

• Hands-on exploratory and regression testing, with test cases kept in a lightweight tool (TestRail, Qase, Notion or a spreadsheet)

• Working-level Playwright in TypeScript: run the suite, read a failure and trace, fix a broken locator, add a case (Cypress experience transfers)

• API testing with Postman, Bruno or Playwright’s request API, including checking error handling and verifying webhooks

• Read-level SQL to check what landed in Postgres after an action

• Ability to read a GitHub Actions CI run and tell a flaky test from a real failure

• Clear, reproducible bug reports in GitHub Issues, Linear or Jira

• Clear written English, since most of the job is written