Testwerkzeuge – Arten

Testwerkzeuge unterstützen den Tester bei der Ausübung seiner Aufgaben.  Es wird hierbei zwischen CASE – Werkzeugen (Computer Aided Software Engineering) und CAST - Werkzeugen (Computer Aided Software Testing) unterschieden.  In diesen beiden Werkzeuggruppen gibt es auch noch verschiedene Untergruppen zur Unterstützung der unterschiedlichen Prozessphasen . Einige dieser Tools werden ich in den kommenden Posts vorstellen.

  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Testwerkzeuge | Verschlagwortet mit | Hinterlasse einen Kommentar

Testmanagement – Standards

Der Testmanager entscheidet in der Regel, welche Standards für den Softwaretest einsetzen will. Er kann unter anderem auswählen zwischen

  • Firmenstandards, z.B. Firmen-interne Prozeduren, Anordnungen oder Leitlinien wie z.B. Templates, Handbücher oder Programmierrichtlinien
  • bewährte Vorgehensweisen, die – obwohl nicht wirklich standardisiert – sich in der Praxis bewährt und sich deswegen als Standard etabliert haben
  • Standards im Bereich Qualitätsmanagment, z.B. ISO 9000
  • Standards im Bereich bestimmter industrieller Bereiche, z.B. EN 50128 für elektrische Signalanlagen
  • Standards im Softwaretest, z.B. IEEE 829
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Standards, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Konfigurationsmanagement – Anforderungen

Für ein erfolgreiches Konfigurationsmanagement sollten folgende Anforderungen erfüllt sein:

  • Versionmanagement; Bereitstellung und Indexierung von Softwareversionen inklusive Kommentare mit Gründen für die jeweilige Softwareänderung
  • Identifikation von Konfigurationen; Identifikation und Management aller Dateein (Konfigurationsobjekte) in der jeweiligen Version welche zusammen eine Subsystem (Konfiguration) bilden. Dies ist die Voraussetzung für das Versionmanagment
  • Dokumentation von Incident-Tickets und/oder Änderungsanfragen und die damit verbundene Möglichkeit, die Applikation der Konfigurationsobjekte zu rekonstruieren.
  • Audits, um zu prüfen, ob alle Softwarekomponenten vom Konfigurationsmanagement ordnungsgemäß dokumentiert sind.
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Konfigurationsmanagement, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Konfigurationsmanagement

Ein Softwaretest bezieht sich nicht nur auf die zu testende Software, sondern auch auf die zu Grunde liegenden Konfigurationen, Softwareänderungen, Versionen usw. Nach Möglichkeit sollte jeder Tester die selben Einstellungen in seiner Testumgebung vorweisen um die erhaltenen Ergebnisse vergleichen zu können. Aus diesem Grunde ist das Konfigurationsmanagement von enormer Wichtigkeit. Folgen falschen oder nicht vorhandenen Konfigurationsmanagement können z.B. sein:

  • Entwickler überschreiben sich gegenseitig ihre Änderungen im Code
  • Erschwerung von Integrationsaktivitäten aufgrund der Nutzung verschiedener Entwicklungstools, Unklarheiten über die aktuelle Softwareversion oder (bei verschiedenen Applikationen) Versionskompatibilitäten
  • Erschwerte Fehleranalyse, – berichtigung und Regressionstests aufgrund unbekannter Änderungen in der zu testenden Version
  • Verhinderung von Testerstellung und -ausführung, da nicht klar ist, welcher Testfall oder welches Ergebnis zu welcher Softwareversion gehört

Aus diesem Grund ist ein verlässliches Konfigurationsmanagement unerlässlich für einen erfolgreichen Softwaretest.

  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Konfigurationsmanagement, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Incident Management – Status

Ein Ticket kann verschiedene Status haben, z.B.:

Status Beschreibung
Neu Das Ticket wird gerade geschrieben
Ticket geöffnet Das Ticket ist fertiggestellt und “abgeschickt”. Der Testmanager prüft nun die Tickets.
Problem wird analysiert Der Entwickler analysiert das Problem
Unter Beobachtung Das Problem kann nicht reproduziert werden und wird weiter im Produktionsbetrieb beobachtet
Zurückgewiesen Sollten die Beschreibungen unvollständig, Duplikate vorhanden oder es sich offensichtlich nicht um einen Fehler handeln, wird das Ticket zurückgewiesen.
korrigiert der Entwickler hat das Problem in Absprache mit dem Projektmanager korrigiert und dokumentiert
Im Test der Tester prüft die Softwareänderung
Test fehlgeschlagen das Problem besteht immer noch und/oder es sind Seiteneffekte aufgetreten
geschlossen der Test ist erfolgreich durchgeführt worden, so dass das Ticket nun nicht mehr benötigt und geschlossen wird. Dieser Status kann nur vom Tester gesetzt werden

Der Status geschlossen ist in jedem Fall der End-Status, der Status zurückgewiesen kann ein Endstatus sein, sofern der Ticket-Ersteller nicht weiterführende Informationen angibt. Alles ist aber – wie eigentlich immer – veränderlich und den Bedürfnissen des einzelnen Unternehmens anpassbar.

  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Incident Management, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Incident Management – Klassifizierung Priorität

Entsprechend des Schweregrades oder auch unabhängig davon (je nach Unternehmen sind Priorität und Schweregrad gekoppelt oder auch nicht) können auch Prioritäten für die zu liefernden Softwareänderungen vergeben werden. Dies kann z.B. so aussehen:

Priorität Ursache für Prioritätsvergabe
1 -  schnellstmöglich Der Betrieb oder der Test werden geblockt
2 – innerhalb von x Wochen Es besteht ein (zeitintensiver) workaround für Problem. Fix sollte zeitnah erfolgen
3 – nächstes Release Keine größeren Probleme, mit dem Programm kann bis zum nächsten Release unter kleinen Einschränkungen weitergearbeitet werden
4 – Bei nächster Softwareänderung Keine Auswirkungen auf das Programm oder generelles Re-Design erforderlich.
5 – noch nicht geplant Lieferung muss noch geplant werden

Anhand Schwergrad und Priortät kann der Testmanager den aktuellen Testlauf gut auswerten, je schwerer/ höher priorisiert die Probleme sind, desto schlechter ist die getestete Software.

  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Incident Management, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Incident Management – Klassifizierung Schweregrad

Um die Schwere eines Fehlers eindeutig klassifizieren zu können sollte im Vorfeld genau festgelegt werden, unter welchen Umständen welcher Schweregrad vergeben werden darf. Dementsprechend könnte eine Klassifizierung von Schweregraden z.B. so aussehen:

Schweregrad Beschreibung
1 – Höchste Problemstufe Software bricht zusammen, Daten gehen verloren und/oder Weiterarbeit ist nicht möglich
2 – Sehr Kritisch Essentielle Komponenten funktionieren nicht oder falsch, starke Beeinträchtigung auf die Arbeit und/ oder Schweregrad 1 mit Workaround
3 – Kritisch Feherhafte Komponente/ Programm. Die Software kann mit Einschränkungen weiter genutzt werden.
4 – Mäßig Keine/ wenige Einschränkungen aufgrund des Fehlers ohne größere Auswirkungen auf die Nutzbarkeit des Programmes
5 – nicht kritisch Kosmetische Änderungen, System kann ohne Einschränkungen genutzt werden.
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Incident Management – Standardisierung

In der Regel sind Incident-Tools schon mit diversen auszufüllenden Feldern vorbelegt. Dies ist auch enorm wichtig, da ein standardisiertes, gut ausgefülltes und vor allem nachvollziehbares Ticket dem Entwickler nicht nur die Arbeit sehr erleichtert sondern auch zu einer schnelleren Lösung des Problems führt. Trotzdem habe ich nochmal ein paar Anhaltspunkte zusammengestellt, anhand denen vielleicht noch Felder hinzugefügt werden können:

  • fortlaufende Fehlernummer
  • Name der Software/Applikation/Modul
  • Softwareversion
  • Erfassendes Team und/ oder Teststufe
  • Name des Testers
  • Datum des Fehlerfundes (kann von der Erfassung abweichen)
  • Umgebungsdaten (Plattform, Test-Umgebung, Zugriff)
  • Bearbeitendes Team
  • Bearbeitender Entwickler
  • Status
  • Schwere des Fehlers (hierzu in späteren Posts mehr)
  • Priorität des Fehlers  (hierzu in späteren Posts mehr)
  • Anforderungen, aufgrund dessen Nicht-Erfüllung ein Incident aufgemacht wird
  • Testfall, inklusive aller Schritte zur Reproduzierung
  • Problembeschreibung
  • Kommentare
  • Änderungen zur Korrigierung des Incdidents
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Incident Management, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar

Testmanagement – Incident Management – Incident-Auswertung

Üblicherweise wird ein zentrales Tool bzw eine Datenbank für jedes einzelne Projekt oder auch jede einzelne Software aufgesetzt, wo alle Incidents welche während Test oder Live-Betrieb auftreten registriert und administriert werden. Es kann sich hierbei nicht nur um Probleme in den getesteten Bereichen, sondern auch um falsche Spezifikationen, Handbücher oder andere falsche Dokumente handeln, die es zu berichtigen gilt.

Jeder Entwickler sollte hierbei die Möglichkeit haben, Kommentare abzugeben, Rückfragen an den Tester zu stellen oder auch unberechtigte Incidents zurückzuweisen.

Auch Korrekturen werden in diesem Tools bei dem jeweiligen Incident vermerkt.

Für Test- und Projektmanager bietet sich so die Möglichkeit, sich jederzeit über den aktuellen Problem-Status, deren Anzahl und Fortschritt zu informieren. Ideallerweise können bei diesen Tools Reporting-Werkzeuge zur schnelleren und einfacheren Auswertung genutzt werden.

  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Incident Management, Testmanagement | Hinterlasse einen Kommentar

Testmanagement – Incident Management – Testberichte

Optimalerweise nach jedem Testlauf, spätestens nach Durchführung des aktuellen Testzyklus werden alle Testberichte ausgewertet. Tatsächliche Resultate werden mit den Erwartungen verglichen und jedes signifikante, unerwartete Ereignis als Indikator für eine Fehlfunktion gesehen. Als nächsten Schritt versichert sich der jeweilige Tester, ob es sich wirklich um einen Fehler oder auch um falsche Testfälle, Vorbereitung oder fehlerhafte Testumgebungen/ Konfigurationen handelt.
Wenn alle anderen Ursachen ausgeschlossen werden können wird ein Problem-/Incident-Ticket eröffnet.

  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • Blogosphere
  • email
  • PDF
  • RSS
  • Technorati
  • Add to favorites
  • blogmarks
  • del.icio.us
  • Digg
  • Wikio
Veröffentlicht unter Incident Management, Testmanagement | Verschlagwortet mit , | Hinterlasse einen Kommentar