7. Non-Functional Quality Engineering

Introduction and Context

Software quality is not determined solely by whether an application produces the correct result for a given input. A web application may calculate an invoice accurately and still be unacceptable if pages take twenty seconds to load, the service becomes unavailable during peak demand, confidential information is exposed, or users with disabilities cannot operate it. These concerns belong to non-functional quality engineering: the systematic planning, measurement, testing, and improvement of qualities that describe how a system performs and operates rather than only what it does.

For full-stack developers, non-functional quality is particularly important because modern applications are distributed across browsers, mobile devices, application servers, databases, caches, message brokers, cloud infrastructure, third-party APIs, and observability platforms. A defect in any layer can affect responsiveness, security, reliability, or accessibility. Non-functional testing therefore cannot be postponed until the final testing phase. Quality attributes must be translated into measurable objectives during requirements analysis, designed into architecture, tested continuously, and monitored after deployment.

This chapter treats non-functional testing as an engineering discipline rather than a collection of specialist activities. It explains how quality attributes are defined, how service objectives guide testing, how performance and resilience experiments are designed, and how security, compatibility, usability, accessibility, localization, and maintainability are evaluated. It also considers trade-offs: stronger security may add latency, extensive logging may increase storage and processing costs, and higher scalability may introduce architectural complexity.

Learning Objectives

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

1. Distinguish functional correctness from non-functional quality and explain the relationship between quality attributes.

2. Convert business expectations into measurable quality requirements, service-level indicators, service-level objectives, and acceptance criteria.

3. Plan and conduct performance, load, stress, scalability, reliability, resilience, and recovery testing.

4. Apply appropriate methods for security, compatibility, usability, accessibility, localization, and maintainability testing.

5. Interpret quantitative evidence such as latency percentiles, throughput, error rates, availability, recovery time, and recovery point.

6. Evaluate risks, ethical issues, governance requirements, and trade-offs in non-functional quality engineering.

7. Select suitable automation, observability, and analytics techniques for continuous quality improvement.

From Quality Attributes to Measurable Objectives

A quality attribute is a characteristic of a system that influences stakeholder satisfaction or operational fitness. Common attributes include performance efficiency, security, reliability, availability, resilience, usability, accessibility, compatibility, maintainability, portability, and recoverability. These attributes are related but not interchangeable. Availability describes whether a service is usable when required; reliability concerns the ability to operate correctly over time; resilience concerns the ability to withstand disruption and restore acceptable service; recoverability concerns the restoration of data and operation after failure.

A useful quality requirement has an object, a condition, a measurable value, and a method of verification. “The system must be fast” is not testable. “For authenticated product searches under normal operating conditions, 95% of responses shall be completed within 800 milliseconds, with an error rate below 0.5%” is testable. The requirement identifies the transaction, workload condition, percentile, threshold, and error measure.

Three operational concepts are especially useful. A service-level indicator (SLI) is an observed measure, such as successful request percentage or 95th-percentile latency. A service-level objective (SLO) is the target for that indicator, such as 99.9% successful requests per month. A service-level agreement (SLA) is a formal commitment, often contractual, that may include consequences when objectives are missed. Testing should focus on evidence relevant to SLOs, while SLAs provide external obligations and business context.

Percentiles are generally more informative than averages. An average latency of 300 milliseconds may conceal a small but significant group of requests taking ten seconds. The 50th percentile represents the median experience, while the 95th and 99th percentiles reveal tail behavior. Quality decisions should identify which percentile matters to users and business operations.

Quality models provide vocabulary for discussing these concerns. ISO/IEC 25010, for example, organizes product quality around characteristics including performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. Such models do not automatically provide test cases; they help teams identify relevant attributes and avoid treating quality as a single undifferentiated property.

Performance Engineering: Measuring Behaviour Under Demand

Performance testing examines system behaviour in relation to time and resource usage. Its principal measures are response time, throughput, concurrency, resource utilization, and error rate. Response time should be measured from a user or client perspective and, where possible, decomposed into network, queueing, application, database, and external-service contributions. Throughput may be expressed as requests per second, transactions per minute, messages processed, or orders completed. Resource utilization includes CPU, memory, disk, network, database connections, and thread or event-loop capacity.

A performance test begins with a workload model. The model describes user populations, request types, arrival patterns, session behaviour, data distribution, think time, and transaction mix. A test that sends an identical request repeatedly may produce excellent results while failing to represent real usage. For example, an e-commerce workload may contain browsing, searching, cart updates, authentication, payment authorization, and order confirmation in different proportions.

Baseline testing establishes behaviour under a known workload and environment. It should be repeatable and documented: software version, infrastructure size, database state, cache state, test data, network conditions, workload intensity, and monitoring configuration. Without a baseline, a later performance result cannot be interpreted confidently.

Load testing applies an expected or planned workload. It asks whether the system satisfies its objectives under normal and forecast peak demand. Stress testing deliberately exceeds expected capacity to identify failure thresholds and failure behaviour. Spike testing introduces a rapid increase or decrease in demand, such as a flash sale or viral event. Endurance testing, sometimes called soak testing, applies sustained demand to reveal memory leaks, connection exhaustion, queue growth, storage degradation, or gradual resource fragmentation. Volume testing evaluates large quantities of data, while capacity testing estimates the maximum useful workload before objectives are violated.

Scalability testing examines how performance changes as resources or workload increase. Vertical scaling adds capacity to an existing instance; horizontal scaling adds instances. A system may scale efficiently for stateless API requests but poorly for operations that require database locks or shared session state. The important question is not simply whether more machines improve throughput, but whether the improvement is economically and technically acceptable. A near-linear increase is desirable in some workloads, but coordination overhead, contention, and shared bottlenecks commonly produce diminishing returns.

A typical performance investigation follows a cycle: define objectives, model workload, prepare a production-representative environment, execute controlled tests, observe system behaviour, analyze bottlenecks, change one or more design variables, and repeat. Results should be compared with thresholds and confidence in the test conditions, not interpreted as universal properties of the software.

Reliability, Resilience, and Recovery

Reliability is the probability that a system performs required functions without failure for a specified period under stated conditions. Reliability testing may involve repeated transactions, long-duration operation, fault injection, and analysis of incident data. It is concerned with both the frequency and consequences of failure. A service that fails rarely but loses all uncommitted customer orders may present greater risk than one that experiences minor, well-contained interruptions.

Availability is often represented as the proportion of time a service is usable. It is affected by failure frequency and restoration time. Mean time between failures (MTBF) describes the average operating time between failures, while mean time to repair or restore (MTTR) describes how quickly service is returned. These are operational measures rather than guarantees, and their usefulness depends on consistent definitions of failure and restoration.

Resilience is broader than fault-free operation. A resilient system detects disruption, limits its effect, continues to provide an acceptable level of service where possible, and recovers. Resilience testing may interrupt network connections, terminate instances, delay dependencies, corrupt selected messages, exhaust resources, or make a downstream service unavailable. Such tests must be authorized, observable, reversible, and proportionate to risk. Chaos engineering is a disciplined form of resilience experimentation in which hypotheses about system behaviour are tested through controlled failure introduction.

Recovery testing evaluates restoration after failure. Two important objectives are the recovery time objective (RTO), the maximum acceptable time to restore service, and the recovery point objective (RPO), the maximum acceptable amount of data loss measured in time. A system with an RTO of one hour and an RPO of five minutes requires different backup, replication, deployment, and operational mechanisms from a system that can tolerate a day of downtime and one hour of data loss.

Recovery tests should cover backup restoration, database failover, infrastructure recreation, deployment rollback, message replay, configuration recovery, credential replacement, and restoration of dependent services. A backup is not evidence of recoverability until it has been restored and verified. Recovery validation should include data integrity, security controls, monitoring, user access, and reconciliation of partially completed business transactions.

Security Quality Engineering

Security testing seeks evidence that confidentiality, integrity, availability, authenticity, accountability, and privacy requirements are protected. It must be integrated with threat modelling, secure design, code review, dependency management, and operational controls. Testing alone cannot make an insecure architecture safe.

A threat model identifies assets, trust boundaries, actors, entry points, threats, and mitigations. The STRIDE categories—spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege—can help structure analysis, although teams should also consider business-specific abuse cases. For a full-stack application, relevant areas include authentication, authorization, session handling, input validation, output encoding, secrets management, API exposure, file upload, logging, database access, dependency vulnerabilities, and cloud permissions.

Security testing methods include static application security testing (SAST), which analyzes source or compiled code; dynamic application security testing (DAST), which examines a running application; software composition analysis (SCA), which identifies vulnerable or non-compliant dependencies; interactive testing, which combines runtime and code context; penetration testing, which uses authorized adversarial techniques; and configuration or infrastructure scanning. Each method has blind spots. Automated scanners may report false positives and miss business-logic flaws, while penetration tests provide depth but limited coverage.

Tests must be conducted with explicit authorization and carefully controlled data. Security testing in production can cause outages, trigger legal consequences, or expose personal information. Findings should be risk-ranked using likelihood, impact, exploitability, affected assets, and compensating controls. Remediation should be verified, not merely marked complete.

Compatibility, Usability, Accessibility, and Localization

Compatibility testing evaluates whether a system works acceptably across relevant browsers, operating systems, devices, screen sizes, network conditions, database versions, APIs, and integrations. A compatibility matrix should be risk-based rather than attempting every possible combination. Usage analytics, customer commitments, supported-platform policies, and business geography should determine priority. Responsive interfaces require testing at representative breakpoints, while APIs require attention to protocol versions, schema evolution, character encoding, time zones, and backward compatibility.

Usability concerns effectiveness, efficiency, learnability, error tolerance, and user satisfaction. Usability testing may include moderated sessions, unmoderated tasks, heuristic evaluation, cognitive walkthroughs, analytics, and support-ticket analysis. A measurable usability objective might specify task completion rate, time on task, error frequency, or abandonment rate for a defined user group. Developers should avoid assuming that technical familiarity represents the wider user population.

Accessibility is the extent to which people with diverse abilities can perceive, understand, navigate, and operate the product. Evaluation should address keyboard operation, focus order, visible focus, semantic structure, headings, form labels, error messages, colour contrast, text resizing, captions, alternative text, screen-reader interaction, motion preferences, and accessible authentication. Automated accessibility tools are valuable for detecting some structural problems but cannot judge all meaningful relationships or task experiences. Manual keyboard testing and assistive-technology testing remain necessary. Accessibility should be treated as a quality and inclusion obligation, not as optional customization.

Localization testing verifies adaptation to language, culture, region, and local conventions. It includes translated text, plural rules, date and time formats, calendars, number and currency formats, sorting, address and name structures, right-to-left layout, text expansion, truncation, collation, legal notices, and culturally appropriate imagery. Internationalization is the design and implementation preparation that allows localization without major code changes. Pseudo-localization can expose hard-coded strings, layout assumptions, and encoding defects before professional translation is complete.

Maintainability and Operability

Maintainability is the ease with which software can be analyzed, modified, tested, and evolved. It has direct economic significance because maintenance commonly occupies a substantial portion of software life-cycle effort. Maintainability testing is not a single test type; it combines architectural evaluation, code analysis, testability assessment, deployment verification, documentation review, and observation of change-related effort.

Useful measures include cyclomatic complexity, duplication, dependency coupling, code churn, defect re-open rate, build duration, test reliability, change failure rate, and mean time to restore. Metrics must be interpreted carefully. A low complexity score does not guarantee good design, and a high test count does not guarantee meaningful coverage. Maintainability is best assessed through evidence about how safely and efficiently teams can make changes.

Operability is closely related. A system should expose meaningful logs, metrics, traces, health checks, diagnostic information, feature flags, safe configuration mechanisms, and actionable alerts. Observability supports both testing and production learning. Tests should verify that failures produce useful signals without leaking secrets or personal data. Deployment strategies such as blue-green, canary, and progressive delivery can reduce change risk, provided rollback conditions are defined and tested.

A Unified Quality Engineering Process

A practical quality-engineering process starts with risk and stakeholder analysis. The team identifies critical user journeys, regulatory obligations, business losses, dependency risks, and unacceptable failure modes. These concerns are converted into quality scenarios with a stimulus, operating condition, system response, and measurable response threshold. For example: “When 2,000 authenticated users submit searches over a ten-minute peak period, the service shall maintain a 99.5% success rate and a 95th-percentile latency below 800 milliseconds.”

Next, the team designs an assurance strategy. It selects test levels, environments, tools, data, workload models, observability signals, entry and exit criteria, and ownership. Test environments should resemble production in architecture and configuration where the tested attribute depends on those factors. Test data must be representative without violating privacy. Synthetic or anonymized data, controlled accounts, and data-retention limits are essential.

Execution should be incremental. Teams can begin with component-level checks, then test integrated services, representative user journeys, realistic workloads, and controlled failure conditions. Results should be stored with version and environment metadata so trends can be analyzed. A failed objective should lead to diagnosis rather than immediate optimization. Queues, database locks, garbage collection, network limits, connection pools, cache misses, and third-party latency are possible causes with different remedies.

Quality gates should be explicit. A release might require no unresolved critical security findings, compliance with latency SLOs under peak workload, successful restoration within RTO, verified keyboard access for core journeys, and compatibility across supported browsers. Gates should not encourage teams to hide poor results; they should trigger informed decisions, risk acceptance, redesign, or release delay.

Applied Case: Resilience and Performance of an Online Examination Platform

The following is an illustrative case. A university deploys a cloud-based examination platform used by 12,000 students. The platform provides authentication, question delivery, autosave, submission, and staff reporting. Examinations begin at a common time, creating a sharp traffic spike. The institution requires that students should not lose answers during a service interruption.

Background and situation. Initial functional testing is successful, but a pilot examination reveals delayed page loads and duplicate autosave records. The stated operational expectations are a 99.9% successful request rate during the examination, a 95th-percentile question-load latency below two seconds, an RTO of fifteen minutes, and an RPO of thirty seconds for saved answers.

Analysis. Workload modelling shows that most students authenticate within five minutes, then request questions and autosave every twenty seconds. The original design stores sessions locally on application instances and writes every autosave synchronously to a single database. This creates two risks: users may lose sessions when instances are replaced, and the database may become a bottleneck. Monitoring also records only server errors, not client-side submission failures.

Approach. The team creates a production-like environment with anonymized examination data and generates a realistic transaction mix. Baseline, load, spike, endurance, and database-failover tests are conducted. Session state is moved to a replicated store, autosave operations receive idempotency keys, and answer versions are reconciled using sequence numbers. Read-heavy question delivery is supported by caching, while database connection limits and queue depth are monitored. A controlled test terminates application instances during an examination and separately makes the database unavailable. Recovery procedures are rehearsed from backups and replicas.

Accessibility and compatibility tests are conducted with keyboard-only navigation, a screen reader, supported browsers, and low-bandwidth conditions. Security testing verifies that one student cannot access another student’s answers and that examination content is not exposed through logs. A client-side health signal is added so failed submissions are visible to support staff.

Outcome. The redesigned system meets the stated latency objective in the planned workload and continues accepting autosaves while one application instance is unavailable. During database failover, some requests are retried, but idempotency prevents duplicate records. The recovery rehearsal demonstrates that the previous backup process would not have met the RPO; replication and more frequent verification are therefore retained. The institution also revises its examination start procedure to stagger authentication where pedagogically acceptable.

Learning points. The case illustrates that performance is shaped by workload and architecture, not merely server size. Resilience requires deliberate failure testing, while recovery objectives must be verified through restoration. Observability must include user-visible failure signals. Security, accessibility, and compatibility are part of the same quality decision because failure in any of these areas can make the platform unusable or unsafe.

Challenges, Risks, and Professional Judgement

Non-functional testing is vulnerable to unrealistic environments, incomplete workload models, unstable test data, non-repeatable results, and misleading metrics. Cloud elasticity can conceal capacity problems until cost rises sharply. Mocked dependencies may remove the very latency or failure behaviour under investigation. Conversely, production testing without safeguards can harm real users.

Teams also face competing objectives. Reducing latency may require caching, which introduces staleness and invalidation risks. Strong authentication may increase user effort. Detailed logs improve diagnosis but create privacy and storage concerns. High availability may require redundancy and operational complexity. Quality engineering therefore requires explicit risk acceptance by accountable stakeholders rather than silent compromise by developers.

Common mistakes include testing only average response time, measuring from inside the server rather than from the user boundary, ignoring tail latency, treating scanner output as proof of security, testing accessibility only with an automated tool, assuming backups are recoverable, and performing resilience experiments without a rollback plan. Another mistake is separating performance, security, and maintainability into isolated silos. Architectural changes often affect several attributes simultaneously.

Governance, Ethics, and Compliance

Non-functional testing frequently processes personal, financial, health, or educational information. Data minimization, anonymization, access control, retention limits, encryption, and auditability should govern test-data use. Security tests must be authorized, scoped, documented, and coordinated with incident-response processes. Accessibility commitments may arise from law, institutional policy, or contractual obligations; compliance should be supported by evidence rather than unverified declarations.

Quality reports should be honest about uncertainty, test limitations, unsupported platforms, and residual risks. Managers should not pressure testers to suppress inconvenient results or redefine an SLO after failure without a documented business decision. Responsible disclosure is required when testing reveals a vulnerability in a third-party product or service. Ethical quality engineering considers not only the paying customer but also vulnerable users, downstream recipients, and the public consequences of system failure.

Automation, Analytics, and Emerging Practice

Continuous integration pipelines can automate quality checks such as static analysis, dependency scanning, API performance smoke tests, accessibility rules, contract compatibility, and deployment verification. Larger load tests may run on scheduled environments or before major releases because they require substantial resources. Synthetic monitoring can exercise critical journeys continuously, while real-user monitoring reveals behaviour across actual devices and networks.

Distributed tracing helps connect user-visible latency with service and database spans. Time-series analytics support trend detection, regression identification, capacity forecasting, and error-budget decisions. An error budget represents the amount of unreliability permitted by an SLO; when the budget is consumed, teams may prioritize stability work over feature delivery. AI-assisted tools can help generate workload variations, detect anomalous telemetry, summarize logs, and identify likely performance regressions. Their outputs require human validation because generated tests may be unrealistic, and anomaly detection may confuse unusual legitimate behaviour with defects.

Emerging practice emphasizes continuous verification, platform engineering, policy-as-code, software supply-chain security, privacy engineering, and resilience as a design property. Quality evidence is increasingly collected throughout delivery rather than at a single test phase. Nevertheless, automation does not remove the need for domain knowledge, exploratory investigation, accessibility expertise, ethical judgement, and accountable decision-making.

Best Practices for Non-Functional Quality Engineering

Effective teams:

• define measurable quality scenarios and connect them to business risk;
• use realistic workload, data, environments, and client conditions;
• analyze percentiles, error rates, saturation, and resource behaviour together;
• test expected demand, overload, long duration, dependency failure, and recovery;
• combine automated scanning with expert security, usability, and accessibility evaluation;
• verify backups, rollback procedures, alerts, dashboards, and runbooks through rehearsal;
• preserve test metadata so results are reproducible and comparable;
• protect test data and obtain authorization for disruptive experiments;
• establish quality gates and explicit residual-risk decisions; and
• use production telemetry and incident learning to refine future test models.

Chapter Summary

Non-functional quality engineering evaluates how well software operates under realistic conditions. Quality attributes such as performance, security, reliability, resilience, compatibility, usability, accessibility, localization, and maintainability must be expressed as measurable quality scenarios. SLIs provide observations, SLOs establish targets, and SLAs formalize commitments. Performance work depends on realistic workload models and includes baseline, load, stress, spike, endurance, volume, capacity, and scalability testing. Reliability and resilience require controlled fault injection, while recovery testing verifies RTO, RPO, data integrity, and operational procedures.

Security testing combines threat modelling, automated analysis, penetration testing, and remediation verification. Compatibility, usability, accessibility, and localization require both automated and human-centred evaluation. Maintainability and operability are assessed through architecture, code, deployment, observability, and change-related evidence. Successful quality engineering integrates automation, analytics, governance, ethical data handling, and continuous learning. The central professional responsibility is to make quality claims traceable to evidence and explicit about uncertainty and risk.

Key Terms

Quality attribute: A characteristic that describes how a system operates or is experienced.

Service-level indicator (SLI): An observed quantitative measure of service behaviour.

Service-level objective (SLO): A target value or range for a service-level indicator.

Service-level agreement (SLA): A formal service commitment, often contractual.

Latency percentile: A response-time value below which a stated percentage of observations fall.

Throughput: The amount of work completed per unit of time.

Load testing: Testing under expected or planned demand.

Stress testing: Testing beyond expected capacity to study limits and failure behaviour.

Spike testing: Testing a rapid and substantial change in workload.

Endurance testing: Testing under sustained workload for an extended period.

Scalability: The ability to accommodate increased workload through additional resources or design changes.

Resilience: The ability to withstand disruption, limit impact, and recover acceptable service.

Recovery time objective (RTO): The maximum acceptable time to restore service.

Recovery point objective (RPO): The maximum acceptable period of data loss.

Threat modelling: Structured identification of assets, threats, trust boundaries, and mitigations.

Accessibility: The extent to which people with diverse abilities can use a system.

Localization: Adaptation of software to language, region, and cultural conventions.

Maintainability: The ease of analyzing, modifying, testing, and evolving software.

Observability: The ability to infer internal system condition from outputs such as logs, metrics, and traces.

Chaos engineering: Controlled experimentation that tests system behaviour under induced failure.

Review Questions

Short Answer Questions

1. Why are latency percentiles often more useful than average latency?

2. Distinguish an SLI, an SLO, and an SLA.

3. What is the purpose of endurance testing?

4. Define RTO and RPO.

5. Why is automated accessibility testing insufficient by itself?

Long Answer Questions

1. Explain how a realistic workload model is designed and used in performance testing.

2. Discuss the relationship among reliability, availability, resilience, and recovery.

3. Describe a layered security testing strategy for a full-stack application.

4. Explain how compatibility, usability, accessibility, and localization testing differ and overlap.

5. Discuss how observability, quality gates, and release practices support continuous quality engineering.

Analytical / Application Questions

1. An API meets its average latency target but its 99th-percentile latency increases sharply during peak demand. Analyze possible causes and propose an investigation plan.

2. A company claims that its backup system satisfies an RPO of fifteen minutes but has never restored a backup. Evaluate the claim and design a verification exercise.

3. A mobile banking service must support older browsers, screen readers, intermittent networks, and strict authentication. Propose a prioritized non-functional test strategy and justify the trade-offs.

22. Multiple Choice Questions with Answers

Question 1

Which requirement is the most testable non-functional quality requirement?

A. The application should be user-friendly.

B. The application should respond quickly.

C. 95% of product-search requests under peak load shall complete within 800 milliseconds.

D. The application should have excellent performance.

Correct Answer: C. 95% of product-search requests under peak load shall complete within 800 milliseconds.

Question 2

Why is the 99th-percentile latency important in performance analysis?

A. It identifies the most common response time.

B. It reveals the experience of the slowest significant tail of requests.

C. It measures server availability directly.

D. It replaces the need to measure error rates.

Correct Answer: B. It reveals the experience of the slowest significant tail of requests.

Question 3

Which test is specifically intended to reveal memory leaks during prolonged operation?

A. Spike testing

B. Compatibility testing

C. Endurance testing

D. Penetration testing

Correct Answer: C. Endurance testing

Question 4

A system continues limited operation when a payment provider is unavailable and later restores normal operation. Which quality attribute is primarily being demonstrated?

A. Resilience

B. Localization

C. Maintainability

D. Portability

Correct Answer: A. Resilience

Question 5

What does an RPO of thirty minutes specify?

A. The maximum time allowed to repair a failed server

B. The maximum acceptable amount of data loss measured in time

C. The maximum response time for a transaction

D. The percentage of requests that may fail

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 6

Which statement best describes a limitation of automated security scanners?

A. They cannot identify any dependency vulnerabilities.

B. They always require production access.

C. They may miss business-logic flaws and produce false positives.

D. They replace threat modelling and penetration testing.

Correct Answer: C. They may miss business-logic flaws and produce false positives.

Question 7

A team tests only one browser because it is used by most customers. What is the strongest reason this may be inadequate?

A. Browser tests are unrelated to compatibility.

B. Other supported platforms may behave differently at relevant interfaces.

C. Compatibility can only be tested manually in production.

D. The most-used browser cannot be tested automatically.

Correct Answer: B. Other supported platforms may behave differently at relevant interfaces.

Question 8

Which practice most directly verifies that a backup strategy satisfies recoverability objectives?

A. Checking that backup files exist

B. Increasing log retention

C. Restoring the backup and validating data and service operation

D. Running a static code analysis scan

Correct Answer: C. Restoring the backup and validating data and service operation

Question 9

Why should keyboard-only and screen-reader testing supplement accessibility automation?

A. Automated tools cannot detect any HTML defects.

B. Human interaction is needed to evaluate task flow and meaningful relationships.

C. Screen readers measure database throughput.

D. Keyboard testing is required only for mobile applications.

Correct Answer: B. Human interaction is needed to evaluate task flow and meaningful relationships.

Question 10

A load test shows throughput stops increasing when CPU remains low, while database lock wait time rises. What is the most plausible interpretation?

A. The client browser is necessarily defective.

B. The database or lock contention is a bottleneck.

C. The system has no scalability limit.

D. The test proves the system is secure.

Correct Answer: B. The database or lock contention is a bottleneck.