DEV Community: 2SD Technologies Limited

How do you decide two buttons are the same button?

2SD Technologies Limited — Fri, 11 Sep 2026 08:06:46 +0000

Every UI test rests on a claim that sounds trivial and is not: this element, on this page today, is the same element I recorded last week.

Selectors are how we usually make that claim, and they make it by proxy. #checkout-btn does not mean "the button that completes the purchase". It means "whatever has that id", and the relationship between the two is a convention somebody upheld until a release did not.

So the question worth asking is not how to write more durable selectors. It is what would have to be true for a tool to decide, after a change, that two elements are the same thing.

Why the obvious answers do not survive

Use stable test ids. Correct, and it is the best advice in this article -- data-testid attributes owned by the team, treated as API rather than decoration, will prevent most of this. It is also advice that arrives too late for the suite you already have, and it does not survive a component library upgrade that rewrites the markup underneath your attributes, or a third-party checkout widget you do not control, or the two hundred tests written before the convention existed.

Use XPath from a stable ancestor. This trades one fragility for a worse one. A path encodes structure, and structure is the thing most likely to change: one wrapper div for a new layout mode and every path below it is wrong.

Use the accessible name. Much better, and genuinely durable, right up to the point where the copy changes. "Continue" becomes "Continue to payment" in a conversion experiment, and a test keyed on visible text is now keyed on a marketing decision.

Each is right about something. None is right alone, and that is the actual shape of the problem: element identity is not carried by any single attribute. It is distributed across several, each of which is individually unreliable and collectively quite informative.

Identity as a scoring problem

Which suggests treating it the way you would treat any other fuzzy-matching problem: capture several independent signals at record time, and after a change, score candidates against them rather than requiring an exact match on one.

The signals worth capturing are the ones that tend to change independently of each other:

Role. Is it still a button -- not a link, not a div with a click handler? Role is the most stable of the four, because changing it usually means changing behaviour.
Label. The visible text a person would actually click. Unstable under copy changes, but strong evidence when it matches.
Position. The same place in the same form, expressed relative to its container rather than in pixels. Survives restyling; does not survive reordering.
Neighbours. The fields either side of it. This one is underrated: a checkout button whose preceding sibling is still the card-number field is probably still the checkout button, even if its id, text and position all moved.

No single one of those is worth much. A candidate matching three of four, where the fourth is the one that plausibly changed in this release, is worth a great deal.

The part that decides whether any of this is a good idea

Here is where scoring becomes dangerous rather than clever, and it is worth being blunt about it, because this is the difference between a useful mechanism and a liability.

A scorer must be able to decline.

If the implementation always returns its best candidate, you have built something that converts failures into passes. The test was red because the button genuinely vanished; the scorer finds something button-shaped nearby, clicks it, and the suite goes green. You have not fixed a test. You have removed a signal, and you will not find out until production.

So the behaviour under uncertainty is the whole design, not an edge case:

A confidence threshold, below which the run fails -- and fails as a missing element, with the candidates it considered and their scores, not as a generic assertion error.
Every accepted match recorded as a change, in the run output, with the old identity and the new one side by side. A relocation is an event, not an implementation detail.
A way to see those events without going looking for them. If reviewing relocations is an optional screen somebody has to remember to open, nobody opens it, and you are back to silent passes with extra steps.

The uncomfortable implication is that a tool making this claim should sometimes be more alarming than a brittle one, not less: it should fail loudly in exactly the cases a naive selector would also have failed, and the difference should show up only where the evidence is genuinely strong.

What to ask, and what to do if you are not buying anything

If you are evaluating something that advertises self-healing, two questions get to the bottom of it quickly. Ask to see a low-confidence case -- not a demo of a successful relocation, but what happens when the tool is unsure. And ask where accepted relocations appear, and whether anyone on the team has looked at that list this month.

If you are not buying anything, the useful takeaway is smaller and free: when a test fails on a missing element, the debugging information you want is not "selector not found". It is what else was on the page that nearly matched, and why it was rejected. Most frameworks will not tell you that, but you can usually capture it yourself in a failure hook -- dump the candidates with the same role, and their labels, before you throw. It turns a class of ten-minute investigations into ten-second ones, and it costs about twenty lines.

Disclosure

2SD Technologies builds TAI, a testing platform, and relocation-by-scoring is how it handles interface changes. The reason this article spends more words on declining to match than on matching is that we think it is the only part of the idea that is contentious -- the scoring is straightforward engineering, and the threshold is where a vendor's judgement is either sound or expensive for you.

Happy to show you the low-confidence case against your own application, if it would be useful: info@2sdtechnologies.com

Five test tools, five dashboards, and nobody can say what happened

2SD Technologies Limited — Thu, 10 Sep 2026 12:40:07 +0000

Most teams did not choose to have five testing tools. They accumulated them, one reasonable decision at a time.

Something was needed for the browser journeys, so a UI framework went in. The API contract broke twice in a quarter, so a contract-testing tool followed. A load test was required before a launch, and the person who ran it picked whatever they knew. Security scanning arrived through the compliance programme rather than through engineering. And somewhere there is a spreadsheet, or a person, comparing generated customer documents against a baseline by eye.

Each of those was the right call. The sum of them has a property nobody chose.

The bill nobody itemises

Ask what five tools cost and you will be told about licences. That is the smallest line.

The real cost shows up the first time something fails in a way that spans two of them. Here is the shape it takes, and it is worth walking through slowly, because the difficulty is structural rather than cultural.

A checkout total comes out wrong in staging on a Thursday afternoon.

The UI suite is red on checkout_applies_promotion. It has a screenshot of a total reading £48.00 where the assertion wanted £43.20.
The API suite is green. Every contract test passed, including the one covering the pricing endpoint.
The load run was on Tuesday, against a build from Monday, and showed the pricing service at a p99 nobody wrote down, because the run was considered a pass.
The security scan is a weekly job. It ran overnight and is unrelated, but it did restart a container.
The document comparison is not part of any of this, and the invoice template changed last sprint.

Five signals. One of them is red. And the honest answer to "what happened" is that nobody in the building can say, because no two of those signals can be joined to each other.

Why they cannot be joined

This gets mistaken for a communication problem. It is not. The signals are genuinely unjoinable, for four concrete reasons.

There is no shared run identity. The UI suite has a run id. The API suite has a different run id, in a different namespace. Neither carries the other's, and neither carries the id of the build they ran against -- or if it does, it carries the CI job number, which is not the same thing as an artefact version. You cannot ask "show me every signal for build 4471", because no field in any of the five systems means that.

There is no shared clock that matters. Every tool timestamps its own events, and the timestamps are accurate. But the UI failure at 14:32:07 and the pricing service's config reload at 14:31:58 live in two systems with no relationship, so the nine seconds between them is a coincidence until a human notices it. Correlating by eyeballing timestamps across browser tabs is the default technique in this situation, and it is about as reliable as it sounds.

There is no shared environment of record. "Staging" is not one thing. The UI suite pointed at the edge; the API suite pointed at the service directly, bypassing the gateway where the pricing rule actually lives. Both are correct about their own target, and neither is wrong -- which is precisely why two teams can each hold a passing result and still disagree.

The artefacts expire on different schedules. The screenshot is kept for 30 days by the UI tool's default. The API payloads are in CI logs, gone in 7. The load results are wherever that tool keeps them, possibly on a laptop. By the time the argument is settled, at least one piece of the evidence has aged out.

So the meeting happens. The UI team says the API changed. The API team says the payload has always looked like that. Somebody suggests re-running everything, which takes until Monday. Nobody is being unhelpful -- they are each holding a true statement about a different system.

What the release decision is actually made on

Now consider how this reaches a decision.

Whoever signs off does not look at five dashboards. They look at a summary -- a status in a release ticket, or a message in a channel, written by someone who looked at the dashboards. That person compressed five partially contradictory signals into a sentence.

So the decision is made on a summary of a summary, by someone with no way to inspect the evidence underneath. The failure mode is not that they decide wrongly. It is that they learn the summary is unreliable, and start deciding on other things instead: whether the team seems confident, whether the last release went fine, whether the date can move.

That is how a team ends up with a great deal of testing and very little signal.

What "one place" has to mean to be worth anything

The instinct is to consolidate vendors. That is one answer, it is not the only one, and it is worth separating the useful part from the procurement part. The useful part is four properties:

One run identity that spans every kind of check, carried as a field in every event and artefact, and tied to the artefact version rather than the CI job number.
One sink. Every check writes its result to the same store, in a shape that can be queried across kinds. Not a dashboard embedding five iframes -- one queryable place.
One environment of record per run, recorded as data, so "the API suite was bypassing the gateway" is a fact you can read rather than something you discover in the meeting.
One retention policy across artefacts of the same run, so the evidence does not half-expire while it is still under discussion.

None of these requires replacing anything. If you have five tools and no appetite for changing that, the three cheapest moves, in this order, are:

Generate a run id at the top of the pipeline and pass it into every tool as an environment variable or a tag.
Ship every tool's structured output to one place, even if that place is a bucket and a table.
Record the resolved target URL and the artefact version alongside each result.

That is roughly a day of pipeline work, and it converts the Thursday afternoon above from an argument into a query.

The reason a single platform is attractive is not that it does something a well-instrumented set of five tools cannot. It is that those four properties come as defaults, rather than as a project somebody has to fund and then maintain.

Where the signal should land

One more thing, because it tends to be left out of the consolidation conversation.

Having one queryable place is necessary but not sufficient. If the result of all this is a dashboard, it will be read by the people who already read dashboards. What changes behaviour is the finding arriving where the work happens: an issue in the tracker the developers already have open, carrying the run id, the environment of record, and the artefact.

Testing is usually described as a stage sitting between development and release. It is more useful to treat it as the signal a release gets judged on -- the thing that has to be legible at the end, to somebody who was not in the room for any of it.

Disclosure

2SD Technologies builds TAI, a testing platform, so we have an interest in the conclusion. What we would defend is the diagnosis rather than the shopping list: most teams' testing problem is attribution rather than coverage, and the four properties above are worth having whether you get them from one product or from a day of plumbing across the five you already own.

If you would like to talk it through against your own pipeline, we would be glad to: info@2sdtechnologies.com

Your test environment is where the governance stops

2SD Technologies Limited — Tue, 08 Sep 2026 10:02:53 +0000

Every estate has a boundary where the controls get serious. Production sits inside it. Access is brokered, changes are reviewed, reads are logged, and somebody owns the log.

Test environments sit outside it. Not by decision — by accretion. Someone needed a realistic dataset for a migration in 2019, took a snapshot, and the snapshot became the fixture. It got copied into a second environment for load testing, then into a third so a contractor could reproduce a bug. Nobody signed anything, because nobody was doing anything that felt like it needed signing.

That is how the least-governed part of an estate ends up holding the most production-shaped data in it.

Why the data has to be production-shaped

The obvious answer is "then don't use real data", and it is worth being honest about why teams do it anyway.

Test data has to be representative or the tests are theatre. The interesting defects live in distributional properties: the customer with 4,000 orders, the account whose name contains an apostrophe, the address with no postcode, the record migrated from the system before the system before this one. Synthetic generators produce data that satisfies the schema. Schemas are not where the defects are.

So teams reach for a subset of production, and the honest ones anonymise it. Anonymisation is real work and it helps, but it is a spectrum rather than a state — a dataset that keeps the distribution keeps a lot of what makes a record identifiable, and a dataset that does not keep the distribution has stopped being useful for the thing you wanted it for.

The practical position most teams land on is: this data is not production, but it is close enough that we would not want it in a public bucket.

Then a testing tool is pointed at it.

What that makes a testing tool

A testing tool is an unusual thing to introduce into an estate. Consider what it needs in order to work at all:

Credentials for an application, usually more than one set, usually including a privileged one because half the interesting paths are behind an admin role.
Network reach into the environment where that application runs.
The ability to drive the application as a user, which means it can read whatever a user can read.
Somewhere to keep results — screenshots, request and response payloads, database state before and after.

That last one is the part people miss when they think about test tooling as a build-time concern. The artefacts a test run produces are a copy of the data the run touched. A failing API assertion is stored with the payload that failed it. A failing UI step is stored with a screenshot of the screen it failed on, and that screen had a customer's name on it.

So a testing tool is not just a consumer of test data. It is a second store of it, in a place whose retention policy nobody wrote down.

None of this is an argument against test automation. It is an argument that the access model of a testing tool is not a datasheet appendix. It is the thing that decides whether the tool can be adopted at all in an estate that takes its boundary seriously — and it is why these tools get rejected at review by people who were never against the tool.

The four questions, and what a real answer looks like

Reviewers are not asking for reassurance. They are asking for artefacts. Four categories cover most of it.

Identity. Does the tool authenticate against the directory you already run, or does it keep its own user list? A second user list is not a preference difference — it is a population of accounts that does not get deprovisioned when someone leaves, because your leaver process does not know it exists. The answer a reviewer wants is a protocol, not a promise: SAML or OIDC against the existing identity provider, so joiners and leavers are handled by the process that already handles them.

Authorisation. Once someone is in, what can they do? The failure mode here is a tool with one effective permission level, where access control is really URL obscurity — anyone who can reach the run can see the run. Roles need to be coarse enough that people actually use them and fine enough that "can trigger a run against the payments service" and "can read the payloads that run captured" are separable, because those are genuinely different privileges.

Tenancy. If the tool is multi-tenant, what enforces separation, and at what layer? "Separate databases" and "a tenant_id column and a WHERE clause" are both answers to that question, and they are not the same answer. If the tool runs inside your own boundary, the question changes shape rather than disappearing: separation is now your own controls' problem, which is usually what a reviewer prefers, because they can already audit those.

Evidence. And this is the one worth being precise about.

"A run happened" is not the same artefact as "here is what it could see"

Most tools can produce a list of runs. Who triggered it, when, against which environment, pass or fail. That is an activity log, and it answers a question about the tool.

The question a reviewer is actually asking is about the data. Which endpoints did that run call? Which records came back? Which of those artefacts are still stored, and for how long? If a screenshot captured a customer record, is that screenshot inside the retention window that applies to the record, or the one that applies to build artefacts?

Those are different logs. The first is cheap and every tool has it. The second requires the tool to have been built with the assumption that its own outputs are sensitive — which mostly means decisions made early: artefacts stored with the same classification as their source, retention configurable per artefact class rather than globally, and redaction available at capture rather than as a cleanup job.

You can test for this in about five minutes. Ask to see the audit view for a run that touched customer data, and ask which of the artefacts from that run still exist. A tool that has thought about it will show you. A tool that has not will show you the activity log again.

A short checklist

Portable, and not about any particular product:

Does it authenticate against our identity provider, or keep its own user list?
Can "trigger a run" and "read what the run captured" be granted separately?
What enforces tenant separation, and at which layer?
For a run that touched customer data: which artefacts still exist, and under whose retention policy?
Where are those artefacts processed, and does that answer change under load?

The fourth one is the one that finds things. It is also the one most likely to be answered with a screenshot of a dashboard rather than a policy, which is itself the answer.

Disclosure

2SD Technologies builds TAI, a testing platform, it runs inside the customer's own environment, which means most of question three becomes a question about controls the customer already audits — and the checklist .

The bug your requirements cannot contain

2SD Technologies Limited — Thu, 03 Sep 2026 09:55:35 +0000

There is a category of defect that cannot appear in your acceptance criteria. Not because
nobody thought of it, but because the shape of a requirement has no room for it.

A requirement describes a state and a rule. A customer can apply a valid promo code at
checkout. State: the code is valid. Rule: it is accepted. Both are evaluated at a single
instant, because a sentence has one tense.

Real systems do not have one instant. They have two, and sometimes a lot more.

The gap between checking and using

Take that promo code. The system validates it when the customer types it into the basket. The
system commits it when the customer pays. Between those two events sits an unbounded amount
of time — thirty seconds if they have their card handy, three days if they leave the tab open
on a laptop lid.

If the code expires in that gap, what happens?

The requirement cannot tell you. It never contemplated a gap, because it was written as one
sentence about one moment. And a test written by hand almost certainly cannot tell you either,
because a person writing a test naturally writes it the way they would perform it: enter code,
assert accepted, pay, assert charged. Three lines, one instant, no gap.

This is time-of-check to time-of-use. Most developers first meet it as a security problem —
access() then open(), and a symlink swapped in between. The same shape appears at business
timescale, and there it is far more common and far less discussed:

Stock is reserved at basket, decremented at dispatch. Someone else buys the last one.
A permission is checked when the page loads, enforced when the action fires. The role changed.
A price is quoted at quote time, charged at renewal. The tariff moved.
A rate limit is checked at admission, consumed at execution. The window rolled over.
A feature flag is read at session start, branched on at submit. Someone flipped it.
A token is validated at the gateway, used by a downstream call. It expired in flight.

Every one of those is a real defect class, and not one of them will be written into a
requirement, because in each case the requirement is correct. It is the world that has two
timestamps.

Why it survives to production

It survives because it passes every test anybody wrote, and because it is not reproducible on
a developer's machine at a developer's speed. You cannot see it by clicking through the flow,
because you click through the flow in eleven seconds.

It also survives because the failure is usually silent and plausible. The customer gets
charged full price and does not notice. The order ships without the discount and support
handles it as a one-off. Nothing goes red. You find out from a pattern in refunds, three
months later, and by then the pattern is the only evidence.

Testing for it deliberately

The technique is not complicated. It is just not what a hand-written test looks like, and you
have to decide to do it.

Split the transaction in your test. Instead of one continuous flow, make the two moments
explicit and put a mutation between them:

# not this
apply_code("SAVE10")
assert basket.discount == 10
pay()
assert charge == 90

# this
apply_code("SAVE10")
assert basket.discount == 10

expire_code("SAVE10")          # move the world, not the clock in your test runner

result = pay()
assert result.status == "revalidated"
assert charge == 100           # or whatever you decided it should be

The important line is the third one. To write it you need the ability to change state
between two calls — which usually means a test seam your system does not have yet, and
which is the real reason this class goes untested. Adding it is the work.

Then pick the case that hurts. For each two-phase interaction, ask what changes in the
gap, and who changes it:

Who moves the world	Example
The clock	the code, token or quote expires
Another user	the last unit of stock is bought
An administrator	a role, a flag or a price is changed
The system itself	a batch job settles or reconciles

Four questions per interaction, not thirty. It is a tractable list once you accept it exists.

What to do about it in the design

Testing tells you it is broken. Fixing it is a design decision, and there are only really
three options:

Re-check at commit. The honest default. Costs a round trip and can surprise the user at the worst moment, which is why it needs a typed result and a real UI state — not an exception that renders as "something went wrong".
Hold the promise. Reserve the stock, lock the price, honour the code you already accepted. Correct from the customer's point of view and expensive from the business's, and it needs an expiry of its own or the reservations pile up.
Make it atomic. Collapse the two moments into one so there is no gap. Usually only available for interactions inside a single system.

The one option that is never right is the accidental one: check at entry, commit at payment,
and never state which of the three you chose. That is not a design, it is a coin flip
resolved by whoever is unlucky.

The uncomfortable bit

If you have never tested this class, you almost certainly have some. Not because your team is
careless — because a requirement is a sentence, a hand-written test mirrors the requirement,
and neither has a second timestamp in it.

Pick your most valuable two-phase interaction. Write one test that changes the world in the
middle. See what happens.

*Disclosure: this post is published by 2SD Technologies, where we build TAI — a testing platform that generates cases from requirements, user stories and the application, including this category. *

Generating test cases is the easy part

2SD Technologies Limited — Wed, 02 Sep 2026 09:07:50 +0000

This post has moved. The current version, with the animation, is here: https://dev.to/2sdtechnologiesdotcom/generating-test-cases-is-the-easy-part-2l3a

There is a ceiling on your test coverage and it is not technical.

Running tests has been a solved problem for a long time. Runners are fast, parallelism is cheap,
CI is a commodity. None of that touches the actual limit, which is that somebody has to sit
down, read the requirement, work out what could go wrong, and write the cases.

So coverage ends up being a function of how much of that a person had time to do. Not what could
break. Not what changed in this release. What fitted in the sprint.

A worked example

Take one line of acceptance criteria:

As a customer I can apply a promo code at checkout.

Ask a competent engineer to cover it and you will reliably get three cases:

a valid code is accepted
an invalid code is rejected
an expired code is rejected

Those three are not a failure of skill. They are the three cases stated in the requirement.
The requirement has one happy path and two named error conditions, so you get one happy path and
two named error conditions.

Now here is a different list for the same line:

the same code applied twice in one basket
a code at exactly the minimum basket value
a code combined with a gift card
a code on a partially refunded order
a code applied in a second currency
a code that expires between basket and payment

Every one of those is a defect worth betting on. And not one of them is in the requirement.

The pattern

Those six are not a grab bag. They fall into categories, and the categories generalise to
anything you are testing:

Category	The question it asks	In the example
Idempotency	What if this happens twice?	the same code applied twice
Boundary	What happens exactly at the threshold?	exactly the minimum basket value
Composition	What if another feature is active at the same time?	code plus gift card
Prior state	What if the entity has history?	a partially refunded order
Locale	What if the assumptions about format are wrong?	a second currency
Time-of-check to time-of-use	What if state changes between validation and commit?	expires between basket and payment

That last row is the interesting one, because it is a genuine race and it is the one least likely
to be written by hand. Validation happens when the code is entered. Commitment happens at
payment. If your expiry check runs only at entry, the bug is invisible in every test that treats
the basket as instantaneous — which is every test somebody writes at their desk.

The requirement will never mention it. It is not a requirement. It is a consequence of the
requirement meeting a real system.

This is the actual gap. Not execution. Not maintenance. Enumeration.

So generate them — but that is where it gets interesting

Producing that second list from the requirement plus the code is tractable. Language models are
good at enumerating category × feature combinations, and the categories above are a decent prompt
on their own. You can try it this afternoon.

The hard part is that a generated case is only worth having if four things are true.

1. It is traceable to something. A case you cannot tie back to a clause in the requirement or
a branch in the code is a case nobody can review, and a case nobody reviews will not survive its
first false failure. Whatever generates the case has to carry the provenance with it.

2. It is prioritised. Six extra cases per acceptance criterion, across a real backlog, is not
coverage — it is a suite nobody runs. Generation without ranking converts an enumeration problem
into a scheduling problem. Something has to say these two matter for this change.

3. It survives maintenance. This is where self-healing selectors earn their place, and it is
worth being precise about why. Self-healing on a hand-written suite is a convenience. Self-healing
on a generated suite is a precondition — because the whole proposition is more tests, and more
tests hand-maintained is just more maintenance. Healing is the floor that makes the volume viable.
It is not the feature.

4. It fails loudly when it is unsure. Any mechanism that relocates a moved element is making a
judgement. A tool that quietly picks the nearest match when nothing scores well has not saved you
a failure; it has converted a red test into a green one that proves nothing. A heal nobody can
review is a silent pass, and a silent pass is worse than a broken test because you stop looking.

The honest trade

Generation does not remove human judgement from testing. It moves it — from authoring cases to
reviewing them. That is a genuinely better place for it to sit, because reviewing a proposed
case against a requirement is faster than inventing one from scratch, and because the categories
above are easier to check than to remember.

But it is a trade, not a free win. If your team has no capacity to review, generation will produce
a large suite of plausible tests with unexamined assumptions baked in, and you will have moved the
problem rather than solved it.

Start with one acceptance criterion. Generate against the six categories. See how many of the
results you would actually have written. That number is your coverage ceiling, and it is usually
uncomfortable.

Disclosure: this post is published by 2SD Technologies, where we build TAI — a testing platform that does the generation, prioritisation and healing described above.

Generating test cases is the easy part

2SD Technologies Limited — Mon, 31 Aug 2026 14:20:10 +0000

There is a ceiling on your test coverage and it is not technical.

So coverage ends up being a function of how much of that a person had time to do. Not what could
break. Not what changed in this release. What fitted in the sprint.

A worked example

Take one line of acceptance criteria:

As a customer I can apply a promo code at checkout.

Ask a competent engineer to cover it and you will reliably get three cases:

a valid code is accepted
an invalid code is rejected
an expired code is rejected

Now here is a different list for the same line:

the same code applied twice in one basket
a code at exactly the minimum basket value
a code combined with a gift card
a code on a partially refunded order
a code applied in a second currency
a code that expires between basket and payment

Every one of those is a defect worth betting on. And not one of them is in the requirement.

Three to nine, from the same one line.

The pattern

Those six are not a grab bag. They fall into categories, and the categories generalise to
anything you are testing:

Category	The question it asks	In the example
Idempotency	What if this happens twice?	the same code applied twice
Boundary	What happens exactly at the threshold?	exactly the minimum basket value
Composition	What if another feature is active at the same time?	code plus gift card
Prior state	What if the entity has history?	a partially refunded order
Locale	What if the assumptions about format are wrong?	a second currency
Time-of-check to time-of-use	What if state changes between validation and commit?	expires between basket and payment

The requirement will never mention it. It is not a requirement. It is a consequence of the
requirement meeting a real system.

This is the actual gap. Not execution. Not maintenance. Enumeration.

So generate them — but that is where it gets interesting

The hard part is that a generated case is only worth having if four things are true.

The honest trade

Disclosure: this post is published by 2SD Technologies, where we build TAI — a testing platform that does the generation, prioritisation and healing described above.