Catching Problems Before They Ship — Testing, QA, and Staging

When you ask for a new feature, the development team sometimes replies: “It’s on staging, please check it,” “I’ll deploy once QA is done,” “it has to pass tests first.” What they mean is that what they built doesn’t go straight to users — there’s a stage in between that it must pass through.

In the last post, I described how teams respond to breakages with hotfixes and rollbacks. But the best outcome is filtering out a problem before users ever encounter it. In this post, I’ll unpack that filter — testing, QA, and staging — without any code.

Testing automatically checks that code runs as intended #

Testing is checking ahead of time that the code you built works as intended. A person clicking through by hand is also testing, but the testing developers talk about usually refers to checks that run automatically.

For example, you write down the input and the expected result in advance: “add two items at 1,000 won each and the total should be 2,000 won.” Then, every time the code changes, these checks all run automatically at once and quickly tell you whether anything has gone wrong.

Automated tests shine especially when checking whether existing features broke. Adding a new feature often breaks something else that was working fine, and the checks written in advance are standing guard, catching that change at once and raising the alarm. A person can’t re-click every screen each time, so these automatic checks become a reliable safety net.

QA checks quality from the user’s side #

If testing is a check at the code level, QA steps back to inspect the finished feature from the user’s side. It stands for quality assurance, and the role dedicated to this work is also called QA.

QA scrutinizes not only whether things run as specified, but also what happens when users behave unexpectedly — pressing a button with a field left empty, hitting back during checkout, or loading on a slow connection, and so on. The person building a feature tends to follow the normal path, but QA deliberately wanders down the wrong ones to surface problems ahead of time. It exists because catching what’s wrong matters just as much as building it well.

Staging is a rehearsal stage built just like production #

A question comes up here: where exactly do these checks happen? If you test on the same place real users use, mistakes can go straight to users. So you keep a separate space built just like the production environment, and this is staging.

Staging is an environment almost identical to the real service, but users don’t come in — a rehearsal stage. You put a newly built feature here first and give it a final check under conditions just like the real thing. Planners and designers usually review the result on this staging too. Once it’s confirmed problem-free here, only then do you send it out to the production environment that users use. “Please check it on staging” means looking at the result first on this rehearsal stage, before it goes out to users.

Together, they reduce accidents in front of users #

The three stages are filters placed in turn before reaching users. Automated tests filter mismatches at the code level, QA surfaces gaps from the user’s side, and all those checks happen on a staging built just like production. The better you set up this filter, the less users run into bugs, and the less you have to scramble with hotfixes and rollbacks. The time spent filtering ahead of time is what prevents later accidents.

Why this makes work easier for non-developers #

• You know which stage “please check it” refers to. Knowing that a review request on staging belongs to the pre-release stage makes it clear what to inspect and with what eye.
• You build review time into the schedule. Building the time for testing and QA into the schedule reduces skipping verification under last-minute pressure.
• You report bugs well. Writing down which environment you were in and what you did to hit the problem helps QA and the team reproduce the same situation and find the cause fast.

Wrapping up #

Today we looked at the three stages that filter what you built before sending it to users. Testing automatically checks that code runs as intended, QA inspects quality from the user’s side, and staging is the production-like rehearsal stage where those checks happen. The sturdier this filter, the fewer accidents go off in front of users.

If you’re curious about the response after something breaks, read Bugs, Hotfixes, and Rollbacks; if you want to know why even one feature takes time, including the review, read Why Simple-Looking Features Take So Long.