Tips des Monats

Hier finden Sie alle Tips des Monats zum Nachschlagen; ich freue mich auch über Kommentare zu älteren Tips - schreiben Sie einfach ein Mail!

Tips des Jahres 2010

► Februar: Testen – Gedanken zum Prozeß (I)

Nach dem langen Januar-Tip zu den Testzielen steht nun der Prozeß im Vorder-
grund. Und der besteht eben nicht nur daraus, das fertige System auszuprobieren und aus dem Bauch heraus das eine oder andere damit anzustellen, ganz im Gegenteil gehört da eine ganze Reihe von Teilprozessen dazu.

Zunächst ist das die Analyse der Anforderungen, wie schon im Januar angesprochen; aber was gehört zu dieser Analyse?

Testbarkeit

Sind die Anforderungen so formuliert, daß man das Testziel und mögliche Tests ableiten kann; sind die Anforderungen also „testbar“?

Aus der Vielzahl von Kriterien, an der man die Testbarkeit von Anforderungen bewerten kann, will ich zwei herausgreifen, die wesentlich sind:

1.

Eindeutigkeit:

Die Anforderung kann nur in einer Richtung interpretiert werden, ihre Aussage ist also klar.

Beispiel:
Es muß die Summe der Eingaben bestimmt werden. ist nicht eindeutig, weil nicht klar ist, wer der Aktor ist; soll das System diese Summe bilden oder der Benutzer? (Passiv-Formulierung von Anforderungen ist generell nicht empfehlenswert.)

Besser: Das System soll nach Abschluß der Eingaben deren Summe bilden und darstellen.

2.

Quantitative Formulierung

Wenn eine Anforderung etwas über Zahlen, Mengen, Zeiten aussagt, muß sie das präzise tun, damit der Vergleich der tatsächlichen Beobachtung mit der Anforderung eindeutig ist.

Beispiel:
Das System muß performant sein. ist nicht testbar, weil die Aussage keine Vergleichbarkeit zuläßt, sind 10 sec gut oder 5 Minuten? Ist es die Zeit zwischen zwei Kaffeeschlucken des Benutzers?

Tips des Monats

Tips des Jahres 2009

Tips des Jahres 2010

► Januar: Ziele des Testens

► Februar: Testen – Gedanken zum Prozeß (I)

1.

Eindeutigkeit:

Die Anforderung kann nur in einer Richtung interpretiert werden, ihre Aussage ist also klar.

Beispiel:
Es muß die Summe der Eingaben bestimmt werden. ist nicht eindeutig, weil nicht klar ist, wer der Aktor ist; soll das System diese Summe bilden oder der Benutzer? (Passiv-Formulierung von Anforderungen ist generell nicht empfehlenswert.)

Besser: Das System soll nach Abschluß der Eingaben deren Summe bilden und darstellen.

2.

Quantitative Formulierung

Wenn eine Anforderung etwas über Zahlen, Mengen, Zeiten aussagt, muß sie das präzise tun, damit der Vergleich der tatsächlichen Beobachtung mit der Anforderung eindeutig ist.

Beispiel:
Das System muß performant sein. ist nicht testbar, weil die Aussage keine Vergleichbarkeit zuläßt, sind 10 sec gut oder 5 Minuten? Ist es die Zeit zwischen zwei Kaffeeschlucken des Benutzers?

Besser: Die maximale Antwortzeit des Systems bei Dialogen soll 5 sec betragen.

► März: Testen – Gedanken zum Prozeß (II)

► April: Testen – Gedanken zum Prozeß (III)

► Mai: Testen – Die Dokumentation

► Juni: Wie schreibt man gute Protokolle (I)

► Juli: Wie schreibt man gute Protokolle (II)

► November: Planung → Termine → Streß?

► Dezember: Defensive Planung

Tips des Jahres 2011

Tips des Monats

Tips des Jahres 2009

Tips des Jahres 2010

► Januar: Ziele des Testens

► Februar: Testen – Gedanken zum Prozeß (I)

1.

Eindeutigkeit:

Die Anforderung kann nur in einer Richtung interpretiert werden, ihre Aussage ist also klar.

Beispiel: Es muß die Summe der Eingaben bestimmt werden. ist nicht eindeutig, weil nicht klar ist, wer der Aktor ist; soll das System diese Summe bilden oder der Benutzer? (Passiv-Formulierung von Anforderungen ist generell nicht empfehlenswert.)

Besser: Das System soll nach Abschluß der Eingaben deren Summe bilden und darstellen.

2.

Quantitative Formulierung

Wenn eine Anforderung etwas über Zahlen, Mengen, Zeiten aussagt, muß sie das präzise tun, damit der Vergleich der tatsächlichen Beobachtung mit der Anforderung eindeutig ist.

Beispiel: Das System muß performant sein. ist nicht testbar, weil die Aussage keine Vergleichbarkeit zuläßt, sind 10 sec gut oder 5 Minuten? Ist es die Zeit zwischen zwei Kaffeeschlucken des Benutzers?

Besser: Die maximale Antwortzeit des Systems bei Dialogen soll 5 sec betragen.

► März: Testen – Gedanken zum Prozeß (II)

► April: Testen – Gedanken zum Prozeß (III)

► Mai: Testen – Die Dokumentation

► Juni: Wie schreibt man gute Protokolle (I)

► Juli: Wie schreibt man gute Protokolle (II)

► November: Planung → Termine → Streß?

► Dezember: Defensive Planung

Tips des Jahres 2011

Beispiel:
Es muß die Summe der Eingaben bestimmt werden. ist nicht eindeutig, weil nicht klar ist, wer der Aktor ist; soll das System diese Summe bilden oder der Benutzer? (Passiv-Formulierung von Anforderungen ist generell nicht empfehlenswert.)

Beispiel:
Das System muß performant sein. ist nicht testbar, weil die Aussage keine Vergleichbarkeit zuläßt, sind 10 sec gut oder 5 Minuten? Ist es die Zeit zwischen zwei Kaffeeschlucken des Benutzers?