QA Services

Software Testing & QA Automation Services

Practical testing support for teams that need to validate features, investigate defects, improve regression coverage, or automate repeatable workflows.

Scope, access and deliverables are agreed before any work begins.

What I Can Test For You

Four focused services. Each engagement is scoped to your application and agreed up front, so you know what is covered and what you will receive.

Manual & Functional Testing

What is covered

  • Functional and exploratory testing
  • Regression testing after changes
  • Business-rule validation
  • Boundary and negative scenarios
  • Defect reproduction and documentation

Typical deliverables

  • Agreed test scope
  • Test scenarios or test cases
  • Execution results
  • Reproducible defect reports with evidence
Related proof of work ↓

API Testing

What is covered

  • Request and response validation
  • Status codes and response structure
  • Authentication and authorization scenarios
  • Negative cases and invalid inputs
  • Business-rule validation and integration checks where appropriate

Typical deliverables

  • API test scenarios
  • Execution evidence
  • Documented findings
  • Automation code, when explicitly included in scope
Related proof of work ↓

Playwright Test Automation

What is covered

  • Automation of suitable UI workflows
  • API automation
  • Regression suites with a maintainable structure
  • Test reporting
  • CI integration where appropriate

Typical deliverables

  • An agreed automated test suite
  • Source code
  • Execution reports
  • Setup and execution documentation
Related proof of work ↓

Payment Workflow Testing

What is covered

  • Successful and failed payments
  • Cancellation scenarios
  • Duplicate submissions
  • Refund workflows
  • Transaction-state validation
  • Webhook scenarios and idempotency, where the integration supports them

Sandbox, not production. My public payment work runs against Razorpay Test Mode. It shows method; it does not show that a production payment integration has been validated.

Related proof of work ↓

Proof of Work You Can Inspect

Each service links to an independent public project. Source code and documentation are on GitHub, including what each project does not prove.

Payment Workflow Testing

Razorpay Payment Gateway QA & Automation

What was tested
A small Razorpay Test Mode checkout app: order creation, payment signature verification, amount integrity, webhook signature validation and idempotency, refund error handling, and the order state machine.
Why it matters
Payments cross the UI, the app, the gateway and asynchronous webhooks, and each can disagree with the others. Testing found two High-severity defects, both fixed and regression-tested.
Tools
Playwright Test (API and UI), Express, SQLite, GitHub Actions.
What was automated
37 test definitions; 34 run in CI, 3 need live Test Mode credentials and are run manually.
Limitations
Sandbox only. Playwright drove a real Checkout payment in one documented session, but that session is not a committed, repeatable test. No webhook from Razorpay itself was observed arriving, and no successful live refund was completed.
API Testing

RESTful Booker API Automation

What was tested
The public RESTful Booker demo API across authentication, create, retrieve, full and partial update and delete, plus negative cases and multi-step workflows.
Why it matters
It shows how I structure API checks: status codes, response structure, data persistence across requests and rejection of invalid input.
Tools
Playwright Test, TypeScript, reusable API client classes, GitHub Actions.
What was automated
47 test definitions in 9 suites, including 8 negative tests.
Limitations
A public practice API, not a client system. The last recorded CI run is 10 September 2026 and is a historical result.
Playwright Test Automation

Automation Exercise

What was tested
The Automation Exercise e-commerce demo: core customer journeys through the UI and selected REST endpoints.
Why it matters
It shows a maintainable UI and API regression suite built with page objects and run in CI, not a set of one-off scripts.
Tools
Playwright Test, Page Object Model, GitHub Actions.
What was automated
26 test definitions: 16 API and 10 UI.
Limitations
A public demo site. The last recorded CI result is 29 August 2026 with retries enabled and is a historical result.
Manual & Functional Testing

Automation Exercise: the manual layer

What was tested
The same e-commerce demo, planned and tested manually first: a test plan, a manual test case log, exploratory testing using boundary-value analysis and state-transition heuristics, and a summary execution report.
Why it matters
Automation only covers what someone decided was worth checking. These documents show that decision step: scope, scenarios, execution results and a release assessment.
Tools
Manual and exploratory testing, documented in Google Docs; Playwright for the repeatable parts.
Limitations
A public demo site and an independent project. My employer project work is confidential and appears on this site only as generalized summaries.

These are independent, self-directed projects, not client or employer work. Test counts are unique test definitions listed by each repository, not a measure of coverage. CI run logs on GitHub require a sign-in.

How an Engagement Works

  1. Discuss

    We talk through the application, the requirements and the testing problem you want solved.

  2. Define scope

    We agree what is in scope, what access I need, the timeline and the deliverables.

  3. Execute

    I carry out the agreed testing work.

  4. Report

    I share findings and, if included in scope, verify the fixes.

  5. Hand over

    When automation is in scope, I deliver the code and setup and execution documentation.

Scope is agreed before work begins. If something falls outside it, we discuss it first. It is not added silently.

Before We Start

What I will need from you

  • A description of the application, feature or API to be tested
  • Access to a test or staging environment, not production
  • Requirements or acceptance criteria, if they exist
  • A point of contact for questions and for confirming defects

What I will not promise

  • A bug-free release. Testing reduces risk; it cannot prove defects are absent
  • A fixed number of defects found
  • Turnaround times before the scope is known
  • Coverage of anything outside the agreed scope

Let’s Discuss What Needs Testing

Tell me what you are building and what worries you about it. I will reply to talk through scope before anything is agreed.

What is the application, what should be tested, and is there a test environment? Please do not include passwords or confidential data.

Your details are used only to reply to this inquiry. See the privacy notice.

Hiring instead?

If you are recruiting for a Software QA Engineer role, my experience and résumé are here.

View résumé · Contact