Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Barbara Göller

Barbara Göller

Qualität als Konzept: In 7 einfachen Schritten zu qualitativ hochwertige(re)n Test Cases im TFS!

Mittwoch, 15. Juni 2016

Ein Testfall beschreibt eine Reihe auszuführender Aktionen sowie die zu erwartenden Ergebnisse dieser Aktionen. Der Sinn eines Testfalles ist es, eine bestimmte Funktionalität eines Testobjektes zu verifizieren. Testfälle sind der erste Schritt im gesamten Testing Lifecycle und bilden somit den Grundstein für eine hohe Qualität im selbigen. Dabei wird die Qualität von Testfällen zunächst durch zwei Faktoren bestimmt:

Zum einen ist es essentiell, das Richtige zu testen. Dafür müssen die relevanten Anwendungsszenarien bekannt sein (“Doing the right thing”). Auf der anderen Seite müssen die Testfälle die Wege durch diese Anwendungsszenarien so beschreiben, dass sie von den Testern eindeutig nachvollzogen werden können (“Doing the things right”). Doch was bedeutet dies konkret und wie sieht ein “guter” Testfall aus?

Leider gibt es kein allgemeingültiges Rezept um diese Fragen zu beantworten. Daher stellen wir in diesem Blogbeitrag 7 Tipps aus der Praxis vor, welche es mit den im TFS zur Verfügung stehenden Mitteln ermöglichen, die Qualität von Testfällen zu verbessern:

  1. Verwendung von Namenskonventionen für Titel von Testfällen: Die Titel von Testfällen sollten einem definierten Schema genügen. Dies dient dem Zweck, allen am Testprozess Beteiligten auf den ersten Blick ersichtlich zu machen, was getestet wird und damit ein einheitliches Verständnis zu fördern. Es sollte vermieden werden, unnötige Bestandteile in die Namenskonvention aufzunehmen. So ist z.B. das verbreitete Präfix TC (für Test Case) redundant, da der Work Item Typ in jeder Ansicht des TFS leicht ersichtlich ist. Ein beispielhaftes Namensschema ist %Zu testendes Modul%_%Zu testende Funktion%. Ein Testfall des Logins einer Web Applikation würde gemäß dieser Konvention einen Titel wie LoginPage_ValidateUserCredentials tragen.
  2. Einbeziehung des Domänenwissens von Testern: Mit Hinblick auf die Granularität der Testschritte ist es essentiell, das Domänenwissen von Testern zu berücksichtigen. Werden die Testfälle von Testern durchgeführt, welche kein fachliches Wissen über das Testobjekt besitzen, so müssen die Testfälle sehr feingranular beschrieben werden. Sind für die Testausführung hingegen Tester mit Expertenwissen verantwortlich, so können gewisse Aspekte vorausgesetzt werden, wodurch eine weniger detaillierte Beschreibung der Testfälle ausreichend ist.
  3. Berücksichtigung der Teststufe: Ein weiterer Aspekt, der sich auf die Granularität der Testschritte auswirkt, ist die Teststufe, auf welcher ein Test angesiedelt ist. Ein Integrationstest z.B. testet das Zusammenspiel mehrerer Komponenten und damit ganze Prozesse innerhalb eines Produktes . Hierbei kann oft aufgrund des Umfangs eines solchen Tests nicht jeder Schritt bis ins kleinste Detail spezifiziert werden. Ein funktionaler Test hingegen testet auf unterster Ebene eine einzige Einheit eines Produktes auf Bases einer funktionalen Spezifikation und sollte sehr detailliert beschrieben werden.
  4. Einheitliches Wording: Bei der Formulierung der Testschritte sollte darauf geachtet werden, keine Synonyme für dieselbe Bedeutung zu verwenden, sondern ein einheitliches Wording über alle Testfälle hinweg zu erreichen. So sollte beispielsweise nicht in einem Schritt die Formulierung “Drücken Sie den Button Login” und in einem anderen die Formulierung “Klicken Sie auf die Schaltfläche Logout” verwendet werden. Beide Formulierungen beschreiben dieselbe Tätigkeit und sollten daher auf dieselbe Weise beschrieben werden. In diesem Kontext kann es sich als nützlich erweisen ein zentralen Glossar (auch über den Bereich des Testings hinaus) einzuführen um die Verwendung eines einheitlichen Wordings zu erleichtern. Dies reduziert Unklarheiten und verbessert das Verständnis des Testers.
  5. Einheitliche Beschreibung von Navigationspfaden: Wie ein einheitliches Wording, so fördert auch die einheitliche Beschreibung von Navigationspfaden die Lesbarkeit und das Verständnis von Testfällen. Dabei ist zu beachten, dass Navigationspfade von außen nach innen beschrieben werden sollten um damit den Tester vom groben zum genauen Ort über die Oberfläche zu führen. Befindet man sich beispielsweise auf der Login/Logout Seite für Downloads von Produkten der AIT (vgl. Abb. 1), so kann man mehrere Bereiche erkennen wie z.B. die Navigationsleiste oder den Bereich Registrieren. Möchte man nun also den Tester zu der Textbox Benutzername im Bereich Benutzeranmeldung führen, so sollte mit dem äußeren Element begonnen werden. Man könnte also schreiben “Benutzernamen im Bereich Benutzeranmeldung in der Textbox Benutzernamen angeben.”. Des weiteren ist es wichtig, ein einheitliches Schema für die Beschreibung von Navigationspfaden zu definieren. Anstatt die Pfade ausformuliert zu beschreiben sollte ein kompaktes Schema durch Nutzung von Trennzeichen wie “|” oder “—>” verwendet werden. Ebenso sollte definiert werden, ob Beschreibungswörter wie Bereich und Textbox miteinbezogen werden sollen oder nicht. Eine kompaktere Schreibweise für den zuvor beschriebenen Testschritt lautet damit “Benutzernamen in Benutzeranmeldung|Benutzername eingeben”.

    LoginPage

    Abb. 1: Login/Logout AIT Downloads

  6. Verwendung von Parametern: Der TFS erlaubt in der Beschreibung der Testschritte die Verwendung von Parametern. Diese ermöglichen es, denselben Testfall mit unterschiedlichen Daten durchzuführen. Die Beschreibung eines Positivtests und eines Negativtests für die Benutzervalidierung beim Login kann beispielsweise mithilfe von Parametern innerhalb eines Testfalls erreicht werden (vgl. Abb. 2). Damit werden Redundanzen vermieden und eine effizientere Testfallerstellung ermöglicht.

    Abb. 2: Verwendung von Parametern

  7. Verwendung von Shared Steps: Shared Steps können im TFS genutzt werden, um Schrittfolgen zentral zu definieren und in unterschiedlichen Testfällen einzubinden. Dieses Vorgehen hat mehrere Vorteile: Zunächst wird durch das Verwenden von Shared Steps die Wartbarkeit der Testfälle wesentlich verbessert. Ändert sich an der in einem Shared Step definierten Schrittfolge etwas, so muss diese Änderung nur einmal vorgenommen werden statt in jedem betroffenen Testfall. Darüber hinaus wird eine erhöhte Einheitlichkeit erzielt, da dieselbe Schrittfolge immer exakt gleich beschrieben ist. Im bereits herangezogenen Beispiel einer Web Applikation mit Login muss in jedem Testfall zunächst der Login durchgeführt werden. Die Schritte dieses Logins können als Shared Steps definiert und diese Shared Steps in allen Testfällen eingebunden werden.

Fazit

Testfälle bilden die Schnittstelle zwischen den Anforderungen und Tests und damit den Grundstein für eine hohe Qualität im gesamten Testprozess. Zwar ist es schwer, zu definieren wie ein qualitativ hochwertiger Testfall im Allgemeinen auszusehen hat, jedoch sollte er effizient, einheitlich und eindeutig definiert werden. Beachtet man also die vorgestellten Tipps kommt man dem Ziel, einer durchgängig hohen Qualität, einen großen Schritt näher. Und wie so oft gilt auch bei der Definition von Testfällen: “Qualität ist das Produkt der Liebe zum Detail.” (Andreas Tenzer).

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , , ,

Hinterlasse eine Antwort