Repository navigation
Validation
fouad elian edited this page Sep 28, 2026
·
34 revisions
This page documents how RoamView’s software specifications will be verified through measurable, repeatable tests, preferably before final deployment.
For each specification, the test procedure defines:
Setup and tools: The environment and equipment needed.
Steps: Instructions for executing the test.
Measurements: The quantities, units and precision used.
Pass/fail criteria: The results required to satisfy the specification.
Risks and intermediate tests: Missing information, testing limitations and methods for testing before full integration.
Each test references its corresponding specification in the Software Requirement Specification. Any changes to a specification or its verification method must be reflected in the Requirement–Specification Tracing table.
| Specification ID | Test ID | Verification |
|---|---|---|
| SP-4.1.1 | VT-4.1.1 | Live Walkthrough Latency |
| SP-4.1.2 | VT-4.1.2 | Live Walkthrough Robot Access Authorization |
| SP-4.1.3 | VT-4.1.3 | Live Walkthrough Control Lease |
| SP-4.1.4 | VT-4.1.4 | Live Walkthrough Requests Limitation |
| SP-4.1.5 | VT-4.1.5 | Live Walkthrough Minimum Stream Resolution |
| SP-4.1.6 | VT-4.1.6 | IoT Gateway Video Relay Capacity |
| SP-4.1.7 | VT-4.1.7 | Streaming Service Transcoding Capacity |
| SP-4.1.8 | VT-4.1.8 | API Gateway Relay Capacity |
| SP-4.1.9 | VT-4.1.9 | RoamView App Playback Capacity |
Test ID: VT-4.1.1
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | Measure the time between sending a control command from the App and registration of that command at the robot-side receiver. |
| Setup and tools | Running App, API Gateway, IoT Gateway and robot-side receiver or mock. Use an automated command sender, unique command IDs and timestamped logs. Configure the network conditions specified in SP-4.1.1. | |
| Procedure | Steps | 1. Establish an authorized session and start a mock tour. 2. Record the network configuration and confirm the receiver is ready. 3. Send 30 commands at a permitted rate, each with a unique ID. 4. Record each command’s send time and matching receiver-registration time. 5. Calculate the delay for each command and report the mean, maximum and any missing commands. 6. Repeat under each specified network condition. |
| Confirmation | Quantity / units / precision | Command-registration latency: ms. Network bandwidth: Mbps. Record timestamp resolution and clock-synchronization uncertainty; both must support comparison against the specified latency limit. |
| Pass/fail criteria | All commands are registered within the latency limit defined in SP-4.1.1. Missing commands count as failures. The numerical limit remains TBD in the specification. | |
| Feasibility | Risks / required clarification | Finalize the latency formula and its input values. A gateway response alone does not prove robot registration. Timestamps from different devices require synchronized clocks with measured uncertainty. |
| Intermediate / integrated test | Use an instrumented mock receiver before robot integration. Repeat with the real robot receiver and representative network conditions. |
Test ID: VT-4.1.2
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | Verify that commands containing invalid session tokens are rejected and never forwarded to the robot. |
| Setup and tools | API Gateway, IoT Gateway and mock robot with received-command logs; API request script or tool; valid, expired and revoked test tokens. Assign a unique ID to each command. | |
| Procedure | Steps | 1. Acquire control and send 10 valid commands; confirm acceptance and delivery. 2. Send 10 commands without a token. 3. Send 10 commands with malformed tokens. 4. Send 10 commands with expired tokens. 5. Release a session’s control and send 10 commands using its revoked token. 6. Send 10 commands with a valid token altered by one byte without re-signing. 7. Check responses and gateway/receiver logs using command IDs; confirm no invalid command reached the robot. |
| Confirmation | Quantity / units / precision | Exact counts of rejected and delivered commands. Rejection rate = rejected invalid commands ÷ 50 × 100%. With 50 requests, results change in increments of 2 percentage points. |
| Pass/fail criteria | All 50 invalid commands rejected; zero invalid commands forwarded; all 10 valid commands accepted and delivered. Otherwise, fail. | |
| Feasibility | Risks / required clarification | Correct the specification’s ±1% precision wording. These cases verify the listed token categories; a separate test using a valid session that does not hold control is needed to confirm the single-controller requirement. |
| Intermediate / integrated test | Execute against a mock robot before hardware integration. Repeat with the real receiver using safely observable commands. |
Test ID: VT-4.1.3
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | Verify that control is released after 180 s of inactivity or after 360 s total, regardless of activity. |
| Setup and tools | Lease-management service, two test sessions, mock robot, automated command sender and timestamped server logs. | |
| Procedure | Steps | 1. Acquire control and record the acquisition time. 2. Send one valid command, record its acceptance time, then send nothing further. Record the actual release time. 3. Confirm the previous holder cannot send commands after release and another session can acquire control. 4. Acquire a new lease and send valid commands every 30 s. Record when control is released relative to acquisition. 5. Repeat both cases three times. 6. In a separate idle test, send an invalid command and confirm it does not reset the inactivity timer. |
| Confirmation | Quantity / units / precision | Idle duration = release time − last valid-command time, in s. Total lease duration = release time − acquisition time, in s. Record server timer resolution. |
| Pass/fail criteria | Control is released at the 180 s idle and 360 s total boundaries within the agreed timing tolerance. Commands from the former holder are rejected afterward. Timing tolerance remains TBD. | |
| Feasibility | Risks / required clarification | Clarify whether the card’s ±30 s refers to measurement precision or acceptable timing variation. Checking only after 300 s does not verify release at the 180 s boundary. |
| Intermediate / integrated test | Verify timer logic using a controlled clock, then execute the real-duration tests with the service. Repeat expiry and command rejection checks with the integrated robot. |
Test ID: VT-4.1.4
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | |
| Setup and tools | ||
| Procedure | Steps | |
| Confirmation | Quantity / units / precision | |
| Pass/fail criteria | ||
| Feasibility | Risks / required clarification | |
| Intermediate / integrated test |
Test ID: VT-4.1.5
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | |
| Setup and tools | ||
| Procedure | Steps | |
| Confirmation | Quantity / units / precision | |
| Pass/fail criteria | ||
| Feasibility | Risks / required clarification | |
| Intermediate / integrated test |
Test ID: VT-4.1.6
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | |
| Setup and tools | ||
| Procedure | Steps | |
| Confirmation | Quantity / units / precision | |
| Pass/fail criteria | ||
| Feasibility | Risks / required clarification | |
| Intermediate / integrated test |
Test ID: VT-4.1.7
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | |
| Setup and tools | ||
| Procedure | Steps | |
| Confirmation | Quantity / units / precision | |
| Pass/fail criteria | ||
| Feasibility | Risks / required clarification | |
| Intermediate / integrated test |
Test ID: VT-4.1.8
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | |
| Setup and tools | ||
| Procedure | Steps | |
| Confirmation | Quantity / units / precision | |
| Pass/fail criteria | ||
| Feasibility | Risks / required clarification | |
| Intermediate / integrated test |
Test ID: VT-4.1.9
Date last modified: Sept 27, 2026
| Section | Field | Description |
|---|---|---|
| Test definition | Objective | |
| Setup and tools | ||
| Procedure | Steps | |
| Confirmation | Quantity / units / precision | |
| Pass/fail criteria | ||
| Feasibility | Risks / required clarification | |
| Intermediate / integrated test |
RoamView Wiki
- Home
- 1. Introduction
- 2. Project Proposal
- 3. Backlog
- 4. Sprint Summaries
- 5. Architecture
- 6. UI Design
- 7. Testing
- 8. Defect Tracking
- 9. Quality Measurements
- 10. Ethics & Accountability