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.

```text
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). |