2.1 AI-Based vs Conventional Systems

2.1 AI-Based vs Conventional Systems

When you test a payroll engine, a tax calculator, or the firmware in a microwave, you are usually testing a conventional system. A person wrote the rules. The code says what to do, in what order, and under which conditions. When you test a photo app that labels cat versus not-cat, a credit model that scores default risk, or a chatbot that drafts an email, you are testing an AI-based system. Ordinary software still wraps the model—APIs, queues, access control—but the important decision procedure often lives in a model that was fitted to data, not in a list of if-then statements a developer typed by hand.

That split is the first testing fork in the road. It changes what you can predict, what you can explain after an incident, what you must watch in production, and what the word coverage even means.

How conventional systems decide

Conventional software is typically written in imperative languages: the programmer specifies step-by-step instructions. The familiar building blocks are not optional decoration; they are the policy:

• Assignments and data structures that hold known business facts (tax tables, speed limits, account flags)
• If-then-else branches that encode rules (if the account is overdue more than 30 days, refuse the withdrawal)
• Loops that walk records, retry a network call, or accumulate a total
• Deterministic functions that, given the same input and the same stored state, produce the same output

Because the rules are explicit, a competent reader can usually trace why a given input produced a given output. That transparency is why classical testing techniques still earn their keep: you can build a decision table from the specification, force every interesting branch, and compare the result with an independently calculated expected value (the test oracle).

Conventional systems are not simple by definition. A compiler, a database query planner, or a fly-by-wire control law can be extraordinarily sophisticated. The point is not intelligence-looking complexity. The point is where the decision procedure comes from. In a conventional system, humans authored the procedure. If the business changes, humans change the code or the configuration the code interprets. Until someone ships an update, the system's policy is static.

How AI-based systems, especially machine learning, decide

Most AI-based systems that testers meet in production are built with machine learning (ML). Instead of writing cat-detection rules, a team collects images, labels many of them as cat or not-cat, and runs a training procedure that adjusts a huge set of internal numbers (parameters) until the model does well on that data. The deployed program still has ordinary code around the model, but the classification policy is not a handwritten taxonomy of whiskers and pointed ears.

Try, for a moment, to write a conventional cat classifier. You might start with if the image has triangular ears and vertical pupils, then cat. You immediately drown in exceptions: hats, cartoons, night photos, lynxes, and dogs with pointed ears. An ML classifier does not store that rule list. It stores a pattern extracted from examples. Show it a new photo and it computes a score—often a probability—that the photo belongs to the cat class.

That is a different kind of program:

• The requirements for the core decision are partly data, not only a written specification
• The same input can yield slightly different outputs across versions, random seeds, sampling settings, or even parallel hardware
• Correct is often a rate (for example, recall on a held-out set) rather than a single golden string

The serving code can still be conventional and well specified. Testers who only read that code will miss the product. The product is the composition of pre-processing, model, threshold, and downstream action.

Probabilistic reasoning versus a single right number

Many AI-based systems reason probabilistically. They estimate how likely an outcome is, then a surrounding policy turns that estimate into an action: show the label, block the transaction, or ask a human to review.

A conventional checksum either matches or it does not. A medical-image model might output 0.81 probability of a finding. Downstream software might treat anything above 0.70 as flag for radiologist. Testers must understand both layers. The model can be statistically strong and still be operationally wrong if the threshold is careless. The system can be deterministic in its code and still be non-deterministic in its observable behavior if the model, the decoding temperature, or a retrieval index moves.

Non-determinism shows up in several practical ways:

• Random initialization and data shuffling during training produce different models from the same recipe
• Stochastic decoding in generative models (temperature, top-k sampling) produces different texts for one prompt
• Floating-point parallelism can change low-order bits of a score
• Online learning or periodic retraining means yesterday's expected output is not a lifetime contract

None of this means anything goes. It means your oracle is often a band, a metric, a relationship that should hold across inputs, or a human rubric, not a single hardcoded byte.

Explainability and the black box

A conventional function of a few dozen lines can be stepped through in a debugger. A modern deep model may contain billions of parameters. No tester—and no clinician, loan officer, or accident investigator—can meaningfully inspect each weight. That black-box character is not an insult. It is a structural fact about high-capacity models.

Explainability matters most where a wrong or unjustified decision harms people or the public:

Around the model you will still find conventional code that can be traced: feature stores, rule-based overrides, audit logs, kill switches. Testers should map that hybrid. Do not pretend the neural net is a flowchart. Do not ignore the flowchart that wraps the neural net.

Techniques such as feature-importance plots, saliency maps, and local surrogate models can give partial stories. Treat them as evidence, not as a proof of internal correctness. A heatmap that highlights the hospital logo instead of the lesion is a defect, not a documentation flourish.

Adaptability versus a static conventional release

Conventional systems typically wait for a human to ship a change. If tax rates change, someone edits a table or a function and regression-tests the release. AI-based systems can be self-learning or frequently retrained: they update their behavior as new data arrives. That adaptability is valuable in fraud detection, recommendation, and speech recognition, where the world does not sit still.

Adaptability is also a testing liability. A model that keeps learning can drift away from the behavior you certified. Data can shift (new phone cameras, new slang, new fraud tactics). Feedback loops can amplify bias. An attacker can poison the training stream. For that reason, adaptive systems demand continuous monitoring: track live metrics, data schemas, slice performance, and incident rates so the system still satisfies the core requirements you accepted at release. A one-time factory test is not a lifetime argument.

Some ML systems are locked after training: the production artifact does not keep fitting itself. Locked systems still age, because the world changes, but they do not silently rewrite their own parameters between releases. Testers must know which kind they have. Later study in this guide returns to locked versus adaptive systems in depth. Here, remember the contrast with conventional software, which is locked by construction until a person changes it.

Comparison testers actually use

flowchart TB
  subgraph conventional [Conventional]
    R[Explicit if-then rules and loops]
    D[Deterministic inspectable flow]
    R --> D
  end
  subgraph aibased [AI-based ML]
    Data[Examples and labels]
    Model[Learned parameters]
    P[Probabilistic scores and policies]
    Data --> Model --> P
  end
  D --> MonitorConv[Change via human release]
  P --> MonitorAI[Change via data retraining and monitoring]

What testers should change in their habits

If you carry only conventional instincts into AI testing, you will under-test the risky parts and over-trust the easy parts.

Expect non-determinism. Design checks that remain valid when scores jitter. Repeat inference. Fix random seeds in the lab when you need reproducibility, and still exercise the non-seeded production path.

Invest in oracles and thresholds. When there is no single correct caption or bounding box, define acceptance as a metric window, a human grading guide, a set of invariants (the system must not diagnose from the hospital logo), or a comparison against a previous model. Record the threshold policy; a 0.50 cutoff and a 0.90 cutoff are different products.

Do not treat code-path coverage as enough. You can cover every line of the pre-processing script and still have a model that fails on night-time photos, a minority dialect, or an adversarial sticker. Coverage of the wrapper is necessary and nowhere near sufficient. You also need data coverage, scenario coverage, and behavioral testing of the model.

Keep conventional testing where it still applies. Authentication, encryption, access control, latency budgets, and crash handling remain ordinary software. The AI core does not excuse skipping those tests; it adds another test object beside them.

A useful picture for the exam: the conventional system is a recipe someone wrote. The ML system is a palate trained on thousands of meals. Both can serve dinner. Only one lets you read the recipe line by line. Your job is to know which kitchen you walked into, and to pick oracles that match that kitchen.