← back to section

A team is building a food-delivery app, and this week's task is promo codes: a customer types SUMMER25 in the cart and sees a discount. You can wait until the task is "done" and click through the screen on the last day. Or you can ask, before the code exists, what happens to an expired code, set up five codes in the test database in advance, and catch a double discount from a double click on the first build.

That difference is the role: a tester finds out how the system actually behaves and brings the team a picture — what works, what is broken, what we risk by shipping as is. The role is usually called QA engineer, or just QA.

sprint task: promo codes in a delivery app Requirement Code Check Release asks before code:what if expired?cheapest bug to fix prepares checksand test data found: discountapplied twicethe bug goes back into work risk picture:what and how bad the product owner calls the release

A tester joins at every step, not at the end: they show what is broken and what it would cost. The call — fix now or ship now — belongs to the team.

A tester's day: one task from question to release

Before the code. You ask what the description does not answer: what happens with an expired code, can two codes be applied at once, does the discount stack with a campaign. An answer of "hmm, good question" is a hole in the requirements, caught while the fix still costs one conversation (how to ask). While the code is written you put future checks into a checklist or test cases and ask for five promo codes with different conditions: on the day the build lands nobody will create them quickly.

The build arrives. Three everyday words: a build is a working version of the app tagged with a number; a test environment is a separate copy with its own database, where you can break anything; production is the copy real people use, with real money in it. Builds go to the test environment first and to production only after the checks. On two clicks in a row the cart takes 500 off instead of 250. You do not write "promo codes are broken" in the chat: first check whether it repeats every time and whether it needs a fast click, then file a bug report with steps, expected and actual result, a screenshot and the build number.

Re-check and release. On the new build you repeat the same steps, then walk a plain order and an order with a campaign: the fix could have touched something next to it — that is regression, checking that what used to work still works. Before the release you say out loud what was checked, what was not and why: delivery promo codes were never checked, there are none in the test environment. An unchecked area the team knows about is a risk; one only you know about is a mine.

Who is around you and what they need from you

  • The analyst and the product owner — inconvenient questions before the work starts, a picture before the release, the answer to "is this a bug or is it intended".
  • The developers — a bug that reproduces on the first try; they also answer "where do I see this": test accounts, which table holds the data.
  • The designer — the answer to "is this a defect or just ugly": "the mockup looks different" is grounds for a bug.
  • Support — knows what people complain about most and what broke last time: a free source of ideas for checks.
  • Your team lead or a senior tester — priorities and the answer to "I cannot check everything, what do I drop": staying quiet about missing time is worse than saying so.

There may be nobody around at all: in a small product the tester is often alone, and the decision "what we are not going to check" is effectively theirs; a large company has a department with shared conventions and roles such as automation. A newcomer is expected to know the product and to file bugs that do not come back, not to build a process (skills for the start, where to grow).

Why the team needs a separate person for this

Developers do check their own code, but it is not enough, and the reason is not carelessness: "how do I make this work" and "under what conditions does this break" sit badly in one head, and the author follows the very model they built — like proofreading your own writing, where the eye reads what you meant. A fresh person clicks the button twice and pastes a code with a trailing space. Add the conflict of interest with the deadline: a find costs the author another evening and costs you nothing.

Developers check themselves at a different level — with unit tests such as "the discount function returns 750 for an amount of 1000 and a 25% code"; a test like that will never notice that a button fires twice (levels of testing).

What a tester decides, and what they do not

It feels like the tester is the one who "keeps bad things out of production". In fact their output is not the verdict "the release is off", it is a picture:

The discount is applied twice on a fast double click of "Apply". Reproduces in three runs out of five, on any promo code. Affects anyone who clicks nervously — and on a sale day plenty of people do. The cost is a double discount on the order, in real money. No workaround. Not checked: delivery promo codes, there are none in the test environment.

With that picture the team chooses: fix now and ship later; ship now and fix in the next build; ship with a guard — the button locks after the first click. That is a business question, not a testing one: how much a day of delay costs, whether an ad starts tomorrow. The product owner answers it, and your word carries as much weight as your picture is precise.

Next the find is weighed by severity and priority — fix now, "works as designed", or "fix it later" — and moves through statuses in the tracker. "Cannot reproduce" means "there was not enough data": add the build number, the exact code, a screen recording (bug report quality). And a bug that slipped through is examined as a hole in the process, not as someone's fault (root cause analysis).

QA, QC and testing — where the difference shows up

Back to the question you asked before the code: what if someone applies a promo code and then removes the item that pushed the cart over the minimum amount? The analyst added the requirement, the developer handled the case — you tested nothing, there was no code, but one bug was never born. That is QA (Quality Assurance): the work of making sure problems do not appear.

And when you take a finished build and compare how the system works with how it should work, that is testing, an activity inside the broader QC (Quality Control). QC looks at the finished thing, QA works on the process. In practice almost everyone is called "QA", and that is fine; the difference explains why you are invited where there is nothing to check yet.

In short

  • A tester brings the team a picture: what is broken, how often it reproduces, who it affects, what is left unchecked.
  • The work starts with questions about the requirements, not with a build: there a bug costs a conversation, in production a rolled-back release.
  • The author of the code checks against the model they built and has a conflict of interest with the deadline.
  • "Fix now or ship now" belongs to the product owner; your word carries as much weight as your picture is precise.
  • "Cannot reproduce" is cured with data; a bug that slipped through is a hole in the process, not a fault.
  • QA is about problems never appearing; QC and testing are about checking what is already built.