HTTP Basic Auth
The hosting password prompt is stored in Site Protection and sent before the staging site loads.
[02] Staging first
Every update tested
on staging first
Save the staging URL as an environment, store the hosting password once, and the same tests click through both sites.
Staging first, then the live site
The same saved tests run against the staging copy after an update, then against Production, and every run lands in Results.
Staging and live
Save the staging URL as an environment next to Production and run the same tests on either.
Forms and checkout
Contact forms, logins and WooCommerce checkout are described in plain language, the way a visitor would use them.
WordPress, WooCommerce, Elementor
Agents work from the rendered page, so any theme, builder or plugin a visitor can use is testable.
Test one client site after its next update
Add the staging URL and the Basic Auth prompt, then run the first test.
[03] Production monitoring +
Client sites on a schedule
Each client site is its own project with its own Production Monitoring schedule, so weekly or daily runs on Production report to that client's Slack channel and its Results table.
Weekly checks
Pick hourly, daily, weekly or a custom cron under Production Monitoring and the group runs on Production on the client's clock.
Results per site
Every scheduled run lands in that client's Results table with status, duration and the environment it ran on.
Client-ready summaries
Each failed run posts to Slack with the test name, the step that broke and what the agent actually saw.
Editor accounts
Store a WordPress login as a Test Account once and every run signs in with it.
One project per client
Each client site keeps its own tests, logins and run history, so nothing bleeds between accounts.
[04] Proof
Teams that stopped checking
the live site by hand
I used to manually check production after every deploy, just to be safe. With TesterArmy, I leave the office and wait for the Slack message.
Benedict Chan
Co-Founder, Lightsprint
[07] Read next
Three reads for teams that maintain sites
FAQ
Frequently asked questions
Does it work with WooCommerce, Elementor, Divi, and the usual WP stack?
Yes. Agents test the rendered site in a real browser. WooCommerce, Elementor, Divi, Gutenberg, ACF and custom themes work through the same visitor-facing flows, with no test scripts tied to a plugin's implementation.
Can it run after WordPress or plugin auto-updates?
Yes. Trigger your saved test group through a webhook after a core, plugin or theme update. You can also enable Production Monitoring to run the group on a recurring schedule. Test the staging environment before applying an update to the live site.
Can one agency monitor multiple client sites?
Yes. Create a project per client site. Each project keeps its tests, saved accounts, environments and run history separate. Set a Production Monitoring schedule for each client's test group and connect the appropriate Slack channel.
Does TesterArmy need a plugin installed on the site?
No. TesterArmy opens your site in a cloud browser and follows plain-language test steps. Add the site URL and any credentials the tests need; there is no WordPress plugin, SDK or test framework to install.
Can it test contact forms - Contact Form 7, Gravity, WPForms?
Yes. Agents fill in the form, submit it and check the confirmation. For email verification, use the agent's inbox as the recipient so the test can verify that the email arrives as well as checking the page.
What does an alert look like and where does it go?
Connect Slack in Integrations to receive summaries from scheduled or webhook-triggered group runs. A failed test includes its name, the step that broke, what the agent saw and a link to the run, where you can inspect the recording and screenshots.
Can it test the staging site behind the hosting password prompt?
Yes. Save the staging URL as an environment and configure HTTP Basic Auth in Site Protection. TesterArmy sends those credentials before the page loads, so the same saved tests can reach the protected staging copy.
How do agents sign in to wp-admin and member areas?
Save a dedicated WordPress login as a Test Account in the project. Agents use it when the test requires signing in. Keep separate accounts for roles such as Editor and Member, and use Site Protection for any additional hosting password prompt.
