no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Testen mit TestLink ======
+[[http://testlink.oobd.org|TestLink]] erscheint als ein mächtiges Tool zum Erstellen und Abarbeiten von Testprozeduren. Mächtig heißt leider auch kompliziert, und darum versuche ich hier mal, das zum Benutzen notwendigste zusammen zu schreiben, damit man sich nicht jeden Level selber nochmal durchspielen muß...
+===== Wo kommen eigentlich die kleinen Teste her? =====
+Äh, ja, äh, das ist wie bei den Bienen...
+Testlink ist nicht nur eine loose-Blatt-Sammlung irgendwelcher geht/geht nicht- Abfragen, sondern hilft dem Test-Ingenieur bei der Herleitung der Inhalte, der Versionierung, der Zuweisung, der Abarbeitung und der Auswertung. Wie gesagt, mächtig halt..
+Wenn man also einen Gesamtüberblick behalten möchte, haben die Götter den Schweiß vor den Erfolg gesetzt. Man fängt bei Adam und Eva an nämlich mit der
+===== Die TestLink- Module =====
+==== Anforderungsspezifikation ====
+Hier beschreibt man so genau wie nötig, was man eigentlich von dem Produkt/Software erwartet (Funktionalität/Performance). Anforderungsspezifikationen sind zwar optional und können im Setup für jedes Testprojekt abgewählt werden, aber es bietet sich an, die einzelnen Anforderungen zu definieren, damit man sehen kann, was ein Test überhaupt beweisen soll.
+Testlink bietet hier die schöne Möglichkeit, die Anforderungen einer Anforderungsspezifikationhierachisch in einer Baumstruktur immer feiner aufzusplitten
+==== Testprojekt ====
+Jedes Testprojekt stellt ein in sich geschlossenes Test- Universum dar. So könnte man viele unabhängige Projekte verwalten, wir haben aber nur eins
+==== Testspezifikation ====
+Genau wie bei der Anforderungsspezifikation kann man hier in einer Baumstruktur die sogenannten Testfälle verwalten.
+==== Testfälle ====
+Ein Testfall ist ein Ablauf einer oder mehrerer Testschritte und beschreibt den eigentlichen Test. Jeder Testfall kann (und zweckmäßigerweise sollte) einen oder mehreren Anforderungen zugeordnet werden und stellt quasi den formalen Beleg der Funktionalität der Anforderung da.
+==== Testschritt ====
+Ein Testschritt sagt, welche Aktionen durchzuführen sind und welche Ergebnisse erwartet werden. ((Leider sieht es wider Erwarten nicht so aus, als könnte man ausser Geht/Geht nicht hier noch sowas wie "Na ja, reicht erstmal" unterbringen. Ich hab zwar versucht, das mit einem benutzerdefiniertem Feld abzufangen, aber irgendwie kann ich dagegen keine Reports fahren.))
+==== Testpläne ====
+Hier werden Testpläne zu einem kompletten Testlauf zusammengefasst. Diese Testpläne können dann Usern zur Erledigung zugewiesen werden.
+==== Builds ====
+Sehr praktisch: Hiermit refenziert man quasi auf den aktuellen Versionslevel seines Produkts. Einen Testlauf kann man nur dann erzeugen, indem man einen Testplan mit einem aktuellen Build verheiratet, und so hat man den Bezug, welche Version man eigentlich getestet hat.
+===== Das Testen ======
+Und nach soviel Vorgeplänkel kommen wir nun endlich zu dem, für was das Ganze eigentlich gut sein soll, dem Testen. Und so aufwendig die Vorarbeiten sind, so einfach ist das Testen: Test auswählen, Punkte abarbeiten, Fertig. Mehr nicht..