A pile of loose pieces, waiting to break. I'm a QA engineer who finds what's wrong and helps it all click into place.
01 GOVERNMENT · LICENSING
End-to-end QA for the national Driving License and Vehicle Registration systems: citizen website, mobile app, middleware and the business rules that tie them together.
02 GOVERNMENT · SECURITY
QA for a security-sector hold-management platform: who can create, review, approve and release, making sure nobody can do what they shouldn't.
03 WEB & COMMERCE
More than 30 websites and online stores delivered across my own freelance work and Tale Twist in Doha, built, tested and validated on every screen.
PROCESS
STAGE 01 / 06
Read the rules before the code. Map business rules, roles and what breaks if they fail.
STAGE 02 / 06
Boundaries, equivalence classes, state transitions. The happy path, the sad path, and the weird one.
STAGE 03 / 06
Functional, integration and cross-browser runs on every build, on web and mobile.
STAGE 04 / 06
Repro steps, evidence and root cause. Tickets developers can fix without asking twice.
STAGE 05 / 06
Playwright + TypeScript, Page Object Model, wired into CI so regressions get caught early.
STAGE 06 / 06
Nothing ships until the old flows still pass. Then it gets a green light.
TOOLKIT
EXPERIENCE
ABOUT
I'm Ali Mzayhem, a QA Engineer based in Mount Lebanon. I work on large systems and digital products, making sure they're not only usable and clear, but stable, testable and ready for real users.
With a Computer Science background from the Lebanese University and a start in UI/UX design, I write test cases, log bugs, improve flows and work closely with the people who build them.
LANGUAGES & EDUCATION
Hello
OFF THE CLOCK
Go ahead, play with these.
Always on while I test. Now spinning: The Godfather Waltz by Nino Rota.
South Lebanon, digitized: a village above the olive groves. The light follows the real time there, day or night. Take one.
SOUTH LEBANON --:-- · DAY
UCMAS national champion, and I represented Lebanon internationally. Give the abacus a sum.
0
RUN_REPORT // TTVMA-001
End-to-end QA for the national Driving License & Vehicle Management system: complex flows, strict rules, and real-world edge cases.
The Driving License System (DLS) and Vehicle Registration System (VRS) are two separate government platforms developed for TTVMA. DLS includes a citizen website, mobile application and internal middleware; VRS is a dedicated web application for vehicle registration and related services.
I validate end-to-end journeys across both platforms for citizens and internal staff, verifying data flow between the website, mobile app, middleware, VRS and integrated services, and checking business rules for license eligibility, examination workflows, document validation and vehicle registration.
Every release gets functional, integration and regression testing so new changes don't break existing behaviour, backed by detailed bug reports with clear reproduction steps. This work earned a formal recognition from the Head of TTVMA.
Defects traced back to the exact business rule each one violated:
| Area | Key finding | Severity | Impact |
|---|---|---|---|
| Driving License | Multiple exam requests not generated for foreign license exchange | Critical | Applying for several categories via foreign exchange produced one exam request instead of one per category, causing wrong scheduling and reporting. |
| Driving License | Nationality validation missing for restricted public categories | Critical | Non-Lebanese applicants could select public driving categories restricted to Lebanese citizens. |
| Driving License | Category A1 fees calculated below configured tariff | Critical | Fee calculation returned less than the configured amount, affecting financial accuracy. |
| Vehicle Registration | Duplicate chassis number accepted | Critical | Duplicate chassis/VIN numbers could be registered, creating duplicate vehicle identities. |
| Vehicle Registration | Drafts created per VUN regardless of business process | High | Multiple drafts for the same VIN across processes instead of enforcing process-specific uniqueness. |
The application follows a clear state machine, which I use to design scenarios that verify every transition and block invalid jumps:
RUN_REPORT // ISF-002
QA for an internal hold-management application: request lifecycles, role-based approvals, and data integrity between officers and administrators.
The ISF Hold Application manages hold requests through their whole lifecycle (creation, review, approval, activation and release) under strict role-based access control.
I validate end-to-end workflows across user roles, making sure permissions are enforced, state transitions follow business rules and data stays consistent across the application and integrated services.
Each release gets functional and regression testing, with positive and negative scenarios around permissions and workflow transitions, and structured bug reports for fast resolution.
Testing the hold lifecycle surfaced defects in document mapping, fee generation and action permissions:
| Key finding | Severity | Impact |
|---|---|---|
| Inspector can change claim status from disabled to enabled | Critical | Finalized claims could be modified, bypassing business restrictions. |
| Hold documents incorrectly mapped to hold type | Critical | Required supporting documents changed incorrectly due to invalid mapping configuration. |
| Duplicate hold fees for a single transaction | High | The fee engine charged twice for one hold operation. |
| Hold actions available for unsupported hold types | High | Users could run actions reserved for specific hold types, violating workflow rules. |
The request lifecycle follows a strict state machine, used to derive valid-transition and invalid-jump scenarios:
RUN_REPORT // TALE-003
More than 30 websites and online stores across my own freelance work and Tale Twist in Doha, with QA built into delivery, not bolted on.