From Usable to Loveable: Redefining Software Quality and Testing Costs

Introduction

The rapid rise of large‑model technologies like ChatGPT has shaken the software quality and testing landscape, prompting many quality engineers to feel anxious about insufficient organizational support and short‑term delivery pressures. This article aims to clarify the concept of software quality, guide practitioners in complex environments, and help them make more informed decisions.

Three Layers of Software Quality

Usable (可用) : Ensures the service is stable, meets SLA, and functions correctly. The primary goal is to control business loss caused by defects.

Desirable (好用) : Focuses on user experience, turning a stable service into one that delights users, thereby driving retention and ecosystem growth.

Loveable (爱用) : Encourages users to become advocates, turning the product into a recommendation engine that fuels continuous business growth.

Quality Modeling

A quantitative model links quality to business loss:

Loss = Σ(ChangeCount × IssueDensity × DevelopmentLeakRate × TestLeakRate × HandlingLevel)

. The model breaks down factors such as change types, issue density, development and test leak rates, fault impact, and MTTR, providing a clear view of how each element contributes to overall loss.

Testing Overview

Testing is defined as the set of activities that expose potential defects early and comprehensively. It is divided into verification (VE) – objective correctness checks, and validation (VA) – subjective user‑centric checks.

Testing Process

Test Input : Design realistic test scenarios, data, and environment configurations.

Test Execution : Run the test steps, collect behavior data.

Test Analysis : Observe outputs, detect anomalies, and assess performance.

Test Localization : Pinpoint root causes of detected issues.

Test Evaluation : Estimate residual risk and decide further actions.

Testing Classification

By problem type: performance, functional, security, interface, stability, UI, compatibility.

By object level: unit, module, system.

By technique: precise, automated, stress, exploratory, fuzzing, online, manual.

By responsibility: new‑feature testing (primarily developer‑driven) and regression testing (QA‑driven).

Cost of Defect Recall

The total cost of recalling a defect includes recall effort, localization effort, and fixing effort:

Cost = RecallTime×RecallRate + LocateTime×LocateRate + FixTime×FixRate

. Different recall levels have vastly different costs—white‑box level is mainly labor, module level adds automation cost, and system level incurs higher labor and automation expenses.

Reducing Recall Cost

Two main strategies are proposed:

Reduce Workload : Eliminate ineffective or duplicate test actions by focusing on high‑impact changes.

Adjust Distribution : Shift defect detection to earlier stages (code, module) and leverage machines over humans wherever possible.

Technology is the key enabler for both strategies, providing smarter test input generation, automated analysis, and risk‑driven decision making.

Risk‑Based Testing Technology

Risk‑based testing evaluates potential impact before executing tests, aiming to maximize ROI by avoiding wasteful test execution and uncovering hidden defects. It differs from precise testing by incorporating risk models, dynamic coverage assessment, and automated decision making.

TestGPT – AI‑Driven Testing

Inspired by large‑language models, TestGPT would perceive code changes, decide on test inputs, generate or select test cases, execute them, and evaluate risk. It promises to shift QA from experience‑based work to creativity‑driven, model‑centric workflows.

Conclusions

Software quality is not merely a series of "clicks"; it requires a layered understanding, quantitative modeling, and continuous investment in testing technology. Embracing risk‑based testing, automation, and AI (e.g., TestGPT) can dramatically improve defect recall efficiency, reduce costs, and sustain high‑quality delivery in the era of rapid iteration.