ChaosQA · Guides

How to test a promo code field

Updated October 30, 2026

A promo code field feeds both the input handling on the page and the pricing on the server, and most of its bugs sit where one hands the code to the other. The checks below go roughly from the cheapest to the ones people skip.

Start from the rule, not the field

Before typing anything, write down what the requirement actually promises. A typical one reads: "Code SAVE10 gives 10% off the tickets. Codes are not case-sensitive." That sentence already gives you four questions: what the discount applies to (tickets only, or fees too), what happens with another discount, what "not case-sensitive" covers, and what an unknown code should do. If the requirement does not answer one of these, that gap is worth raising before any testing.

Letter case and spaces

InputExpected if codes are not case-sensitive
SAVE10Accepted, 10% off
save10, Save10Accepted, same discount
SAVE10 (trailing space)Accepted, or rejected with a clear message. Never half-accepted.
SAVE10 (leading space)Same answer as the trailing space
SAVE 10Rejected: a different string
SAVE1, SAVE100Rejected: a prefix or a longer code must not match

Trailing spaces are the interesting row. They arrive for free when someone copies a code from an email. A common bug is that one part of the system trims the code and another does not: the page shows the discount, but the order goes through at full price. The opposite also happens, where the page rejects the code and the server would have accepted it.

Type it, paste it, autofill it

Many fields run code on every key press: upper-casing, stripping characters, limiting length. That code only runs when someone types. If you only ever paste the code, or a test tool sets the field's value directly, you will never see what it does. Type the code by hand at least once, slowly, and watch the field. A length limit set one character too short, for example, turns SAVE10 into SAVE1 while you type, and pasting would hide it.

Check the reverse too: paste a code with lowercase letters and see whether the field corrects it the same way it corrects typing.

Discounts that meet each other

As soon as there is a second discount (student, member, a sale price), you need the rule for combining them. Write the expected numbers down before you run the case. With a ₪100 basket, a 10% code and a 20% student discount:

RuleExpected total
Only the larger discount applies₪80.00
Discounts add up₪70.00
Discounts apply one after another₪72.00

All three rules exist in real shops. The bug is when the form follows a different one from the requirement, and it is easy to miss if you only check that "some discount" was applied.

Also check what the percentage applies to. If the code is "10% off the tickets" and there is a fixed service fee, the fee should not shrink.

What you see versus what you pay

The total on screen and the amount charged are often computed in different places. After applying a code, place the order and compare the confirmed amount with the total you were shown. Then repeat with a twist: calculate the total, change the code (or remove it), and place the order without recalculating. Which total was charged? Either answer can be defended, but the page should not show one number and charge another.

Unknown, expired and reused codes

Codes nobody told you about

Sometimes a code works that is not in any requirement: an old campaign, a test code left in place, a code mentioned only in a source comment. If you find one, report it. And if a requirement mentions a code you cannot find anywhere on the page, ask where it came from before you treat it as real.

Try it on a live form. The TicketBox practice form has a promo code field, a student discount and a service fee, with bugs planted in each session. You get an instant check of what you found.
Open the practice form

More guides: checkout totals · email fields · all guides