Beim Testen stoßen wir oft auf hartnäckige Konventionen, bei denen Om-Denken dringend erforderlich ist. In diesem Blog ändern wir die Perspektive dieser Konventionen durch Om-Denken.
These 1 | Das Testen von Software zielt darauf ab, festzustellen, ob eine Software richtig funktioniert.
Wenn dies der Ansatz für einen Testprozess ist, läuft etwas grundlegend falsch. An dieser Stelle müssen Sie sofort darüber nach denken. Schließlich zielt das Testen von Software darauf ab, die Wahrscheinlichkeit von Fehlern und Risiken zu verringern. Beim Testen von Software geht es darum, Fehler zu finden und Risiken zu verringern. Ein Software-Tester, der in einer Testprojekt keine Fehler oder Risiken findet, wird sich unwohl fühlen.
These 2 | Der Testmanager will sich in alles einmischen.
In einem früheren Blog haben wir einmal folgendes Zitat notieren lassen: "Als Testmanager ist man nicht immer beliebt". Jeder, der testet, weiß, dass der Testmanager sein bester Freund ist. Schließlich ist der Testmanager derjenige, der Ihnen hilft, die Anzahl der Fehler und Risiken in Ihrem Projekt zu minimieren. Je früher ein Fehler gefunden wird, desto einfacher (billiger) ist er zu beheben. Das Böhmsche Gesetz sagt darüber einiges aus.
These 3 | Sie brauchen Cloud-Anwendungen nicht zu testen.
Wir kaufen zunehmend Software aus der Cloud. Das spart Zeit, Kosten und ist einfach zu implementieren. Um es gleich vorweg zu sagen: Wir sind selbst Fans von SaaS-Tools. Doch diese Aussage erfordert ein umgekehrtes Denken. Softwareentwickler sind gut darin, Software zu entwickeln, aber kennen sie auch alle Ihre kritischen Geschäftsprozesse? Würden Sie es wagen, Ihre kritischen Geschäftsprozesse über SaaS-Tools laufen zu lassen, ohne einen funktionalen Anwendungstest durchzuführen? Wir raten auf jeden Fall davon ab.
These 4 | Testautomatisierung reicht für den Testprozess aus
Dies ist ein hartnäckiger und weit verbreiteter Gedanke. Hier ist ein Umdenken dringend erforderlich. Denn Testautomatisierung gibt es nicht. Es gibt aber Testautomatisierungswerkzeuge. Diese Werkzeuge prüfen, ob das, was stabil und bereits getestet ist, noch funktioniert. Sie liefern keine neuen Erkenntnisse über neue oder veränderte Situationen. Das muss immer manuell getestet werden. Testautomatisierung mag für Systemtests und Sicherheitstests ideal sein, für funktionale Tests ist sie jedoch kaum geeignet. Testautomatisierung ist also gut als Teil eines Testprozesses geeignet, aber sie ist kein eigenständiger Testprozess.
These 5 | Die letzte Phase eines Projekts ist das Testen der Software
In These 2 haben wir bereits auf das Böhmsche Gesetz hingewiesen. Die Aussage sollte also lauten: Der Testmanager ist vom ersten bis zum letzten Tag des Projekts (und darüber hinaus) involviert. Für einen Projektleiter mag das schwer zu akzeptieren sein, aber wer Fehler und Risiken minimieren will, arbeitet eng mit dem Testmanager zusammen. Dieser wird von Anfang an und in jeder Phase des Projekts fragen, was wir tun werden, wie wir es tun werden, wer es tun wird, wann wir es tun werden, was die Risiken sind, wo die Fehlerchancen liegen, wie wir es testen werden usw. ....
These 6 | Wir testen nicht, weil wir eine kleine Organisation sind
Der Ausgangspunkt für einen Testprozess ist nicht die Größe Ihrer Organisation. Der Ausgangspunkt sollte sein, welche Risiken mein Unternehmen mit der aktuellen IT-Landschaft eingeht. Sie können ein Unternehmen mit nur 25 Vollzeitäquivalenten haben, aber in dem Moment, in dem die datenschutzrelevanten Informationen von 3.000 Kunden öffentlich zugänglich sind, haben Sie ein Problem. Auch in diesem Fall ist ein Umdenken angesagt.
Teilen Sie Ihre Erfahrungen mit uns
Als Testersuite Team sind wir immer an besonderen Fallbeispielen interessiert. Haben Sie ein tolles Beispiel für eine Testprojekt-Situation, die ein Umdenken erforderte? Teilen Sie ihn mit uns und wir werden ihn in diese Liste aufnehmen.
