Reliability in the AI-enabled future (5/8)

Testability determines agility.

Not low/no code. Not faster code generation.

Agility is determined by mathematically testable architectures, that ensure integrity of the software that's built.

Legacy testing offers general approaches.

Legacy testing is fragmented in unit, UI and integration tests.

Software's future is native testability, using first-class constructs that naturally assist a software's users against regressive behaviour of itself.

The challenging problem of testing business orchestration problems.

Think of a common business orchestration problem with 10 tasks.

Each task having 5 possible actions.

There are 9765625 (or 5 to power 10) possible testing paths.

Having 100 or 5000 automated test cases, that are hard to maintain do not make a difference in changing probability of regression when problem space is humongous (9765625).

Hence, it is observed that most business orchestration systems get manually tested, with coverage for shallow happy paths and few exotic corner cases.

The alternative to legacy testing methodology: reliable digital components.

What if the workflow system in above example is focused on building reliable tasks. Each task has just 5 entry and 5 exit paths (2x5 = 25 testing paths).

The problem of testing is now tractable and we can genuinely have a reliable task, that does a micro-function really well.

Now, assume that such tasks are orchestrated by pure math functions, that do not have side effects.

An activity consisting of such reliable tasks and tested pure math functions can also be deemed reliable.

The key to reliable business orchestration problem is certified reliable digital components that collectively solve the problem.

An analogy from the hardware world.

The hardware world relies on this principle to build very large, complex, interconnected, reliable systems from tiny reliable and easy to test logic gates.

Why isn't testing already solved?

While functions can be unit tested, existing software architectures do not allow interface components to be tested in isolation from other components.

This is likely to change as architecture teams must shift to delivering easy and mathematically sound testability at every layer, including the interface layer.