Informatiker FA M227 Zusammenfassung

Der Testprozess

Welche Standards fördern die Softwarequalität

• ISO 12207 Rahmen für Beschaffung, Lieferung, Entwicklung, Betrieb, Wartung)
• Capability Maturity Model (CMM). Fünf Reifegrad-Stufen. Initialier Prozess, Wiederholbarer Prozess, Definierter prozess, Gesteuerter propzess, Optimierter Prozess
• ISA 15504 Kombination aus ISO 12205 und CMM
• Test Maturity Model (TMM). Fünf Stufen des Reifemodells: Unsystematisch, organisiert, Kostensenkend, Systematisch, Optimiert.

Beziehungen zur Qualitätssicherung

Die Abteilung "Qualitätssicherung" erarbeitet Qualitätstandards für das gesamte Unternehmen. Die Qualitätsrichtlinien werden im QS-Plan niedergeschrieben und sind verbindliche Rahmenbedingungen. Folgende zwei QS-Massnahmen werden grundsätzlich vorgeschlagen:

Konstruktive QS-Massnahmen:

• Qualität wird bereits beim Erstellen des Systems eingebracht.
• durh Vorgaben, Sprachen, Tools, organisatorische Regelungen, Standards, Checklisten

Analytische QS-Massnahmen

• überprüfen des erstellten Systems
• Verifizieren von Dokumenten
• Den Anforderungen gegenüber stellen.

Beziehungen zum Projektmanagement

• Projekt innerhalb vorgegebener Zeit, den budgetierten Kosten und der gewünschten Qualität abliefern
• PL gibt Soll-Termine und Meilensteine vor
• PL gibt auch Soll-Kosten vor welche als Input für den Testplan dienen.
• PL gibt Akzeptanzkriterien vor. Diese fliessen in den Testentwurf.

Beziehung zu Systementwicklung

• Softwareentwicklungsprozess liefert zu prüfende Objekte
• Die Softwareentwicklung bearbeitet die erstellten Problemmeldungen
• Die QS Aktivitäten verifizieren die Artefakte (Verifikation und Validierung)

Testen im Phasenmodell

• Phasenmodel: Fachkonzept, DV-Konzept, Realisierung, Testphase, Einführung
• In der Phase "Realisierung" findet die Codeinstpektion und die Unit-Tests statt.

V-Modell

• weit verbreitetes Vorgehensmodell
• Bewusste Genüberstellung der konstruktiven zu den prüfenden Aktivitäten

Testprozess im Rational Unified Process

• de-facto Standard in der objektorientierten Systementwicklung

Testen im Extreme Programming (XP)

• Einfaches Prozessmodell
• Softwaretests haben zentrale Bedeutung

Beziehung zum Beschaffungsprozess

• Im Gegensatz zum Systementwicklungsprozess wird das zu prüfende Objekte nicht selbst hergestellt, sonder eingekauft.
• Es sind Abnahmetests vorzusehen
• Die Kriterien sind im Voraus im Pflichtenheft sauber zu definieren

IT-Qualitätssystem

Ziel eines IT-Systems ist es während der Betriebsphase den geplanten Nutzen für das Unternehmen zu erbringen. In einem verbindlichen QS-Plan werden zwei Arten von Qualitätssicherungs-Massnahmen unterschieden:

• Konstruktive QS-Massnahmen (Vorgaben, Sprachen, Tools, organisatorische Regelungen, Standards, Checklisten
• Analytische QS-Massnahmen: überprüfen des erstellten Systems, Verifizieren von Dokumenten, den Anforderungen gegenüberstellen.

Welches sind die Prüfobjekte

• Anforderungsspezifikation (Use-Case-Modelle, Prozessmodelle, Datenmodelle etc.)
• Design(Eingabemasken, Architektur, Prozessbeschreibung, Reports, etc.)
• Sourcecode
• Lauffähige Anwendung inkl. Handbücher und Installationsanweisungen
• Betriebs- und Systemsoftware
• DBMS
• Hardware
• Netzwerk

Welche Qualitätsdimensionen weist ein IT-System auf

• Funktionalität. Aufgabenangemessenheit, Genauigkeit, korrekt, fehlerfrei, Verknüpfbarkeit mit anderen Anwendungen, Konformität z.B. zum Gesetz oder CI.
• Zuverlässigkeit. Robustheit, eine gewisse Reife, Fehlertoleranz, Wiederherstellbarkeit. Wird anhand Anzahl der Systemausfälle in einer bestimmten Zeitperiode gemessen.
• Benutzbarkeit. Ergonomie, Anwenderfreundlich, Bedienbarkeit, Erlernbarkeit, GUI-Standards.
• Effizienz. Antwortzeiten, Lastverhalten, Batchverarbeitung, Datendurchsatz, Skalierbarkeit
• Wartbarkeit. Unterbruchfreien Betrieb sicherstellen. Erweiterbarkeit, Parametrierung, Analysierbarkeit (für Erweiterung), Prüfbarkeit.
• Übetragbarkeit. Installierbarkeit (gemäss regeln des OS), Deinstallierbarkeit, Konformität, Austauschbarkeit, OS-Portierbarkeit.

Qualitätsmerkmale messen

• Für jedes Messverfahren muss ein Messverfahren festgelegt werden.
• Klar definierte Messbedingungen
• Messskala und Grenzwerte festlegen

Teststrategie

• Unternehmen werden von eine Vision getragen
• Aus der Vision wird die Unternehmensstrategie abgeleitet
• Darunter die IT-Strategie
• Das Qualitätsmanagement (QM) hat die Aufgabe die Qualität in allen Bereichen des Unternehmens zu erhalten bzw. zu steigern. Dort wird unter anderem der QS-Plan erstellt welcher die QS-Organisation regelt, die Aufgaben, Verantwortlichkeiten, und Schnittstellen vorgibt.
• Der QS-Plan beinhaltet weiter Methoden, Techniken, Richtlinien sowie Kontrollmassnahmen.
• In die Teststrategie fliessen die Vorgaben der IT-Strategie und des QS-Plan ein.

Die Testpolitik regelt grundlegende Prinzipien zum Thema "Prüfen und TEsten"

• Definition und Bedeutung von Prüfen und Testen
• Definition des zu erreichenden Qualitätsniveaus
• Definition des Testprozesses und Zusammenspiel mit Unternehmensprozessen
• Metrik für Messungen
• Ansatz zur Optimierung des Testprozesses (z.B. TMM)

Das Testhandbug regelt dagegen konkrete Aspekte des Testprozesses:

• Projektübergreifende Richtlinien und Methodiken
• Darstellung der Risiken und Massnahmen
• Aufzuziehende Testorganisation
• Richtlinien Testumgebung (Infrastruktur, Testwerkzeuge)
• Workflow des Testprozesses
• Einsatz von Testmethoden und Testarten
• Firmeninternes Glossar
• Vorlagen für Test- und Berichtsdokumente

Welche Grundsätze beeinflussen des Testprozess?

• Alle menschlichen Erzeugnisse weisen Fehler auf
• Die Abwesenheit von Fehlern kann ab einer bestimmten Komplexität nur noch mit einem extrem Aufwand nachgewiesen werden.
• Der Summationseffekt bildet ein weiteres Problem: Fehler die z.B. in der Analysephase entstehen, führen zu einem mangelhaftem SW-Entwurf, der sich dann bei der Implementation fortsetzt.
• Faustregel: Je früher sich ein Fehler einschleicht und je später er entdeckt wird, desto teurer wird dessen Behebung
• Ein Entwickler sollte nicht sein eigenes Programm testen. (gleiche Überlegungsfehler)
• Die Tester müssen das Auffinden von Fehlern als Erfolg betrachten. (Wettbewerb fördern)
• Pareto-Prinzip: 80-zu-20-Regel, besagt, dass 80 % der Ergebnisse in 20 % der Gesamtzeit eines Projekts erreicht werden. Die verbleibenden 20 % der Ergebnisse verursachen die meiste Arbeit.
• Wo ein Fehler gefunden wird, ist es wahrscheinlich, dass noch weitere Fehler existieren.
• implizite Qualitätsanforderungen: Nicht alle Qualitätsmerkmale lassen sich explizit (schriftlich) festhalten. Das Einhalten bestimmter GUI-regelen wird z.B. automatisch vorausgesetzt.
• Ein Benutzer darf in keine Falle laufen. Ein Benutzer darf aufgrund einer Fehleingabe keine Daten und/oder kostbare Zeit verlieren.

Welches ist das optimal Testvorgehen

• ein inkrementelles Vorgehen ist oft besser als ein Big Bang
• Test soll parallel zur Systementwicklung ablaufen
• Die Integrationstests können dadurch in einem frühen Stadium vorgenommen werden.

Top-Down Verfahren

• eignet sich vor allem für ein frühes Stadium
• Mit Hilfe eines Prototyps kann das Aussehen und die Abläufe mit dem Auftraggeber besprochen werden.
• Noch nicht entwickelte Module werden durch Stubs (Dummies, Testrümpfe) ersetzt.
• Bei diesem Verfahren stehen die einzelnen Anwendungsfälle beim Testen im Vordergrund.

Bottom-Up Verfahren

• bewährt sich im fortgeschrittenen Stadium
• die entwickelten Module werden im Detail getestet
• die aufrufende Software wird durch "Drivers" simuliert.
• In diesem verfahren geht man von der bestehenden Funktionalität aus.

Manchmal lässt sich die Reihenfolge der zu entwickelnden Komponenten nicht streng nach Bottom-Up oder Top-Down realisieren. Dann werden die Module ad hoc nach deren Fertigstellung integriert. Eine andere Variante ist die bewusste Priosierung der komplexen und risikoreichen Module: hardest first.

Wie werden die Testfälle ermittelt?

Methodisches versus exploratives Vorgehen

Vorteile methodisches Vorgehen:

• Abdeckung der Fälle berechenbar
• Testfortschritt messbar
• Deshalb für kritische Systeme weitgehend methodisch vorgehen.

exploratives Vorgehen:

• intuitive Vorgehensweise
• Testen methodisch nicht erfassten Fälle
• Aufgrund persönlicher Erfahrung werden mögliche Fehler erahnt.
• unübliche Konstellationen können getestet werden
• Beim ad hoc Test werden die Testfälle spontan ermittelt und ausgeführt
• Beim unsymetrischen Test wird ohne im Voraus definiertes System getestet
• Beim Zufallstest werden Testfälle zufällig ausgewählt
• Beim Guerilla-Testen testet man unerlaubtes. Falsche Eingaben, alle Tasten gleichzeitig, Strom abstellen etc.
• Darf nicht mit chaotischem Testen verwechselt werden.
• Für Frontends gut geeignet.

Explorative Tests sind vor allem bei System- und Abnahmetests zu empfehlen und haben folgende Vorteile:

• Kann grosse Zeitersparnisse mit sich bringen.
• Erfahrung des Testers kann voll genutzt werden.
• Hohe Flexibilität während des Testens
• Systemfunktion kann während des Testens erforscht werden, was zu neuen, vorher nicht erkennbaren, Testfällen führen kann.

Methodische Testfallermittlung

Je nach Phase werden schwerpunktmässig andere Testmethoden ausgewählt:

• Modul- und Unittest: Whitebox- und/oder Blackboxtest
• Integrationstest: Greybox-Test
• Systemtest: Blackbox-Test

Whitebox-Test (strukturelles Testverfahren)

• setzt detaillierte Kenntnisse des Systems voraus.
• Anhand des Sourcecodes und den Anforderungen wird gezielt getestet
• Weil beim erstellen Sourcecode Teile noch fehlen können, müssen die Detailspezifikationen für das Testen ebenfalls beigezogen werden.
• Die Testabdeckung zeigt anhand der inneren Struktur den prozentuellen Abdeckungsgrad. (Welche Programmpfade wurden schon getestet). Dazu können Coverage-Monitore eingesetzt werden.

Beispiel einer Adeckungsanalyse:

Greybox-Test

• wird vor allem beim Integrationstest eingesetzt
• Die Tester kennen den Source-Code der einzelnen Module nicht. Sie betrachten die einzelnen Programme also im Blackbox-Verfahren.
• Das Zusammenspiel und die Ablauffolge der einzelnen KOmponenten ist aber bekannt. Die Testfallauswahl erfolgt somit im Whitebox-Verfahren.
• Es wird somit geprüft ob alle Komponenten mindestens einmal getestet werden. (Komponentenabdeckung)
• Zeitreihen können eine wichtige Rolle spielen (z.B. mehrere Änderungen an einer Adresse)

Blackbox-Test

• Wird vor allem beim Systemtest angewendet
• Die Tester kümmern sich nicht um die innere Struktur.
• Getestet wird das erwartete Verhalten und die definierten Schnittstellen
• wird deshalb funktionelles Testverfahren genannt
• Ausgangsbasis: Anwendungsfälle (Use Cases), Anforderungen aus dem Pflichtenheft und dem Systementwurf.

Testfälle werden auf Grund von Äquivalenzklassen und Grenzwertanalysen gebildet

• Äquivalenzklassen = gleichartiges Verhalten
• Es werden alle Äquivalenzklassen ermittelt und je ein Vertreter der Klassen gibt einen Testfall der alle anderen möglichen Fälle der anderen Klassen vertritt.

In der Grenzwertanalys werden alle Fälle bei Wertübergängen erfasst und die Tests konzentrieren sich auf diese Übergänge in der Annahme, dass sich die Werte dazwischen gleich verhalten.

Beispiel einer Äquivalenzklassenbildung:

Beispiel einer Grenzwertanalyse:

Zustandsbezogene Tests

• gehört zum Blackbox-Testing
• Es gibt Programmobjekte welche sich bei mehrmaligem Aufruf unterschiedlich verhalten (je nach State)
• Die Aktion hängt von der Historie ab
• Dies wird in einem Zustandsdiagramm dargestellt
• Aufgrund der möglichen Zustände und Übergänge wird ein Übergangsbaum erstellt.

Die folgende Komponenten steuert die Zutrittskontrolle eines Unternehmens. Die maximal Anzahl der Mitarbeiter die Zutritt haben, wird dem Personalbestand entnommen. Je nach Zustand wird der Zutritt gewährt oder abgelehnt.

Beispiel eines Zustandsdiagramm:

Übergangsbaum:

Diversifizierendes Testen

Back-to-Back-Test

• zwei Programmierer erhalten die selben Spezifikation
• beide entwickeln Module
• beide Module werden getestet
• wenn beide Module das selbe Resultat liefern kann man davon ausgehen, dass die getesteten Fälle korrekt sind.

Mutationentest

• In einer Version wird bewusst ein Fehler oder eine Erweiterung eingebaut
• Beide Version werden gleich getestet
• Wenn sich sich identisch verhalten, kann man davon ausgehen, dass ein Fehler existiert.

Risikoorientiertes Vorgehen

• Oft fehlt die Zeit um alles ausgiebig zu testen
• Deshalb müssen die Objekte in Risikokategorien eingeteilt werden.
• Das Risiko entspricht der Eintrittswahrscheinlichkeit multipliziert mit dem finanziellen Schadensausmass

Externe Risiken (nicht beeinflussbar):

• Naturereignisse
• Politische, gesetzliche Veränderungen
• Gesellschaftliche Veränderungen
• Marktwirtschaftliche Veränderungen

Strategische Risiken (schwer beeinflussbar)

• Organisatorische Veränderungen
• Finanzielle Risiken

Projektrisiken (relativ gut beeinflussbar)

• Vertragserfüllung
• Mitarbeiter
• Termine
• Synchronisation bzw. Abhängigkeiten zu anderen Tätigkeiten
• Ressourcen
• Kommunikation

Produktrisiken (relativ gut beeinflussbar):

• Funktionale Fehler
• Akzeptanz durch die Benutzer
• Systemintegration und -konfiguration
• Mengen (Datenmenge, Anzahl Benutzer, Anzahl Transaktionen)
• Image des Unternehmens
• Sicherheit des Systems

Beim risikoorientierten Vorgehen wird jedem Objekt eine Kritikalität zugewiesen. Z.B.

• Sehr hoch: gefährdet Unternehmen oder sogar Leben
• Hoch: kann zu massiven materiellen oder immateriellen Schäden führen.
• Mittel: kann zu kalkulierbaren Schäden führen
• Niedrig: kann zu geringen Schäden führen.

Testarten

• Beim statischen Prüfverfahren werden die einzelne Artefakte (z.B. Anforderungsdokument, Analyse-, Designmodell, SourceCode, tech Doku) genauer unter die Lupe genommen.
• Beim dynamischen Prüfverfahren (Testen im eigentlichen Sinn) werden Systems ausgeführt und Fehlerwirkungen nachgewiesen. Anhand der Resultate suchen die Entwickler danach die Fehler.

Statische Prüfverfahren

• QS-Überwachung
• Prüfung primär durch Menschen
• Es gibt aber auch unterstützende Tools die den Code oder die Dokumente analysiseren.
• Hauptziel: Fehler in einer möglichst frühen Phase erkennen und beheben.

Informelles Review

• wird nicht angeordnet
• Der Autor wird selber aktiv und bitte Arbeitskollegen zu einer ad hoc Sitzung.
• Eine einfachere Variante ist die die Zustellung mit der Bitte zu einer Stellungsnamen (mit Termin)
• Bei einem Peer Rating sind die Projektmitarbeiter örtliche getrennt. Das prüfobjekt wird dann mit einer Checkliste und einem Beurteilungsbogen zugestellt.

Walktrough

• mit einem mehr oder weniger struktierten Vorgehen wird die Qualität des Prüfobjektes verbessert.
• in einer entspannten Atmosphäre
• möglichst viele Fehler oder Regelverstösse finden.
• miteinander eine gute Lösung finden
• mit einer prüfobjektorientierter Checkliste kann die Effizienz markant gesteigert werden.

Technisches Review

• formelle Prüfungsart
• werden von PL angeordnet
• Moderator stellt Objekt mehreren Experten zur Verfügung
• In einer gemeinsamen Sitzung wird beurteilt.
• Der Autor beantwortet nur gestellt Frage oder klärt Missverständnisse, hält sich aber sonst zurück.
• Es wird ein Protokoll geführt. (evtl. durch den Autor)
• Mögliche Beschlüsse: Freigabe, Freigabe mit Vorbehalt, Zurückweisung.

Inspektion

• Schwerpunkt liegt bei der Überprüfung klar definierter Anforderungen (Codekonventionen, Ressourcengebrauch, Schnittstellenkonformität)
• ist ebenfalls formelle Prüfung
• der Ablauf entspricht dem beim technischen Review

Audit

• wird i.d.R. vom Management angeordnet
• ein Gegenstand wird auf die Erfüllung externer Anforderungen untersucht
• geschieht im Rahmen eines Assesements.
• kann sowowohl Dokumentenstudium wie ciah Sitzungen und Interviews umfassen.
• wird durch einen Assementbericht abgeschlossen. Die gibt eine Beurteilung des Ist-Zustandes und eine Empfehlung für den Soll-Zustand ab.

Dynamische Prüfverfahren

• Tests im eigentliche Sinne
• Lauffähige Systeme werden gegenüber den Erwartungen validiert.
• Je nach Phase werden steten andere Testarten zur Verfügung

Testarten, die statische Prüfverfahren unterstützen

• jede Testart lässt sich einer Teststufe zuordnen
• Die Planung des durchzuführenden Testarten wird deshalb Teststufenplan genannt.
• Testaktivitäten unterstützen die statischen Prüfverfahren
• In der Analyse- und Entwurfsphase werden Prototypen entwickelt.
• Der Prototyptest erfolgt in einem Review.
• Wird SW nicht selber entwickelt, wird dies über einen Evaluationsprozess. Während der Auswahl erfolgt ein Proof-of-Concept. Dabei führt der Lieferant eine Testinstallation beim Kunden durch.

Unit-Tests

• Während der Implementation testen Entwickler fortlaufend. Diese Tests sind Bestandteil des SW-Entwicklungsprozesses.
• Der Unit-Test ist jedoch Bestandteil, des Testprozesses
• Hier werden Bestandteile als separate "Units" getestet (Funktionalität, Schnittstellen)
• Mit Negativtests (Eingaben welche fehler verursachen müssen) wird Robustheit getestet.
• Zeitverhalten wird geprüft.
• Überprüfung der Wartbarkeit mittels Review oder Inspektion.
• Unit-Tests können mit der White- oder Blackboxmethode durchgeführt werden.
• Testtreiber und Analysatoren unterstützen den Tester bei der Automatisierung und der Auswertung.

Bezeichnungen für Unit-Test (je nach Prüfobjekt)

• Modultest
• Programmtest
• Klassentest
• Komponententest
• Datenbanktest

Integrationstest

• Das Zusammenspiel der einzelnen Komponenten und die Schnittstellen zu dem Umsystemen wird geprüft.
• Die einzelnen Schichten (n-tier) werden geprüft.
• Danach dir Schnittstellen zu den anderen Schichten.
• Hardwarekompatiblität und Betriebssystemkompatibilität wird geprüft.
• Auch das Netzwerk ergibt eine breite Palette an Testfällen

Mit dem Integrationstest soll nicht gewartet werden bis alle Unit-tests abgeschlossen sind.

Systemtest

• Nach dem Integrationstest folgt der Systemtest.
• Hier wird das ganze System getestet.
• Ziel ist es, die geforderte Systemqualität nachzuweisen

[[Image:Systemtest.gif]

Neben den eigentlichen Testspezialisten können auch andere Fachbereiche vertreten sein (Netzwerkspezialist, Systemspezialist, Andwende etc.)

Funktionstest

• sämtliche Anwendungsfälle (Use Cases) werden getestet.
• Vollständigkeit und Richtigkeit steht im Vordergrund

Benutzerbarkeitstest

• GUI-regeln werden geprüft
• sachlich logische und intuitive Benutzerführung
• einfache Erlernbarkeit
• Dokumentation
• kontextsensitive Hilfe

Installationstest

• verschiedene Betriebssystemvarianten
• Sprachen
• Installation muss automatisch ablaufen
• saubere Deinstallation
• Upgradeinstallationen

Zertifizierungstest / Kompatiblitätstest Die Kompatiblität muss auf drei Ebenen sichergestellt werden

• Hardware und Netzwerk
• Betriebssoftware
• Andere veknüpfte Anwendungssoftware

Folgede Zertifizierungen sind denkbar:

• Hardware-Anbieter
• OS Anbieter
• Amtliche Stellen (z.B. SUVA)

Perfomancetest

• Beim Lasttest wird die Effizienz und Zuverlässigkeit geprüft. Systemlast wird simuliert. Antwortzeiten interessieren.
• Beim Stresstest wird die Systemlast bis zum Zusammenbruch erhöht. System muss wie erwartet reagieren (z.B. Meldungen auslösen und regulierende Massnahmen auslösen). Darf nicht kommentarlos zusammenbrechen.

Benchmark-Test

• genormte Messverfahren
• Kriterien werden miteinander verglichen

Katastrophentest

• Extremsituationen werden simuliert (Stromausfall, Disk-Crash, netzwerkausfall)
• Im Idealfall soll System automatisch wieder im letzten konsistenten Zustand anlaufen.
• Auch organisatorische und bauliche Massnahmen werden mit einbezogen (z.B. Feuerschutz)

Sicherheitstest

• Datensicherheit (keine Daten dürfen verloren gehen)
• Datenschutz
• Penterationtests
• Ethical Hacking (von innen, von aussen, angekündet, nicht angekündet, physischer Zugang, remote Zugang, Tarnen als Mitarbeiter)

Abnahmetest

• Beim Abnahmetest geht es um die Beurteilung aus Sicht es Kunden
• Ein erfolgreicher Abnahmetest entlastet das Entwicklungsteam und bestätigt, dass alle Anforderungen vollumfänglich erfüllt sind.

Varianten Abnahmetest:

• Test der vertraglichen vereinbarten Akzeptanz
• Test der Benutzerakzeptanz
• Test der Akzeptanz durch den Systembetreiber
• Verknüpfung des Abnahmetests mit einem Livetest.

Probleme bereiten iommer wieder nicht explizit erwähnte Anforderungen die sich aus Industriestandards oder Usanzen ergeben. Empfehlung: Solche Anforderungen immer explizit in den Vertrag nehmen.

Live-Test

• findet in der produktiven Umgebung statt
• erhöht die Sicherheit, dass die Anforderungen im produktiven Umfeld erfüllt werden.
• Live-test ist oft Abnahmetest.
• begrenzter Zeitrahmen

Parallebetrieb

• altes und neues System laufen eine bestimmte Zeit lang parallel
• resultate werden laufen verglichen
• aufwändiges System
• kann nur für kritische Projekte eingesetzt werden.

Pilotbetrieb

• ein Teilbereich eines Unternehmens arbeitet eine bestimmte Zeit lang auf dem neuen System. Die anderen auf dem alten
• Wenn Mängel auftreten wird nicht das komplette Unternehmen beeinträchtigt.
• Wenn sich das neues System bewährt, kann dieses für das ganze Unternehmen freigegeben werden.
• Dieses Verfahren kann nur eingesetzt werden wenn keine Integrationsschwierigkeiten mit den bestehenden Systen der anderen OE auftreten

Beta-Test-Phase

• hat sich bei Standardsoftware eingebürgert welche an ein breites Publikum verkauft wird.
• Benutzer melden sich meist freiwillig
• Das Risiko ist beim Tester
• Die Fehler werden beim SW-Hersteller gesammelt und jenachdem wird ein zweiter Beta oder Finalrelease herausgegeben.

Regressionstest

• Bei jeder Änderung des Systems besteht das Risiko von Sideeffects.
• Das Configmanagement regelt den Änderungs- und releaseprozess
• bevor ein neues Release freigegeben wird, mus sein Set von Tests durchgeführt werden.
• Diese Testwiederholung wird Regressionstest genannt.
• Diese sind i.d.R. risikoorientiert.
• hoher Automatisationsgrad
• Ein Subset der wichtigsten Tests wird Smoke-Test genannt und sollte vollautomatisch ablaufen.

Testorganisation

Damit Menschen effizient arbeiten können, müssen sie sich organisieren. Zwei Aspekte spielen eine Rolle:

• Aufbauorganisation
• (Prozessorganisation) Ablauforganisation

Welche Rolle können Projektmitarbeiter im Testprozess übernehmen

• Die Testorganisation ist ein Teil der Projektorganisation
• Die Rollen sind in der Teststrategie zu definieren.
• Innerhalb eines Projektes werden den Rollen Personen zugeordnet.
• Eine Person kann mehrere Rollen haben
• Nicht in allen Projekten wird jede Rolle benötigt. Einen Restdesigner, Testmanager und mindestens ein tester werden aber immer benötigt.

möglich Rollen mit ihren typischen Skills:

Aus welchen Teilschritten besteht der Testprozess

• Der Test ist ein phasenübergreifende, nebenher laufender Prozess
• wird auch Testverfahren oder Testvorgehensweise genannt.
• ANSI/IEEE 829 definiert die einzelnen Phasen und die daraus resultierenden Dokumente

Test planen

• Der Testmanager erstellt parallel zum Design des Systems das Testkonzept (auch Testplan ider Prüfplan genannt). Wichtige Informationen aus den Anforderungen und dem Entwurf des neuen Systems fliessen in die Planung der zu testenden Funktionen.
• Grundlagen für den Testplan bilden der QS-Plan, die Teststrategie, die Anforderungs- und Entwurfsdokumente sowie der Projketplan.
• Für jedes Testobjekt wird der gewünschte minimale Qualitätsstandard definiert.(ohne Details)
• Aufbauorganisation wird anhand der notwendigen Ressourcen definiert und bei der PL beantragt.
• Restumgebung und Testwerkzeuge werden festgelegt und Beschaffung bzw. Bereitstellung beantragt.
• Ressourcen- und Zeitplan werden wenn möglich toolgestützt mit dem TL abgestimmt (z.B. MS Project)

Test entwerfen

• Anhand des Testplans und den Anforderungen erstellt der testdesigner die Testentwurfsspezifikation. Dies läuft paralell zu den Designarbeiten.
• Der Entwickler kann seine eigenen Unit-tests bereits darauf abstützen.
• Für jede zu testende Funktion gemäss Testplan wird das Testverfahren festgelegt
• Der testdesigner bestimmt die Testmethode.
• Daraus leitet er die Testfälle ab (ohne Details)
• Er kreiert auch einzelnen Testszenarien (zusammenhängende, logische Testfälle)
• Ein einzelnes Testdrehbuch handelt ein solches Testszenario ab.
• Auf Grund der Qualitätskriterien werden Pass- und Failkriterein festgelegt.

Test spezifizieren

• Auf Grund der im Testentwurf aufgeführten Testfälle spezifiziert der Testdesigner die Details der einzelnen Fälle.
• Ein Testfall ist eine Kombination von Eingabedaten, Bedingung und erwarteten Ausgaben.
• Die Vorbedingung und Abhängigkeiten sowie die nötige Testumgebung ist aufzuführen.
• Hinweis auf mögliche Automatisierung

Testprozedur erstellen

• Der Testdesigner erstelle pro Testseznario ein Testdrehbuch.
• Darin sind die zu testenden Fälle mit Sinn und Zweck aufgeführt.
• Ebenso sind sind die auszuführenden Schritte und die erwarteten resultate aufgeführt.

5.2.4

• Testengineer oder Testautomatisierer erstellen evtl. benötigte Automatisierungsscripts
• Deren Beschreibung kommen ins Testdrehbuch
• Die Automatisierungsscripts unterliegen dem Change- und Configmamanagement (Zuweisung zum richtigen Build)

Testumgebung aufbauen

• Der Testadministrator organisiert die Infrastruktur
• Entwicklungs- Test- und Produktivumgebung werden strickt getrennt.
• Evtl. sind auf Grund der Komplexität mehrere Testplattformen nötig.
• Testwerkzeuge müssen installiert werden.
• Benutzer- und deren Rechte definieren.
• Schulung der Tester (Testsoftware)
• Für die Unit- und Integrationstest ist das Testgeschirr zu installieren.
• Testgeschirr = Software zur Simulation aufrufender Programme.
• Testobjekte bereitstellen.

Test ausführen

• Tester nehmen ihre eigentliche Arbeit auf
• exploratives "spielen" wie auch schrittweises Durcharbeiten der vorgegebenen Szenarien
• Tester stützt sich primär auf Testdrehbuch
• Tester nimmt ergänzend die Testfallbeschreibung und die Testentwurfsspezifikation zur Hand.
• Neben des Tests ist das Protokollieren die wichtigste Tätigkeit
• Im Protokoll enthalten: Welche Testschritte, welche Resultate, eventuelle Änderungen an der Testumgebung.
• Aufgetretene Probleme sind als Problemmeldung für die Entwickler nachvollziehbar zu dokumentieren.
• Vermutungen können vermerkt werden.
• Fehlersuche ist aber Aufgabe des Entwicklers (nicht Tester)

Test auswerten

• Testmanager fast Resultate im Testprotokoll zusammen
• Gemäss QS-Plan geforderte Dokumente werden erstellt (Testmanager)
• Systeme welche einen Test nicht bestanden haben, werden der Entwicklung zurückgegeben.
• Wenn alle TEsts innerhalb einer Haupttestart (z.B. Unit-TEst, Integrationstest, Systemtest etc) bestanden sind, verfasst der Testmanager einen

Testabschlussbericht und gibt das System für die nächste Haupttestart frei.

Wie läuft der Testzyklus ab

• Testprozess läuft nicht stur nach dargelegten Schritten ab
• Testplanung wird einmalig vorgenommen und danach bei Bedarf überarbeitet
• Die Testspezifikation wird während der Softwareentwurfsphase möglichst für alle Testarten komplett erstellt.
• Testumgebung wird ebenfalls einmalig aufgesetzt und schrittweise den Bedürfnissen angepasst

• Fehlersuche und Fehlerbehebung sind keine eigentlichen Testtätigkeiten. Sie gehören aber eng zum Testen.
• Je nach Art des festgestellten Mangels findet eine Triage statt.
• Wenn Testdaten falsch sind, Probleme mit der Testumgebung existieren oder die Testwerkzeuge fehlerhaft sind wird die Umgebung angepasst und der Test wiederholt.
• Bei Implementierungsfehlern müssen entweder Anforderungen, das Design oder die entwickelte Komponente angepasst werden.
• Je nach Abhängigkeit müssen dadurch andere Testszenarien wiederholt werden (Sideeffects)
• Mögliche sind auch Benutzerfehler(Tester). Benutzer schulen, Doku anpassen.
• Beim Testen auftretende Wünsche müssen als Change Request (CR) behandelt werden. SOnst wird Projektplanung gefährdet.
• CR werden dem Change Management übergeben. DOrt wird entschieden ob und wann die Änderung einfliesst.

Testdokumente

• Erstellung der Testdokumente = wichtige Aufgabe des Testteams.
• Ansonsten tappen PL und Testmanager im Dunkeln
• Grosser Teil der Kommunikation zwischen PL und Testmanager erfolgt über Testplan und die darin definierten Testberichte
• Wenn die Testspezifikationen dem Entwickler abgegeben werden, ergibt dies einen positiven Effekt.
• Alle Dokumente sollten eine Identifikation enthalten und eine einer Projektablage zugänglich sein.

Wie ist Testkonzept aufgebaut

Ersteller = Testmanager. Inhalt:

• Einführung
• Zu testenden Komponenten
• Teststrategie
• Pass- und Failkriterien
• zu erstellende Dokumente
• Testumgebung
• Verantwortlichkeiten
• Testorganisation
• Zeitplan
• Risiken

Wie ist die Testentwurfsspezifikation aufgebaut

Ersteller = Testdesigner. Inhalt:

• Testobjekte
• zu testende Funktionen
• Testverfahren
• Verweise auf Testfälle und Testdrehbücher
• Detaillierte Pass- und Failkriterien

Aus welchen Elementen besteht der Testfall

Der Testfal ist Kombination aus Eingabe, Bedingung und erwarteter Ausgabe.Er besteht aus

• Testobjekt (Rererenzierung zum Testentwurf)
• Eingabedaten (z.b. Input-Tabelle, File-Share, Datenbank, Testtool, Bildschirmeingaben)
• Erwartete Ausgaben (Output-Tabelle, Files, Antwortzeiten, Ausdruck, Systemmeldungen, Rückgabewert)
• Notwendige Testumgebung
• Zu berücksichtigende Punkte

Was beinhaltet das Testdrehbuch

Der Testdesigner notiert im Testdrehbuch wie ein Testszenario Schritt für Schritt getestet werden soll. Bereits bestehende Anweisungen aus der Testfallbeschreibung werden nur referenziert. Inhalt:

• Zielsetzung
• Voraussetzungen
• Einzelschritte des Tests (Vorbereitung, Start, Durchführung, Beobachtung, Abruch, Neustart, Stopp, Abschluss, Aufräumen, Unvorhergesehenes)
• Art und Weise der Loggführung ist festzulegen

Testumgebung

Begriffe:

• Testgeschirr: notwendige Instrumente und Tests durchzuführen
• Testbett:: Bequeme und sachlogische Einbettung in die Systemumgebung
• Testrahmen: organisatorische und teschnische Rahmenbedingungen

Folgendes muss bei der Testumgebung beachtet werden:

• Unterschiedliche Anforderungen
• Einfache Wiederholbarkeit
• Systematische Erfassung der Resultate
• Bequeme Auswertung

Wie wird Testumgebung aufgebaut und betrieben

• frühzeitig planen
• wenn nötig über Evalutaionsprozess Teile beschaffen

Umgebungen immer sauber trennen

Testumgebung beschaffen

• Anforderungen an die Testumgebung sind im Testplan festgehalten
• Frühzeitig eventuelle Beschaffung auslösen
• Ressourcen reservieren
• Die Auswahl der richtigen Automatisierungstools ist sehr wichtig. Deshalb genügend Zeit einplanen. Auch für Schulung.
• Der Tester muss geschult werden. Deshalb muss Testinfrastruktur vor den eigentlichen Tests bereitstehen.
• Der Testadministrator ist für die Koordination und den Auf- und Abbau der Testumgebung verantwortlich. Er ist auch Anpsrechpartner bei Schwierigkeiten.

Elemente der Testumgebung

• Die Elemente werden als Vorgaben im testplang festgehalten.
• Der Testmanager gibt dort die organisatoreischen und infrastrukturiellen Vorgaben an.
• Technische Merkmale in den Vorgaben sind hilfreich.

Testumgebung verwalten

Je nach Einsatzgebiet ergeben sich mehrere Anforderungsdimensionen:

• Software-Releases welche für dei Wartung nicht gewährleistet werden muss.
• Unterschiedliche Betriebssysteme (z.B. alle Windows-Varianten, Unix, Linux etc.)
• Diverse DBMS (MS-SQL, Orcale, DB2)
• Länderspezifische Einstellungen
• verschiedenene Sprachversionen

Deshalb braucht es verschiednene Methoden und Techniken. Z.B.

• Unterschiedliche Systeme welche auf Grund der Namensgebung Aufschluss über die version geben.
• durchdachte Verzeichnissstruktur
• Disks clonen
• Arbeiten mit virtuellen Maschinen

Auf Grund der Komplexität ist die Testumgebung oft Teil des Konfigurationsmanagements.

Wie können Tests automatisiert werden

• Ab einer bestimmten Kompleitätsstufe ind automatisierte Testwerkzeuge ein MUSS.
• z.B. Lasttests
• Bereits ab der dritten Testwiederholung loht sich ein Tooleinsatz
• CAST = Computer Aided Software Testing
• Die Tools sind jedcoh nur hilfrewich wenn sie in geschulten Händen und in geordneten Prozessen angewendet werden.

Tools zur Prozzessunterstützung

Testmanagement-Software

• unverzichtbare Basis für Testmanager
• gute Tools sind mit den Anforderungen verknüpft
• Schwerpunkt ist due Verwaltung sämtlicher Testfälle sowie deren Fehlermeldungen.
• Status der Testfälle sichtbar

Testinformation-Repository

• ist Datawarehouse des ganzen Testprozesses.
• enthält strukturierte Daten (Datenbanken) wie auch unstrukturierte (Dateien)
• Suchfunktionen sind sehr wichtig

Tools für statische Prüfungen

Static Measurment Tools

• analysieren Code ohne diesen auszuführen.
• Prüfen von Programmier-Richtliniee
• verschtelungstiefe
• nicht erreichbaren Code
• Anzahl Zeilen
• Zugriff auf undefinierte Variablen

Complexity Analyzer

• untersuchen den Code auf Anzahl Parameter, Variablen, Bedingungen, Loops etc.
• dadurch kann Komplexität abgeschätz werden.

Tools für Testvorbereitung

• Codebasierte Testdatengeneratoren analysieren code und bilden eine Menge von Inputdaten (aber keine Sollwerte)
• Schnittstellenbasierte Testdatengeneratoren analysieren Interfaces und leiten mitteles Äquivalenzklassen- und grenzwertanalayse die testdaten davon ab.
• Massendaten-Generatoren bilden Testdaten welche vor allem für Perfomance-tests gebraucht werden.

Tools für Testdurchführung- und Auswertung

• Drivers simulieren aufrufende Programme (werden zum Testen von einzelnen Komponenten benötigt)
• Stubs simmulieren aufgerufene Funktionen ((werden zum Testen von einzelnen Komponenten benötigt)
• Capture- bzw. Playback-Tools sind testroboter. Sie zeichnen alles auf was der Tester macht. Der Test kann danach wieder abgespielt werden.
• Performance-Analyzer zeichnet das Systemverhalten während der Testphase auf.
• Coverage-Monitor prüft während der Ausführung den Abdeckungsgrad. In den Reports ist dann zu sehen welcher Codeteik noch nicht getestet wurde.
• Debugger
• Testresult-Comperator. Unabdingbar bei Massentest.

Alle diese Tools lassen sich nur sinnvoll nutzen wenn sie richtig in die Systemumgebung passen und von geschulten Leuten bedient werden.

Berichtsdokumente

Die Testdokumente bilden den gesamten dispositiven (planenden) Teil im Testprozess ab. Die Berichtsdoukmente beinhlaten sämtliche Informationen über die Testausführung und Auswertung

Welche Aufgaben beiinhaltet die Testdurchführung

• Grundlegende Voraussetzungen für die Testaufsührung sind Kenntnisse über die zu testende Anwendung und die testwerkzeuge.
• Die Tester verfügen über das Testdrehbuch (führt Schritt für Schritt durch die Testarbeit)
• Tester dürfen aber trotzdem ihrer Intuition und ihrer Erfahrung folgen (explorative Tests)
• Aber alles muss sauber und vollständig protokolliert werden.
• Aufgrund der Informationen aus dem Testprotokoll kann der Testmanager die Testauswertungen vornehmen und den Status des Testfortschrittes bestimmen.

Produzierte Berichtsdokumente:

Tests durchführen

• Im Testdrehbuch ist ein Testszenario mit mehreren Testfällen beschrieben
• Die Abarbeitung entspricht einem Testlauf
• Ein Testprotokoll ist zu erstellen
• Eventuell ensteht je nach Test auch ein Testlog
• Wenn alle Kriterien erfüllt sind, gilt der Testlauf als "passed".
• Auch wenn nur ein Kriterium nicht erfüllt ist, gilt der Testlauf als "failed".
• Das Testprotokoll wird vom Tester in einer speziellen Software strukturiert erstellt.

Testprotokoll erstellen

• muss sich auf das Testdrehbuch beziehen
• muss folgende Infos enthalten: Datum/Uhrzeit des Tests, Name Tester, eingesetzte Testumgebung und Hinweis auf eventuelle Anomalien.
• eingesetzter Release und Build des Testlings
• enthält detailliertes Ergebnis aller Testfälle (passed, failed). Auch der persönliche EIndruck des Testers darf/kann erwähnt werden.

Problemmeldung für jede aufgetretene Abweichung

• jedes Problem eine Meldung
• Bei einem Problem kann es sich um Programmmierfehler, Nichterfüllung eines Akzeptanzkriteriums oder um etwas ganz andees handeln
• Zuerst ist das Fehlverhalten zu beschreiben (Resultat ist 50 statt 100)
• Danach die Fehlerwirkung (sichtbare Auswirkung)
• Hinweise auf die Reproduzierbarkeit
• Eventueller Workaround
• Eventuelle Vermutung des Testers was den fehler verusachen könnte.
• Für die Planung der Fehlerbehebung ist eine Einschätzung des Testers notwendig.

Folgende Klassifizierungen sind möglich:

Problemstatus

Problembearbeitungszyklus

Fehler lokalisieren

• gehört nicht zum eigentlichen Testprozesss sondern zum Softwareentwicklungsprozess
• zu den bereits genannten Ursachen können zusätzliche auftauchen: Bedienungsfehler, nicht korrekte Testdaten, fehlerhaftes Testscript.

Wie wird die testauswertung erstellt

• um dem PL und dem Auftraggeber über den projektstand informieren zu können, sind die Testauswertungen und ein sauberes Reporting ein absolutes MUSS.
• Aufpassen wegen dem 95%-Syndrom (jeder meint fast fertig zu sein, in Tat und Wahrheit sind es erst 70%)

Testmetriken

Die Testmetriken sind ein Versuch, Masseinheiten zu definieren um den Arbeitsfortschritt möglichst verständlich wiederzugeben.

Testabdeckung

kann auf verschiedene weisen gemessen werden.

• Coverage-Monitor (ermittelt den getesteten Code)
• Anwendungsfallabdeckung: Wie viel Prozent der Use Cases sind schon getestet?
• Komponentenabdeckung: Wie viel Prozent der Komponenten sind schon getestet?

Testeffizienz

• zeigt auf wie viele fehler in einer bestimmten Zeit gefunden wurden.
• Die Testeffizienz zeigt somit das verhältnis zwischen ingesetzten personellen ressourcen und gefunden Fehlern.

Fehlertrend

Die Fehlertrendstatistik sagt etwas über die Art der gefunden Fehler aus. Die Klassifizierung des Schweregrades liefert gegenüber dem testeffizienz-Diagramm eine detailliertere Sichtweise

Fehlerdichte

• ist das Verhältnis zwischen der Anzahl Fehler und der Grösse des Systems (meistens in Anzahl Codezeilen gemessen)

Testfortschritt

• Der Testfortschrittsbericht ist eine Zusammenfassugng und Beurteilung des Testmanagers des aktuellen Standes
• muss alle drei ewähnten Testmetriken beinhalten, und in einen Prozentwert versichten.
• Bedingt viel Erahrung

Beispiel:

Testberichtswesen

• Der testmanager fasst die Erkenntnisse und resultate in einem periodischen testbericht zusammen.
• wird dem PL abgegegen
• neben der allgeminen lager werden auch spezielle Vorkomnisse erwähnt.
• der Testbericht gibt die Ist-Werte, die Soll-Werte und die Abweichungen an-
• Aufgrund der Abweichungen sind Massnahmen vorzuschlagen
• Bei einem speziellen Vorkommnis muss der Testmanager sofort einen Testvorfallsbereicht zu Handes des PL verfassen (z.B. krankitsbedingertr Aufall, verspätete Lieferung.
• Alles was den geplanten Ablabuf und die termine gefährdet muss so schnell wie möglicg gemeldet werden.

Massnahman ableiten

• Der Testmanager ist verantwortlich dafür notwendige bzw. mögliche Massnahmen aufzuzeigen
• Seine Kompetenzen sind meist sehr beschränkt.
• Deshlab muss er Antrag an PL sctellen.
• Aufgrund der Schlüsselfaktoren (Testabdeckungsgrad, fehlertendenz, Fehlerdichte etc.) sind folgende Massnahmen zu beantragen:
  • Testunterbruch
  • Anpassen der Ressourcen
  • Terminverschiebung
  • Testende

Testabschlussbericht

• ist eine zusammenfassende Darstellung des kompletten testprojkets.
• darin werden die Testaktivitäten beschrieben (oder aufgelistet), die Testergebnisse zusammengefasst und und eine Tachkalkulation des Testaufwandes vorgenommen.
• ist der formelle Abschluss der Testarbeiten

Ergänzungen Migros Klubschule

Fehlerbegriffe

• Fehler ist die Nichterfüllung einer festgelegten Anforderung
• Ein Mangel liegt vor, wenn eine gestellte Anforderung oder eine berechtigte Erwartung nicht angemessen erfüllt wird.
• Eine Fehlerwirkung(failure) oder ein Äusserer Fehler bezeichnet das Sichtbarwerden eines Fehlers für den Anwender oder Tester.
• Ein Fehlerzustand(fault)–auch Defekt oder innerer Fehler–ist die Ursache für das Auftreten einer Fehlerwirkung.
• Eine Fehlermaskierung bedeutet, dass zwei oder mehr Fehlerzustände sich gegenseitig nach aussen hin kompensieren, so dass eine Fehlerwirkung nicht auftritt, bis einer der maskierenden Fehler korrigiert ist.
• Eine Fehlhandlung(error) ist die Ursache für einen Fehlerzustand oder Defekt und stellt eine Fehlhandlung einer Person dar, etwa die fehlerhafte Programmierung eines Entwicklers.

Kriterien für die Priorisierung

• Eintrittswahrscheinlichkeit einer Fehlerwirkung
• Fehlerschwere
• Wahrnehmung einer Fehlerwirkung
• Priorität der Anforderungen
• Komplexität der Komponenten

Prinzipien des Softwaretestens

• Grundsatz 1: Testen zeigt die Anwesenheit von Fehlern
• Grundsatz 2: Vollständiges Testen ist nicht möglich
• Grundsatz 3: Mit dem Testen frühzeitig beginnen
• Grundsatz 4: Häufung von Fehlern
• Grundsatz 5: Wiederholungen haben keine Wirksamkeit
• Grundsatz 6: Testen ist abhängig vom Umfeld
• Grundsatz 7: Trugschluss: Keine Fehler bedeutet ein brauchbares System

Die Stufen im allgemeinen V-Modell

• Programmierung: Programmierung jedes spezifizierten Bausteins in einer Programmiersprache.
• Komponententest: Prüfung, ob jede Komponente für sich den Vorgaben seiner Spezifikation entspricht.
• Integrationstest: Prüfung, ob Gruppen von Komponenten, wie sie im technischen Systementwurf vorgesehen sind, zusammenspielen sowiedie Prüfung der Interaktionen zwischen verschiedenen Teilen eines Systems
• Systemtest: Prüfung ob das implementierte System den spezifizierten Anforderungen entspricht.
• Abnahmetest: Prüfung, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist.