Post-install validation in the council chamber shows ICMP ping success to the gateway, yet Microsoft Teams calls fail quality thresholds. What testing principle should the expert insist on?
Select an answer to reveal the explanation.
Short Explanation
Ping is a polite knock on the door; Teams is a full conversation in the living room. A green ping doesn’t mean the call sounds good. Always validate with the real apps and their latency/jitter/MOS-style metrics.
Full Explanation
Post-install validation in a council chamber that shows ICMP ping success to the gateway while Microsoft Teams fails quality thresholds illustrates a core testing principle: validate with the real applications and relevant QoS/latency/jitter/loss metrics, because ICMP success alone does not prove app performance. Ping uses different timing, packet sizes, and often different QoS treatment than real-time media. Accepting ping as sufficient because Teams somehow always shares the same best-effort path forever ignores DSCP/WMM paths and media requirements. Skipping application tests when a predictive heatmap was green confuses coverage prediction with capacity and experience validation. Retesting only after disabling all security on the SSID may change behavior and abandons the municipal security baseline you must actually support. Exam caveat: acceptance criteria should include application SLOs, not merely reachability. Operational check: run Teams (or equivalent) test calls from dais and audience positions with voice/video metrics, correlate with WLAN retries and QoS markings, and sign off council-chamber Wi-Fi only when real meeting apps meet thresholds under representative load. Council-chamber sign-off should attach sample Teams quality scores alongside WLAN counters so elected-official support staff inherit evidence-based acceptance criteria. Repeat a short application test after any QoS or SSID template change that could alter the civic meeting experience.