In Phase 3, we are completing the integration of the system by connecting the user interface layer to the communication control and tower infrastructure assembled in the earlier phases. This phase incorporates the Dispatch consoles, the Mobile Application on iOS and Android, and the operational behavior of the Radio Firmware so that all architectural layers interact as designed. The goal in this phase is to confirm that user-initiated actions are correctly translated into control operations, that system state information is accurately delivered to the interface components, and that the end-to-end data flows between subsystems function as intended.
This third phase introduces the full set of user facing components, it exercises several functional requirements. Directly affected requirements include FR-1 Push to Talk as triggered through hardware or software PTT controls, FR-2 creation, modification, and deletion of talk groups through dispatch interfaces, FR-3 network switching as experienced by mobile and radio clients moving across WiFi, LTE, 5G, and P25 coverage, FR-4 emergency alert initiation and delivery, FR-5 system monitoring displays that report the status of units, groups, users, and towers, FR-6 communication among multiple agencies within shared talk groups, FR-7 authentication, login, and authorization workflows, and FR-9 access to recorded call and alert histories. This phase also touches FR-8 indirectly because backup path switching, while already tested at lower levels, must continue to propagate through the upper layers and appear correctly in the user facing components.
The testing performed here is still integration focused. The intent is to verify that the interface components interact properly with the underlying services, that the control flows are correctly propagated through the system, and that user level operations trigger the expected architectural responses. The scenarios used in this phase include logging in, selecting or joining groups, initiating communication sessions, triggering emergency alerts, issuing configuration changes from dispatch, and navigating monitoring and log views to ensure that all layers of the system exchange information correctly.
| Id | Test Case Objective | Test Case Description | Expected Results |
|---|---|---|---|
| P3-01 | Verify that authentication and authorization work across Dispatch, iOS, Android, and that authorized groups/permissions are correctly reflected in the UI. | Attempt login from, Dispatch console (Windows/Mac), iOS app, and Android app using valid credentials with different roles (commander, regular user, multi-agency user) and Invalid Invalid credentials (wrong password, unknown user, disabled accounts). After successful login, navigate to group selection / status screens. | Valid credentials succeed; invalid or disabled accounts are rejected with clear error messages (FR-7). Each platform shows the same authorized talk groups and functions for the same user (FR-7, NFR-7). Users without commander role cannot see or use group configuration features (FR-2 / authorization). No access to PTT, group lists, or monitoring screens before successful login. |
| P3-02 | Verify that pressing PTT on hardware radios and mobile apps sends a join/request to the control channel, establishes a voice path through towers and controller, and displays correct state on Dispatch. | Log in one user on a hardware radio, another on the mobile app, and one dispatcher. From the radio select a specific talk group. Press and hold hardware PTT, then speak. From the mobile app Select the same talk group. Press software PTT, then speak. Observe Dispatch console and other devices for audio and status. | Each PTT press triggers a join request on the control channel for the selected talk group (FR-1). Communications Controller assigns a channel; Tower Base Stations relay the transmission. All members of that talk group (radio, mobile, dispatch) hear the audio clearly and see “unit X transmitting” or equivalent indicator on UI (FR-1, FR-6). PTT release stops audio and updates UI back to idle; no audio leakage when PTT is not engaged. Call details (time, channel, participating units/users) are logged for later retrieval (FR-9). Measured setup time from PTT press to speech path establishment meets ≤ 50 ms target where measurable (NFR-2). |
| P3-03 | Ensure that talk group management done at Dispatch propagates correctly to radios and mobile apps and affects communication behavior. | From Dispatch UI, create a new talk group and assign a set of users using various devices. Then, modify the group by adding and removeing users, changing the assigned channel/frequency, and deleting the talk group. On devices refresh or navigate to group list and attempt to join and use PTT before and after each changes. | Newly created talk group appears on all relevant clients after synchronization (FR-2, FR-6, NFR-7). Only assigned users can join and transmit in that group; removed users are no longer allowed to join or transmit after modification (FR-2, FR-7). Channel/frequency updates are sent via Communications Controller to Tower Base Stations and down to radios; audio flows use the updated configuration. After deletion, group disappears from the UIs and devices cannot join or PTT to it. All configuration changes and affected units are logged (FR-9). |
| P3-04 | Verify that the mobile application automatically switches between Wi-Fi/LTE/5G/P25 to maintain connectivity while not actively transmitting. | Log a mobile user into the app and join a talk group. With no active call in progress, progressively Disable Wi-Fi. Degrade or disable LTE signal. Introduce a P25 or 5G path as alternative. Monitor network indicators in the app and Dispatch's view of the unit's connection status. | Mobile client detects loss/degradation of current network and automatically switches to the next available path (Wi-Fi → LTE → 5G or P25) without requiring re-login (FR-3). Dispatch monitoring view continues to show the unit as online, but with updated network/status information (FR-5). Any brief connectivity disturbances do not exceed acceptable interruption thresholds of 1.5s (NFR-8). No user data or logs are lost during switches. |
| P3-05 | Confirm that active PTT voice sessions can survive a network handoff with minimal interruption as the client moves between coverage types. | Log in a mobile user and a dispatch operator; join the same talk group. Start a PTT session from the mobile client. While transmitting force a switch from Wi-Fi to LTE/5G. Monitor audio at Dispatch and the other clients, and observe any status indicators. | Communications Controller and Tower/Base Stations detect the network change and reroute without dropping the session (FR-3, FR-8). Voice may briefly glitch, but total interruption does not exceed 1.5 s as per NFR-8. PTT session resumes and completes without requiring users to re-press PTT or re-join the group. Dispatch UI must not show the unit as offline during the brief handoff (FR-5). No user data or logs are lost during the switch. |
| P3-06 | Ensure that an emergency alert triggered at the field device overrides normal traffic, reaches Dispatch and relevant units immediately, and is correctly shown and logged. | Set up several ongoing normal PTT conversations across multiple talk groups useing radios and mobile apps. On one radio device, press the dedicated emergency button; on a separate run, trigger emergency from the mobile app. Observe audio channels at towers, controller, dispatch UI, and other devices in the same group. | Emergency button press causes radio/mobile firmware to override normal traffic and send emergency request on the control channel (FR-4). Towers and Controller prioritize the emergency, temporarily pre-empting non-emergency transmissions where needed (FR-4, FR-3). Dispatch console shows prominent emergency alert notification, including radio ID/user and location (FR-5). Other relevant units in the emergency talk group receive the emergency alert or broadcast immediately. All emergency events are logged with time, originating unit, group, and channel; they are flagged as emergency in the history (FR-9). |
| P3-07 | Verify that Dispatch monitoring screens show correct real-time status of units/talk groups/towers and reflect backup path switching when an abnormal condition occurs. | With multiple active units and towers, open Dispatch monitoring/overview screens. Introduce an abnormal condition such as a tower outage or severe RFI causing loss of a primary path or a back-haul link failure so that Controller must route via backup. Observe monitoring views and behavior of ongoing or new PTT calls. | Monitoring dashboard shows updated status for affected tower(s) (FR-5). System detects abnormal condition and automatically switches to configured backup communication path (FR-8). New and ongoing PTT calls are routed via backup without user intervention and remain functional. Dispatch UI reflects that calls are still active; impacted components are clearly indicated so operators can respond. Events are logged, including outage start time, backup activation, and restoration time (FR-9). |
| P3-08 | Confirm that users from different agencies/departments can share a talk group and communicate in real time, while other groups stay isolated. | Configure a shared talk group containing users from at least two agencies, each on different device types. Log in all users and join the shared talk group; also ensure each user has at least one private/agency-specific group. Pass a sequence of messages including PTT transmissions from each agency to the shared group and PTT transmissions to private agency-specific groups. | All users in the shared group can hear each other's transmissions in real time regardless of agency or device type (FR-6, NFR-7). Users in agency-specific groups do not receive shared-group traffic unless explicitly joined, and vice versa (isolation of groups). Dispatch can monitor and optionally join the shared group and agency-specific groups as configured (FR-2, FR-5). All shared group conversations are logged with participating units and agencies (FR-9). |
| P3-09 | Verify that recorded calls and alerts are stored and accessible through user-facing components with required metadata. | Generate a sequence of normal and emergency calls involving multiple groups, networks, and device types. From Dispatch console inspect the call/alert history or recording log view. | All generated calls and alerts appear in the history with at least: call ID, timestamp, channel, users/units, connection status, and emergency flag where applicable (FR-9, NFR-6). Results are consistent across Dispatch and mobile where features overlap (NFR-7). No missing or obviously corrupted records for calls executed during the test. |
| P3-10 | Validate that the system maintains required connection rates and latency under high concurrent load. | Simulate or provision at least 150 concurrent active voice connections across multiple towers with a mix of radio, iOS, and Android clients and multiple talk groups. From a subset of clients, repeatedly press PTT, start/stop short calls, and switch groups. Monitor successful/failed connection attempts, any voice delay from PTT press to audio, and dispatch UI responsiveness and status updates. | System sustains ≥ 150 simultaneous voice connections without functional degradation (NFR-3). At least 90% of connection attempts succeed even if some networks are degraded (NFR-1). Average voice delay between PTT press and audio at receiving clients remains less than 200 ms (NFR-4), and PTT setup time continues to meet ≤ 50 ms where measured (NFR-2). Dispatch monitoring screens remain responsive and accurately reflect unit/talk group status despite the load (FR-5). No UI crashes, unrecoverable errors, or mass call drops occur during the test. |