Symphony Apps Development logo — teal interlocking S monogram beside the studio wordmark
All writing

Testing the part of the app nobody demos

Settings screens, permission edge cases and empty states get the least attention and cause a disproportionate share of support tickets.

Category
Quality
Reading time
5 min
Published
07 May 2026
Topics
Testing, Quality, Product

Every demo shows the happy path through the main feature. Every support queue is full of tickets about the screens that were never in a demo.

The pattern, once you look for it

Across several projects we support, the tickets cluster in the same places: what happens when a list is empty for the first time, what a user with a downgraded permission level sees, what the settings screen does when a required field was never set. None of these are exotic. All of them are easy to skip when a sprint is under time pressure, because they do not demonstrate anything.

Why they get skipped

They are unglamorous to build and unglamorous to test. A stakeholder does not ask to see the empty state in a review. An engineer under deadline pressure ships the version that works when data exists and leaves a comment to handle the empty case later. Later often means "when a user reports it".

What we changed

  • Empty, error and permission-denied states are acceptance criteria, written into the ticket alongside the happy path, not assumed.
  • A short pass at the end of each sprint specifically exercises these states across everything shipped that sprint, separate from the main testing pass.
  • New user accounts and downgraded accounts are part of the standard test data set, not something a tester has to remember to create.
The screens nobody demos are the ones a real user hits first. A new account is, by definition, all empty states.

The cost of getting this wrong

On one project, three weeks of support tickets traced back to a single missing empty state on a reporting page — the page rendered a blank chart with no explanation when a new account had no data yet, and users assumed the product was broken. The fix was four lines of copy. Finding it took longer than writing it, because nobody had thought to test a brand-new account against that specific screen.

Where the discipline pays fastest

New products, more than mature ones. A mature product has accumulated real users hitting these paths over years, so the gaps get found and fixed one at a time. A new product launches all of them simultaneously, in front of users with the least patience for a confusing blank screen: the ones evaluating whether to keep using it at all.

Tell us what you’re trying to ship

A first call is thirty minutes and costs nothing. Bring the problem, not a spec — working out what to build is the part we are good at.

Or email office@symphonyapps.ro. We reply within one business day, in English or Romanian.