MUAYYAD AL HAZMY · QA / SDET
Software Test Engineer · Jeddah, KSA ● Available for senior QA / SDET roles

I test what happens
behind the screen,
not just on it.

Software Test Engineer with a backend-engineering background. I work where most QA stops: APIs, data layers, integration contracts, and the architectural seams where systems quietly disagree with each other.

View case studies → Get in touch
API testing● Integration validation● Database testing● Backend reasoning● Risk-based strategy● ISTQB Certified● Agile Tester● API testing● Integration validation● Database testing● Backend reasoning● Risk-based strategy● ISTQB Certified● Agile Tester●
01 / About

A backend engineer who chose testing as the craft.

I trained as a backend engineer. I designed schemas, built APIs in .NET Core and Spring Boot, and shipped real systems before I moved into testing. That history is the work, not a footnote.

When I read a feature spec, I see the request payload, the database write, the side effects, and the contracts that have to hold across services. UI tests are the last 10% of validation. I focus on the 90% underneath.

That's what I do for the teams I work with: validate the system, not just the screen.

01

Test the system, not the screen.

APIs, database state, message contracts, and integration boundaries first. UI is a thin layer over real risk.

02

Read the code.

I open the repo. Knowing what a function actually does is faster and more accurate than guessing from the spec.

03

Risk over coverage.

I prioritize where business impact and failure likelihood are highest. Coverage numbers without that judgement are noise.

02 / Selected work

Four engagements where I tested systems, not screens.

Validating eligibility, calculations, and integrations on a national workforce-development platform.

The platform decides who qualifies for what, and it relies on a chain of integrations and rule-based calculations to do it. My role is to verify that the rules behave the way they're written, not in the UI, but in the API responses and the data left behind.

Where the risk lives

Rule-based business logic, multi-system integrations, and data-state correctness. Places where a UI test would pass and the system would still be wrong.

How I work it
  • API contract validation on every integration boundary
  • SQL-level data checks against expected post-conditions
  • Acceptance-criteria review before development starts
  • Risk mapping driven from policy and rule specifications

Cross-platform QA on a public-safety system where the wrong response goes nowhere good.

A multi-platform operator and citizen stack where the visible UI is the small part of the system. Most of the risk lives in the services behind it: authentication, routing, state synchronization, and the contracts between them.

Where the risk lives

Service-to-service contracts, cross-platform data parity, and authentication flows. Things that look fine on screen and fail in the network tab.

How I work it
  • API and contract testing across operator and citizen tracks
  • Manual + automated regression on critical operator flows
  • Architectural input on layered patterns for testability
  • Spec review before development, not after

Standing up the QA foundation on a greenfield cross-platform product.

A new product without an existing test estate. I authored the test cases, the test management plan, and seeded the regression automation. The lesson that stuck: the most valuable thing a tester leaves behind is the system that catches the next bug, not the bug they caught today.

Where the risk lives

Greenfield code paths, an evolving spec, and a roadmap moving faster than the QA process, plus multilingual content with native Arabic requirements.

How I worked it
  • Authored the test management plan from product specs
  • Ran manual regression across release cycles
  • Stood up Selenium automation for stable critical paths
  • Owned Arabic-language QA, including RTL fidelity

I built systems before I tested them. That's the credential.

An internal CMS for a government media department: requirements, ER modeling, .NET Core backend, MVC frontend. I include this on a QA portfolio for one reason. It's why I can read a backend, reason about architecture, and find the seams where a system is most likely to fail.

What I built
  • Internal web service for content management
  • ER diagrams and relational schema
  • .NET Core 6 backend with MVC frontend
  • End-to-end: requirements → delivery
Why it matters now

Backend instinct is the differentiator. I sit in architecture conversations and talk testability, not ticket counts, because I've been on the other side of the PR.

03 / How I work

Where I look first when a feature lands.

Most QA starts at the screen and works inward. I start at the data and work outward. The screen is the last thing I check, because by the time it's wrong, the system has already disagreed with itself somewhere I can debug.

This is what backend-leaning testing actually looks like in practice: a sequence I run, in order, every time.

Investigation order top → bottom
01
The data contract
Schema, types, nullability, defaults. What does this feature touch in the database, and is the shape correct after?
02
The API contract
Request/response shapes, status codes, auth, error envelopes. Postman against the spec, not against the UI.
03
The integration seams
Where two services agree to disagree. Idempotency, retries, race conditions, partial failures.
04
The business rules
Eligibility, calculations, state machines. Reproduce them with test data and assert the outcome explicitly.
05
The UI
Last layer. By here, most of the risk is already retired. What's left is rendering, accessibility, and locale.
04 / Toolbox

The tools I reach for, grouped by what they're for.

Testing types

  • Manual / exploratory core
  • UI testing core
  • API testing core
  • Database testing core
  • Black-box / white-box core
  • TDD-aware working

Automation

  • Selenium core
  • Appium working
  • Cypress working
  • Playwright working
  • Cucumber working
  • Postman / REST core

Languages & frameworks

  • Java / Spring Boot core
  • C# / .NET Core 6 core
  • Python working
  • JavaScript / TypeScript working
  • Flutter / React Native familiar
  • SQL · Oracle · PostgreSQL core

Process & DevOps

  • Jira / Confluence / Notion core
  • Git / GitHub / GitLab core
  • GitHub Actions working
  • Agile / Scrum core
  • Layered architecture / MVC core
  • ISTQB Foundation + Agile certified
05 / By the numbers

Quantified, where it can be quantified.

2yrs
As a dedicated QA on enterprise NEOM & HRDF programs.
4×
Sectors covered: public safety, tourism, workforce, municipal.
2/2
ISTQB certifications passed first attempt: Foundation v4 and Agile Tester.
4.58/5
BSc Software Engineering · 2nd-degree honor · University of Jeddah.
06 / Contact

Need a tester who reads the backend?

I'm most useful to teams whose risk lives below the UI: APIs, data, integrations, business logic. If that sounds like your stack, get in touch.

Email me → LinkedIn
Email
[email protected]
Phone
+966 54 774 3131
LinkedIn
muayyad-al-hazmy
Based
Jeddah, Saudi Arabia
Speaks
Arabic (native) · English (advanced)
Status
● Open to opportunities