
Driving License & Vehicle Registeration System
End-to-end QA for a national government platform involving complex citizen workflows, strict business rules, and real-world edge cases.
OPEN_REPORT[2] CAPABILITY_MATRIX
A focused snapshot of my strengths across QA, automation, and product thinking.
[3] OPERATOR_PROFILE
I’m Ali Mzayhem, a QA Engineer based in Lebanon. I work on large systems and digital products, making sure they are not only usable and clear, but also stable, testable, and ready for real users.
With a background in Computer Science from the Lebanese University, I sit between product and engineering — writing test cases, logging bugs, improving flows, and collaborating closely with teams.
[4] TEST_RUNS // CASE_STUDIES
Open a run below to inspect the full report — scope, sample bug reports, and test-case design.

End-to-end QA for a national government platform involving complex citizen workflows, strict business rules, and real-world edge cases.
OPEN_REPORT
Performed QA for a role-based hold management system, validating request lifecycles, user permissions, and state transitions.
OPEN_REPORT[5] SIGN_OFF_LOG
Feedback from project managers, facilitators, and teams I've worked with.
“Ali showed a strong sense of responsibility and commitment at HerronTech. He is always eager to learn, improve, and take feedback seriously. His growth mindset and attention to quality made him a reliable and valuable part of the team.”
“Ali’s QA skills stood out immediately. He consistently identified critical issues early and helped prevent major setbacks. On multiple occasions, his attention to detail played a key role in keeping the project on track and in the deployment stage.”
“Ali made backend development much easier through clear and professional bug reporting. His API testing was thorough, well-documented, and easy to follow, which helped us identify and fix issues faster and with confidence.”
[6] SUBMIT_TICKET
For collaboration and product conversations, file a ticket below — response time is fast.
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, while VRS is a dedicated web application for vehicle registration and related services.
My role focuses on validating end-to-end user journeys across both platforms for citizens and internal staff. I verify data flow between the DLS website, mobile app, middleware, VRS web application, and integrated services while ensuring compliance with business rules, license eligibility, examination workflows, document validation, and vehicle registration processes.
I performed functional, integration, and regression testing for every release, ensuring new changes do not impact existing functionality. I also collaborate with product and development teams by providing detailed bug reports and clear reproduction steps to accelerate issue resolution.
Testing across the Driving License and Vehicle Registration modules surfaced defects tied to specific business rules — here are the key ones, traced back to the exact rule each violated:
| Area | Key finding | Severity | What it demonstrates |
|---|---|---|---|
| Driving License | Multiple exam requests not generated for foreign license exchange applications | Critical | When a citizen applied for multiple license categories through foreign exchange, the system generated a single exam request instead of one per category, resulting in incorrect scheduling and reporting. |
| Driving License | Nationality validation missing for restricted public vehicle categories | Critical | Non-Lebanese applicants were able to select restricted public driving license categories despite business rules limiting them to Lebanese citizens. |
| Driving License | License category A1 fees calculated lower than configured business rules | Critical | Fee calculation for the A1 category returned an amount lower than the configured tariff, affecting financial accuracy. |
| Vehicle Registration | Duplicate chassis number accepted during vehicle registration | Critical | The system allowed registration of duplicate chassis/VIN numbers, creating duplicate vehicle identities and compromising data integrity. |
| Vehicle Registration | Draft applications created per VUN without considering business process | High | The application created multiple drafts for the same VIN across different business processes instead of enforcing process-specific uniqueness rules. |
Internally, the application follows a clear state machine. I use this state model to design scenarios that verify every transition and prevent invalid jumps between states:
RUN_REPORT // ISF-002
QA for an internal hold-management application: request lifecycles, role-based approvals, and data integrity between officers and administrators.
The Internal Security Forces (ISF) Hold Application is a government web platform that manages hold requests throughout their lifecycle—from creation and review to approval, activation, and release—using strict role-based access control.
My role focuses on validating end-to-end workflows across different user roles, ensuring permissions are correctly enforced, state transitions comply with business rules, and data remains consistent across the application and integrated services.
I perform functional and regression testing for each release, design positive and negative test scenarios around permissions and workflow transitions, and provide structured bug reports with clear reproduction steps to support efficient issue resolution.
Testing the hold lifecycle surfaced defects tied to document mapping, fee generation, and action permissions:
| Key finding | Severity | What it demonstrates |
|---|---|---|
| Inspector can change claim status from disabled to enabled | Critical | Inspector workflow allowed modification of finalized claim status, bypassing business restrictions and compromising process integrity. |
| Hold documents incorrectly mapped to hold type | Critical | Required supporting documents changed incorrectly based on hold type due to invalid document mapping configuration. |
| Duplicate hold fees generated for a single hold transaction | High | The fee engine created duplicate charges for one hold operation, resulting in overcharging. |
| Hold actions available for unsupported hold types | High | Users could execute actions that should only be available for specific hold types, violating workflow rules. |
The request lifecycle follows a strict state machine, which I use to derive valid-transition and invalid-jump scenarios: