Igor
To collect UAT feedback on a staging site behind a login, choose how reports will be sent, either a widget added to the staging site or a browser extension that adds a Report button to listed addresses, give every tester an account and test data, and check before the round that a report can actually be sent from a logged-in page. Either way, testers log in as they would anyway; the login is not an obstacle to feedback, but it does change which method is easiest.
What the login changes
Staging is usually hidden for good reasons: unreleased work, test data, a client who does not want the public to see it. The login can be the host's basic authentication, a password page, an app login or a VPN. For feedback, three practical problems follow:
- Tools that load a page from outside, such as a screenshot service, cannot see it.
- Testers are logged in as different roles, so a report must say which.
- Anything you add to staging to collect feedback must not ship to production by accident.
The tools below run in the tester's own browser, after they are logged in, so the first problem does not arise.
Widget or extension
SnagRelay offers both, and the report is the same: the element the tester pointed at, console errors, the requests with their bodies, the steps and the environment. The difference is who installs what.
| Widget | Chrome extension | |
|---|---|---|
| What changes | One script tag on the staging site | Nothing on the site |
| Who installs | You, once | Each tester, in Chrome |
| Testers need | Nothing, no account | The extension and an email sign-in |
| Captures from | The first page view | When a matched page finishes loading |
| Screenshots | From the page | From the tab itself |
Option 1: the widget on staging
Add the script tag to the staging build. Anyone who can load the page, after logging in, sees the Report button and can send a report with no account. This suits non-technical testers and clients, because they install nothing, and it captures errors during the first load.
The risk is the one you want to avoid: the tag ending up on production. Load it only when the environment is staging, for example from an environment variable in your build, and add "script absent on production" to your release checklist. If the staging site is a WordPress site, the WordPress plugin does the same job; note that the WordPress snapshot of versions and warnings needs the site to be publicly reachable, so a site behind a firewall or an HTTP login sends the report without it.
Option 2: the Chrome extension
With the Chrome extension, you do not touch the site at all. In the dashboard you turn on the extension for the project and list the addresses it should match, such as staging.shop.com. Each tester installs it from the Chrome Web Store and signs in with their email and a six-digit code. On a matched site, the Report button appears. On every other site, it adds nothing.
This suits two cases well: staging you are not allowed to change, and a client's site before your script goes in. It has limits you should know. It starts capturing when a matched page finishes loading, so an error during the first load can be missed; it needs Chrome; and each tester has to install it. A project uses one install channel, so if you want the widget on production and the extension on staging, make a second project for staging.
Which one to choose
- Testers are clients or business users and the site is yours to change: the widget, loaded on staging only.
- You cannot change the site, or you want a clean staging build: the extension.
- Your testers use Safari or Firefox: the widget, because the extension is Chrome only.
- You need first-load errors: the widget.
Staging checklist
These checks apply whichever tool you pick. They overlap with the UAT checklist; the points below are specific to a protected site.
- One login per tester, and one per role. Put the credentials where testers can find them, and tell them which role to test as. Reports then say who was logged in.
- Test data that looks real. If you copied production data, mask personal details first.
- Integrations in a known state. Payments in sandbox mode, email going to a catch-all or switched off. A tester should not be able to email a real customer.
- Keep staging out of search. Use the host's password protection, and a
noindexheader or meta tag as a second line. A robots.txt file alone does not stop a page being indexed if it is linked from elsewhere. - Send a test report before the round. Log in as a tester, report a fake problem and check that it arrives where you expect, with the element and the steps.
- Tell testers how to report. One sentence: click Report, point at what is wrong, write what you expected.
- Remove the script or the match address at the end. After sign-off, delete the staging tag or take the address off the extension's list.
SnagRelay collects the defects. It does not manage the test cases or the sign-off; those stay in your plan, as described in the UAT test plan template. For briefing the testers, see how to run UAT with testers who are not technical, and for the whole set-up, UAT testing with SnagRelay.
FAQ
Can testers report bugs on a password-protected staging site?
Yes. Both the widget and the extension run in the tester's browser after they have logged in, so the login does not block them. The widget needs the script on the site; the extension needs the address on its match list.
Do testers need accounts to use the widget?
No. Anyone who can load the page can report with the widget. With the extension, each tester signs in with an email and a code.
How do I stop the feedback tool going live on production?
Load the widget script only for the staging environment, and add a check to the release list. With the extension, nothing is on the site, so there is nothing to remove from production.
Does this work with a VPN-only staging site?
Yes for the report itself, because it runs in the browser. Features that fetch your site from outside, such as the WordPress snapshot, do not work on a site that is not publicly reachable.