Testing standards
What Renvric tests, at which level and for what purpose: unit, integration, end-to-end, performance, security and user acceptance testing, plus the exit criteria that decide when software is ready. Test depth is proportionate to risk and written down before build starts.
Start your project
Testing is evidence, not ceremony
The purpose of testing is to give the people who approve a release honest evidence about how the software behaves. A thousand tests that check trivial getters say little; ten that exercise the money-moving path say a great deal.
Renvric therefore starts from the risks that matter to the business and works outwards to the test plan.
The levels, and what each is for
Unit tests
Fast checks of individual functions and rules, written with the code and run on every change.
Integration tests
Verify that components, databases and external services work together, including how they fail.
End-to-end tests
Drive the system as a user would through a small number of critical journeys, such as sign-up or checkout.
Performance tests
Measure behaviour under expected and peak load, and identify the first component to give way.
Security tests
Automated scans and targeted manual checks for common weakness classes.
Acceptance tests
Client-run checks against the agreed criteria before sign-off.
A balanced suite
Teams often draw a pyramid: many quick unit tests, fewer integration tests, very few end-to-end tests. End-to-end tests are valuable but slow and brittle, so using them for everything leads to a suite nobody trusts. Renvric aims to push checks as low in the pyramid as they can meaningfully go.
Test data and environments
- Test data is synthetic or masked, as described in the data protection commitments.
- Environments are built from the same automated definitions as production, which reduces the surprise of differences.
- External services are replaced by controlled stand-ins in routine runs, with periodic checks against the real ones.
- Tests create their own data and clean it up, so they can run in any order.
Share the outcome you need and Renvric will recommend the smallest useful next step.
Exit criteria
Before a release, the plan states what must be true: all critical journeys pass, no open defects above an agreed severity, performance within the agreed thresholds, security findings triaged and accepted or fixed. If a criterion is waived, the person waiving it and the reason are recorded.
- Pass rate of the automated suite on the release candidate.
- Status of defects by severity.
- Results of performance and security checks where in scope.
- Client acceptance recorded in writing.
What testing cannot do
Testing shows the presence of defects, never their absence. Unusual combinations of user behaviour, data and timing will eventually appear in production. That is why monitoring, quick rollback and a sound defect process belong alongside testing.
Flaky tests and maintenance
A test that fails at random teaches the team to ignore failures. Renvric treats flaky tests as defects in their own right: quarantine them, fix the cause and do not let a red build become normal.
Related areas to explore: AI Integration Services and Artificial Intelligence Development.
Useful next steps: how Renvric works, our engagement models and contact the team.
Common questions
Who is it for?
Quality assurance leads, programme managers, auditors and procurement reviewers who want to know how a supplier decides software is fit to release. Product owners will find it useful when planning their own time for acceptance testing.
What information or evidence is required?
Share the critical user journeys, performance expectations, regulatory test requirements and any existing test tooling. Renvric can provide a sample test strategy, an exit criteria template and an example of how results are reported.
What happens next?
A test strategy is agreed during planning and refined as designs settle. Automated tests accumulate from the first sprint, and results are shared at every review so the client sees the trend, not just the final pass.
Who can answer a related question?
Write to info@renvric.com with testing standards in the subject line. A quality or technical lead will reply to practical questions, and commercial questions on test effort will be handled by your engagement contact.
Will Renvric test on real devices and browsers?
It depends on the audience. For consumer products we typically agree a supported device and browser list based on your analytics, then test the critical journeys on real hardware where emulators may mislead. For internal tools a narrower list is often enough.
More from the Trust Centre
If you operate under a test policy or need particular evidence for an auditor, tell us what it requires. We can show how the plan would produce it.