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.
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
Veröffentlicht unter Standards, Testmanagement
Verschlagwortet mit Standards, Testmanagement
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.
Veröffentlicht unter Konfigurationsmanagement, Testmanagement
Verschlagwortet mit Konfigurationsmanagement, Testmanagement
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.
Veröffentlicht unter Konfigurationsmanagement, Testmanagement
Verschlagwortet mit Konfigurationsmanagement, Testmanagement
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.
Veröffentlicht unter Incident Management, Testmanagement
Verschlagwortet mit Incident Management, Testmanagement
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.
Veröffentlicht unter Incident Management, Testmanagement
Verschlagwortet mit Incident Management, Testmanagement
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. |
Veröffentlicht unter Testmanagement
Verschlagwortet mit Incident Management, Testmanagement
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
Veröffentlicht unter Incident Management, Testmanagement
Verschlagwortet mit Incident Management, Testmanagement
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.
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.
Veröffentlicht unter Incident Management, Testmanagement
Verschlagwortet mit Incident Management, Testmanagement
Hinterlasse einen Kommentar
