Blog

Woher wissen Sie, dass etwas ein Fehler ist? - Mentale Modelle und Orakel beim Testen verwenden

Joost van Wollingen

Aktualisiert Oktober 21, 2025
6 Minuten

Haben Sie jemals ein Problem gefunden, bei dem Sie sich nicht sicher waren, ob es ein Fehler war? Wahrscheinlich haben Sie darüber nachgedacht, in den Anforderungen nachgeschlagen oder mit einem Teammitglied diskutiert. Vielleicht haben Sie es selbst herausgefunden, die Anforderungen haben Ihnen Klarheit verschafft oder Ihr Teammitglied konnte Ihnen weiterhelfen. In jedem Fall brauchten Sie eine Informationsquelle, um das Problem als Fehler zu erkennen. Sie haben Ihre mentalen Modelle und Orakel benutzt.

Mentale Modelle und Orakel sind beide nützliche Hilfsmittel beim Testen. Sie helfen Ihnen festzustellen, ob das Verhalten, das Sie beobachten, ein Problem ist oder nicht. Vor kurzem habe ich eine Gruppe von Entwicklern gefragt, woran sie erkennen, ob etwas ein Fehler ist oder nicht. Schauen wir uns die Antwort an, die mir am besten gefallen hat:

"Normalerweise weiß ich es einfach, aber wenn ich wirklich nicht weiß, ob es ein Problem ist oder nicht, dann frage ich den Produktverantwortlichen.


Mentale Modelle - "Ich weiß es einfach"

Wenn ein Entwickler sagt "Ich weiß es einfach"sagt, verwendet er oder sie einen Mechanismus, um festzustellen, ob ein gefundenes Problem ein Problem ist oder nicht. Wir Menschen machen alle Gebrauch von solchen Mechanismen. Einer dieser Mechanismen sind mentale Modelle. Ein mentales Modell ist eine Erklärung dafür, wie etwas funktioniert[1]. Es hilft uns, über die Welt und die Aufgaben, die wir erledigen müssen, nachzudenken. Wir konstruieren sie in Situationen, die uns fremd sind, um uns eine Strategie zur Lösung von Problemen zu geben, mit denen wir noch nie konfrontiert waren.

"Ein mentales Modell ist eine Erklärung für den Denkprozess einer Person darüber, wie etwas in der realen Welt funktioniert."[2]

Ein vereinfachtes mentales Modell einer Schaltfläche auf einer Webseite könnte so aussehen:

  • Es ist ein Objekt auf einer Webseite (ich kann es sehen)
  • Es hat eine gewisse Affordanz[4], die anzeigt, dass es sich um ein Objekt handelt, mit dem man interagieren kann (ich kann es anklicken)
  • Es wird eine Wirkung haben (Wenn ich darauf klicke, passiert etwas)

Nehmen wir nun an, der betreffende Entwickler hat ein Problem mit einer Schaltfläche auf seiner Website festgestellt: Wenn die Login-Schaltfläche angeklickt wird, wird der Login-Dialog nicht angezeigt.

Mit diesem mentalen Modell im Hinterkopf ist es leicht zu erkennen, wo die Diskrepanz zwischen der beobachteten und der erwarteten Situation liegt: Die Wirkung der Schaltfläche ist nie eingetreten. Das ist ein klarer Verstoß gegen die Funktionsweise von Schaltflächen und es ist sehr wahrscheinlich, dass diese Beobachtung des Entwicklers ein tatsächliches Problem darstellt.

Sie werden feststellen, dass dieses mentale Modell einer Schaltfläche auf jede beliebige Website angewandt werden kann, der Entwickler braucht keine Kenntnisse über diese spezielle Website. Ähnlich wie Ihr mentales Modell des Autofahrens es Ihnen ermöglicht, Ihr eigenes Auto zu fahren, aber auch ein Mietauto. Natürlich reicht dieses Modell vielleicht nicht aus, um ein Auto zu reparieren, wenn es ein Problem gibt. Das liegt daran, dass mentale Modelle Vereinfachungen der Realität sind[2], sie beruhen auf Überzeugungen und nicht auf Fakten[3]. Wie alle Modelle sind auch sie fehlbar[5]. Ich bin vielleicht nicht in der Lage, das Auto zu reparieren, aber ein Mechaniker wird ein viel detaillierteres mentales Modell verwenden, um das Problem zu finden und zu beheben.

Orakel - "Fragen Sie den Produktverantwortlichen"

Als der Entwickler in unserem Beispiel nicht in der Lage war, festzustellen, ob es sich bei dem Problem um ein tatsächliches Problem handelte, war der Ausweg, den Produktverantwortlichen zu fragen. Der Produkteigentümer wird sich das Problem wahrscheinlich ansehen und entscheiden, ob es ein Problem ist oder nicht. Dies ist ein klassisches Beispiel dafür, dass der Produktverantwortliche als Orakel fungiert[8]. Im Namensraum von Rapid Software Testing ist ein Orakel definiert als[7]:

"Ein Orakel ist ein Mittel, mit dem wir ein Problem erkennen, auf das wir beim Testen stoßen."

Während der Softwareentwicklung sind wir von vielen Orakeln umgeben. Die Spezifikationen in unseren User Stories, das Verhalten vergleichbarer Produkte, Standards für die Softwareentwicklung, all das sind Beispiele für Orakel. Ein großer Teil des Testens (und der Softwareentwicklung) kann darin bestehen, herauszufinden, wo, was und wer Ihre Orakel sind. Ohne sie können Sie nie sicher sein, dass Sie das Richtige entwickeln[9].

Mentale Modelle und Orakel in der Praxis verwenden

Mentale Modelle und Orakel kommen zusammen, während ich das Produkt beobachte und mit ihm interagiere. Sie fließen in mein Testdesign ein und helfen dabei festzustellen, ob meine Beobachtungen Probleme darstellen.

Beobachtung des Systems

Ich versuche oft, (einen Teil) meiner mentalen Modelle in Whiteboard-Diskussionen explizit zu machen. Ich finde dies nützlich, um meine Annahmen darüber zu überprüfen, was ich mit meinem Team aufbaue und ob es so funktioniert, wie ich es mir vorstelle. Eine visuelle Darstellung kann dabei helfen, Ihre Modelle auf Ihre Teammitglieder zu übertragen. So haben Sie auch ein gemeinsames Vokabular, das Sie in zukünftigen Diskussionen verwenden können, um die Kommunikationslücke zu verringern.

Heutzutage kann es wirklich schwer sein, Orakel in Form von Spezifikationen zu finden. In der Regel sind Sie zumindest teilweise für die Erstellung dieser Anforderungen zusammen mit Ihrem Team und den Interessenvertretern des Unternehmens verantwortlich. Techniken wie Specification by Example und Example Mapping werden immer notwendiger, um qualitativ hochwertigen Input für den Entwicklungsprozess zu liefern.

Auswirkungen auf automatisierte Kontrollen

Es ist schwer, automatisierte Prüfungen zu schreiben, die in jeder Situation zuverlässig sind. Das liegt zum Teil daran, dass eine automatisierte Prüfung kein mentales Modell oder Orakel hat, abgesehen von dem, was Sie ihr einprogrammieren. Angenommen, eine Schaltfläche wird aufgrund von DOM-Änderungen auf der Seite an eine neue, falsche Stelle verschoben. Sie haben Ihre Prüfung nicht so programmiert, dass sie die genaue Position der Schaltfläche prüft. In diesem Fall ist es wahrscheinlich, dass der Test einen Erfolg meldet, obwohl es tatsächlich ein Problem gibt. Es ist unmöglich, alle Ihre mentalen Modelle und Orakel in Ihren automatisierten Prüfungen explizit zu machen, da ein großer Teil dieses Wissens stillschweigend vorhanden ist[6]. Dies kann ein Grund sein, in Ihrer Teststrategie Raum für explorative Tests zu schaffen. Ein neugieriger Tester, der sich seiner mentalen Modelle und Orakel bewusst ist, kann den entscheidenden Unterschied ausmachen[10].

Referenzen

[1]: Mentale Modelle, James Clear, James Clear über Mentale Modelle
[2]: Mentales Modell, Wikipedia, Wikipedia-Eintrag zu Mentalen Modellen
[3]: Mentale Modelle, Jakob Nielsen, Nielsen Norman Group über Mentale Modelle
[4]: Affordanzen, Interaction-Design.org, Interaction Design über Affordanzen
[5]: Alle Modelle sind falsch, Wikipedia, Wikipedia-Eintrag zu "All Models Are Wrong"
[6]: Stillschweigendes Wissen, Wikipedia, Wikipedia-Eintrag zu Stillschweigendes Wissen
[7]: Orakel von innen nach außen, Michael Bolton, Michael Boltons Blog über Orakel
[8]: Testorakel, Wikipedia, Wikipedia-Eintrag zu Testorakeln
[9]: Softwarebereitstellung wird bedarfsorientiert, Viktor Clerc, Xebia Artikel von Viktor Clerc über Softwarebereitstellung
[10]: Der ultimative Tester: Neugierde, Maaike Brinkhof, Xebia Blog auf Der ultimative Tester: Neugierde

Verfasst von

Joost van Wollingen

Contact

Let’s discuss how we can support your journey.