01
Technical independence
Example: Testers who did not design or write the software
Approach: We write tests from the contract and requirements, not from the vendor's own test cases
Independent Testing
Independent software testing and IV&V
When the team that built the software also tests it, the results answer to the people who want it shipped. Agnotic Technologies tests software we did not build, from the contract and requirements, and reports to you.
Reports to the buyerContract-based testsAgreed severity rulesAudit-ready records
Trusted by global innovators
Independent testing
What is independent software testing?
Independent software testing is testing done by a team that did not build the software and does not report to the people who did, so its findings go straight to the buyer or owner. Agnotic Technologies runs independent testing and IV&V for clients accepting a vendor's release, preparing regulated software or wanting a second opinion before launch.
IV&V stands for independent verification and validation: checking that the software was built right against its specification, and that it is the right software for its intended use.
This page is about who tests and who receives the results. Test design, security testing and performance testing are separate topics; we bring them into an independent engagement as needed.
Independence
What makes a test team independent?
Independence has three parts. A team can have one without the others, so we agree which ones your situation needs.
02
Managerial independence
Example: Findings reported outside the development team's management
Approach: We report to you; the vendor sees findings through you or a channel you agree
03
Financial independence
Example: The tester is not paid from the build budget or by the vendor
Approach: You contract us separately from the build contract
Decision table
How much independence does your situation need?
Pick the row closest to your situation. It sets the independence we agree and the deliverable you receive.
| Situation | Independence needed | What you get |
|---|---|---|
| Accepting a vendor's release before you pay | Technical and financial; managerial too for larger contracts | An acceptance test report against the contract's requirements, with open defects by severity |
| Regulated software, such as medical device software | Technical and managerial, as your quality system defines | Test protocols, executed records and a traceability matrix your regulatory team can use |
| Second opinion before a public launch | Technical | Risk-based results on the main journeys and a list of release blockers |
| A quality dispute with a vendor | Technical, managerial and financial | Reproducible defect evidence tied to the contract, written for non-engineers |
| Security or privacy assessment for a buyer's review | Technical and managerial | Results the buyer can rely on because the developer did not assess its own work |
| Ongoing checks on an outsourced product | Technical and financial | A regression suite you own, run on each vendor release, with a short report each time |
Engagement
How does an independent test engagement run beside your vendor?
Independent does not mean adversarial. The vendor keeps working while we test.
1.
Agree the rules
Scope, severity definitions, who sees findings and how disputes are settled, agreed with you and shared with the vendor.
Rules2.
Build the test basis
Tests derived from the contract and requirements, plus a review of the vendor's own test evidence for gaps.
Basis3.
Test each release
Builds tested as the vendor delivers them, without holding up their sprints; defects logged with evidence in a shared tracker.
Test4.
Report to you
A plain report per release: what passed, what failed, what was not tested, and whether we would accept it.
ReportWhat we need
What we need to start
The documents, access and agreements an independent engagement depends on.
Test basis
- The contract or statement of work
- Requirements and acceptance criteria
- Design documents, if any
- Known defects and change log
Access
- Read access to the code repository
- A test environment that matches production
- Test accounts for each role
- Release notes for each build
Builder's evidence
- Their test plan and results
- Unit and integration test reports
- Build and deployment records
- Open defect list
Agreements
- Who receives findings
- How defects are disputed
- Severity definitions
- Confidentiality and data handling
Reporting
How are findings reported and disputed?
Clear rules, agreed before testing, keep the conversation about the software rather than about each other.
- Every defect has steps, expected and actual results, and evidence such as logs or screen recordings
- Severity follows definitions agreed before testing, so it is not argued defect by defect
- The vendor can respond to each finding; disagreements reach you with both views written down
- Retests are recorded against the original defect, so the history stays complete
- Each release report says plainly whether we would accept the release, and why
- We do not fix the vendor's code during an independent engagement, so our results stay independent
Failure points
What goes wrong when the builder tests its own work?
Patterns we find when we review a vendor's test evidence.
Challenge
Tests are written from the code, so they confirm what was built, not what was asked for.
Agnotic approach
We write tests from the contract and requirements, so gaps between the two show up.
Challenge
Hard requirements were quietly dropped.
Agnotic approach
Our traceability matrix maps every contracted requirement to a test, including the ones nobody built.
Challenge
Defects are closed as working as designed.
Agnotic approach
Disputed defects go to you with both views and the requirement text side by side.
Challenge
Release pressure skips the slow tests.
Agnotic approach
Our test schedule is agreed with you, not set by the delivery deadline.
Challenge
Evidence is a pass count with no detail.
Agnotic approach
Every executed test keeps its steps, data and result, so it can be audited later.
Who it is for
Who hires an independent tester?
Buyers and owners who need results they can rely on.
Companies buying custom software
Acceptance testing before milestone payments to a development vendor.
Medical device and regulated software teams
Testing under your quality system, with records for your regulatory file.
Investors and acquirers
A test-based view of whether a product works as described, alongside code review.
Public sector buyers
Acceptance evidence against contract requirements for delivered systems.
Startups before launch
A second opinion on the main journeys from people who did not build them.
Teams with an outsourced product
Release-by-release checks on a product a vendor maintains.
Facts and sources
Facts behind independent software testing
Standards and rules that describe independence and acceptance, each linked to its primary source.
NIST SP 800-53 control CA-2(1) calls for independent assessors who are free of conflicts of interest with the system's development and do not assess their own work.
Source: NIST SP 800-53 Rev. 5, CA-2(1) Independent AssessorsNIST SP 800-53 control SA-11 requires the developer of a system to perform unit, integration, system or regression testing and to produce evidence of the test plan's execution and results.
Source: NIST SP 800-53 Rev. 5, SA-11 Developer Testing and EvaluationIn US federal contracts, acceptance is the government's acknowledgment that supplies or services conform with the contract's quality and quantity requirements.
Source: 48 CFR 46.501 (eCFR)IEC 62304:2006+A1:2015 defines the life cycle requirements for medical device software, covering both its development and its maintenance.
Source: IEC 62304:2006+AMD1:2015 (IEC Webstore)
References
References behind our independent testing
The controls and standards behind the decision table.
NIST SP 800-53 CA-2(1)NIST SP 800-53 SA-11FAR 46.501IEC 62304Traceability matrixSeverity definitions
Scope and cost
What drives the cost of independent software testing?
We do not publish prices. These decide the size of an engagement.
Size of the requirement set
How many contracted requirements or user stories need tests.
Independence level
Technical only, or managerial and financial too, with the reporting that brings.
Release rhythm
One acceptance test, or testing every vendor release.
Evidence level
A short report, or full protocols and executed records for a regulated file.
Platforms and environments
Web, mobile and integrations, and whether a production-like test environment exists.
Specialist testing
Security or performance testing added to the engagement.
Frequently Asked Questions
QA is usually part of the delivery team and helps it ship good software. IV&V is done by a separate team that reports to the buyer or owner, so its job is to give an independent answer on whether the software meets its requirements.
We do not publish prices. Cost depends on the requirement set, the independence level, how many releases we test, the evidence you need and any security or performance testing. You get a written proposal after the scoping call.
It should not. We test builds as they arrive and log defects in a shared tracker, so the vendor's sprints continue. The rules for findings and disputes are agreed up front to avoid arguments later.
Yes, under your quality system: we write and execute test protocols and keep the records and traceability your regulatory team needs. Regulatory strategy and submissions stay with your regulatory team.
Only on software we did not build. We never act as the independent tester on our own work, and we do not take on the build contract for a product while testing it independently.
Not always. Acceptance testing can work from the running system alone. Read access to the code helps with deeper verification, such as checking that error handling and logging match the requirements.
AI tools may help us read long specifications and draft test ideas, but every test is written and checked by a test engineer against the contract text. Findings are never generated by AI.