SPF Consulting Automating Everything

Quality is Exciting, Automation is Boring. Holism and Atomicity are Crucial

Automation everywhere? On Accuracy and Correctness of Predictions

Expectations, or better: “expected results“, as we have them in functional testing, user stories, use cases or business cases, can only be applied for the checking of outcomes, where we have situations in which we know the answers to our questions. I.e., areas, where we use machines to make us faster. Arithmetics e.g., or simple business processes, where the human is underwhelmed and inaccurate and should be replaced by an automaton.

SPF Consulting Automating Everything

Automation, as it seems, is only applicable in boring fields of work.

More sensible use of digital machinery is found in predictive areas. Where we either e.g. literally want to predict the future (forecast) or understand risk (finance) or similar. Some parts of the software, however, are of predictive nature in most if not all IT solutions. It’s complicated, no, wait, complex.

Unfortunately, this is incompatible to standardized rules as wished by most administration.

There is no conveyor belt like work in the software industry.

But there is no way of knowing beforehand what a predictive instrument should deliver as an outcome, by definition. Expected results, but also our dear friends “Definition of Done“, “Acceptance Criteria“ and in the end also “User Story“ have no raison d’être in this whole area.

We need more quality – not medieval style, centralized regulation.

It is therefore of vital importance to have a solid ground, a way of not making mistakes on a base level. Atomic quality (Unit Testing) is the only way not to get combinations of complex systems producing inaccurate results in an unrecognizable way. Latter is leading to a world that accepts old and wrong results or bad practice as a reference and enables religious wars against good innovation because it is not understood. Like the legend of iron in spinach.

AI is no better.

This, of course, also holds true for machine learning, as there is no way of telling how one single weight or parameter influences the whole machine. The rising hype of “AI” called machine learning leads to even more people joining the “vernacular” programmers community. Quality is neglected all over, professional crafting is marginalized, even seen as unnecessary. If we ask data scientists about testing, the answer is „of course, we have training sets and test sets“ (-: . Expect to have more wrong statistics, fake news, crashing planes and missing target space missions.

Regression Testing is not a Save Space?

One popular attempt to alleviate the problem is to see if the built solution would have predicted the present if given the past as input. Experience as wisdom, which, in the end, also is what machine learning does. Experience, though, cannot predict the future.

Use case based functional testing without checking for outcome is not totally useless. It can reveal coverage statistics, bad exception handling and excess of runtime. But on the other hand, semi randomly generated tests can do that even better.

Yesterday’s weather.

Using the weather forecast as an example: The quality of the outcome increased over the years mainly by abstraction/extraction of better models out of the bare data and by putting sensors everywhere to get good data from micro climates in the first place. Not by having countless red regression tests in legacy software.

Commonly understood underlying models

The other crucial element for not making mistakes is speaking the same language and using a common domain to ensure the outcomes are not driven by misunderstandings and single interest drivers. Documentation is not good enough in this case. We need clear contracts.

So, now what?

Bottom line. There is no quality without unit testing and mutual theory building and good plausibility is reached with intuition and exploratory testing. It’s time to stop reading code and start to writing it better.

But I repeat myself.


Contact Information


Danilo Biella, Agile & Quality Professional



SPF Consulting AG - Insights - Teaching the Mob to students

No, we do not just learn from our mistakes!

Do we learn best from our mistakes?

Many unscientific pseudo-psychological posts from self-proclaimed coaches on social media claim that we learn best from mistakes, from our own mistakes, even. That is just not true. The attempt to move from finger pointing high-blame practice to fail-fast agile ways is sensible and lovable of course, but as always there is no simple answer to complex questions.

Why did this even come up? I have been hearing cheap ways of saying for a long time, now (“learning by burning“? Seriously?), but lately everybody seems to explain their lives with them.

Nature versus Nurture

or, it sounds better in German: Kultur gegen Natur. Culture wins. Twice. We mainly learn from patterns inferred and shown by parents, stories told by main peers and education.

The reason why humans overtook the apes in evolution is because we outsourced instincts into wisdom, wisdom that is transferred through culture, not through genes and not by making our own mistakes. That way there is space for even more culture in our heads without making the gestation period non-survivable.

Never mind the Bambi lie

That is the reason why a baby deer does not eat poisonous plants without being taught anything and human kids need to train for decades before becoming capable of surviving. Apparently there is no free lunch.

Do we really learn from mistakes?

Of course not, at least not in general. We tend to suppress negative experience in order not to be traumatized and non-functional on a long-term. And history repeats itself, we repeat the same mistakes over and over again.

A few counter examples

If we really learn from our mistakes,

  • Why do we go to work while being ill and cough all through the way there in public transport, not even months after lock-down restrictions?

  • Why do we still believe evolution needs growth?

  • Why do we believe populist harmful short-term solutions, although they never have worked?

We do learn from success

The statement that we only learn from mistakes can only be believed by people who never had success. Poor them. The same does not count for the people who spread these claims. They clearly make a profit by selling their theories to unsuccessful people. What a tragic development – that actually proves the saying wrong. Those people have learned that their success can be repeated by making weak people feel miserable in a variety of new ways by commodifying ineffective solutions.

Fail fast? Sure!

Failing fast is about making experiments in order to recognize mistakes in made assumptions as soon as possible. It is not about glorifying failure and seeking not to be successful. Trying to get away from Waterfall is important. Overdoing it doesn’t help. Simplification doesn’t help. Because, as always, there are no simple solutions to complex problems.


This is another example of everybody wanting a slice of the hype topics‘ cake without having a clue about the regarding topics. Pseudo-science on the large. If we really were only learning from mistakes, we would be degenerating already because of negative selection. Oh wait. We probably are. Happy exponential activism, everyone (-:


Contact Information


Danilo Biella, Agile & Quality Professional



SPF Consulting AG - Insights - Testautomatisierung: Kritik and den blinden Wahnsinn

Testautomatisierung: Kritik an die blinde Automatsierungswut

Automatisch ausgeführte Checks sind von Anfang an automatisch, nicht automatisiert. Echtes Testen jedoch ist bildend, explorativ und kreativ. Ein Überführen vom einen in den anderen Bereich ist a priori nicht sinnvoll.

Testautomatisierung kritisch betrachtet.

SPF Consulting AG - Insight - Testautomatisierung: Kritik and den blinden Wahnsinn

Testautomatisierung im herkömmlichen Sinne versteht sich leider als Stütze vom “manuellen Testen“, in dem man Tests, die mehrmals ausgeführt werden mussten, durch Automaten ausführen lässt und so vermeintlich wiederholbar werden lässt und Personal einspart.

Dabei nimmt man oft – insbesondere bei Legacy Projekten – ohne besseres Wissen schwergewichtige Werkzeuge zur Hand, die alles tun, was vom menschlichen Clickthrough herrührt – und vergisst oder ahnt nicht, dass dabei etliche Probleme erst entstehen.

  • Solche Tests sind in der Regel Langläufer, deren Zweck mit schnellen Units auch erfüllt werden könnte, ohne den ganzen Applikationskontext hochzufahren.
  • Sie hinken dem Entwicklungsprozess hinterher, werden unkompatibel zur Funktionalität und müssen neu geschrieben werden, ohne dass sie Fehler finden.
  • Sie spiegeln nicht reproduzierbare oder nicht deterministische Verhalten (flakey Tests). Dadurch sind Testläufe selten bis nie grün.
  • Sie sind äusserst redundant und jeder neue Test trägt immer weniger zu einer echten Abdeckung bei.
  • Sie dokumentieren alte Bugs, die nie wieder kommen und exponenzieren die Menge an Tests, obwohl Bugs eigentlich nicht wieder kommen, wenn man versionieren kann. Der Glaube, man müsse für jeden gefundenen Fehler einen funktionalen Test schreiben, ist so etwas wie der Eisengehalt vom Spinat.

Das alles führt dazu, dass man die notwendige Schnelligkeit nicht erreicht, ja zum Teil die Ausführung länger geht als die Zeit zwischen zwei Releases.

Professionelles Test Management ist sich dessen bewusst und erspart den Projekten Lizenz-, Herstellungs- und Betriebskosten.

Gute Tester:innen sind Menschen mit Fachverständnis von Business Analysierenden oder Superusern und mit Erfindergeist, um dort zu stören, wo man es bisher nicht erwartet hatte. Das echte Testing ist eine lernende, evolutionäre und kreative Disziplin und kann (noch?) nicht von Automaten erledigt werden. Auch nicht von künstlichen Intelligenzen, obwohl man letztere durchaus als Werkzeug einsetzen soll, wo es hilfreich ist.

Wo – also – automatisieren?

Automatische Tests (oder besser: Checks) sind von Anfang an automatisch. Hier ein Auszug der Möglichkeiten:

  • Unit Tests: Diese werden von den Entwickelnden in der Umsetzung erstellt, vorzugsweise mit Test Driven Development (TDD) und Abdeckungskriterien. Sie sind schnell und können beim Kompilieren oder spätestens beim Rückführen der Änderungen des Programms ausgeführt werden, ohne dass es Wartezeiten erzeugt.

  • Funktionale Tests: Im Optimalfall basieren sie auf Use Cases oder Business Cases. Sie sind soweit abstrahierbar, dass man daraus direkt Tests generieren kann. Sie sind Schnittstellen basiert und bringen erwartete Ausgaben mit sich, die man mit dem Code versionieren kann. Respektive, man lässt sie gegen mehrere Versionen laufen und prüft damit die getroffenen Annahmen und die Rückwärtskompatibilität. In der Grundfunktion sind diese Tests nicht integrativ.
    Durch Ein- und Ausschalten der Umsysteme wird ermöglicht, deren Simulation (Mock Ups) über die mehrfache Versionierung zu speichern.

  • Generative Tests: Der Automat kann dort am besten helfen, wo der Mensch sich besser mit intelligenteren Aufgaben beschäftigt. Durch systematische, teilzufällige Proben (z.B. mit Quickcheck) werden Fehler aufgedeckt, die man durch überlegtes Handeln allein nicht gefunden hatte.

Zusammenfassend erzeugt das Nutzen von big time Testing Tools mit tausenden von „Langläufern“ eine falsche Sicherheit bei den Verantwortlichen. Eine Abdeckung wird nicht erreicht, die Redundanz der Tests ist sehr hoch. Die Tests sind dabei selten grün, werden dadurch bald nicht mehr beachtet und die Qualität wird am Ende verschlechtert. Neue Fehler werden nicht bemerkt, da man keine Veränderung feststellt und schnell zum Resignieren neigt: „Ach, das war gestern schon rot“. Zusätzlich frustriert es alle Mitarbeitenden, was das Problem verstärkt. Testen wird immer noch mehr zur unbeliebten Disziplin, die man lieber delegiert, statt integriert. Wichtige Grundlagen für agiles Arbeiten sind dadurch vernichtet. Die Qualität wird verunmöglicht.

Bei Unklarheiten oder Fragen zum Thema sind wir selbstverständlich jederzeit für ein Gespräch verfügbar.


SPF Consulting AG - Danilo Biella - Agile & Quality Professional

Danilo Biella, Agile & Quality Professional