Archiv der Kategorie: MTM

Queries in MTM/WebAccess

Es gibt in MTM zwei Möglichkeiten Queries abzufeuern:
 
1. Editor
Leider gibt es weder in MTM noch in Web Access einen Query-Texteditor in welchem man auch schnell ein Bulk-Query zusammenbauen kann. Für schnelle, kurze Abfragen ist der dort angebotene Zusammenklicken-Editor perfekt:

Eine häufige Abfrage im Testbereich dürfte sich auf das Feld Steps beziehen.
 
2. URL
Für Bulk-Actions ist der Ansatz über die REST-API / URL am besten.
Die URL besteht aus zwei Teilen:
Erster Teil

http://DeineDomain:8080/DeinPfad/_workitems?_a=query&wiql=

Zweiter Teil
Hierzu erstellt man im beliebigen Texteditor (z.B. notepad++) ein WIQL-Query, z.B.

SELECT [System.ID], [System.Title]
FROM WorkItems
WHERE [System.TeamProject]='DeinTeamProject'
AND [System.State]='Active'

Dieses URL-encoded man sodann, hängt es dem ersten Teil an und gibt es in den Browser ein. Die Ergebnisse kann man dann (multi-)selektieren und mittels Kontextmenü dann Bulk-Actions durchführen.

Test Plans & Test Suites & Test Cases in Microsoft Test Manager

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

Organize-Tab in Microsoft Test Manager


Im Testing Center von Microsoft Test Manager findet sich der Tab ‘Organize’ unter dem sich vier Sub-Tabs finden.
Obwohl man sich laut den Breadcrumps in einem bestimmten Testplan befindet, werden in den vier Sub-Tabs per default alle Entitäten (Test Pläne, Test Konfigurationen, Testfälle, Shared Steps) innerhalb des TFS Team Projekts angezeigt, was einigermaßen verwirrend ist.
Grundsätzlich kann man sagen, dass die Spaltenbenutzung nicht ganz so intuitiv ist, wie man es sich wünschen würde:

  • Zu den sichtbaren Spalten kann man mit einem `Geheimtrick` noch weitere hinzufügen. Rechtsklick auf die Spaltenüberschriften-Leiste und zahlreiche zusätzliche Spalten können zum Anzeigen ausgewählt werden.
  • Auch kann man die Spalten aufsteigend/absteigend sortieren, indem man ein bzw. zwei Mal auf die entsprechende Spaltenüberschrift klickt.
  • Einige Spalten kann man noch filtern. Wenn man mit der Maus über die rechte Ecke fliegt, erscheint aus dem Nichts ein Pfeil. Bleibt er grau, kann man nicht nach den Spaltenwerten filtern – wird er schwarz, kann man es.

Was noch sinnvoll gewesen wäre, wenn man die Tabs schon ‘Manager’ nennt, wäre noch ein Zähler aller aufgeführten Entitäten in den einzelnen Sub-Tabs.
 
Test Plan Manager
In diesem Tab finden sich alle Testpläne eines TFS Teamprojekts aufgelistet. Eine Besonderheit stellt noch der Button ‘Edit run settings’ dar, wohinter man die Datensammlung beim Testen erweitern kann – nähere Erläuterungen: hier.
 
Test Configuration Manager
Was es mit den Testkonfigurationen auf sich hat, kann man am besten an konkreten Beispielen verdeutlichen. Eine Konfigurationsvariable für einen Test ist beispielsweise das Betriebssystem – die einzelnen Werte der Konfigurationsvariable können also beispielsweise Windows, Linux oder MacOS sein. Eine weitere Konfigurationsvariable für das Testen von Webanwendungen ist beispielsweise der Browser. Diese Konfigurationsvariable kann die Werte Firefox, Chrome, Internet Explorer, Safari oder Opera annehmen. Eine Konfiguration ist eine mögliche Kombination aus den Werten der Konfigurationsvariablen, z.B. (Windows, Firefox). Legt der Testmanager also diese Konfiguration für den kommenden Testdurchlauf fest, dann teste ich den Testplan gegen die Anwendung auf Firefox auf einem Windows-Rechner. Genau das kann man im Sub-Tab Test Configuration Manager einstellen.
 
Test Case Manager
Bei einer Testsuite mit sehr vielen Testfällen friert MTM erstmal für ein paar Sekunden ein, bevor man weiterarbeiten kann. Man kann die Auswahl der Testfälle nun einschränken, indem man sich der üblichen Spaltenfilter oder eines erweiterten Filters bedient; letzteres indem man auf ‘Unfiltered’ klickt. Jetzt kommt die nächste kleine Verwirrung, denn obwohl das Dropdown-Menü ‘Unfiltered’ angezeigt hat, erscheint ein Filter, den man nun editieren kann. Z.B. kann man diesen default-Filter nun weiter einschränken, indem man noch eine weitere Teilbedingung hinzufügt, z.B. zur Ausgabe ausschließlich automatisierter Testfälle:

Mittels Run-Query kann die vorläufige Auswahl ermittelt werden und mittels ‘Save query’ wird die Auswahl schließlich gespeichert. Ob diese nette Funktion ausreicht, um den Tab mit dem Begriff ‘Manager’ zu adeln sei einmal dahingestellt.
 
Shared Steps Manager
Shared Steps sind zusammengefasste Testschritte, die in einem Testfall wiederverwendet werden können (das gern genommene Standardbeispiel ist ja der Login). Der Sub-Tab Shared Step Manager funktioniert analog zu dem Sub-Tab Test Case Manager. Zusätzlich gibt’s noch den Button ”Create action recording” – hier steht, was es damit auf sich hat. Warum es einen solchen im Shared Steps Manager gibt, nicht jedoch einen analogen im Test Case Manager bleibt wohl für immer das Geheimnis der Erbauer dieses Tools.