Phase 7 - Testing and Validation
After implementation is complete, the next stage is to ensure that the built software truly conforms to the needs defined across all Sources of Truth. This phase focuses on verification and validation of the system before the software is declared ready for release.
In Chain of Truth, testing is not only done against code. Testing is done against the conformance of the implementation with previously validated artifacts. Thus, the question to be answered is not just:
"Does the code run?"
But:
"Does the built system meet the agreed requirements?"
Goals of the Testing Phase
The main goal of this phase is to ensure that:
- Requirements have been fulfilled.
- User Flows work as designed.
- APIs work according to contract.
- Frontend and backend integration works correctly.
- Error handling works as expected.
- Acceptance criteria are met.
This phase is the final gateway before the system can be considered ready for use.
Basis for Test Case Development
In Chain of Truth, test cases are derived from Sources of Truth, not created based on code alone.
The main sources of testing are:
| Source of Truth | Used For |
|---|---|
| User Flows (SoT #4) | Functional Testing, User Journey Testing, Acceptance Testing |
| UCIC (SoT #7) | API Testing, Contract Testing, Integration Testing |
| HiFi Prototype (SoT #5) | UI Validation and User Acceptance Review |
This approach keeps testing focused on business needs and expected system behavior.
Types of Testing
Functional Testing
Ensures each use case works according to User Flow.
Examples:
- Login succeeds.
- Creating an order succeeds.
- Canceling a transaction succeeds.
API Testing
Ensures endpoints work according to the contract defined in UCIC.
Examples:
- Request payload is valid.
- Response payload matches specification.
- Status code is correct.
- Error response follows contract.
Integration Testing
Ensures frontend and backend can work together without integration issues.
Examples:
- Frontend form sends correct data.
- Backend returns appropriate response.
- Data is stored correctly in the database.
Acceptance Testing
Ensures the system meets the acceptance criteria established in User Flows.
Acceptance Testing is usually performed by stakeholders or the product owner before the system is declared ready for use.
When Testing Fails
One of the important principles in Chain of Truth is:
Fix the artifact that causes the problem, not just the symptoms.
When a test failure is found, the team must determine the source of the problem:
If Implementation is Wrong
Requirement is correct
↓
User Flow is correct
↓
UCIC is correct
↓
Implementation is wrong
Then the code implementation is what gets fixed.
If Source of Truth is Wrong
Requirement is correct
↓
User Flow is incomplete
↓
UCIC becomes wrong
↓
Implementation follows UCIC
Then the User Flow is fixed, then its derivative artifacts are updated and re-validated.
This approach prevents undocumented patching practices and maintains consistency across the entire artifact chain.
Output of Phase 7
If all testing is successfully passed, the output of this phase is:
- Validated System
- Release Candidate
- Test Results
- Validation Records
These artifacts serve as evidence that the implementation has met the requirements defined in the Sources of Truth.
Key Principle of Phase 7
Testing is not merely a bug-finding activity. In Chain of Truth, testing is the process of verifying that the entire artifact chain — from requirements to implementation — remains consistent.
The success of this phase is not only measured by the number of bugs found, but by the team's ability to answer the question:
Does the built system truly realize the user needs as defined in the Chain of Truth?
If the answer is yes, then the implementation result can be promoted to a Release Candidate and is ready to enter the deployment or release process.