GitHub Actions
The job sits after your deploy step in the same workflow and waits for every test to finish.
[02] From the pipeline
Staging tested
from the pipeline
One job after deploy installs the CLI and runs ta ci against Staging. Every enabled test runs in a real browser.
One job in the workflow
The test job installs the CLI, signs in with the project key and runs ta ci against Staging after the deploy step.
GitLab, Bitrise, EAS
Anything running Node runs the CLI, so the same job fits GitLab CI, Bitrise and EAS workflows.
One command, one file
ta ci runs the group, waits for every test and writes the outcome to .testerarmy/ci-result.json.
Any environment
Point the job at Staging, a PR Preview or Production; the environment is saved once in project settings.
Test staging from the pipeline you already have
The CLI runs your saved tests and writes one result file the job can read.
[03] Results +
Results where your team already looks
Every CI run lands in the Results table with its status, duration and environment. Failures reach Slack or Discord with a link to the run.
Failed runs stand out
A failed test keeps its row in Results with the step it stopped on and the recording.
One Results table
Every CI run lands in Results with its status, duration and environment.
Check on the commit
With the GitHub App connected, the run also posts a check on the commit it tested.
Step by step
Open any run to see each step the agent took and where a failed one stopped.
Slack on failure
When a pipeline run fails, a summary with a link to each run reaches Slack or Discord.
[04] Explore the platform +
Run at every step of shipping
The same tests run on every pull request, from your CI job, on a schedule against Production, or by hand. Every run lands in one Results table.
Web apps in a real browserWeb testingiOS and Android from a buildMobile app testingReact Native on both platformsReact NativeExpo builds in your EAS workflowExpoWordPress sites before every updateWordPressCheckout tested like a shopperEcommerceOne CI job after deployCI/CD testingCoding agents over one MCP endpointCoding agents
[05] Proof
Novu runs the saved suite
on staging after every merge
~30%faster release cycles
I can see from the recordings that the agent sometimes takes a different path if the UI has changed, or there is a new pop-up. The test can adapt to it, and we're not seeing those types of flakiness.
Dima Grossman
Co-founder and CTO, Novu
Read how Novu moved from an outsourced QA service to tests on every pull request.
Dima Grossman's own account of Novu's staging smoke tests, from the interview of 2026-08-26. The release-speed figure is his estimate.
FAQ
Frequently asked questions
What is CI/CD testing with TesterArmy?
Your pipeline triggers saved tests after deployment. TesterArmy runs them in the cloud against the selected environment, and the CLI waits for the results. Runs also appear in the dashboard with steps, screenshots and recordings.
Does it work with GitLab CI?
Yes. GitLab CI can trigger saved tests through the CLI, API or a signed group webhook after deployment. Results stay in TesterArmy; there is no native GitLab repository connection or merge request reporting.
Does it work with Jenkins, Buildkite or CircleCI?
A pipeline that can run the Node.js CLI or make an HTTP request can trigger tests. Run the test job after deployment and pass the saved environment or reachable deployment URL.
What does the pipeline need to store?
Store your TesterArmy API key as a CI secret, and configure the project, test group and target environment. A signed group webhook can be used instead; its URL is also a secret. Keep credentials out of source control.
Should we test staging or production?
Use staging for release checks and flows that change data. Production can run a separate set of safe checks with a dedicated Test Account. Saved environments let the same tests use different URLs and credentials.
Can it fail the pipeline?
Yes. The ta ci command waits for results and exits unsuccessfully if a run fails, is blocked, is cancelled or times out. A webhook response only confirms that the runs were queued; poll results if the pipeline needs a final verdict.
Does it work for iOS and Android builds?
Yes. Upload a supported iOS simulator or Android build and run its saved mobile tests from your pipeline. TesterArmy manages the hosted simulators and emulators. See the mobile integration documentation for build requirements.
How is this different from Pull Request Testing?
CI testing runs from a job that you add to your pipeline. Pull Request Testing can start automatically when a connected preview deployment is ready and report directly on the pull request. Both produce runs in the same Results table.
