Wie bei allem in MTM muss man daran denken, dass man immer den Aktualisieren-Button drücken muss, um im rechten Bereich die gerade gemachten Änderungen wiedergespiegelt zu sehen …
Test Plans
Test Plans sind von den Microsoft-Entwicklern eigentlich dazu gedacht, innerhalb eines bestimmten Zeitraums abgearbeitet zu werden. Nach dem Ablauf dieses Zeitraums und einem hoffentlich befriedigenden Testergebnis, wird also ein neuer Test Plan erstellt. Regressions-Testsuiten schreien ja danach, in einem darauffolgenden Test Plan wiederverwendet zu werden. Mit Copy kann eine Test Suite von einen Test Plan in einen anderen kopiert werden, ohne deren Test Cases neu zu erzeugen (flat copy). Will man auch neue Test Cases bei diesem Vorgang erzeugen (deep copy), liest man diesen Artikel.
Häufig findet man jedoch in der Praxis auch Fälle, in denen der Test Plan ohne zeitlichen Bezug einfach als übergeordnete Struktur für Test Suites verwendet werden. Dann sollte wenigstens das Enddatum des Test Plans auf 31.12. überübernächsten Jahres o.Ä. gesetzt werden, um eine solche Verwendung jedem zu verdeutlichen.
Unter Testing Center -> Plan -> Properties finden sich der eine Teil der Eigenschaften eines Test Plans. Iteration ist redundant zu Start Date und Finish Date, weil die Iteration diese Information ja schon implizit enthält. Jedenfalls wird eine Iteration in Scrum Sprint genannt und geht meistens zwei bis drei Wochen, deren Start- und Enddatum jedoch klar definiert sind.
Unter Testing Center -> Plan -> Run Settings finder sich der andere Teil der Eigenschaften eines Test Plans. Unter Configurations findet sich die defalut-config, die einem neuen Testfall zugewiesen wird. Auch diese Einstellmöglichkeit spricht für die Nutzung der Test Pläne innerhalb eines Zeitraums.
Test Suites
Microsofts „Übersetzungsroboter“ hat den Begriff Test Suites unklugerweise mit Testsammlungen ins Deutsche übersetzt und nicht als Fachwort unübersetzt gelassen. Außerdem entspricht die MTM Test Suite nicht dem, was zumindest ich mir unter einer Test Suite vorstelle, nämlich einen ‚Eimer‘ mit Testfällen drin, die bezüglich bestimmter Kriterien zusammen gehören. Test Suites sind seitens MTM jedoch, als Substruktur eines Test Plans, dazu gedacht bis zu einem bestimmten Zeitpunkt beendet zu sein. Daher hat jede Testsuite auch ein Iteration-Attribut.
Beim Anlegen eines Test Plans wird automatisch eine gleichnamige Root-Test Suite erzeugt.
TestSuites sind seit MTM 2013 Update 3 vollwertige Work Items; man kann sie also per query abfragen, bekommt deren Historie angezeigt, ein Feld kann hinzugefügt werden und ein Status kann gesetzt werden.
Es gibt drei Typen von Test Suites
- Static (lege bestimmte Test Cases in die Test Suite rein)
- Requirement-based
- entstehen, wenn man „Add requirements“ zu einer TestSuite hinzufügt. Ein requirement ist hierbei bsp.weise ein Backlog Item
- Falls bei dem Backlog Item noch Test Cases angelegt worden waren, werden diese im rechten Bereich aufgelistet.
- Query-based (bsps.weise einer bestimmten area zuegordnet)
Es gibt drei selbsterklärende Out-of-the-Box-Status von Test Suites: In Planning (geplant), In Progress (ausgeführt) und Completed (abgeschlossen). Leider wird der Status nicht in der Tree-View repräsentiert – aber wenn man eine TestSuite auswählt, erscheint er ob rechts:
Test Cases
Test Cases existieren unabhängig von Test Suites, weshalb die Test Cases, die einer Test Suite zugeordnet sind, auch deren Löschung überleben. Umgekehrt ist es auch so, dass wenn man die TestCases aus dem rechten Bereich von MTM per Remove the selected test cases entfernt, sie nicht gelöscht werden. Dies kannst Du mal ausprobieren, indem Du einen Dummie-Testcase erstellst, Dir die ID merkst und dann mal eine im Track-Tab nach dem Testfall suchst – er wird vorhanden sein. Man kann einen Test Case keiner, einer oder mehreren Test Suites zuordnen, muss es jedoch nicht. Einen Test Case kann man per Drag’n’Drop einer andere Test Suite zuweisen. Wer einen Test Case copy&pasten will, der hält beim drag’n’drop gleichzeitig die Strg-Taste gedrückt.
Die Priorities sind nicht ganz durchdacht implementiert, denn diese sind an den Testcase gebunden und nicht an die Testcase-Testsuite-Kombination oder noch besser als TestConfiguration-Testcase-Testsuite-Kombination. Man kann also in MTM nicht abbilden, dass das Testen eines Login-Testfalls mit Chrome wichtiger ist, als mit Safari.
Mit dem Assign-Button weist man einem Testfall einen Tester zu. Öffnet man nun einen Test Case, dann taucht der Tester nicht auf. Das macht Sinn, denn der zugewiesene Tester führt den Testfall nur in dieser Testsuite aus – für die Durchführung des gleichen Testfall in einer anderen Testsuite ist womöglich ein anderer Tester verantwortlich.
Mit dem Order-Button kann man die Reihenfolge der auszuführenden Testfälle festlegen. Und damit den o.g. Mangel der Priotiäten-Implementierung teilweise kompensieren.
Configurations-Button: Eine Test Configuration ist ein Tupel (z.B. „Chrome“, „Windows 7“, „Notebook“) verschiedener Konfigurationsvariablen (z.B. Browser, Betriebssystem, Hardwareplattform). Um einem Test Case innerhalb einer Test Suite eine Test Configuration zuzuweisen, selektiert man einen oder mehrere Test Cases im rechten Bereich und klickt auf den Configurations-Button. Wählt man nun All Configurations und klickt in die Configurations-Spalte
Quellen
https://msdn.microsoft.com/library/dd286738(v=vs.110).aspx
