Inhalt dieser Lerneinheit
Im Rahmen dieser Lerneinheit werden sie mit den folgenden Themen vertraut gemacht:
Softwareentwicklungsmodelle
Das allgemeine Vorgehensmodell
Teststufen
Komponententest
Testarten
Wartungstest
Komponententest
Testtreiber und Platzhalter
Integrationstest
Testarten
Softwareentwicklungsmodelle
Testen kann nicht als einzelne isolierte Aktivität stattfinden. Die Testaktivitäten beziehen sich immer auf Softwareentwicklungsaktivitäten. Die Software-Entwicklung basiert meistens auf sog. Vorgehensmodellen. Diese verschiedenen Modelle haben jeweils einen unterschiedlichen Lebenszyklus und erfordern deshalb auch unterschiedliche Testansätze.
Grundsätzlich können Vorgehensmodelle in zwei Typen unterschieden werden:
Sequenzielle Vorgehensmodelle und
iterative Vorgehensmodelle
Folgend wird das sequenzielle anhand der Methode hermes5 und das iterative Modell anhand von srum erklärt.
Hermes als Beispiel für eine primär sequenzielle Vorgehensmethode
HERMES ist die Projektmanagementmethode für Projekte im Bereich der Informatik, der Entwicklung von Dienstleistungen und Produkten sowie der Anpassung der Geschäftsorganisation. HERMES unterstützt die Steuerung, Führung und Ausführung von Projekten verschiedener Charakteristiken und Komplexität. HERMES hat eine klare, einfach verständliche Methodenstruktur, ist modular aufgebaut und erweiterbar.
Das Phasenmodell bildet das Rückgrat des Projekts. Es gliedert den Lebenszyklus des Projekts und schafft die Voraussetzung für das gemeinsame Verständnis der Projektbeteiligten zum Projektablauf. Das HERMES-Phasenmodell besteht aus vier Phasen:
Das Projekt beginnt mit der Phase Initialisierung beim Meilenstein Projektinitialisierungsauftrag und endet am Schluss der Phase Einführung beim Meilenstein Projektabschluss.
Jedes Phasenende ist durch einen Meilenstein bestimmt, der den Entscheid zum weiteren Vorgehen hervorhebt. Diese Meilensteine entsprechen Quality Gates, an denen der Stand des Projekts und die Qualität der Projektplanung und -durchführung überprüft werden. Dabei erfolgt auch die Abstimmung mit den übergeordneten Strategien und Zielen der Stammorganisation. Die Überprüfung der Erreichung der Meilensteine erfolgt mit Checklisten, welche mit projektspezifischen Kriterien ergänzt werden. Ergänzend zu den Meilensteinen an den Phasenenden gibt es szenariospezifische Meilensteine als weitere Quality Gates, z.B. für Architektur und Sicherheit.
Entlang den Phasen und Meilensteinen erfolgt das Reporting gemäss den Vorgaben der Stammorganisation bezüglich Inhalt und Frequenz.
Das Phasenmodell bildet auch eine Grundlage für die finanzielle Steuerung des Projekts. Bei Phasenfreigabe werden die Mittel (finanziell, personell, Infrastruktur) für die nächste Phase durch den Auftraggeber freigegeben.
Das Phasenmodell erleichtert die Koordination und Steuerung der Projekte in einem Programm. Es ist eine Voraussetzung für die Integration der Projekte in das Projektportfoliomanagement der Stammorganisation. Dadurch werden die Projekte übergeordnet durch die Stammorganisation steuerbar.
Scrum als iteratives-inkrementelles Vorgehensmodell
Scrum (aus englisch scrum für „[das] Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt.[1] Es ist eine Umsetzung von Lean Development für das Projektmanagement.[2][3]
Scrum besteht aus nur wenigen Regeln. Diese beschreiben fünf Aktivitäten, drei Artefakte und drei Rollen, die den Kern (oder englisch core) ausmachen. Die Regeln sind im sogenannten Agile Atlas (für den Kern, also wohl die Grundlagen) oder im (etwas ausführlicheren) Leitfaden Scrum Guide beschrieben.[4][5] Das Scrum-Framework muss durch Techniken für die Umsetzung der Aktivitäten, Artefakte und Rollen konkretisiert werden, um Scrum tatsächlich umsetzen zu können. Der Kern von Scrum wurde von den Umsetzungstechniken getrennt, um einerseits die zentralen Elemente und Wirkungsmechanismen klar zu definieren, andererseits um große Freiheiten bei der individuellen Ausgestaltung zu lassen.
Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert.[6]
Arbeitsablauf nach Scrum
Ein mit Scrum gesteuertes Projekt beginnt mit der Entwicklung einer Produktvision. Die Vision darf zu Beginn des Projekts noch ungenau sein, da sie im Laufe des Projekts weiter konkretisiert werden kann. Auf Basis der Vision verfasst der Product Owner das Product Backlog.
Die eigentliche Produktentwicklung erfolgt in den sog. Sprints, die in der Regel einen Entwicklungszeitraum von zwei bis vier Wochen vorsehen. Zu Beginn eines Sprints präsentiert der Product Owner dem Team das priorisierte Product Backlog. Das Team entscheidet eigenständig, wie viele der am höchsten priorisierten Anforderungen es im anstehenden Sprint umsetzen will. Daraus ergibt sich das sog. Sprint Backlog.
Am Ende des Sprints präsentiert das Team in einem Review den Zuwachs der Funktionalität den Stakeholdern, sodass diese auf der einen Seite die Funktionalität überprüfen und auf der anderen Seite rechtzeitige Anpassungen oder Änderungen vornehmen können. Weiter erfolgt am Ende eines Sprints eine Retrospektive, in der das Team den Entwicklungsprozess sowie die Zusammenarbeit im vorangegangenen Sprint analysiert und bei Bedarf Verbesserungen für die Arbeitsorganisation entwickelt.
Scrum Artefakte
Der Scrum Guide schlägt folgende Artefakte zur Steuerung vor:
Product Backlog
Sprint Backlog
Product Increment
Product Backlog
Product Backlog
Ausgehend von der gemeinsamen Vision für das Produkt erstellt der Scrum Product Owner häufig in Zusammenarbeit mit den Stakeholdern eine Liste mit allen Anforderungswünschen für das Produkt/Projekt.
Einzelne Produkt Backlog Items, meist User Stories, beschreiben diese Anforderungen aus Sicht des Kunden und in der Sprache des Kunden.
Die Liste aller für das Produkt/Projekt zu erledigen Backlog Items ergeben den Product Backlog.
Der Scrum Product Owner hat die Hoheit über das Product Backlog.
Eigenschaften des Product Backlogs
Das Product Backlog ist eine geordnete Liste mit einer eindeutigen Reihenfolge.
Die Reihenfolge legt der Scrum Product Owner fest. Ein wichtiger Einflussfaktor ist der "Business Value" der Backlog Items.
Das Product Backlog soll geschäzt sein (am besten nach Value und Größe der Backlog Items).
Das Product Backlog ist nie "Vollständig". Es ist ein "lebendes" "emergentes" Artefakt. Dies bedeutet auch, dass das Product Backlog vom Scrum Product Owner umsortiert werden kann.
Backlog Items die im Product Backlog "oben" stehen sollen möglichst "Ready" sein.
Das Product Backlog spiegelt das zu entsehende Produkt wieder.
Sprint Backlog
Das Sprint Backlog ist ebenfalls eine Liste. Es macht die Arbeit sichtbar, die das Development Team in einem Sprint erledigt. Es enthält alle Product Backlog Items, die in diesem Sprint bearbeitet werden und die dazugehörigen heruntergebrochenen Einzelaufgaben (Tasks).
Das Sprint Backlog wird während des Sprint Plannings erstellt. Neue Aufgaben (aber keine neuen Anforderungen) können jederzeit wärend eines laufenden Sprints ergänzt werden.
Das Sprint Backlog ist ein Arbeitsmittel des Development Teams und deshalb hat auch das Development Team die Hoheit über das Sprint Backlog.
Product Increment
(engl. Potentially shippable (Product) Increment): Teilergebnis des Projekts, das pro Sprint geliefert wird.
Das Resultat am Ende des Sprints ist ein potenziell auslieferbares Produkt. Die Funktionalität des Ergebnisses wächst stückchenweise (inkrementell). Deswegen sprechen wir von einem Produktinkrement. Das Inkrement enthält das Ergebnis aller im Sprint umgesetzten Product Backlog Einträge.
Das Entwicklungsteam arbeitet immer so, dass es das Product Increment ausliefern könnte. Ob es tatsächlich ausgeliefert wird, entscheidet der Product Owner. Sprich das Inkrement ist "Done".
Die Schwierigkeit gerade für neue Scrum-Teams ist, im Planning ein sinnvolles Inkrement zu definieren.
Es kann passieren, dass nicht alle Backlog Items die im Sprint Planning Meeting für den Sprint ausgwählt wurden auch umgesetzt wurden. Doch selbst dann sollte das Product Increment "Done" sein. Quelle: https://www.scrum-events.de/scrum-artefakte.html
Das allgemeine V-Modell
Das V-Modell ist ein Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in Phasen organisiert wird. Neben diesen Entwicklungsphasen definiert das V-Modell auch das Vorgehen zur Qualitätssicherung (Testen) phasenweise. Auf der linken Seite wird mit einer funktionalen/fachlichen Spezifikation begonnen, die immer tiefer detailliert zu einer technischen Spezifikation und Implementierungsgrundlage ausgebaut wird. In der Spitze erfolgt die Implementierung, die anschließend auf der rechten Seite gegen die entsprechenden Spezifikationen der linken Seite getestet wird.
Die Bestandteile des allgemeinen V-Modells Bestandteile des allgemeinen V-Modells In der Praxis kann ein V-Modell auch weniger, mehr oder andere Stufen besitzen. Die Zusammensetzung hängt vom Projektvorgehen und vom Produkt ab, um das es sich handelt. Beispielsweise kann es Komponentenintegrationstests nach Komponententests oder Systemintegrationstests nach Systemtests geben. Entwicklungsdokumente (wie z.B. Geschäftsvorfälle, Anforderungsspezifikationen, Entwurfsdokumente und Code), die während der Entwicklung entstehen, sind oftmals die Basis für Tests in einer oder mehreren Stufen. Während des Erstellens der Entwicklungsdokumente werden diese verifiziert (Review, statische Analyse). Basierend auf diesen Dokumenten wird anschliessend der Testentwurf vorgenommen.
Der linke Ast vereint die immer detaillierter werdenden Entwicklungsschritte, in deren Verlauf das vom Kunden gewünschte System schrittweise entworfen und schliesslich programmiert wird.
Weitere Vorgehensmodelle
Weitere Vorgehensmodelle in der Softwareentwicklung sind:
Teststufen
Komponententest
Hat zum Ziel, Software, die separat getestet werden kann (z. B. Module, Programme, Objekte, Klassen etc.), zu prüfen und darin vorhandene Fehler zu finden.
Integrationstest
Prüft die Schnittstellen zwischen Komponenten und die Interaktionen zwischen verschiedenen Teilen eines Systems, wie zum Beispiel zum Betriebssystem, zur Hardware oder den Schnittstellen zwischen den Systemen.
Systemtest
Testet das Verhalten eines Gesamtsystems oder Gesamtprodukts, das vorab im Rahmen eines Entwicklungsprojekts oder -programms definiert worden ist.
Abnahmetest
Das Ziel besteht darin, Vertrauen in Bezug auf das System, Teilsystem oder in spezifische nicht-funktionale Eigenschaften eines Systems zu schaffen.
Komponententest
Testbedingungen
Es ist sicherzustellen dass die laut Spezifikation geforderte Funktionalität korrekt und vollständig realisiert ist.
Testbasis
Die Testfälle werden aus den Anforderungen und weitere Entwicklungsdokumenten oder direkt aus dem Programmcode abgeleitet.
Testobjekte
Einzelne Komponenten (Softwarebausteine), welche von anderen Komponenten des Systems isoliert werden können.
Diese nennt man der verwendeten Programmiersprache entsprechend auch: Units, Komponenten, Module oder Klassen.
Auch die Umwandlung und Migration von Daten kann als Testobjekt spezifiziert werden.
Ebenso ist der Zugriff auf und die Interaktion mit Datenbank-Systeme ein zu testende Eigenschaft.
Fehlerwirkungen
Test auf Funktionale und nicht funktionale Eigenschaften, Robustheit (Negativtest), Effizienz und Wartbarkeit.
Testumgebung
Die Umgebung sollte entwicklungsnah gestaltet sein und die Verwendung von Platzhaltern und Treibern ermöglichen.
Anwendung von Debugging-Werkzeugen.
Teststrategie
Whitebox und Blackbox Testfälle.
Da unter Umstände Programmier-Kenntnisse erforderlich sind, erfolgt der Test oft durch den Entwickler selbst.
Testtreiber und Platzhalter
Treiber und Platzhalter simulieren aufrufende und aufgerufene Funktionen bzw. Komponenten.
Komponenten meist nicht isoliert funktionsfähig
Entwickeln von Treibern und Platzhaltern (Stubs) für den Test
Entwicklungsaufwand kann beträchtlichen Umfang erreichen.
Mit zunehmender Entwicklungsdauer nimmt die Notwendigkeit ab, Stubs und Treiber einzusetzen.
Integrationstest
Testbedingungen
Test der Schnittstellen und das Zusammenspiel zwischen integrierten Komponenten.
Testbasis
Die Beschreibungen der Schnittstellen (Technische Systemspezifikation).
Die Architektur-Schnittstellen (Hardware und Software).
Die Schnittstellen zu den Arbeitsabläufen (Geschäftsprozesse und betriebliche oder operationelle Prozesse).
Testobjekte
In der Integrations-Testphase werden die Komponenten zu grössere Teilsystemen zusammengefasst und getestet. Auch Teilsysteme können zu Gesamtsystemen zusammengefasst werden.
Datenbank-Interaktion.
Infrastruktur-Schnittstellen.
Geschäftsprozess-Schnittstellen.
Konfigurations-Schnittstellen (Hardware, Betriebssystem und Dritt-Applikationen).
Fehlerwirkungen
Test auf Funktionale und nicht funktionale Eigenschaften. Aufspüren von Fehlerzuständen in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten.
Testumgebung
Vielfach die gleiche Umgebung wie im Komponententest. Verwendung von Platzhaltern und Treibern, Schnittstellenmonitore zur Überwachung der Schnittstellen.
Teststrategie
Sowohl White- als auch Blackbox.
Auswahl der optimalen Integrationsstrategie.
Systemtest
Testbedingungen
Überprüfen ob und wie gut das fertige System die an das System gestellten Anforderungen (funktional und nicht-funktional) erfüllt.
Testbasis
Testfälle werden von den Anforderungen, den Geschäftsprozessen oder anderen Beschreibungen des funktionalen Systemverhaltens abgeleitet.
Auch Risikoanalysen können als Basis für diese Tests dienen.
Testobjekte
Die vollständig integrierten Systeme.
Benutzerhandbücher.
Betriebshandbücher.
Konfigurations-Anforderungen.
Fehlerwirkungen
Die Anforderungen (funktional und nicht-funktional) werden nicht, teilweise oder nicht mit der notwendigen Performanz erfüllt.
Testumgebung
Die Testumgebung soll mit der Produktionsumgebung so weit wie möglich übereinstimmen.
Die Durchführung erfolgt oftmals durch unabhängige Testteams («Closed Shop»).
Teststrategie
Blackbox.
Unter Umständen werden Whitebox-Tests zur Messung der Überdeckung durchgeführt, um die Programmdokumentation zu vervollständigen.
Abnahmetest
Testbedingungen
Die Einsatzfähigkeit und die Nutzung des Systems werden durch den Kunden bzw. den Anwender bewertet.
Testbasis
Die Benutzer-Anforderungen (Requirements) dienen als Basis für die Testspezifikationen. Zusätzlich können verwendet werden: Systemanforderungen; Anwendungsfälle; Geschäftsprozesse; Anwenderverfahren; Formulare.
Testobjekte
Die für die Inbetriebnahme vorgesehenen Systeme.
Fehlerwirkungen
Die Einsatzfähigkeit und die Nutzung des Systems sind nicht gewährleistet.
Testumgebung
Die Testumgebung soll mit der Produktionsumgebung so weit wie möglich übereinstimmen.
Teststrategie
Benutzer-Abnahmetest
Betrieblicher Abnahmetest
Vertrags- und regulativer Abnahmetest
Alpha- und Beta-Test.
Benutzer-Abnahmetest
Er prüft die Tauglichkeit eines Systems zum Gebrauch durch Anwender bzw. Kunden.
Betrieblicher Abnahmetest
Die Abnahme des Systems durch den Systemadministrator enthält:
Test des Erstellens und Wiedereinspielens von Sicherungskopien (backup/ restore)
Wiederherstellbarkeit nach Ausfällen
Benutzermanagement
Wartungsaufgaben
Datenlade- u. Migrationsaufgaben und
periodische Überprüfungen von Sicherheitslücken
Regulatorischer Abnahmetest
Beim vertraglichen Abnahmetest wird kundenindividuelle Software explizit gegen die vertraglichen Abnahmekriterien geprüft. Abnahmekriterien sollten beim Vertragsabschluss zwischen den beteiligten Parteien definiert werden.
Regulatorische Abnahmetests werden gegen alle Gesetze und Standards durchgeführt, denen das System entsprechen muss – beispielsweise staatliche, gesetzliche oder Sicherheitsbestimmungen.
Alpha- und Beta-Test
Hersteller kommerzieller oder Standardsoftware wollen oft Feedback von potenziellen oder existieren- den Kunden erhalten, bevor sie ein Produkt kommerziell zum Kauf anbieten. Der Alpha-Test wird am Herstellerstandort durchgeführt, nicht jedoch vom Entwicklungsteam. Der Beta- (oder Feldtest) wird von Kunden oder potenziellen Kunden an den Kundenstandorten durchgeführt.
Organisationen können ebenso andere Begriffe nutzen z.B. Fabrikabnahmetests oder Kundenakzep- tanztests für Systeme, die getestet werden, bevor oder nachdem sie zum Einsatzort eines Kunden gebracht wurden.
Testarten
Funktionale Test
Um die Funktionalität, die ein System, Teilsystem oder eine Komponente erbringen muss, zu beschreiben, können unterschiedliche Quellen benutzt werden:
Anforderungsspezifikationen
Anwendungsfälle (Use Cases)
Funktionale Spezifikationen.
Die Funktionalität beschreibt, was geleistet werden muss. Funktionale Merkmale lassen sich nach ISO 9126 wie folgt zusammenfassen:
Angemessenheit,
Richtigkeit,
Interoperabilität,
Ordnungsmässigkeit
Sicherheit.
Die Funktionen und die Eigenschaften des funktionalen Testens leiten sich aus den vorhandenen Dokumenten ab.
Das funktionale Testen kommt in allen Teststufen zur Anwendung Spezifikationsbasierte Testentwurfsverfahren werden verwendet, um Ausgangskriterien und Testfälle zur Funktionalität der Software oder des Systems aus den Spezifikationen herzuleiten. Ein funktionaler Test betrachtet das von aussen sichtbare Verhalten der Software (Black-Box-Test). Ein spezieller Typ des funktionalen Tests, der Sicherheitstest, begutachtet sicherheitsrelevante Funktionen (z.B. Firewalls) bezüglich ihrer Fähigkeit, externe Bedrohungen wie Viren etc. zu erkennen. Ein weiterer Test, der Interoperabilitätstest, bewertet die Fähigkeit des Softwareproduktes, mit ein oder mehreren spezifizierten Komponenten oder Systemen zu interagieren (USB- Schnittstelle). Anforderungsbasiertes Testen Im Mittelpunkt steht das Testen von einzelnen, auf Anforderungen basierenden Funktionen. Jede Anforderung sollte zumindest mit einem Testfall abgedeckt werden. Häufig sind jedoch mehrere Testfälle notwendig.
Anforderungsbasiertes Testen Im Mittelpunkt steht das Testen von einzelnen, auf Anforderungen basierenden Funktionen. Jede Anforderung sollte zumindest mit einem Testfall abgedeckt werden. Häufig sind jedoch mehrere Testfälle notwendig.
Geschäftsprozessbasiertes Testen Im Mittelpunkt steht das Testen von Abläufen als Ergebnis einer Analyse oder Beschreibung der Geschäftsprozesse.
Die Testfälle basieren auf Szenarien typischer Geschäftsfälle.
Die Priorität der Testfälle richtet sich nach der Häufigkeit und Relevanz der entsprechenden Geschäftsprozesse.
Nicht-funktionaler Test
Nicht-funktionaler Test Der Begriff «nicht-funktionaler Test» bezeichnet Testarten, die zur Prüfung von allgemeinen Software- und Systemmerkmalen verwendet werden. Das Test-Ziel besteht darin, zu überprüfen, wie ein System arbeitet. Zur Quantifizierung dieser Merkmale werden unterschiedliche Massstäbe eingesetzt, wie z. B. Antwortzeiten beim Performancetest. Diese Testarten können auf einem Qualitätsmodell basieren. Die nicht-funktionalen Test-Arten nach ISO 9126 sind: Zuverlässigkeit,
Benutzbarkeit,
Effizienz (Performance),
Änderbarkeit und
Übertragbarkeit
Für die Prüfung nicht-funktionaler Merkmale werden logischerweise funktionale Testfälle eingesetzt.
Nicht-funktionales Testen kommt in allen Teststufen zur Anwendung.
Strukturbezogener Test
Strukturbezogene Tests können auf allen Teststufen vorkommen, diese werden jedoch vorwiegend im Komponenten- und Integrationstest eingesetzt. Bei den strukturellen Tests kann die Testintensität durch die Beurteilung des Überdeckungsgrades gemessen werden. Diese Testüberdeckung zeigt auf, inwiefern eine Struktur durch die Tests geprüft bzw. ausgeführt (überdeckt) wurde. Dabei wird jeweils der prozentuale Anteil der überdeckten Strukturelemente angegeben. Liegt die erreichte Testüberdeckung unter 100%, kann diese verbessert werden, indem für die noch nicht abgedeckten Elemente zusätzliche Testfälle spezifiziert werden. Die strukturbezogener Tests basieren zum Beispiel auf:
der internen Struktur der Komponente
der Software-Architektur
der Systemarchitektur
der Aufruf-Hierarchie
Die strukturorientierten Tests können auch auf die Stufen System-, Systemintegrations- oder Abnahmetest angewendet werden. Hier werden dann Geschäftsmodelle oder Menüstrukturen als Testbasis verwendet. Für die systematische Herleitung der Testfälle dienen White-Box-Verfahren. Damit die Überdeckung gemessen werden kann, werden entsprechende Werkzeuge durch die Entwickler eingesetzt.
Änderungsbezogener Test
Durch Weiterentwicklungen und Wartungsarbeiten werden fortwährend Teile der Software verändert und müssen erneut getestet werden. Solche änderungsbezogenen Tests haben gewisse Eigenschaften oder Bedingungen:
Die dabei gefundenen Fehler können sich entweder in der zu testenden Software selbst oder aber in einer anderen Softwarekomponente befinden.
Ein Regressionstest sollte im Anschluss an den Fehlernachtest oder Wartungstest ausgeführt werden, wenn sich die Software selbst oder ihre Umgebung geändert hat.
Der notwendige Testumfang sollte durch das Risiko bestimmt werden, dass neu eingeführte Fehler eventuell nicht gefunden werden.