Engineering, Testing and Operations of Mobile Systems

Introduction and Context

Mobile systems are socio-technical systems whose behavior depends on devices, radio networks, cloud services, applications, users, operating environments, and regulatory constraints. Engineering such systems is therefore more than implementing a mobile application. It requires coordinated requirements analysis, architecture selection, prototyping, simulation, emulation, laboratory validation, field measurement, secure delivery, observability, and operational lifecycle management.

Mobility introduces variability that is less prominent in conventional fixed systems. A mobile system may experience changing signal strength, handover, intermittent connectivity, device heterogeneity, battery limitations, constrained input methods, location-dependent regulation, and rapidly changing user context. Testing only under ideal laboratory conditions can consequently produce false confidence. A system that is correct in a controlled network may fail during congestion, roaming, weak coverage, device thermal throttling, or loss of cloud connectivity.

This chapter presents an engineering lifecycle for mobile systems. It connects requirements and architecture decisions with measurable quality attributes, explains the roles of prototyping, simulation, emulation, and field trials, and develops a DevSecOps and observability perspective for dependable operation.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Translate mobile-system goals into testable functional and quality requirements.

2. Select an appropriate architecture using technical, economic, security, and operational criteria.

3. Distinguish prototyping, simulation, emulation, laboratory testing, and field measurement.

4. Design interoperability, security, usability, performance, and energy tests.

5. Apply DevSecOps, observability, release-management, and incident-response practices.

6. Evaluate limitations, ethical risks, and governance obligations in mobile-system operations.

1. Requirements Engineering for Mobile Systems

1.1 Stakeholders and system boundaries

Requirements originate from multiple stakeholders: end users, product owners, network operators, device manufacturers, security teams, regulators, accessibility groups, and operations personnel. A useful system boundary identifies what the engineering team controls and what it merely depends upon. For example, an emergency-response application may control its user interface and backend service but depend on public cellular coverage, a positioning provider, an identity service, and an emergency organization’s dispatch platform.

A context diagram should identify:

• mobile clients and supported operating systems;
• radio access technologies and connectivity states;
• edge, cloud, and enterprise services;
• external identity, payment, mapping, or notification providers;
• human and organizational actors; and
• data flows, trust boundaries, and failure dependencies.

1.2 Functional and quality requirements

Functional requirements specify behavior, such as registering a device, synchronizing records, submitting a sensor reading, or operating offline. Quality requirements specify how well the behavior must be delivered. Important mobile-system quality attributes include latency, availability, reliability, energy consumption, security, privacy, accessibility, interoperability, maintainability, and resilience.

A weak requirement states, “The application should be fast.” A testable requirement states, “For a defined transaction and test population, 95% of successful requests shall receive an application-level response within 800 ms under the reference network profile.” The requirement must identify the transaction, measurement point, workload, network conditions, percentile, and success criteria.

Percentiles are preferable to averages for user-facing latency because a small number of very slow requests can significantly affect user experience. If response times are sorted, the 95th percentile is the value below which 95% of observations fall. The percentile alone does not describe why the remaining requests are slow; therefore it should be reported with sample size, workload, and confidence information where decisions are consequential.

1.3 Scenario-based analysis

Mobile requirements should be expressed through scenarios rather than isolated features. A scenario includes the actor, preconditions, trigger, normal flow, alternative flows, environmental conditions, and acceptance criteria. Particularly important scenarios include:

• first installation and permission denial;
• authentication with an expired token;
• handover between radio cells;
• operation without connectivity;
• clock changes and time-zone transitions;
• low battery and thermal throttling;
• notification delivery during background execution restrictions;
• lost or stolen devices; and
• recovery after backend or identity-service failure.

A requirements traceability matrix maps each requirement to design elements, test cases, telemetry, and release evidence. This reduces the risk that non-functional requirements disappear after initial planning.

2. Architecture Selection and Engineering Trade-offs

2.1 Architectural styles

A mobile system commonly combines several architectural styles:

• Client-server architecture: the mobile client invokes centralized services. It simplifies data governance but depends heavily on connectivity.
• Offline-first architecture: local storage and local workflows remain usable without a network, followed by synchronization. It improves resilience but creates conflict-resolution and data-consistency problems.
• Edge-assisted architecture: computation is moved near users or devices to reduce latency and bandwidth consumption. It introduces deployment, security, and fleet-management complexity.
• Event-driven architecture: state changes generate events consumed by independent services. It supports scalability and loose coupling but requires careful handling of ordering, duplication, replay, and eventual consistency.
• Peer-to-peer or device-to-device architecture: nearby devices exchange information directly. It may reduce infrastructure dependence but increases discovery, trust, privacy, and interoperability challenges.

No architecture is universally superior. Selection should be based on explicit quality-attribute scenarios and constraints.

2.2 Decision criteria

Architecture evaluation should consider:

1. Connectivity tolerance: Can critical functions continue during loss, delay, or low bandwidth?

2. Data consistency: Is immediate global consistency required, or is eventual consistency acceptable?

3. Security exposure: Which components store credentials, personal data, or cryptographic keys?

4. Operational complexity: How many services, versions, regions, and device variants must be managed?

5. Energy and resource cost: What are the CPU, memory, radio, storage, and battery implications?

6. Scalability and resilience: How does the design behave under bursts, regional failure, and dependency outage?

7. Interoperability: Are standards, versioning, and capability negotiation defined?

8. Regulatory obligations: Are data residency, retention, consent, accessibility, or sector-specific rules applicable?

Architecture decision records should document alternatives, assumptions, rejected options, risks, and evidence. This is more useful than recording only the final diagram.

2.3 Offline synchronization

Offline-first systems require explicit synchronization semantics. A record should normally carry an identifier, version or revision information, modification time, origin, and integrity metadata. Conflict policies may include last-writer-wins, field-level merging, authoritative-server resolution, or application-specific reconciliation. Last-writer-wins is simple but can silently discard valid user work and is unsafe when device clocks are unreliable. For critical records, a conflict should be made visible and resolved using domain rules.

Security must apply to local data as well as network traffic. Encryption at rest, platform-protected key storage, minimal retention, secure deletion where feasible, and protection against backups or screenshots may be necessary depending on sensitivity.

3. Prototyping, Simulation, Emulation, and Field Measurement

3.1 Prototyping

A prototype is an intentionally incomplete representation used to reduce uncertainty. A paper or interactive user-interface prototype tests information architecture and accessibility. A technical spike tests a radio API, background execution constraint, sensor, codec, or synchronization mechanism. A vertical-slice prototype connects a small client feature to a real service and is particularly valuable because it exposes integration risks early.

Prototype results must not be mistaken for production readiness. A prototype may omit authentication hardening, observability, failure handling, accessibility, or scale characteristics. Its purpose is to answer a specified question.

3.2 Simulation

Simulation models system behavior without reproducing every implementation detail. Network simulation can explore propagation, interference, mobility, routing, queueing, or protocol behavior. Discrete-event simulation is useful when events such as packet arrivals, handovers, or service completions occur at distinct times. Simulation supports controlled comparison of alternatives and can investigate rare or expensive conditions.

Its limitations are model validity and parameter quality. A simulation that assumes independent packet loss may not represent correlated loss caused by tunnels or radio blockage. Results should therefore include assumptions, parameter sources, sensitivity analysis, and validation against measurements.

3.3 Emulation and testbeds

An emulator reproduces selected properties of a target environment while executing more realistic software. Network emulation can impose delay, bandwidth limits, loss, jitter, reordering, and disconnection on real devices or virtual machines. Hardware-in-the-loop testing connects real sensors, radios, or devices to controlled simulated surroundings.

Emulation is often more useful than simulation for application behavior because the actual application stack encounters realistic timing and operating-system behavior. However, emulation may not reproduce antenna characteristics, battery chemistry, thermal behavior, or every vendor-specific implementation.

3.4 Field measurement

Field trials expose the system to real geography, mobility, users, devices, coverage, interference, and operational dependencies. A rigorous field plan defines routes or locations, device models, software versions, radio technologies, weather or environmental conditions where relevant, time windows, sample sizes, and safety and privacy controls.

Measurements should distinguish application, transport, and radio layers. For example, a slow screen may result from server processing, DNS resolution, transport retransmission, radio scheduling, local database work, or rendering. Timestamped spans and correlated device, network, and backend telemetry are needed to attribute causes.

A useful engineering progression is:

1. static analysis and unit tests;

2. component and contract tests;

3. integration tests;

4. controlled emulator or simulator tests;

5. device-lab tests;

6. limited pilot release; and

7. representative field measurement.

Each stage reduces a different class of uncertainty; none substitutes completely for another.

4. Test Engineering and Quality Evidence

4.1 Test strategy

A test strategy connects risks to test types, environments, data, entry criteria, exit criteria, and ownership. Risk-based testing prioritizes failures by impact and likelihood. A medical mobile system, for example, should allocate more evidence to incorrect dosage display, patient identity, privacy, and loss of records than to a cosmetic animation.

Tests should be deterministic where possible, isolated from unstable external dependencies, repeatable across device and operating-system combinations, and instrumented sufficiently to diagnose failure. Test data must be representative without unnecessarily exposing personal information; synthetic or de-identified data is preferred.

4.2 Interoperability testing

Interoperability concerns whether components exchange and interpret information correctly. It has at least four dimensions:

• syntactic: messages conform to required formats and encodings;
• semantic: fields have the same meaning and units;
• behavioral: components follow compatible sequences, timing, and error rules; and
• operational: components continue to work across versions, vendors, networks, and deployment environments.

Contract tests validate an agreed interface between a consumer and provider. Negative tests should include unknown fields, missing mandatory fields, invalid encodings, duplicate messages, stale versions, unsupported capabilities, and authentication failures. Version negotiation and backward compatibility should be tested explicitly rather than assumed.

4.3 Security testing

Security testing should follow threat modeling and include the client, APIs, identity system, device storage, build pipeline, third-party libraries, and operational environment. Typical activities include static analysis, dependency and secret scanning, dynamic application testing, API authorization tests, secure-storage inspection, transport validation, fuzzing, penetration testing, and abuse-case testing.

A sound threat model identifies assets, actors, trust boundaries, attack surfaces, abuse paths, mitigations, and residual risks. Mobile-specific risks include reverse engineering, insecure local storage, exported components, overlay attacks, excessive permissions, token theft, certificate-validation errors, malicious or compromised accessories, and privacy leakage through logs or analytics.

Security controls should be tested as behavior. For example, it is insufficient to verify that a token is encrypted in storage; tests should also establish that a user cannot access another user’s object by changing an identifier, that revoked credentials fail promptly, and that logs do not reveal secrets.

4.4 Usability and accessibility testing

Usability is best assessed with representative users performing realistic tasks. Useful measures include task completion rate, error rate, time on task, abandonment, and observed confusion. Qualitative interviews and think-aloud sessions explain the causes of quantitative results.

Accessibility testing combines automated checks, manual inspection, assistive-technology testing, and users with disabilities where feasible. It should cover scalable text, contrast, focus order, screen readers, touch-target size, captions, reduced motion, haptic alternatives, and operation under one-handed or low-attention conditions. Accessibility is a system requirement, not a post-release visual enhancement.

4.5 Performance and capacity testing

Performance testing should define workload, device state, network profile, concurrency, data volume, warm or cold start conditions, and success criteria. Tests include baseline, load, stress, spike, endurance, soak, and recovery testing.

For a simple open workload, an approximate relationship between throughput, average response time, and the number of concurrent in-flight requests is often expressed as Little’s Law:

L = λW

where L is the average number of items in the system, λ is the average throughput in items per unit time, and W is the average time an item spends in the system. The relationship assumes a stable system over the observation interval and consistent definitions of the measured population. It is not a complete performance model and should not be used to infer tail latency or causation.

For example, if a service sustains 20 requests per second and the average end-to-end time is 0.25 seconds, the average number of in-flight requests is approximately 20 × 0.25 = 5. This does not mean every request takes 0.25 seconds or that five connections are always required.

Performance analysis should inspect saturation indicators such as CPU, memory, garbage collection, radio activity, database queueing, connection pools, and downstream dependencies. A system can have acceptable average latency while its 99th percentile becomes unacceptable during queue buildup.

4.6 Energy testing

Energy consumption is affected by radio state transitions, network quality, screen brightness, CPU workload, sensors, location services, background scheduling, and application wakeups. A practical experiment compares a baseline device against the application under controlled workload, brightness, battery state, temperature, and connectivity. Repeated trials are needed because battery measurements contain noise.

A simple energy relation is:

E = P t

where E is energy, P is average power, and t is elapsed time, provided power is approximately constant and units are consistent. If power varies, energy is the integral of instantaneous power over time and must be measured or estimated across intervals. Application-level battery percentage is only a coarse indicator and should not be treated as a precise energy meter.

Energy optimization should target unnecessary work rather than merely reducing visible functionality. Batching network transfers, using adaptive location accuracy, respecting background scheduling, compressing appropriately, caching carefully, and avoiding frequent polling can help. Optimization must be evaluated against freshness, safety, privacy, and usability requirements.

5. DevSecOps and Release Engineering

DevSecOps integrates development, security, testing, and operations throughout the delivery lifecycle. A mobile pipeline may include source control, reproducible builds, dependency pinning, signing, static analysis, unit and integration tests, artifact provenance, vulnerability scanning, device testing, staged deployment, and post-release monitoring.

Build security is particularly important because mobile applications are distributed artifacts. Signing keys require strong access control, secure storage, rotation planning, separation of duties, and recovery procedures. Secrets should not be embedded in source code or ordinary application packages. Third-party software should be inventoried and assessed for licensing, vulnerabilities, maintenance status, and supply-chain risk.

Progressive delivery reduces blast radius. Techniques include internal testing, closed beta, canary release, phased rollout, feature flags, remote configuration with safe defaults, and rapid rollback. Rollback planning must consider database schema compatibility, cached data, synchronization protocols, and clients that cannot be immediately upgraded.

A release should have explicit evidence: tested build identifier, source revision, dependency manifest, security results, compatibility matrix, known limitations, approval record, deployment scope, and rollback procedure. “It passed testing” is not sufficient without defining which tests and environment were used.

6. Observability and Operations

Monitoring reports known measurements, whereas observability supports inference about internal system state from externally visible outputs. The principal signals are metrics, logs, traces, and events.

• Metrics support trends, thresholds, and aggregation.
• Logs record detailed events but require structured fields, severity discipline, and retention control.
• Traces connect a user transaction across client, network-facing API, services, queues, and databases.
• Events represent important state transitions such as deployment, authentication failure, synchronization conflict, or policy change.

Useful mobile service-level indicators include successful transaction rate, latency percentiles, crash-free sessions, startup time, synchronization age, notification delivery rate, battery impact, and offline-queue growth. Indicators must be segmented by application version, device model, operating system, region, network type, and feature where privacy and sample size permit.

Alerts should be actionable and tied to user or business impact. Alerting on every low-level error creates fatigue. Runbooks should state symptoms, likely causes, diagnostic queries, mitigation, escalation, communication requirements, and recovery validation.

Incident management should preserve a timeline, decision record, affected scope, and evidence. Blameless post-incident reviews focus on contributing conditions and control improvements rather than individual fault. Reliability objectives should be balanced against delivery speed, cost, and user harm. Error budgets can provide a practical mechanism: when reliability consumption is high, risky changes are reduced and improvement work is prioritized.

7. Case Study: Illustrative Remote Patient Monitoring System

Background

Consider an illustrative system in which patients use a smartphone application connected to a wearable device. The system records heart rate and symptoms, displays trends, and sends selected alerts to a clinical service. The system must work during intermittent connectivity and must protect health information.

Problem

An initial pilot shows that measurements are occasionally duplicated, battery drain is high, and clinicians receive delayed alerts in areas with poor coverage. The team also discovers that a test account can view another patient’s record by modifying an API identifier.

Analysis

The problems span several layers. Duplicate records may result from retries without idempotency. Delayed alerts may reflect offline queues, backend processing, or notification-provider behavior. Battery drain may be caused by frequent radio wakeups and high-rate location requests. The authorization defect is a direct object-access control failure, not merely a user-interface problem.

The team constructs a traceability matrix linking clinical scenarios to requirements and tests. It defines an offline data model with stable event identifiers, origin metadata, sequence information, and an explicit reconciliation policy. Server-side authorization checks the authenticated subject and permitted patient relationship for every object request. The client is not trusted to enforce access control.

Approach and solution

The revised design batches non-urgent measurements, preserves urgent measurements for immediate transmission attempts, and maintains an encrypted local queue. Each event has an idempotency key; repeated submissions produce one logical record. Synchronization tests cover retries, process termination, clock disagreement, duplicate delivery, and partial server responses.

The security test suite adds authorization matrix tests for every endpoint, including altered identifiers, expired sessions, role changes, and direct API calls outside the mobile interface. A device-lab experiment compares energy use under the original and revised sampling policies. Field trials use controlled routes with connectivity loss and recovery, while synthetic patient data prevents exposure of real health information.

Observability adds a trace identifier to measurement ingestion, queueing, clinical alert generation, and notification submission. Dashboards segment alert delay by application version, region, device, and connectivity state. A release is first deployed to internal users, followed by a small clinical pilot with a rollback plan.

Outcome

The revised system eliminates duplicate logical records, reduces unnecessary radio activity, and makes delayed alerts diagnosable rather than invisible. The authorization tests prevent recurrence of the object-access defect. However, the team documents that notification delivery cannot be guaranteed by the application alone; clinical procedures must define escalation when a notification is not acknowledged.

Learning points

The case demonstrates that reliability, energy, security, and clinical safety are interdependent. Offline capability requires a data model and conflict policy, not merely a local cache. Security must be enforced at every service boundary. Field trials and correlated telemetry are necessary to explain failures that cannot be reproduced in a laboratory.

8. Governance, Ethics, and Contemporary Developments

Mobile systems frequently process location, behavioral, biometric, financial, or health data. Data minimization, purpose limitation, informed consent where applicable, retention controls, access governance, and transparent privacy notices should be designed into the lifecycle. Location collection should be justified by a defined function, not enabled simply because it is technically available.

Regulatory obligations vary by jurisdiction and sector. Engineering teams should involve legal, privacy, safety, accessibility, and security specialists early. Auditability must not become uncontrolled surveillance: operational telemetry should be minimized, access-controlled, and protected from secondary use.

AI and machine learning may support anomaly detection, predictive maintenance, adaptive quality of service, or test-case generation. They also introduce risks of bias, opacity, data leakage, model drift, adversarial manipulation, and inappropriate automation. AI-generated code and test cases require human review, dependency scrutiny, licensing review, and security validation. An AI model should not silently make safety-critical decisions without defined accountability and override procedures.

Contemporary mobile engineering increasingly involves edge computing, private cellular networks, eSIM and programmable connectivity, confidential computing, digital twins, automated policy enforcement, and software bills of materials. These developments can improve adaptability and assurance but expand the operational system and its attack surface. Adoption should follow evidence-based pilots and explicit risk analysis.

9. Best-Practice Engineering Checklist

A mature mobile-system program should:

• define measurable functional, quality, privacy, and safety requirements;
• maintain architecture decisions and traceability;
• test representative devices, operating systems, networks, and user contexts;
• combine simulation, emulation, laboratory testing, and field measurement;
• threat-model client, APIs, devices, dependencies, and operations;
• verify authorization server-side and protect local data;
• measure latency distributions, failure rates, crashes, synchronization age, and energy impact;
• make offline behavior, retries, idempotency, and conflict resolution explicit;
• use reproducible, signed, traceable builds and staged rollout;
• instrument transactions with privacy-preserving observability;
• prepare runbooks, rollback procedures, incident processes, and post-incident learning; and
• review accessibility, ethics, regulatory obligations, and environmental impact throughout the lifecycle.

Challenges and Limitations

Mobile-system evidence is difficult to generalize because devices, radio environments, users, and software versions change continuously. Laboratory repeatability can conflict with field realism. Telemetry improves diagnosis but can create privacy and storage costs. Automated testing may miss usability failures, emergent interactions, and rare environmental conditions. Simulation depends on model validity, while field trials are expensive and may expose participants or sensitive locations. Finally, operational success is not permanent: new operating-system policies, network technologies, dependencies, threats, and user expectations require continuous reassessment.

Chapter Summary

Engineering mobile systems requires a lifecycle perspective linking requirements, architecture, implementation, testing, deployment, and operations. Requirements must be measurable and scenario-based, particularly for latency, resilience, security, energy, accessibility, and interoperability. Architecture selection should evaluate offline behavior, consistency, trust boundaries, scalability, operational complexity, and regulatory constraints.

Prototyping reduces uncertainty, simulation explores modeled behavior, emulation exercises realistic software under controlled conditions, and field measurement reveals environmental and human variability. Effective test programs combine interoperability, security, usability, performance, energy, and recovery testing. DevSecOps provides reproducible and secure delivery, while observability connects user outcomes to technical causes. Progressive release, incident response, privacy governance, and lifecycle management are essential for dependable operation. The central professional principle is to treat mobile quality as evidence gathered across representative contexts rather than as a claim established by a single test environment.

Key Terms

Requirements traceability: Mapping requirements to design elements, tests, telemetry, and release evidence.

Quality attribute: A non-functional property such as security, latency, reliability, or usability.

Offline-first: An approach in which important functions remain available without continuous connectivity.

Eventual consistency: A model in which replicas may temporarily differ but converge after updates propagate.

Architecture decision record: A documented decision, alternatives, assumptions, and consequences.

Prototype: An incomplete representation used to investigate a specific uncertainty.

Simulation: Model-based execution used to study system behavior without reproducing the complete implementation.

Emulation: Controlled reproduction of selected environmental properties while running realistic software.

Field measurement: Observation of a system in representative real-world conditions.

Interoperability: Ability of independent components to exchange and correctly interpret information.

Contract test: A test verifying that a provider and consumer follow an agreed interface contract.

Threat model: Structured analysis of assets, actors, attack surfaces, threats, and mitigations.

Idempotency: Property whereby repeating an operation produces the same logical result as performing it once.

Little’s Law: The stable-system relationship L = λW between population, throughput, and average time.

DevSecOps: Integration of development, security, testing, and operations throughout delivery.

Progressive delivery: Gradual release of changes to limit risk and enable evidence-based rollback.

Observability: Ability to infer internal system conditions from outputs such as metrics, logs, traces, and events.

Service-level indicator: A measured value representing a service outcome, such as successful latency.

Error budget: Permitted unreliability associated with a defined reliability objective.

Energy profiling: Measurement or estimation of energy or power use under defined workloads.

Review Questions

Short Answer Questions

1. Why should mobile requirements include environmental and connectivity conditions?

2. Distinguish simulation from emulation.

3. What is the purpose of an architecture decision record?

4. Name four principal observability signals.

5. Why is server-side authorization essential in a mobile system?

Long Answer Questions

1. Explain how an offline-first architecture affects data consistency, security, and testing.

2. Develop a test strategy covering interoperability, security, usability, performance, and energy for a mobile banking application.

3. Discuss the role of DevSecOps in secure mobile release engineering.

4. Explain how field measurements should be planned and correlated with backend telemetry.

5. Critically evaluate the benefits and limitations of progressive delivery and feature flags.

Analytical / Application Questions

1. A service processes 40 requests per second with an average response time of 150 ms. Using Little’s Law, estimate the average number of in-flight requests and state the assumptions behind the calculation.

2. Design an experiment to determine whether a proposed batching strategy reduces battery use without violating a mobile health application’s freshness requirement.

3. A mobile application works in laboratory tests but loses records during intermittent connectivity in the field. Analyze likely causes and propose architecture, testing, and observability changes.

Multiple Choice Questions with Answers

Question 1

Which requirement is most testable?

A. The application should be user-friendly.

B. The application should be modern.

C. 95% of successful reference transactions shall receive a response within 800 ms under the defined network profile.

D. The application should feel fast.

Correct Answer: C. 95% of successful reference transactions shall receive a response within 800 ms under the defined network profile.

Question 2

Which architecture characteristic is most directly associated with offline-first design?

A. Continuous dependence on a central server

B. Local operation followed by synchronization

C. Elimination of all data conflicts

D. Removal of local data storage

Correct Answer: B. Local operation followed by synchronization

Question 3

What is a principal limitation of simulation?

A. It cannot support controlled comparisons.

B. It always requires production hardware.

C. Its results depend on model validity and parameter quality.

D. It cannot represent rare conditions.

Correct Answer: C. Its results depend on model validity and parameter quality.

Question 4

Which test primarily verifies that a consumer and provider follow an agreed interface?

A. Contract test

B. Soak test

C. Usability test

D. Battery test

Correct Answer: A. Contract test

Question 5

Which security control must be enforced at the service boundary rather than trusted to the client interface?

A. Screen brightness

B. Object-level authorization

C. Animation speed

D. Text size

Correct Answer: B. Object-level authorization

Question 6

A service sustains 20 requests per second and has an average response time of 0.25 seconds. According to Little’s Law, what is the average number of in-flight requests?

A. 0.05

B. 5

C. 20.25

D. 80

Correct Answer: B. 5

Question 7

Which statement correctly describes observability?

A. It is identical to threshold monitoring.

B. It infers internal state from outputs such as metrics, logs, and traces.

C. It replaces all functional testing.

D. It requires collecting every possible user datum.

Correct Answer: B. It infers internal state from outputs such as metrics, logs, and traces.

Question 8

What is the main purpose of progressive delivery?

A. To prevent all future defects

B. To release changes gradually and limit blast radius

C. To eliminate the need for rollback

D. To avoid monitoring after deployment

Correct Answer: B. To release changes gradually and limit blast radius

Question 9

Which approach best addresses duplicate submissions caused by retries?

A. Remove all retries

B. Use an idempotency key and server-side deduplication

C. Increase screen brightness

D. Disable offline operation

Correct Answer: B. Use an idempotency key and server-side deduplication

Question 10

For variable power consumption, energy is most accurately determined by which approach?

A. Multiplying battery percentage by screen size

B. Using elapsed time alone

C. Integrating instantaneous power over time or summing measured interval energy

D. Counting application screens

Correct Answer: C. Integrating instantaneous power over time or summing measured interval energy