Testmanagement_T_Sys..

Testmanagement in Theorie
und Praxis.
T-Systems
Multimedia Solutions
T-Systems Multimedia Solutions – Test and Integration Center.
Grundbegriffe des Testens.
Warum testen?
Application Lifecycle und damit einhergehende QS-Maßnahmen.
Der Testprozess und Aufgaben eines Testmanagers.
Auch so kann‘s gehen – Ein Beispiel aus der Praxis.
Überblick ausgewählter Testarten.
Data Privacy and Security.
1. T-Systems Multimedia Solutions.
1.
2.
3.
4.
5.
6.
7.
8.
Agenda
Und wir wachsen weiter: wir stellen permanent neue Mitarbeiter ein.
Stuttgart
München
Dresden
Umfassende QS entlang des Application Lifecycle | Matthias Schneider, T-Systems Multimedia Solutions GmbH
Freiburg
Bonn
Jena
Mit über 980 Kollegen realisieren wir jährlich 1.400 komplexe IT-Projekte.
Berlin
Wir sind Deutschlands Marktführer bei internetbasierten Lösungen.*
Hamburg
Uns gibt es seit 1995.
* New Media Service Ranking 2010 (BVDW)
Die T-Systems Multimedia Solutions GmbH ist eine
Tochter der T-Systems.
AUS GUTEM HAUSE.
Stuttgart
München
Jena
Dresden
Berlin
Support Services
Communities
Mobility
Project Management
Web TV/IPTV
Event TV
Mediathek
Collaboration
Application Integration
Communications
Consulting
E-EntertainmentContent Management
Shopsysteme
Pay Media Technology
E-Workplace
Consulting
E-Services
Testing Services & Support
Portale
Business
Processes
Code Quality Management
E-Commerce
IT Strategy and Video-On-Demand
Service
Security
Business Strategies
Certification
Online-Marketing
E-Procurement
Umfassende QS entlang des Application Lifecycle | Matthias Schneider, T-Systems Multimedia Solutions GmbH
Freiburg
Bonn
Hamburg
Testautomatisierung
Funktionstest
Code Quality
Management
QualitätssicherungsBeratung
Datenschutz
TestManagement
LEISTUNGSPORTFOLIO.
Security
SOA -Test
Abnahmetest
Lasttest
Usability/
AccessibilityTest
Application
Monitoring
Applikationsanalyse
Das Testlabor arbeitet nach ausgereiften
Methoden und Verfahren.
Die Mitarbeiter verfügen über hervorragende
Kompetenzen.
Die Infrastruktur des Testlabors erfüllt die
hohen technischen Anforderungen.
Das Management und die Prozesse sind auf
einem hohen Niveau.
Umfassende QS entlang des Application Lifecycle | Matthias Schneider, T-Systems Multimedia Solutions GmbH
Durch die Akkreditierung wird dem TIZ der
T-Systems MMS bescheinigt:
Das TIC der T-Systems MMS ist ein akkreditiertes Softwareprüflabor der Bundesrepublik in
der Internet- und Multimediabranche. Die Akkreditierung erfolgte durch die Deutsche
Akkreditierungsstelle Technik (DATech e.V.), die Mitglied im Deutschen Akkreditierungsrat
(DAR) ist.
Test and Integration Center.
Akkreditiertes Software- Prüflabor
Mängel
Abweichung
Ähnliche Begriffe:
Differenz zwischen Soll- und IstVerhalten
Nichterfüllung einer Anforderung
Eine Abweichung zwischen dem
gemessenen Wert / Zustand und
dem entsprechenden spezifizierten
Wert.
Fehler:
WAS IST EIN FEHLER?
2. Grundbegriffe des Testens.
• Fehlerwirkung
• Fehlerzustand
• Fehlerhandlung
Testen ist der Prozess, ein Programm mit
der Absicht auszuführen, Fehler zu finden.
Vergleich eines Zustandes des
Testobjektes mit dem gewünschten bzw.
verlangten Zustand.
Gesamter Prozess, ein Programm auf
systematische Weise auszuführen, um die
korrekte Umsetzung der Anforderungen
nachzuweisen und Fehlerwirkungen
aufzudecken.
TEST: WAS IST DAS EIGENTLICH?
Testen ist nicht Debugging / Testen
identifiziert nicht die Fehlerursache
Man kann ein schlechtes Produkt nicht
"gut"-testen.
Man kann nicht alles testen.
Testen kann nicht garantieren, dass die
Software fehlerfrei ist
Was Test NICHT ist
TEST: WAS IST DAS EIGENTLICH?
Tester sind die Praktiker. Sie wollen nachweisen, dass das Programm unter
bestimmten Bedingungen versagt.
Tester bringen schlechte Nachrichten Konfliktpotential
Entwickler sind die Theoretiker im Projektteam. Sie entwickeln die Ideen und
glauben gern, dass die ganze Welt so funktioniert, wie sie sich das vorstellen.
Wenn Entwickler selbst testen, suchen sie nach einer Bestätigung der
Gültigkeit ihrer theoretischen Überlegungen.
Test soll von den Personen durchgeführt werden, die nicht an der
Programmierung der Software-Module beteiligt waren!
Unabhängiges Testen (Objektivität behalten)
Ein bisschen Psychologie
WARUM GIBT ES ENTWICKLER UND TESTER?
Fehler sind SEHR teuer
SW-Kritikalität (ohne Programme funktioniert kaum was noch)
SW-Komplexität
Warum?
Erfüllung von Normen / Vorschriften / Auflagen
Senkung der Fehlerrisiken
Steigerung der Softwarequalität
Finden von Fehlern
ZIEL DES TESTENS
Warum testen?
3. Warum testen?
Quelle: Forrester Research, 2003
allein in Deutschland Ausfälle von jährlich 85 Milliarden Euro durch mangelnde
oder unzureichende Testing - Maßnahmen.
Quelle: Studie der LOT Consulting Karlsruhe, IT-Services 3/2001
Produktivitätsverluste durch Computerausfälle aufgrund fehlerhafter Software:
ca. 2,6% des Umsatzes - 70 Mrd. € p.a.
35,9% der IT-Budgets für Beseitigung von Programmfehlern entsprechen 14,4
Mrd. € p.a.
Geschätzte Verluste durch Softwarefehler in Mittelstands- und Großunternehmen
in Deutschland:ca. 84,4 Mrd. € p.a.
Was kosten Fehler?
Quelle: Standish Group, CHAOS Report 2009: „Chaos History“ von IT-Projekten.
Warum testen?
für Überarbeitung
Geschäftsprozess, Review,
Diskussion
für zusätzliche
Entwicklungskosten
4.000 €
12.000 €
48.000 €
90.000 €
Feinkonzept / DVKonzept
Realisierung
Abnahme / Einführung
Betrieb
Umsatzverlust, Imageschaden
für zusätzliche
Abnahmekosten,
wiederholtes Roll out
für Überarbeitung
Geschäftsprozess, Review,
Diskussion
1.000 €
Softwarefehler, die
erst in der PostProduction-Phase
entdeckt werden,
verursachen 50
Prozent höhere
Kosten als wenn sie
bereits in der
Entwicklung behoben
worden wären.
Giga Information
Group:
Istanalyse / Grobkonzept
Was kostet die Fehlerbeseitigung?
Was kostet die Fehlerbeseitigung?
Application
Lifecycle
4. Application Lifecycle und damit
einhergehende QS-Maßnahmen.
Design
Anforderungen
Anforderungen
Einführung
Realisierung
Design
Anforderungen
Realisierung
Design
Anforderungen
Betrieb
Einführung
Realisierung
Anforderungen
Optimierung
Design
Realisierung
Design
Einführung
Betrieb
Anforderungen
Design:
Fehler frühzeitig finden und beseitigen
Anforderung:
Weichenstellung für Qualität
Funktionalität
Oberfläche
Entwicklertest
Vollständige Geschäftsprozesse
Betriebliche Tests
Reaktion auf System-Probleme
Komponententest
Integrationstest
Systemtest
Schnittstellen
Performance
Ausfallsicherheit
Abnahmetest
Betrieb
Einführung:
Prüfen auf Herz und Nieren
Realisierung:
Frühzeitiges, isoliertes Testen
Test gegen Anforderungen
Betrieb:
Qualität nachhaltig managen
Einführung:
Prüfen auf Herz und Nieren
5. Der Testprozess und Aufgaben eines
Testmanagers.
Optimierung:
Verbesserungen ableiten
Klassifizierung
Testobjekte auf Basis
A/B/C-Analyse
Erarbeitung Testfälle ->
Testspezifikation
Erstellung der
Testscripte
Erstellung der
Testdaten
Bereitstellung der
Testumgebung
Installation
Konfiguration der
Testtools
Testvorbereitung
Annahmetest
Testdurchführung nach
Testspezifikation
Protokollieren der
Testergebnisse
Erstellung der
Fehlermeldungen
Re-Test
Erstellung der
periodischen Berichte
Testdurchführung
Erstellung / Koordination und Review der Teststrategie und –planung inkl. Anpassung
entsprechend der Testergebnisse / des Testverlaufs
Testplanung, Auswahl der Testmethoden inkl. Zeit- / Aufwands- sowie Kostenschätzung,
Ressourcenbeschaffung, Planung des Abweichungs- und Fehlermanagements
Initiieren der Spezifikation / Vorbereitung / Implementierung und Ausführung der Tests
Definition von Metriken für Nachweis der Effizienz des Testprozesses und für
Qualitätsaussagen zur getesteten Anwendung / Produkt
Terminierung, Überwachung und Steuerung der Testausführung
Ergreifen von Maßnahmen bei auftretenden Problemen
Erstellen von Testberichten
Bewertung der
Testergebnisse
Überprüfen der
Abnahmekriterien
Dokumentation /
Bericht
Zertifizierung
Freigabe
Testauswertung
AUFGABEN DES TESTMANAGERS.
Teststrategie und Testziele
Testumfang
Teststufen
Testvoraussetzungen
Testumgebung
Bedarfsanalyse zur
Testautomatisierung
Toolauswahl
QS–Maßnahmen
Ressourcen
Fehlerklassen und
Fehlerworkflow
Risikomanagement
Testdaten
Testkonzeption
Testvorgehen in der T-Systems MMS.
SW-Hersteller:
deutscher Mittelständler
Projektzusammensetzung
GU: T-Systems
Kunde:
Deutsche Krankenkasse
Ziel des SWE-Projektes: Bereitstellung einer Online-Plattform für die elektronische
Genehmigung und Abrechnung von ärztlichen Verordnungen im Krankenkassenumfeld
Ausgangssituation.
6. Auch so kann‘s gehen – Ein Beispiel
aus der Praxis.
SW-Unternehmen hat keine Erfahrung bzgl. Umgang mit Großkunden und komplexen Projekten
Geplanter Livegang
2009
September: SW noch nicht im Pilotbetrieb
EtablierungTaskforce
2010
Alleiniger Test durch SW-Unternehmen auf Basis formloser Entwicklertests, wobei
Testautomatisierung vernachlässigt wurde
Ausgangssituation.
Keine Aussage möglich, wann Software in den Pilotbetrieb gehen kann
früherer Versuch der Etablierung eines Testmanagements schlug fehl
Kunde war unzufrieden aufgrund unklarer Situation hinsichtlich Anforderungsumsetzung und
Fehler-Status
Keine Erkenntnis bis 2009, dass Testmanagement essentiell wichtig für den Projekterfolg ist
Ausgangssituation.
Reporting zur Testdurchführung
und Fehlersituation
Sicherstellung der Testergebnis-Dokumentation
Planung, Steuerung & Monitoring
initiale Testdurchführung
Testmanager zusammen mit Test-Koordinatoren
09.07.2009
Analyse der IstIst-Situation und
identifizierte Verbesserungspotentiale.
Entwicklung SW-Hersteller
Titel der Präsentation | T-Systems Multimedia Solutions GmbH
Koordination FehlerBewertung
Kunde & ManagementTeam
Klärung bei Defects. die ein
weiteres Testen unmöglich
machen / stark erschweren
Organisation TP Test.
Planung, Steuerung & Monitoring
Nachtests
Testteams (sowohl Kunde als auch SW-Hersteller)
46
Sicherstellung der kontinuierlichen Kommunikation
zwischen Entwicklung und Test
Verbesserungspotential
Mapping der Anforderungen zu den bereits
abgestimmten Testfällen
Bestimmung der Testfälle, die 80% der
Funktionalitäten der Applikation ausmachen
(= riskante Systemteile) → Testfall-Priorisierung
Aufsetzen eines internen Fehlerkorridors mit
Abstimmung, ob auch für Kunde im Rahmen der
Übernahme anwendbar
Finding
Keine Traceability zwischen Testfällen und
Anforderungen
Nur partielle Risikoanalyse zur
Bestimmung der SW-System-kritischen
Teile vorhanden
Fehler werden durch Kunde grundsätzlich
nur den Fehlerklassen 1 und 2 zugeordnet
Ableitung von Verbesserungspotentialen-TOP 6.
Einholen des Commitments beim Kunde: definierte
TF-Beschreibungen = fixierten Anforderungen inkl.
Abnahmekriterien
Um kritische Testfälle mit entsprechender Intensität zu
testen, sind in einem Teststufenplan die
Testfallreihenfolge, Testaufwand und -ressourcen
zuzuordnen
Keine mit dem Kunden gemeinsam
definierten Abnahmekriterien
Zuordnung der Tester zu den Testfällen
erfolgt momentan nach Verfügbarkeit
⇒ Grundlage für die Erstellung eines belastbaren Teststufenplans
Hochrechnung der benötigten Zeiten für weitere Testfall-Erstellung
Anfang Oktober 2009:
Auslieferung der ersten 20 Testfall-Beschreibungen durch den Kunden
1. Erkenntnis: zum ersten Mal wurde auf Seiten des Kunden als auch SW-Herstellers die
Wichtigkeit erkannt, formalisierte Testfälle zu erstellen
Kunde erstellt die Testfälle, die gleichzeitig die Abnahmekriterien darstellen inkl. deren Einstufung
nach Priorisierungskategorien
Mapping der Testfälle zu den grobgranular spezifizierten Anforderungen schwierig, deshalb:
Testkonzeption auf Basis der abgeleiteten
Verbesserungspotentiale.
Testaktivitäten durch neue Anforderungen / Abstimmung Frozen Zone mit Kunde, in der keine
CRs seitens Kunde stark erschwert
Umsetzung neuer Anforderungen / CRs erfolgt
Verbesserungspotential
Finding
Ableitung von Verbesserungspotentialen-TOP 6.
Penetrationstest
Kunden-Test, 2. Teil
Kunden-Test, 1. Teil
Interner Test auf Basis Kunden-TFs, 2. Teil
Interner Test auf Basis Kunden-TFs, 1. Teil
Interner Test auf Basis eigener TFs
Funktions- und Prozesstest
Layout Test
Last- und Performancetest sKV
Funktionstest sKV
Last- und Performancetest
November
Dezember
Januar
ab 27.11.2009
09.11. – 30.11.2009
ab 06.11.2009
09.11. – 27.11.2009
19.10. – 06.11.2009
05.10. – 16.10.2009
20.10. – 06.11.2009
tbd.
20.10. – 06.11.2009
06.11. – 23.11.2009
20.10. – 13.11.2009
KW41 KW42 KW43 KW44 KW45 KW46 KW47 KW48 KW49 KW50 KW51 KW52 KW53 KW01 KW02 KW03 KW04
Oktober
3. Erkenntnis vor Allem für den Kunde: es gibt keine 0 Fehler-Qualität, deshalb Einigung auf einen
Fehlerkorridor
Bei zeitlichen Engpässen: alle Testfälle mit Priorität 1 und 2 werden mindestens einmal
ausgeführt.
Funktionaler Performanctest
Jeder definierte und mit dem Kunden abgestimmte Testfall wird mindestens einmal
ausgeführt.
Zielkorridor:
2. Erkenntnis für Kunde und SW-Hersteller: Test aller fachlich denkbaren Ausprägungen aufgrund
Kosten-Nutzenverhältnis nicht machbar, weswegen die Testfall-Priorisierung von Nöten ist sowie
die Definition eines Zielkorridors
Testkonzeption auf Basis der abgeleiteten
Verbesserungspotentiale.
Positives Ergebnis für alle Testphasen
Die zum Testzeitpunkt zur Verfügung stehenden Testfälle wurden fehlerfrei durchlaufen
Alle identifizierten Fehler wurden behoben und erfolgreich nachgetestet: lediglich 1 nicht Pilotverhindernder Fehler (FK 4-5) war nicht behoben, erfolgte im gemeinsamen Regressionstest.
Einhaltung des intern definierten Fehlerkorridors (0/0/9/15/-)
Konflikt: zurück gestellte Testfälle aufgrund fehlender bzw. fehlerhafter Testfallbeschreibungen.
09.07.2009
SW-Hersteller interner Test:
Ergebnisse und Konflikte.
Titel der Präsentation | T-Systems Multimedia Solutions GmbH
Testkoordination und -monitoring.
monitoring.
53
Dezember
Funktions- und Prozesstest
Kunden-Test, 2. Teil
Kunden-Test, 1. Teil
Interner Test auf Basis Kunden-TFs, 2. Teil
Interner Test auf Basis Kunden-TFs, 1. Teil
Interner Test auf Basis eigener TFs
Januar
ab 06.11.2009
09.11. – 27.11.2009
19.10. – 06.11.2009
05.10. – 16.10.2009
ab 27.11.2009
KW41 KW42 KW43 KW44 KW45 KW46 KW47 KW48 KW49 KW50 KW51 KW52 KW53 KW01 KW02 KW03 KW04
November
Entscheidung zu einem abgestimmten Prozess hinsichtlich TF-Anpassungen
⇒
Oktober
Entscheidung zum gemeinsamen Test mit einem gemischten Team aus Testern von der
Kunden- als SW-Hersteller-Seite
⇒
Hohes Fehleraufkommen beim anschließenden Kunden-Test:
bisherige Testergebnisse wurden angezweifelt
aber auch kundenseitige Fehler beim Testvorgehen
während des Tests wird erkannt, dass TF-Korrekturen erforderlich sind
Zur Erinnerung: ursprüngliche Testplanung
Ergebnisse und Konflikte.
Dezember
Januar
ab 30.11.2009
ab 27.11.2009
ab 15.02.2010
ab 18.01.2010
ab 06.01.2010
08.12.2009
ab 06.11.2009
09.11. – 27.11.2009
19.10. – 02.11.2009
05.10. – 15.10.2009
Redaktionsschluss TrialTrial-System: 11.03.2010, Schwenk zum Produktivsystem
Übernahmetest
Gemeinsamer Regressionstest
Praxistest Kunde
Freihandtest SW-Hersteller
Gemeinsamer Test vor Ort beim
Kunden
Kunden-Test, 2. Teil
Kunden-Test, 1. Teil
Interner Test auf Basis Kunden-TFs, 2. Teil
Interner Test auf Basis Kunden-TFs, 1. Teil
Interner Test auf Basis eigener TFs
Funktions- und Prozesstest
November
KW41 KW42 KW43 KW44 KW45 KW46 KW47 KW48 KW49 KW50 KW51 KW52 KW53 KW01 KW02 KW03 KW04
Oktober
8
287
11
0
50
100
150
200
250
300
93%
214
Testdurchführung insgesamt
3% 1%3%
0
50
100
150
200
250
300
308 300
Blockiert durch anderen
Fehler
Pilotverhindernde
fehlerbehaftete Testfälle
Nicht Pilot-verhindernde
fehlerbehaftete Testfälle
fehlerfrei
offen (inkl. zurück
gestellte Testfälle)
durchgeführt
gesamt
0
20
40
60
80
100
120
140
160
9
19
36
82
49
2
24
11
13
287
Aufteilung Testfall-Status nach Fehlerfreiheit
Blockiert durch anderen
Fehler
Pilotverhindernde
fehlerbehaftete Testfälle
Nicht Pilot-verhindernde
fehlerbehaftete Testfälle
fehlerfrei
offen (inkl. zurück gestellte
Testfälle)
2
Testdurchführung - Abarbeitung Testfälle
53
102
99
136
155
Anzahl TestfallDurchführung
kumuliert (Ist)
Anzahl
Testdurchführung
kumuliert (Plan)
offen zum
Nachtest
bereit zum
Nachtest
erfolgreich
(nach-) getestet
149
0
10
20
30
40
50
60
70
80
90
0
10
20
30
40
50
60
70
Pilotverhindernd
1
Pilotverhindernd
7 6 5
37
33
Nicht-Pilotverhindernd
1 2
28
1
Summe
65
Summe
8 8 7
8
88
Titel der Präsentation | T-Systems Multimedia Solutions GmbH
55
28
Nicht-Pilotverhindernd
7
20
Fehlerstatus Meldungen gesamt
1
36 37
56
65
Fehlerstatus akzeptierte Fehler nach Fehlerschwere
09.07.2009
62
Fehlermanagement.
Gesamt
akzeptierte Fehler
doppelt
einvernehmlich
abgewiesen
zurück gezogen
durch Kunde
Gesamt
closed
bereit zum
Nachtest
gefixt
offen
Erfolgreich Nicht erfolgreich
nachgetestet nachgetestet
und unkoordiniert abgearbeitet
Fehler wurden unbewertet auf Zuruf in internes Ticket-System des SW-Herstellers eingestellt
Vorab-Bewertung durch Entwicklungsteam des SW-Herstellers
Tägliches Fehler-Reporting an den Kunden
new
new
closed
re-test
re-opened
KUNDE
QS
re-test
closed
Zurück
gezogen
KUNDE
TESTER
new
Fehler Clearing
akzeptiert
SW-Hersteller
QS
Nicht
akzeptiert
assigned
Entwicklung
gefixt
closed
re-opened
Erfolgreich
nachgetestet
SW-Hersteller
Test
closed
SW-Hersteller
QS
Bewertung Fehler-Klassifizierung und Behebungstermin mittels eines „Fehler Clearings“
Fehlermanagementsystem (TRAC) als „Fehler“ erfasst und dokumentiert sowohl durch den
Kunden als auch SW-Hersteller
Alle festgestellten Fehler, Abweichungen, Probleme, usw. werden unmittelbar im
Nun:
Bislang:
Fehlermanagement – Allgemeiner Workflow.
Fehlermanagement – Allgemeiner Workflow.
Nicht erfolgreich
nachgetestet
Freigabe nächste Teststufe
(Kundentest)
Status: geschlossen oder
wiedereröffnet
Status : behoben
Nachtest durch Testteam
Entscheidung, wann Patch
auf Testsystem Kunde
GPL, Testmgmt, Entwickl.mgmt
Umsetzung erfolgt in Version x
Entscheidung
Analyse sonstige Risiko
Analyse Impact bereits erreichte Testergebnisse
Fehlerbeseitigung, Test
Ergebnis = CR
Entwicklung
Termin der Behebung
zu beheben in Version x
Entwickler
Priorität
Fehlerklasse
Zuordnung
Ergebnis = Fehler
gibt es einen Workaround
Analyse Aufwand (Entwicklung und Test)
wie oft kommt der Fall vor
Fehlermanager, Test und Entwicklung
des Impacts (was passiert ,wenn wir es nicht tun)
Analyse Risiko & Impact
Changeboard (GPL, PL Kunde)
Täglich Fehlerclearing
Workflow
„Neue Fehler“
Fehlerprozess – Klassifizierung und Priorisierung.
Release-Versionsplan
Change Requestliste
Auszug aus
Ticketsystem
Dokumente
Die tägliche Kommunikation im Projektteam als auch mit dem Kunden hat die nötige Transparenz
bzgl. notwendiger Maßnahmen sowie zum Status geschaffen. Das schaffte vor Allem Vertrauen auf
Kundenseite.
Aktives Fehler Clearing zusammen mit dem Kunden führte zur zügigen Umsetzung / Behebung
der aus seiner Sicht wichtigsten Pain Points.
Der gemeinsame Test unter Beteiligung des SW-Herstellers und des Kunden, konnte frühzeitig
Anwendungsfehler aufdecken, um „falsche“ Fehler zu verhindern.
Die Anwendung befindet sich heute seit fast einem halben Jahr im Wirkbetrieb.
67
Die saubere Aufnahme und Abstimmung von Anforderungen zusammen mit dem Kunden ist das
A und O für erfolgreiche Projekte.
09.07.2009
Fazit.
Titel der Präsentation | T-Systems Multimedia Solutions GmbH
Fazit.
Code Quality
Management
Testautomatisierung
Funktionstest
Testart = Eine Gruppe von
Testaktivitäten, mit der Absicht, eine
Komponente oder ein System auf einige
zusammenhängende
Qualitätsmerkmale zu prüfen. Eine
Testart ist auf ein bestimmtes Testziel
fokussiert.
Testarten im Überblick.
SOA-Test
Security
Lasttest
Usability/
AccessibilityTest
Applikationsanalyse
7. Überblick ausgewählter Testarten.
Funktionstest.
Systematik entspricht den DIN-ISONormen 9126 und 12119.
Qualitätsmerkmale.
Qualitätsmerkmale von Softwaresystemen:
Funktionsumfang – kann die Software alle
Aufgaben erfüllen?
Zuverlässigkeit – wie reagiert das System
auf die Fehleingaben?
Benutzbarkeit – ist das System
verständlich und leicht bedienbar?
Effizienz –wie sind die Antwortzeiten ?
Änderbarkeit – kann die Software
erweitert werden?
Übertragbarkeit – läuft die Software unter
verschiedenen Betriebssystemen oder
Browsern?
Reife
Fehlertoleranz
Wiederherstellbarkeit
Angemessenheit
Richtigkeit
Interoperabilität
Vorgehen
Verbrauchsverhalten
Erlernbarkeit
Konformität
Austauschbarkeit
Prüfbarkeit
Installierbarkeit
Anpassbarkeit
Übertragbarkeit
Stabilität
Modifizierbarkeit
Analysierbarkeit
Änderbarkeit
Systematik entspricht der DIN-ISO-Norm 9126
Zeitverhalten
Verständlichkeit
Bedienbarkeit
Effizienz
Benutzbarkeit
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 74
Tut die Anwendung genau das, was in den funktionalen
Anforderungen beschrieben wurde?
Wo gibt es Abweichungen und welchen Auswirkungsgrad besitzen
diese?
Was muss zuerst/am intensivsten getestet werden, wo sind
einfachere Test ausreichend?
Wie wird die Wirtschaftlichkeit des Tests sichergestellt?
Wie gut ist die Qualität der Entwicklung?
Motivation
FUNKTIONSTEST.
Sicherheit
Ordnungsmäßigkeit
Zuverlässigkeit
Funktionalität
Nicht-funktionale Q-Merkmale
QUALITÄTSMERKMALE EINES SOFTWARESYSTEMS.
Lasttest.
SOA
Automatisiert
Testspezifikation
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 75
Intuitiv
Schätzung durch
Manuell
Zustandsbasiert
Schätzung durch AG
Entwicklung
Grenzwertanalyse
Häufigkeit
Testmethode
Äquivalenzklassen
Priorisieren
Komplexität
Vorgehen
Testelemente
abgrenzen
Motivation
FUNKTIONSTEST.
Vorgehen
Nutzen
Controller
Ergebnis
-analyse
LASTTEST.
LastAgenten
Überwachung der
Agenten
Virtuelle Benutzer
Beantwortung folgender Fragen:
Wie viele User verkraftet die Anwendung?
Wo liegen Performance-Engpässe unter Last?
Wie lange müssen die Kunden bei steigender
User-Anzahl warten?
Wie sind meine Server ausgelastet?
Wann muss die Hardware erweitert werden?
Testsystem
Serverüberwachung
in Realzeit
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 78
Überprüfung
der Antworten
TrueLog
Erzeugung
der
Anfragen
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 77
Warum Lasttest?
Steigende Nutzer- und Zugriffszahlen können längere Antwortzeiten, Fehler
und Abstürze provozieren
Wirtschaftliche Schäden durch Ausfall und Störungen entstehen
Imageverlust durch schlechte Performance
8 Sekunden Regel - Kunde macht sein Geschäft woanders!
Motivation
LASTTEST.
Vorgehen
Nutzen
Wie gut kommen die Nutzer mit der Anwendung
zu recht?
Spricht die Anwendung die Sprache der Nutzer?
Wo sind kritische Punkte bei der Nutzung?
Motivation
USABILITY/ACCESSIBILITY-TEST.
Usability/Accessibility-Test.
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 80
Vorgehen
Usability-Experten versetzen sich in Rolle repräsentativer Nutzer
Überprüfen auf Basis anerkannter Heuristiken
Ausführliche Erläuterung aller identifizierten Usability-Schwachstellen
Konkrete und praxisnahe Verbesserungsvorschläge zu allen gefundenen Schwachstellen
30- bis 40-seitiger Testbericht
Ausführliche Erläuterung aller identifizierten Usability-Schwachstellen
Konkrete und praxisnahe Verbesserungsvorschläge zu allen gefundenen Usability-Schwachstellen
30- bis 40-seitiger Testbericht inkl. ausgesuchter Kommentare der Probanden
Highlight-Video mit ausgewählten Szenen der Probanden
Motivation
Vorgehen
Nutzen
USABILITY/ACCESSIBILITY-TEST.
Eye-Tracking Analyse einer Schlüsselseite durch einen repräsentativen Probanden
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 82
| T-Systems Multimedia Solutions GmbH | 10.09.2010 | 81
Nutzertest durch 6-8 Probanden, welche typische Aufgaben am zu testenden System durchführen
Usability-Test mit Probanden
Umfassende Evaluation der Nutzungsoberfläche durch mindestens 2 Experten
Nutzen
Usability-Experten-Evaluation
Motivation
USABILITY.
QualitätssicherungsBeratung
Code Quality
Management
Testautomatisierung
Funktionstest
Datenschutz
TestManagement
Und noch viel mehr…
Security
SOA -Test
Abnahmetest
Lasttest
Usability/
AccessibilityTest
Application
Monitoring
Applikationsanalyse
Projektberatung
Regressionstest/
Projektberatung
Test
Penetrationstest/
Zertifizierung
Projektberatung
DV-Konzept
Umfeld.
8. Data Privacy and Security.
Deployment
Sicherheits-/Datenschutzkonzept
Sicherheitsanforderungen
Betrieb
Fachkonzept
Anforderungs
-management
Portfolio
Data Privacy and Security
Code
Review
Implementierung
Anzahl der möglichen „Angreifer“ steigt
Notwendiges Wissen zum Ausnutzen von
Schwachstellen sinkt
Verstärkter Einsatz von Werkzeugen
Schnelle Verbreitung
Weitergabe von Informationen
Social Engineering
Weitere erfolgreiche Angriffsformen:
Informationspreisgabe
{SQL, Command, HTML, PHP, …} – Injection
Cross Site Scripting
Häufige Angriffsformen, die „nur“ einen Browser benötigen:
Neue Angriffsformen mit alten Hilfsmitteln
Formen von Bedrohungen
Data Privacy and Security
Anzahl der Angreifer
Wissen der Angreifer
Data Privacy and Security
Wissen der Angreifer
Arten von Schwachstellen.
Data Privacy and Security.
OWASP Top 10
Data Privacy and Security
Auflisten Verzeichnis
Informationsleck
Pfadmanipulation
Vorhersagbare Quellen
SQL - Injection
Unzureichende AntiAutomation
Unzureichende
Prozessprüfung
Cross Site Request Forgery
Injection Angriffe (Einschleusung)
SQL Injection
Quelle: nach WASC04, WASC 2010
Logische Angriffe
Berechtigungen vorhersagen
Unzureichende Autorisierung
Unzureichende Sitzungsbeendigung
Sitzungs Fixierung
Autorisierung
Befehlsausführung
Brute Force
Unzureichende Authentisierung
Schwache Passwort Wiederherstellung
Cross Site Authentication
Durchführung Penetrationstest.
Data Privacy and Security.
Informationsoffenlegung
Cross Site Scripting
Cross Site Tracing
Inhaltsmanipulation
Nutzerseitige Angriffe
Authentifizierung
Data Privacy and Security
Projektberatung
Regressionstest/
Projektberatung
Vorgehen
Code
Review
Praktische Beispiele
Test
Penetrationstest/
Zertifizierung
Projektberatung
DV-Konzept
– Überprüfung der Wirksamkeit der Maßnahmen aus dem Sicherheitskonzept.
Penetrationstest.
– Sicherheitskonzept wird erstellt (gilt als Testgrundlage).
– Datenschutzkonzept wird erstellt.
Fachkonzepte.
– Anforderungen an Betrieb, Entwicklung und Fachseite wurden definiert.
Anforderungsmanagement, Projektberatung.
Penetrationstest
Data Privacy and Security
Deployment
Sicherheits-/Datenschutzkonzept
Sicherheitsanforderungen
Betrieb
Fachkonzept
Anforderungs
-management
Penetrationstest
Data Privacy and Security
Implementierung
Vorgehen
Penetrationstest
Vorgehen
Data Privacy and Security
Vorbereitung
Informationsbeschaffung
Bewertung
Aktive Eindringversuche
Auswertung
Penetrationstest
Data Privacy and Security
Praktische Beispiele
Praktische Beispiele
0351 28 20 2873
[email protected]
Telefon:
E-Mail:
0351 28 20 2206
[email protected]
Thomas Haase
Telefon:
E-Mail:
Ute Seidel
Kontakt
Danke für Ihre Aufmerksamkeit!