QA context from my CV
My CV lists product exposure to order management, kitchen order tickets, automated bills, taxes, discounts, multiple payment methods, and thermal receipts. This study converts that domain into QA coverage for one order, one bill, one payment state, and one receipt trail.
Risk & proposed scope
The proposed focus is a mismatch between what the cashier sees, what the kitchen receives, and what the customer pays. Confirm rounding, discount ordering, cancellation, and retry rules before execution. Use a payment sandbox and synthetic orders.
Example test scenarios
- Submit twice during a slow response: inspect accepted order count and kitchen tickets.
- Apply a discount at its agreed limit: compare the total with an independent calculation.
- Delayed payment response: maintain an explicit pending state and reconcile the result.
- Receipt printer fails: reprint the receipt without recharging.
- Amend an already dispatched order: verify the agreed kitchen update and bill adjustment.
Evidence & release criteria
Link the order ID, payment reference, kitchen ticket, and receipt. Keep expected calculations separate from application code. Proposed release criteria require no unresolved duplicate-charge or order-loss failures in the executed scope.
Status: design only. No live payment tests, measured improvements, or production defect claims are included.