C:\My Documents\QA_Case_Study.log

A QA cycle on a sales commission engine

Sales compensation software turns transactions into commission: it credits each sale to one or two sellers, claws back commission when a product is returned, measures attainment against a quota and pays through a tiered plan with a gate and a cap. I tested a small engine that does exactly that, from the written requirements to a signed-off release.

The data comes from my retail logistics case: 61 stores, 251 sellers and a quarter of 25,259 transactions with returns and split sales.

What I did

1. Reviewed the requirements for testability and found four gaps before any code ran.
2. Designed 92 test cases with boundary values (the 50% gate, the band limits, the 30-day return window), equivalence partitions and state transitions, prioritised by risk.
3. Automated them with pytest against the REST API and with a Postman collection run by Newman.
4. Tested the database with SQL checks that must return zero rows, on PostgreSQL.
5. Rebuilt the commission plan in Excel as an independent oracle and reconciled every payout.
6. Logged each defect with steps, expected and actual results and impact, retested the fixes and ran the regression in GitHub Actions.

Three defects from the first build

• Critical

  Every sale failed on PostgreSQL and passed on SQLite

  Credit rows were written before their transaction. SQLite does not enforce foreign keys by default, so the local suite was green. Running the same tests on the production database caught it, and CI now runs both.

• Major

  Returns on day 30 were not clawed back

  A < where the requirement said 30 days or less. One boundary test found it and the parallel run measured it: 26 payouts overpaid, 6,066.83 MXN.

• Major

  49.995% passed a 50% gate

  The engine compared the attainment after rounding it for display. A crafted seller placed exactly on that edge exposed it.

Parallel run against Excel

The workbook computes the plan with formulas in integer cents, so its rounding is exact, and it was checked against the worked examples of the requirements before being trusted.

A second, smaller project: MACD Signal API

My technical analysis toolkit, served as an API and tested against pandas and hand calculations. Its test suite found that the crossover detector reported buy and sell signals on rounding noise of about 1e-15, a defect the original command-line tool also had.

Tools

Python, pytest, Postman and Newman, PostgreSQL and SQL, Excel with LibreOffice, Jira, GitHub Actions, FastAPI and SQLModel.