Testkoordination/Teststrategie

[Jessica_Jessica]

Hallo zusammen!

Ich stehe vor folgendem Problem: Ich arbeite als Werkstudentin in einem Softwarehaus in München und soll für ein Haus eigenes System eine Teststrategie machen. Die Software wurde schon entwickelt. (Obwohl das testen ja schon von Anfang an hätte gemacht werden müssen)
Ich soll eine Teststrategie nach CMMI (Das soll für das Unternehmen ein erster Schritt in Richtung CMMI Zertifizierung sein) machen und weiss leider absolut nicht wie ich anfangen soll. Ich habe schon sehr viel gelesen, aber mir fehlt es ein wenig an Beispielen, dass ich mal sehen kann, wie sowas "am Ende" auch aussieht.
Also,
-ich weiss was ich testen soll (welche Funktionen)
-ich habe die Software
-als Use Cases habe ich die Handbücher zur Software (sind nicht gerade die Betsen Vorraussetzungen, aber kann man leider nicht ändern, da das System "einfach so" entwickelt wurde.)
-Risikoabschätzung liegt auch vor
Wie geht man am besten bei der Erstellung einer Teststrategie vor (diese will ich in den Masterplan integrieren, da dies ein sehr kleines Projekt ist)
Als erstes das System gut kennen? (Obwohl der CMMI Standart etwas anderes vorsieht..)
Dann einfach aufs Papier bringen WIE getestet werden soll?

Besten Danke im Voraus...

 

[takidoso]

Ohne CMMI ernsthaft zu kennen ist es beim Testen von "unbekannten Systemen" ganz gut die Fachkonzepte oder die Benutzerdokumentation genauer anzuschauen, um darauf aufbauend die Testfälle abzuletiten.
Je nachdem wie detailiert es für Dich sein muss, könnte man dann Listen mit Testfällen erstellen, die ein "dummer" Tester abarbeiten könnte(nach dem Motto: Testfall X hat funktioniert, -> Haken dran).
Nicht ganz unwichtig sind dann aber auch Negativtests, also was muss das System alles an Fehlern abfangen oder tollerant darauf reagieren.

Achja, ein dummer Tester zu sein und die Testfälle nach Vorschrift abzuarbeiten kann herzlich demotivierend sein, deshalb wäre es nicht falsch auch Testern gewisse Freiheiten über den dokumentierten Testfällen hinaus zu geben, verlangt aber vom Tester dann ein gewisses Maß an fachlichem Knoff Hoff um zu entscheiden , ob die Reaktionen des Systems korrekt, bzw angemessen waren. Es wäre nicht fasch diese vom Tester entwickelten zusätzlichen Testfälle (nachträglich) in die Testfall-Dokumente mit einzutragen.

 

[Jessica_Jessica]

Hi,
danke erstmal für Deine Antwort.
So weit ist mir das auch klar. Woran es eher scheitert ist, wie ich eine Teststrategie anfangen soll. Ich muss ja irgendwie sagen, dass das Testobjekt XY so oder so getestet wird (und auf welcher Ebene das stattfindet).
Als Bsp.:
Beim speichern eines Dokumentes ins Archiv will ich sicher stellen, dass dieses Dokument auch wirklich im Archiv ankommt. (Das könnte ja bei einem Dokumentensystem höchste Prio haben.)
Ich finde es irgendwie banal zu sagen, um dieses Vorhaben zu testen, benötige ich eine Teststrategie...?

Wie könnte denn hier eine Strategie aussehen?

l.g.

 

[takidoso]

Jo, da hast Du recht...
Es ist immer eine Frage der Granularität bezogen auf Teststrategie/Doku
nicht selten erscheinen solche Teststrategiepapiere auch relativ banal.

Bei einem meiner letzten Entwicklungen hatte ich auch mal den Vorschlag zum Testen geäußert für eine dateiverarbeindene Anwendung, die die Eingangsdateien splittet und auf verschiedenen Ziele bringt, dass eine oder mehrere Testdateien zur Verfügung gestellt werden, deren "Datensätze" gleich auch das Zielsystem auf dem die einzelenen Sätze zugeordnet werden sollten in Form eines genormten Strings beinhalten, um später maschinell irrläufer bequem erkennen zu können ohne jeden einzelnen Satz manuell verfolgen zu müssen.
So etwas würde ich persöhnlich als Teststrategie verkaufen, während das aufzählen der einzelnen Testfälle - in diesem Beispiel zum Testen der Splittingkriterein - schon mehr zur "Taktik" gehört.

Im Falle zum testen eines Archivsystems könnte man die Strategie vielleicht in Form auf Oberbegriffe bringen: Indezieren, Archivieren, Recherchieren, konkurenter Zugriff, Performancemessung. Ich weiß klingt auch fürchterlich banal, aber was sollte man sonst als Strategie verkaufen?