chanora/docs/verification/swe6-software-verification-plan.md

Chanora SWE.6 Software Verification Plan

Document type: Software Verification / Software Qualification Test Plan
Process alignment: ASPICE SWE.6 Software Verification
Version: 0.9.2 Status: Baseline Candidate
Language: English
Product: Chanora
Verification object: Fully integrated Chanora software
Direct source layer: SRS

Repo path: docs/verification/swe6-software-verification-plan.md ---

1. Purpose

This document defines the software verification strategy for Chanora. It verifies that the fully integrated software satisfies the Software Requirements Specification.

SysRS -> SysDes -> SRS -> SAD -> SDD
                 -> SWE.6 Software Verification

SWE.6 verifies against SRS. It does not replace SWE.4 unit verification or SWE.5 software integration verification.

2. Software Verification Strategy

Verification type	Purpose
Functional software tests	Verify integrated software behavior against SRS
Non-functional software tests	Verify performance, accessibility, security, diagnostics, localization, and reliability requirements
Platform software tests	Verify integrated software behavior on target platforms
Regression tests	Confirm changes did not break previously verified software requirements
Release-scope test selection	Select tests according to target release content
Summary reporting	Communicate software verification status

3. Software Verification Measures

SWE6-SV-001: Verify server connection flow.

• Source SRS: SRS-001 through SRS-030
• Verification method: End-to-end software test
• Pass criteria: User can connect to a compatible server with configured connection data.
• Evidence: Software verification result

SWE6-SV-002: Verify channel tree, client list, and server state display.

• Source SRS: SRS-031 through SRS-060
• Verification method: End-to-end software test
• Pass criteria: Channel and client state is displayed and updates after server events.
• Evidence: Software verification result

SWE6-SV-003: Verify voice send and receive.

• Source SRS: SRS-061 through SRS-090
• Verification method: Audio software verification test
• Pass criteria: User can transmit and receive voice under supported conditions.
• Evidence: Software verification result

SWE6-SV-004: Verify push-to-talk, mute, deaf, and voice status.

• Source SRS: SRS-061 through SRS-090, SRS-156
• Verification method: End-to-end software test
• Pass criteria: Voice controls perform expected software behavior and display correct state.
• Evidence: Software verification result

SWE6-SV-005: Verify local storage and secure storage behavior.

• Source SRS: SRS-091 through SRS-110
• Verification method: Software security and persistence test
• Pass criteria: Non-secret data persists through approved storage and secrets use secure storage boundaries.
• Evidence: Software verification result

SWE6-SV-006: Verify diagnostics and redacted export behavior.

• Source SRS: SRS-111 through SRS-124, SRS-177, SRS-178
• Verification method: Software verification test, audit
• Pass criteria: Diagnostic export requires user action and redacts sensitive data while preserving safe Unicode content.
• Evidence: Software verification result, audit record

SWE6-SV-007: Verify deployment-sensitive software behavior.

• Source SRS: SRS-125 through SRS-134
• Verification method: Release build verification
• Pass criteria: Release build metadata, packaging behavior, and platform declarations are consistent with software requirements.
• Evidence: Release verification result

SWE6-SV-008: Verify traceability and documentation controls.

• Source SRS: SRS-135 through SRS-143, SRS-180 through SRS-183
• Verification method: Documentation verification
• Pass criteria: SRS, SAD, and SDD direct-source rules pass validation.
• Evidence: Traceability report

SWE6-SV-009: Verify Material 3 and Chanora Design System behavior.

• Source SRS: SRS-144 through SRS-150
• Verification method: UI software verification, review
• Pass criteria: Integrated app uses Material 3 baseline and Chanora semantic tokens without feature-screen hardcoding.
• Evidence: Software verification result

SWE6-SV-010: Verify adaptive layouts.

• Source SRS: SRS-151 through SRS-156
• Verification method: UI software verification
• Pass criteria: Compact, medium, and expanded layouts preserve connection status and primary voice controls.
• Evidence: Software verification result

SWE6-SV-011: Verify accessibility behavior.

• Source SRS: SRS-157 through SRS-161
• Verification method: Accessibility verification
• Pass criteria: Critical controls expose semantics, non-color-only state cues, focus behavior, and text-scale resilience.
• Evidence: Accessibility verification result

SWE6-SV-012: Verify platform behavior.

• Source SRS: SRS-162 through SRS-164
• Verification method: Platform software verification
• Pass criteria: Insets, safe areas, keyboard, Android back behavior, and iOS platform behavior operate as specified.
• Evidence: Platform verification result

SWE6-SV-013: Verify localization and fallback behavior.

• Source SRS: SRS-165 through SRS-169
• Verification method: Localization software verification
• Pass criteria: Product strings are externalized, English baseline exists, additional locales can be added, and fallback is deterministic.
• Evidence: Localization verification result

SWE6-SV-014: Verify Unicode and server-content behavior.

• Source SRS: SRS-170 through SRS-176
• Verification method: Internationalization software verification
• Pass criteria: Server content is preserved, displayed without translation, UTF-8 is used internally, and locale-aware formatting works.
• Evidence: Internationalization verification result

SWE6-SV-015: Verify software architecture and detailed design traceability controls.

• Source SRS: SRS-180 through SRS-184
• Verification method: Documentation/tooling verification
• Pass criteria: SAD derives from SRS and SDD derives from SAD; initialization sequence is verified.
• Evidence: Traceability validation result

4. Regression Strategy

Regression test selection shall consider:

• changed SRS item
• changed feature
• changed architecture component
• changed detailed design unit
• changed platform behavior
• changed localization or Unicode handling
• changed diagnostics or redaction
• changed audio behavior
• changed protocol adapter behavior

5. Traceability Matrix

SRS Range	SWE.6 Coverage
SRS-001 through SRS-030	SWE6-SV-001
SRS-031 through SRS-060	SWE6-SV-002
SRS-061 through SRS-090	SWE6-SV-003, SWE6-SV-004
SRS-091 through SRS-110	SWE6-SV-005
SRS-111 through SRS-124	SWE6-SV-006
SRS-125 through SRS-134	SWE6-SV-007
SRS-135 through SRS-143	SWE6-SV-008
SRS-144 through SRS-150	SWE6-SV-009
SRS-151 through SRS-156	SWE6-SV-010
SRS-157 through SRS-161	SWE6-SV-011
SRS-162 through SRS-164	SWE6-SV-012
SRS-165 through SRS-169	SWE6-SV-013
SRS-170 through SRS-176	SWE6-SV-014
SRS-177 through SRS-184	SWE6-SV-006, SWE6-SV-015

6. Result Reporting

Software verification results shall be summarized in a software verification summary report including:

• release scope
• selected software verification measures
• skipped measures and rationale
• platform/environment used
• pass/fail status
• nonconformances
• regression scope
• residual risks
• release recommendation

7. Change History

Version	Date	Description
0.1.0	2026-05-14	Initial SWE.6 software verification plan derived from SRS v0.5.

---

8. Platform Decision Software Verification Addendum

SWE6-SV-016: Verify platform baseline, release SDK gates, single connection MVP scope, audio defaults, storage/bridge policy, and diagnostics/crash reporting policy.

• Source SRS: SRS-185 through SRS-194
• Verification method: Software verification, release inspection, security/privacy review
• Pass criteria: Integrated software and release configuration satisfy the accepted product decisions.
• Evidence: Software verification result, release inspection record

SRS Range	SWE.6 Coverage
SRS-185 through SRS-194	SWE6-SV-016

SWE6-SV-017: Verify integrated software behaviour for desktop Push-to-Talk against SRS-195 through SRS-203.

• Source SRS: SRS-195, SRS-196, SRS-197, SRS-198, SRS-199, SRS-200, SRS-201, SRS-202, SRS-203
• Verification method: Software verification test (end-to-end) on Windows, macOS, GNOME-on-Wayland reference hosts
• Pass criteria: PTT trait abstraction is platform-agnostic from the caller's perspective; reported capability level equals live runtime behaviour; Windows ladder degrades correctly when Raw Input is denied; macOS Global ↔ Focused toggles with permission state changes; Linux honours portal availability; mouse-side-button binding works where the backend exposes it; capture_active and transmit_active are independently observable; diagnostic export contains zero raw key data; missed-key-up watchdog clears transmit_active after the configured timeout.
• Evidence: SWE.6 test report

SRS Range	SWE.6 Coverage
SRS-185 through SRS-194	SWE6-SV-016
SRS-195 through SRS-203	SWE6-SV-017

Baseline Candidate 0.9.1 Update

Version	Date	Description
0.9.1	2026-05-14	Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set.

Baseline Candidate 0.9.2 Update

Version	Date	Description
0.9.2	2026-05-14	Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage.

Baseline Candidate 0.9.3 Update

Version	Date	Description
0.9.3	2026-05-15	Added desktop PTT software-verification item SWE6-SV-017 covering end-to-end SRS-195..203 verification across Windows, macOS, and GNOME-on-Wayland Linux reference hosts.

9. Android P0 Software Verification Addendum

SWE6-SV-018: Verify Android voice foreground service satisfies SRS-111.

• Source SRS: SRS-111
• Verification method: Device-level software-qualification test on API 28 floor device + mid-tier + current target (per docs/verification/android-p0-acceptance.md TC-3)
• Pass criteria: While connected to a voice channel the foreground service runs with foregroundServiceType="microphone" (API 30+) and a non-dismissible notification; mic capture and playback continue with the screen off for ≥ 10 minutes without being killed; service stops cleanly on disconnect.
• Evidence: Device test log + screen-recording
• Cross-link (added in 0.9.5): SRS-215 device-matrix expansion is covered by SWE6-SV-030. SWE6-SV-018 remains the single-device baseline; SWE6-SV-030 collects per-SDD-116-row evidence.

SWE6-SV-019: Verify RECORD_AUDIO request timing and listen-only fallback satisfy SRS-209.

• Source SRS: SRS-209
• Source SysRS: SysRS-306
• Verification method: Device-level test (android-p0-acceptance.md TC-2)
• Pass criteria: The mic permission is requested at the user gesture that first needs it (not at app launch); denial drops capture but keeps playback open (listen-only); permanently-denied state opens the system settings deep-link instead of re-prompting; re-grant re-enables capture without process restart.
• Evidence: Device test log

SWE6-SV-020: Verify Android in-call audio mode round-trip satisfies SRS-208.

• Source SRS: SRS-208
• Source SysRS: SysRS-305
• Verification method: Device-level test with dumpsys audio (android-p0-acceptance.md TC-6)
• Pass criteria: Pre-join mode is recorded; during voice session mode is MODE_IN_COMMUNICATION; on leave/disconnect prior mode is restored exactly. No permanent mode lock across multiple sessions. No crash if a Bluetooth headset is connected/disconnected mid-session (P0 minimum).
• Evidence: Device test log + dumpsys traces

SWE6-SV-021: Verify Android back navigation satisfies SRS-163.

• Source SRS: SRS-163
• Verification method: Device-level test (android-p0-acceptance.md TC-11 + TC-12) on API 28, an API ≤ 32 device, and an API 33+ device.
• Pass criteria: Modal-first close; one-pop-per-press; home-route back backgrounds; PTT-active ignores back. Predictive-back animation present on API 33+ and absent on pre-33 with identical end behaviour.
• Evidence: Device test log + screen-recording

SWE6-SV-022: Verify Android minimum API satisfies SRS-187 and DEC-004.

• Source SRS: SRS-187
• Source SysRS: SysRS-288
• Verification method: Manifest inspection + install attempt on API 28 device
• Pass criteria: Merged manifest declares minSdkVersion = 28. Install on API 28 succeeds. Install attempt on API 27 simulator/device is rejected with a clean error.
• Evidence: Manifest dump + install logs

SWE6-SV-023: Verify Android Play target API and AAB packaging satisfy SRS-119 and SRS-188.

• Source SRS: SRS-119, SRS-188
• Verification method: AAB inspection + Play Console upload to Internal Testing (android-p0-acceptance.md TC-13)
• Pass criteria: targetSdkVersion matches the currently-required Play target per SRS-188; release artifact is an AAB (not a bare APK) per SRS-119; Play Console accepts the bundle; signing key is the CI release key.
• Evidence: AAB dump + Play Console acceptance screenshot

SWE6-SV-024: Verify Android PTT capability badge reports L0Focused per SAD-086 / SDD-110.

• Source SRS: SRS-208 (mode boundary), SRS-209
• Verification method: Device-level UI test (android-p0-acceptance.md TC-4 + TC-10)
• Pass criteria: Capability badge shows L0Focused with Android-specific explanatory copy. No global hotkey is bound. Backgrounding the app stops PTT transitions from being delivered.
• Evidence: UI screenshot + log

SRS Range	SWE.6 Coverage
SRS-111	SWE6-SV-018
SRS-119	SWE6-SV-023
SRS-163	SWE6-SV-021
SRS-187	SWE6-SV-022
SRS-188	SWE6-SV-023
SRS-208	SWE6-SV-020, SWE6-SV-024
SRS-209	SWE6-SV-019, SWE6-SV-024

Android voice audio backend qualification items (SRS-210..SRS-215, SDD-111..SDD-116 wave)

SWE6-SV-025: Verify SRS-210 mouth-to-ear latency target per device-class on the SDD-116 device matrix.

• Source SRS: SRS-210
• Source SDD: SDD-111, SDD-112, SDD-116
• Verification method: Glass-to-glass acoustic measurement on each SDD-116 matrix device (API 28, API 31, API 34; at least one Pixel + one Samsung). See "Glass-to-glass latency measurement procedure" below.
• Pass criteria: On devices where achieved_performance_mode() == LowLatency the measured mouth-to-ear latency is ≤ 150 ms (median of 20 samples, 95th percentile ≤ 180 ms). On devices where the achieved mode is None/PowerSaving the measured latency is ≤ 250 ms (median of 20 samples, 95th percentile ≤ 300 ms). Tier classification is derived from the SWE4-UV-051 unit-level mapping evaluated against the per-device achieved_performance_mode from SWE6-SV-026.
• Evidence: Per-device measurement log (CSV: device, API, achieved_mode, sample_index, latency_ms) + reference audio recording for spot-check + acceptance form rows TC-17, TC-18
• SDD-116 matrix rows satisfied: all (one row per device)

SWE6-SV-026: Verify SRS-211 input preset achieved value recorded per device.

• Source SRS: SRS-211
• Source SDD: SDD-112 (achieved_input_preset()), SDD-116
• Verification method: Device-level test reading the backend's diagnostics export after voice_join
• Pass criteria: For each SDD-116 matrix device the diagnostics record one of {VoiceCommunication, VoicePerformance, Generic} and that value is consistent with the fallback ladder verified by SWE4-UV-048. VoiceCommunication is preferred and any deviation must be accompanied by a recorded fallback rationale (e.g. preset rejected by OEM stack). No device reports an unrecorded/unknown preset.
• Evidence: Per-device diagnostics export
• SDD-116 matrix rows satisfied: all

SWE6-SV-027: Verify SRS-212 hardware AEC engagement (and NS/AGC where supported) per device.

• Source SRS: SRS-212
• Source SDD: SDD-113, SDD-116
• Verification method: Device-level test inspecting backend diagnostics + audible regression check (echo audibility) under speakerphone-routed playback
• Pass criteria: For each matrix device the diagnostics record per-effect engagement: {aec: hw|sw|unavailable, ns: hw|sw|unavailable, agc: hw|sw|unavailable}. Where AcousticEchoCanceler.isAvailable() returns true the recorded value MUST be hw. Where it returns false the recorded value MUST be sw (software fallback per SDD-113 item 5) — never silent. Audible echo evaluation (test sequence: 10 s of speakerphone playback with mic open at conversational distance) yields no operator-perceptible echo on at least one Pixel device and at least one Samsung device.
• Evidence: Per-device diagnostics export + audible-check operator note
• SDD-116 matrix rows satisfied: all (AEC/NS/AGC availability column)

SWE6-SV-028: Verify SRS-213 output usage and content type achieved per device.

• Source SRS: SRS-213
• Source SDD: SDD-112 (achieved_output_usage, achieved_output_content_type), SDD-116
• Verification method: Device-level test reading backend diagnostics; cross-checked with dumpsys media.audio_flinger where queryable
• Pass criteria: For each matrix device the diagnostics record achieved_output_usage == VoiceCommunication AND achieved_output_content_type == Speech. Where dumpsys exposes the stream attributes, the dump corroborates. Mismatch fails the case. Also verifies the in-call routing side-effect: volume slider during the session adjusts the call-volume stream, not media volume (operator check on at least one device).
• Evidence: Per-device diagnostics export + dumpsys excerpt + operator volume-routing note
• SDD-116 matrix rows satisfied: all

SWE6-SV-029: Verify SRS-214 sharing mode achieved per device.

• Source SRS: SRS-214
• Source SDD: SDD-112 (achieved_sharing_mode), SDD-116
• Verification method: Device-level test reading backend diagnostics on each matrix device
• Pass criteria: For each matrix device the diagnostics record achieved_sharing_mode ∈ {Exclusive, Shared}. The requested value is always Exclusive; deviation to Shared is acceptable and must be recorded with no operational regression (assert: no callback errors in the first 60 s of the session when the achieved mode is Shared). The aggregate device-matrix table in the test report cross-tabulates requested vs achieved per device.
• Evidence: Per-device diagnostics export
• SDD-116 matrix rows satisfied: all

SWE6-SV-030: Verify SRS-215 background mic capture under foreground-service-type=microphone per device.

• Source SRS: SRS-215
• Source SDD: SDD-107, SDD-114 (manifest declarations), SDD-115 (FGS-first sequencing), SDD-116
• Verification method: Device-level test (extends SWE6-SV-018 / android-p0-acceptance.md TC-3) executed on each SDD-116 matrix device
• Pass criteria: With the screen off (device locked or screen timed out) for ≥ 10 minutes the input stream remains open AND frames continue to be produced by the AAudio input (verified by a periodic per-minute frame-count probe in the diagnostics) on every matrix device. On API 34 devices the FGS-type is microphone (verified by dumpsys activity services excerpt). No ForegroundServiceDidNotStartInTimeException or MissingForegroundServiceTypeException in logcat. Cross-link annotation: this item extends SWE6-SV-018 with per-matrix-row evidence; SWE6-SV-018 remains the single-device baseline and SWE6-SV-030 is the device-matrix expansion.
• Evidence: Per-device test log + dumpsys excerpt + frame-count probe export
• SDD-116 matrix rows satisfied: all

SRS Range	SWE.6 Coverage
SRS-210	SWE6-SV-025
SRS-211	SWE6-SV-026
SRS-212	SWE6-SV-027
SRS-213	SWE6-SV-028
SRS-214	SWE6-SV-029
SRS-215	SWE6-SV-018 (single-device baseline), SWE6-SV-030 (device-matrix expansion)

Glass-to-glass latency measurement procedure (SWE6-SV-025)

Mouth-to-ear (glass-to-glass) latency for SRS-210 shall be measured end-to-end across the Android device under test acting as the speaker AND a second Android device (or reference Linux host) acting as the listener, both joined to a controlled test TeamSpeak 3 server on the same LAN (no internet hop; LAN RTT must be measured and recorded separately, and subtracted as a baseline only if > 5 ms).

Measurement setup:

1. Connect the DUT and the reference listener device to the test server. The DUT is the talker; the reference is the listener.
2. Drive a short acoustic impulse (a 1 kHz tone burst, 20 ms duration, or a click track) into the DUT microphone from a controlled acoustic source (small loudspeaker at fixed distance, OR a wired line-in adapter where the DUT supports one).
3. Capture the listener device's loudspeaker output with a reference microphone connected to a stereo audio interface; the same audio interface ALSO captures the source impulse on the second channel via a hardwired tap from the impulse generator. Both channels are recorded into a single stereo WAV at ≥ 48 kHz, 16-bit minimum.
4. Latency is the time delta between the impulse-onset sample on channel A (source tap) and the impulse-onset sample on channel B (listener loudspeaker capture), expressed in milliseconds. Onset detection: first sample exceeding 10× the RMS noise floor of the preceding 100 ms.
5. Required precision: ≤ 1 ms (achievable at 48 kHz with single-sample onset detection). The measurement tool is unspecified; any DAW, sox, or custom script that meets the precision requirement is acceptable. The script and raw WAV files are part of the evidence and shall be archived.
6. Per-device run: 20 impulses spaced ≥ 2 s apart. Record median and 95th percentile.
7. Baseline subtraction: LAN one-way latency to the test server is measured (e.g. via ICMP / TS3 control-channel ping) and recorded but NOT subtracted from the SRS-210 result, because SRS-210's "mouth-to-ear" definition includes the network hop on a representative network. The LAN result is the ceiling case; WAN regression is out of scope for SRS-210 on this matrix.
8. Operator notes record: DUT model, Android API, achieved_performance_mode, achieved_sharing_mode, achieved_input_preset, headset/loudspeaker routing, ambient noise estimate, ambient temperature only if extreme.

This procedure is reproducible without proprietary fixtures. A loopback-cable-only variant (DUT line-out → DUT line-in on a single device with a wired headset adapter) is acceptable as a screening test but is NOT sufficient for SRS-210 sign-off because it does not exercise the network path.

Baseline Candidate 0.9.4 Update

Version	Date	Description
0.9.4	2026-05-18	Added Android P0 software-qualification items SWE6-SV-018..SWE6-SV-024 mapped to SRS-111, SRS-119, SRS-163, SRS-187, SRS-188, SRS-208, SRS-209; cross-linked to docs/verification/android-p0-acceptance.md test cases.
0.9.5	2026-05-18	Added Android voice audio backend software-qualification items SWE6-SV-025..SWE6-SV-030 covering SRS-210 (latency tier per SDD-116 matrix, with glass-to-glass measurement procedure), SRS-211 (input preset achieved), SRS-212 (hardware AEC engagement + software fallback evidence), SRS-213 (output usage/content type achieved), SRS-214 (sharing mode achieved), SRS-215 (FGS-hosted background capture per matrix row). Annotated SWE6-SV-018 with cross-link to SWE6-SV-030 (device-matrix expansion).