Entscheidungstabellen: logisch-leicht-lösbar | Knowledge Department
 
Sie befinden sich hier: Blog  

Entscheidungstabellen: logisch-leicht-lösbar

Beim Black-Box-Test betrachtet man das Programm, ohne etwas über dessen innere Beschaffenheit zu wissen bzw. wissen zu müssen. Mit entsprechenden Black-Box-Testverfahren wird dann gegen eine Anforderungsspezifikation geprüft, ob das Programm das tut, was es tun soll. Eine Abweichung zwischen dem „Ist“ des Programms und dem „Soll“ des Programms weist den Tester auf einen möglichen Fehler hin.
Soweit die Theorie.

In der Praxis fehlen uns Testern hier oftmals ganz grundlegende Parameter. Anforderungen von minderwertiger Qualität (oder deren vollkommene Abwesenheit) ist eher die Regel als eine Ausnahme. Eine „Testbarkeit“ der Anforderungen, was einem Qualitätskriterium an Anforderungen entspricht, ist dann natürlich auch nicht gegeben. Das ist unsere Herausforderung.

Test-Analysten sind die fachlichen Systemtester. Nur durch „kennen“ und „können“ geeigneter Techniken wird es ihnen möglich, die fachliche Funktionalität durch einen systematischen Test umfassend zu prüfen. Eine Technik, die wir unsere Teilnehmer im Advanced-Kurs „Technical Test Analyst“ schulen, die sowohl die Testbarkeit der Anforderungen fördert als auch für den späteren Black-Box-Test verwendet werden kann, ist die „Entscheidungstabelle“.

Stellen wir uns folgendes Szenario vor:
Wir befinden uns in einer frühen Entwicklungsphase, der Anforderungsdefinitionsphase. Tester und Entwickler arbeiten bereits hier eng zusammen. Bevor die Anforderungen tatsächlich ausgeschrieben werden, soll der Test Analyst sicherstellen, dass die Anforderungen später (Systemtest, Abnahmetest) auch testbar sind. Hierbei trifft er auf die folgende Anforderung:
„Falls der der Wartungsserver ein Update (A) oder falls das KM-System ein Deliverable anbietet (B) und unter der Bedingung, dass kein Mitarbeiter am Server angemeldet ist (C), muss das System selbständig in den Modus „Wartung“ wechseln.“
Hier leicht irritiert sein wäre vollkommen normal, denn rein logisch betrachtet ist diese Anforderung an das „Soll“ des Systems weitgehend unklar – der fachliche Test wäre damit auch „nicht testbar“. Es stellen sich hier die folgenden Fragen:
• Kann zeitgleich ein Update und ein Deliverable angeboten werden? Falls ja – brauchen wir Prioritäten? Welche wäre das? Falls nein – wie soll sich das System verhalten?
• Welcher Operator wird zuerst betrachtet? „Und“? „Oder“?
• Darf ausschließlich bei einem Update kein Mitarbeiter am Server angemeldet sein oder wird hier auf das Deliverable Bezug genommen? Bezieht sich der Relativsatz auf beides?
Unklarheiten in der Spezifikation führen zu Unklarheiten beim späteren Test. Durch das frühe Einbinden des Test Analysten können aus der Not getroffene und dann auch sehr wahrscheinlich „falsche“ Entscheidungen vermieden werden. „Sehr wahrscheinlich“ deswegen, weil die Wahrscheinlichkeit des Programmierers hier die richtige Entscheidung zu treffen, bei knapp über 10% liegt, denn logisch möglich wären:
1) (A ^ C) v B
2) A v (B ^ C)
3) (A ^ C) v (B ^ C)
4) (A ^ C) v B
5) A v (B ^ C)
6) (A ^ C) v (B ^ C)
7) (A v B) ^ C
8 ) (A v B) ^ C

Hier kommen „Entscheidungstabellen“ zum Einsatz. Sie helfen dem Test-Analyst einerseits dabei logische Abläufe systematisch zu verifizieren, als auch anderseits später das System gegen die fachlichen Anforderungen zu validieren. Bringen wir die Anforderung also in eine Entscheidungstabelle, indem Bedingungen und deren Aktionen spaltenweise betrachtet werden. Eine enge Zusammenarbeit zwischen Test und Analyse führt, z.B. im Rahmen eines statischen Tests, zur folgenden Tabelle:

B1: Update angeboten                    Y,N   Y   Y   Y   Y   N   N   N   N

B2: Deliverable angeboten            Y,N   Y   Y   N  N   Y    Y   N   N

B3: Mitarbeiter angemeldet            Y,N   Y   N   Y   N   Y   N   Y   N

A1:„Wartungsmodus“ wechseln             –    X   –    X    -    X    -    -

Möglichkeit 7 wäre also die „implizite“ Anforderung des Kunden entlarvt. Durch das frühe Einbinden des Test-Analysten in den Entwicklungsprozess wurde diese Anforderung „testbar“ gemacht (denn natürlich ist die Entscheidungstabelle eine Anforderung) und der Test-Analyst kann zum späteren Systemtest bzw. Abnahmetest das System „spaltenweise“ gegenüber den fachlichen Anforderungen testen.

Wie arbeitet man in der Praxis mit „Entscheidungstabellen“ und wann kommen sie zum Einsatz? Müssen Bedingungen immer mit „Ja“/“Nein“ belegt werden? Wie kann eine Tabelle übersichtlich dargestellt werden, wenn viele Bedingungen getestet werden („kombinatorische Explosion“)? Nach welchem Vorgehen sollten dabei Tests priorisiert werden? Und welche Technik hilft mir „unsinnige“ Tests von vornherein zu vermeiden?

Test-Analysten testen Systeme aus fachlicher Sicht. Verbessern Sie die Qualität ihrer Anforderungen und schaffen Sie ein korrektes System in einer prüfbaren Qualität. Holen Sie sich den „Test-Analyst” ins ihr Team. Unsere ISTQB Certified Tester Advanced Level Test Analyst-Kurse mit optionaler Zertifizierung helfen bei der Aus- und Weiterbildung: http://knowledge-department.de/certified-tester/advanced-level.html

Tags: , , ,

Hinterlassen Sie eine Antwort