Signed-In Browser Checks Before We Call a Feature Accepted

A feature can pass every automated test, deploy cleanly and still fail the person who tries to use it. A button sits under a sticky footer on a phone. A dialog opens off-screen in dark mode. A permission works in tests but the real account is configured slightly differently. A page loads, but the workflow it supports does not make sense.

That is why our final step before calling a feature accepted is a signed-in check in a real browser, against the deployed platform. Here is how those checks work.

A dedicated quality-assurance account

Browser checks use a dedicated quality-assurance account, not the personal accounts of our team members. That keeps checks repeatable, keeps personal accounts out of test activity and makes it clear in any record which actions were part of quality checks.

Before any check that could change something, we confirm exactly which account, which organization and which website the browser is working in. In a platform with many organizations, checking the wrong one is a real risk.

What we check

A typical acceptance check covers:

• The changed pages and dialogs, opened and used as a person would
• Desktop and phone sizes
• Light and dark modes for admin screens
• Keyboard use for the main actions
• Save and reload, to confirm changes persist
• The real outcome, such as a page published or a setting applied

Screenshots are taken along the way and kept with the work's handoff notes.

Read-only by default

Many checks can be done without changing anything: opening pages, reading settings, opening and cancelling dialogs. When a check needs to change something, we use test records and reversible actions, and we undo changes afterward. Some actions are never part of routine checks at all, such as real purchases, sending messages to real people or activating paid services. Those require their own explicit approval.

Separate columns of evidence

We record browser acceptance separately from other evidence. A feature's status might read: source complete, pipeline passed, release verified, browser checked on desktop and phone, provider not yet tested, financial acceptance not applicable. Each column is a different question with a different answer, and mixing them leads to overconfident claims. You can read more about that habit in handoff notes.

Credentials stay out of the process

Signing in is handled carefully. Assistants and tools do not type, read, print or store passwords or session data. Existing signed-in sessions are reused where appropriate, and when a fresh sign-in is needed, a person completes it. Screenshots that might show sensitive data are not shared, and any secret that appears accidentally is treated as exposed and replaced.

Using a separate browser on purpose

We run these checks in a dedicated browser set aside for this work, separate from team members' personal browsing. That keeps test sessions, saved permissions and extensions predictable, and keeps personal accounts and data away from quality checks. Before acting, the person or assistant running the check confirms which account is signed in and which organization and website are in view, because a check run in the wrong place proves nothing and can cause harm.

Checks are part of the change, not an extra

Browser acceptance is planned as part of the work, not added if time allows. When we scope a feature, we decide which pages, sizes and modes need checking and what a passing result looks like. That plan is written into the handoff before the work begins, so acceptance is never an afterthought. You can read more about deciding what to check in testing what matters most.

When the check fails

A failed acceptance check is valuable information. We record what failed, fix it through the normal pipeline and check again. The feature is not described as accepted until the check passes, even if every automated test was green. Being honest about that distinction protects customers from features that only worked on paper.

Checks for websites, not just admin screens

The same approach applies to public websites built on our platform. After a site is published or rebuilt, we check its key pages at desktop and phone sizes, its menus and forms, and any old links that should redirect. For this website, those checks are part of the release plan for the pages and articles you are reading.

Frequently asked questions

What is acceptance testing?

Acceptance testing confirms that a feature works for a real user in realistic conditions, usually after automated tests and deployment have passed.

Why use a separate test account?

A dedicated account keeps checks repeatable, keeps personal accounts out of test activity and makes test actions easy to identify.

Do browser checks change real data?

Most checks are read-only. When a change is needed, test records and reversible actions are used, and real purchases or messages require separate approval.