T-Systems Multlitm i ed e ia i a S ol o u l tito i n o s

Transkript

1 T-Systems Multimedia Solutions

2 Testmanagement in Theorie und Praxis.

3 Agenda 1. T-Systems Multimedia Solutions Test and Integration Center. 2. Grundbegriffe des Testens. 3. Warum testen? 4. Application Lifecycle und damit einhergehende QS-Maßnahmen. 5. Der Testprozess und Aufgaben eines Testmanagers. 6. Auch so kann s gehen Ein Beispiel aus der Praxis. 7. Überblick ausgewählter Testarten. 8. Data Privacy and Security.

4 1. T-Systems Multimedia Solutions.

5 AUS GUTEM HAUSE. Die T-Systems Multimedia Solutions GmbH ist eine Tochter der T-Systems. Uns gibt es seit Wir sind Deutschlands Marktführer bei internetbasierten Lösungen.* Mit über 980 Kollegen realisieren wir jährlich komplexe IT-Projekte. Und wir wachsen weiter: wir stellen permanent neue Mitarbeiter ein. * New Media Service Ranking 2010 (BVDW)

6 Hamburg Berlin Bonn Jena Dresden Stuttgart Freiburg München Umfassende QS entlang des Application Lifecycle Matthias Schneider, T-Systems Multimedia Solutions GmbH

7 Hamburg Berlin Bonn Jena Dresden Stuttgart Freiburg München Umfassende QS entlang des Application Lifecycle Matthias Schneider, T-Systems Multimedia Solutions GmbH

8 Online-Marketing Certification Support Services E-Procurement Testing Services & Support E-Commerce E-Services Portale Business Processes Code Quality Management IT Strategy and Video-On-Demand Service Security Business Strategies Mobility Communities Project Content Management Management E-Entertainment Consulting Shopsysteme Pay Media Technology E-Workplace Consulting Application Integration Event TV Communications Web TV/IPTV Collaboration Mediathek

9 Test and Integration Center. Akkreditiertes Software- Prüflabor 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. Durch die Akkreditierung wird dem TIZ der T-Systems MMS bescheinigt: 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

10 LEISTUNGSPORTFOLIO. Datenschutz Test- Management SOA -Test Usability/ Accessibility- Test Applikationsanalyse Qualitäts- sicherungs- Beratung Funktionstest Lasttest Code Quality Management Security Application Monitoring Testautomatisierung Abnahmetest

11 2. Grundbegriffe des Testens.

12 WAS IST EIN FEHLER? Fehler: Eine Abweichung zwischen dem gemessenen Wert / Zustand und dem entsprechenden spezifizierten Wert. Nichterfüllung einer Anforderung Differenz zwischen Soll- und Ist- Verhalten Ähnliche Begriffe: Abweichung Mängel Fehlerhandlung Fehlerzustand Fehlerwirkung

13 TEST: WAS IST DAS EIGENTLICH? Was Test NICHTist Testen kann nicht garantieren, dass die Software fehlerfrei ist Man kann nicht alles testen. Man kann ein schlechtes Produkt nicht "gut"-testen. Testen ist nicht Debugging / Testen identifiziert nicht die Fehlerursache

14 TEST: WAS IST DAS EIGENTLICH? Gesamter Prozess, ein Programm auf systematische Weise auszuführen, um die korrekte Umsetzung der Anforderungen nachzuweisen und Fehlerwirkungen aufzudecken. Vergleich eines Zustandes des Testobjektes mit dem gewünschten bzw. verlangten Zustand. Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden.

15 ZIEL DES TESTENS Finden von Fehlern Steigerung der Softwarequalität Senkung der Fehlerrisiken Erfüllung von Normen / Vorschriften / Auflagen Warum? SW-Komplexität SW-Kritikalität (ohne Programme funktioniert kaum was noch) Fehler sind SEHR teuer

16 WARUM GIBT ES ENTWICKLER UND TESTER? Ein bisschen Psychologie Unabhängiges Testen (Objektivität behalten) Test soll von den Personen durchgeführt werden, die nicht an der Programmierung der Software-Module beteiligt waren! 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. Tester sind die Praktiker. Sie wollen nachweisen, dass das Programm unter bestimmten Bedingungen versagt. Tester bringen schlechte Nachrichten Konfliktpotential

17 3. Warum testen?

18 Warum testen?

19 Warum testen? Quelle: Standish Group, CHAOS Report 2009: Chaos History von IT-Projekten.

20 Was kosten Fehler? Geschätzte Verluste durch Softwarefehler in Mittelstands- und Großunternehmen in Deutschland:ca. 84,4 Mrd. p.a. 35,9% der IT-Budgets für Beseitigung von Programmfehlern entsprechen 14,4 Mrd. p.a. Produktivitätsverluste durch Computerausfälle aufgrund fehlerhafter Software: ca. 2,6% des Umsatzes - 70 Mrd. p.a. Quelle: Studie der LOT Consulting Karlsruhe, IT-Services 3/2001 allein in Deutschland Ausfälle von jährlich 85 Milliarden Euro durch mangelnde oder unzureichende Testing - Maßnahmen. Quelle: Forrester Research, 2003

21 Was kostet die Fehlerbeseitigung? Giga Information Group: Softwarefehler, die erst in der Post- Production-Phase entdeckt werden, verursachen 50 Prozent höhere Kosten als wenn sie bereits in der Entwicklung behoben worden wären.

22 Was kostet die Fehlerbeseitigung? Istanalyse / Grobkonzept Feinkonzept / DV- Konzept Realisierung Abnahme / Einführung Betrieb für Überarbeitung Geschäftsprozess, Review, Diskussion für Überarbeitung Geschäftsprozess, Review, Diskussion für zusätzliche Entwicklungskosten für zusätzliche Abnahmekosten, wiederholtes Roll out Umsatzverlust, Imageschaden

23 4. Application Lifecycle und damit einhergehende QS-Maßnahmen.

24 Application Lifecycle

25 Anforderungen

26 Anforderungen Design

27 Anforderungen Design Realisierung

28 Anforderungen Design Einführung Realisierung

29 Anforderungen Betrieb Design Einführung Realisierung

30 Optimierung Anforderungen Betrieb Design Einführung Realisierung

31 Anforderung: Weichenstellung für Qualität

32 Design: Fehler frühzeitig finden und beseitigen

33 Realisierung: Frühzeitiges, isoliertes Testen

34 Einführung: Prüfen auf Herz und Nieren Betrieb Vollständige Geschäftsprozesse Betriebliche Tests Reaktion auf System-Probleme Systemtest Abnahmetest Test gegen Anforderungen Funktionalität Oberfläche Integrationstest Komponententest Schnittstellen Performance Ausfallsicherheit Entwicklertest

35 Einführung: Prüfen auf Herz und Nieren

36 Betrieb: Qualität nachhaltig managen

37 Optimierung: Verbesserungen ableiten

38 5. Der Testprozess und Aufgaben eines Testmanagers.

39 Testvorgehen in der T-Systems MMS. Testauswertung Testdurchführung Testkonzeption Testvorbereitung Teststrategie und Testziele Testumfang Teststufen Testvoraussetzungen Testumgebung Bedarfsanalyse zur Testautomatisierung Toolauswahl QS Maßnahmen Ressourcen Fehlerklassen und Fehlerworkflow Risikomanagement Testdaten 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 Annahmetest Testdurchführung nach Testspezifikation Protokollieren der Testergebnisse Erstellung der Fehlermeldungen Re-Test Erstellung der periodischen Berichte Bewertung der Testergebnisse Überprüfen der Abnahmekriterien Dokumentation / Bericht Zertifizierung Freigabe

40 AUFGABEN DES TESTMANAGERS. 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

41 6. Auch so kann s gehen Ein Beispiel aus der Praxis.

42 Ausgangssituation. Ziel des SWE-Projektes: Bereitstellung einer Online-Plattform für die elektronische Genehmigung und Abrechnung von ärztlichen Verordnungen im Krankenkassenumfeld GU: T-Systems SW-Hersteller: deutscher Mittelständler Projektzusammensetzung Kunde: Deutsche Krankenkasse

43 Ausgangssituation. Keine Erkenntnis bis 2009, dass Testmanagement essentiell wichtig für den Projekterfolg ist früherer Versuch der Etablierung eines Testmanagements schlug fehl Kunde war unzufrieden aufgrund unklarer Situation hinsichtlich Anforderungsumsetzung und Fehler-Status Keine Aussage möglich, wann Software in den Pilotbetrieb gehen kann Alleiniger Test durch SW-Unternehmen auf Basis formloser Entwicklertests, wobei Testautomatisierung vernachlässigt wurde SW-Unternehmen hat keine Erfahrung bzgl. Umgang mit Großkunden und komplexen Projekten

44 Ausgangssituation. EtablierungTaskforce September: SW noch nicht im Pilotbetrieb Geplanter Livegang

45 Organisation TP Test. Testteams (sowohl Kunde als auch SW-Hersteller) Planung, Steuerung & Monitoring initiale Testdurchführung Sicherstellung der Testergebnis-Dokumentation Planung, Steuerung & Monitoring Nachtests Sicherstellung der kontinuierlichen Kommunikation zwischen Entwicklung und Test Kunde & Management- Team Reporting zur Testdurchführung und Fehlersituation Testmanager zusammen mit Test-Koordinatoren Koordination Fehler- Bewertung Klärung bei Defects. die ein weiteres Testen unmöglich machen / stark erschweren Entwicklung SW-Hersteller

46 Analyse der Ist-Situation und identifizierte Verbesserungspotentiale. Titel der Präsentation T-Systems Multimedia Solutions GmbH

47

48 Ableitung von Verbesserungspotentialen-TOP 6. 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 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

49 Ableitung von Verbesserungspotentialen-TOP 6. Finding Keine mit dem Kunden gemeinsam definierten Abnahmekriterien Zuordnung der Tester zu den Testfällen erfolgt momentan nach Verfügbarkeit Testaktivitäten durch neue Anforderungen / CRs seitens Kunde stark erschwert Verbesserungspotential 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 Abstimmung Frozen Zone mit Kunde, in der keine Umsetzung neuer Anforderungen / CRs erfolgt

50 Testkonzeption auf Basis der abgeleiteten Verbesserungspotentiale. Mapping der Testfälle zu den grobgranular spezifizierten Anforderungen schwierig, deshalb: Kunde erstellt die Testfälle, die gleichzeitig die Abnahmekriterien darstellen inkl. deren Einstufung nach Priorisierungskategorien 1. Erkenntnis: zum ersten Mal wurde auf Seiten des Kunden als auch SW-Herstellers die Wichtigkeit erkannt, formalisierte Testfälle zu erstellen Anfang Oktober 2009: Auslieferung der ersten 20 Testfall-Beschreibungen durch den Kunden Hochrechnung der benötigten Zeiten für weitere Testfall-Erstellung Grundlage für die Erstellung eines belastbaren Teststufenplans

51 Testkonzeption auf Basis der abgeleiteten Verbesserungspotentiale. 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 Zielkorridor: Jeder definierte und mit dem Kunden abgestimmte Testfall wird mindestens einmal ausgeführt. Bei zeitlichen Engpässen: alle Testfälle mit Priorität 1 und 2 werden mindestens einmal ausgeführt. 3. Erkenntnis vor Allem für den Kunde: es gibt keine 0 Fehler-Qualität, deshalb Einigung auf einen Fehlerkorridor

52 Oktober November Dezember Januar KW41 KW42 KW43 KW44 KW45 KW46 KW47 KW48 KW49 KW50 KW51 KW52 KW53 KW01 KW02 KW03 KW04 Funktionaler Performanctest Last- und Performancetest Funktionstest skv Last- und Performancetest skv Layout Test Funktions- und Prozesstest Interner Test auf Basis eigener TFs Interner Test auf Basis Kunden-TFs, 1. Teil Interner Test auf Basis Kunden-TFs, 2. Teil Kunden-Test, 1. Teil tbd ab Kunden-Test, 2. Teil ab Penetrationstest

53 Testkoordination und -monitoring monitoring. Titel der Präsentation T-Systems Multimedia Solutions GmbH

54 Ergebnisse und Konflikte. SW-Hersteller interner Test: 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.

55 Ergebnisse und Konflikte. 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 Entscheidung zum gemeinsamen Test mit einem gemischten Team aus Testern von der Kunden- als SW-Hersteller-Seite Entscheidung zu einem abgestimmten Prozess hinsichtlich TF-Anpassungen

56 Oktober November Dezember Januar KW41 KW42 KW43 KW44 KW45 KW46 KW47 KW48 KW49 KW50 KW51 KW52 KW53 KW01 KW02 KW03 KW04 Zur Erinnerung: ursprüngliche Testplanung Funktions- und Prozesstest Interner Test auf Basis eigener TFs Interner Test auf Basis Kunden-TFs, 1. Teil Interner Test auf Basis Kunden-TFs, 2. Teil Kunden-Test, 1. Teil ab Kunden-Test, 2. Teil ab

57 Oktober November Dezember Januar KW41 KW42 KW43 KW44 KW45 KW46 KW47 KW48 KW49 KW50 KW51 KW52 KW53 KW01 KW02 KW03 KW04 Funktions- und Prozesstest Interner Test auf Basis eigener TFs Interner Test auf Basis Kunden-TFs, 1. Teil Interner Test auf Basis Kunden-TFs, 2. Teil Kunden-Test, 1. Teil ab Kunden-Test, 2. Teil Gemeinsamer Test vor Ort beim Kunden ab ab Freihandtest SW-Hersteller Praxistest Kunde ab Gemeinsamer Regressionstest ab Übernahmetest ab Redaktionsschluss Trial-System: , Schwenk zum Produktivsystem

58

59 Testdurchführung - Abarbeitung Testfälle gesamt durchgeführt offen (inkl. zurück gestellte Testfälle) fehlerfrei Nicht Pilot-verhindernde fehlerbehaftete Testfälle Pilotverhindernde fehlerbehaftete Testfälle Blockiert durch anderen Fehler 120 Testdurchführung insgesamt 3%1% 3% offen (inkl. zurück gestellte Testfälle) fehlerfrei Anzahl Testdurchführung kumuliert (Plan) Anzahl Testfall- Durchführung kumuliert (Ist) Nicht Pilot-verhindernde fehlerbehaftete Testfälle % Pilotverhindernde fehlerbehaftete Testfälle Blockiert durch anderen Fehler

60 Aufteilung Testfall-Status nach Fehlerfreiheit erfolgreich (nach-) getestet bereit zum Nachtest offen zum Nachtest

61 Fehlerstatus akzeptierte Fehler nach Fehlerschwere Pilotverhindernd Nicht-Pilotverhindernd Summe offen gefixt bereit zum Nachtest closed Gesamt Fehlerstatus Meldungen gesamt Pilotverhindernd Nicht-Pilotverhindernd Summe zurück gezogen durch Kunde einvernehmlich abgewiesen doppelt akzeptierte Fehler Gesamt

62 Fehlermanagement. Titel der Präsentation T-Systems Multimedia Solutions GmbH

63 Fehlermanagement Allgemeiner Workflow. Bislang: Fehler wurden unbewertet auf Zuruf in internes Ticket-System des SW-Herstellers eingestellt und unkoordiniert abgearbeitet Nun: Alle festgestellten Fehler, Abweichungen, Probleme, usw. werden unmittelbar im Fehlermanagementsystem (TRAC) als Fehler erfasst und dokumentiert sowohl durch den Kunden als auch SW-Hersteller Bewertung Fehler-Klassifizierung und Behebungstermin mittels eines Fehler Clearings Vorab-Bewertung durch Entwicklungsteam des SW-Herstellers Tägliches Fehler-Reporting an den Kunden

64 Fehlermanagement Allgemeiner Workflow. KUNDE TESTER KUNDE QS new new SW-Hersteller QS new akzeptiert Entwicklung assigned gefixt SW-Hersteller Test closed Erfolgreich nachgetestet SW-Hersteller QS closed Zurück gezogen Nicht akzeptiert Nicht erfolgreich nachgetestet re-opened closed Fehler Clearing re-opened re-test re-test closed Erfolgreich nachgetestet Nicht erfolgreich nachgetestet

65 Fehlerprozess Klassifizierung und Priorisierung. Workflow Neue Fehler Täglich Fehlerclearing Fehlermanager, Test und Entwicklung Ergebnis = Fehler Zuordnung Fehlerklasse Priorität Entwickler zu beheben in Version x Termin der Behebung Ergebnis = CR Changeboard (GPL, PL Kunde) Analyse Risiko & Impact des Impacts (was passiert,wenn wir es nicht tun) wie oft kommt der Fall vor gibt es einen Workaround Analyse Aufwand (Entwicklung und Test) Analyse Impact bereits erreichte Testergebnisse Analyse sonstige Risiko Entscheidung Umsetzung erfolgt in Version x Dokumente Auszug aus Ticketsystem Change Requestliste Release-Versionsplan Entwicklung Fehlerbeseitigung, Test Status : behoben Nachtest durch Testteam Status: geschlossen oder wiedereröffnet Freigabe nächste Teststufe (Kundentest) GPL, Testmgmt, Entwickl.mgmt Entscheidung, wann Patch auf Testsystem Kunde

66

67 Fazit. Titel der Präsentation T-Systems Multimedia Solutions GmbH

68 Fazit. Die saubere Aufnahme und Abstimmung von Anforderungen zusammen mit dem Kunden ist das A und O für erfolgreiche Projekte. 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.

69 7. Überblick ausgewählter Testarten.

70 Testarten im Überblick. 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. Security Usability/ Accessibility- Test Applikationsanalyse Funktionstest Lasttest Code Quality Management SOA-Test Testautomatisierung

71 Qualitätsmerkmale. Systematik entspricht den DIN-ISO- Normen 9126 und 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?

72 Funktionstest.

73 QUALITÄTSMERKMALE EINES SOFTWARESYSTEMS. Funktionalität Funktionalität Funktionalität Funktionalität Übertragbarkeit Übertragbarkeit Übertragbarkeit Übertragbarkeit Änderbarkeit Änderbarkeit Änderbarkeit Änderbarkeit Effizienz Effizienz Effizienz Effizienz Benutzbarkeit Benutzbarkeit Benutzbarkeit Benutzbarkeit Zuverlässigkeit Zuverlässigkeit Zuverlässigkeit Zuverlässigkeit Angemessenheit Angemessenheit Angemessenheit Angemessenheit Richtigkeit Richtigkeit Richtigkeit Richtigkeit Reife Reife Reife Reife Fehlertoleranz Fehlertoleranz Fehlertoleranz Fehlertoleranz Verständlichkeit Verständlichkeit Verständlichkeit Verständlichkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Zeitverhalten Zeitverhalten Zeitverhalten Zeitverhalten Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Analysierbarkeit Analysierbarkeit Analysierbarkeit Analysierbarkeit Installierbarkeit Installierbarkeit Installierbarkeit Installierbarkeit Anpassbarkeit Anpassbarkeit Anpassbarkeit Anpassbarkeit Nicht-funktionale Q-Merkmale Verständlichkeit Verständlichkeit Verständlichkeit Verständlichkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Zeitverhalten Zeitverhalten Zeitverhalten Zeitverhalten Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Analysierbarkeit Analysierbarkeit Analysierbarkeit Analysierbarkeit Installierbarkeit Installierbarkeit Installierbarkeit Installierbarkeit Anpassbarkeit Anpassbarkeit Anpassbarkeit Anpassbarkeit Verständlichkeit Verständlichkeit Verständlichkeit Verständlichkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Zeitverhalten Zeitverhalten Zeitverhalten Zeitverhalten Ordnungsmäßigkeit Ordnungsmäßigkeit Ordnungsmäßigkeit Ordnungsmäßigkeit Sicherheit Sicherheit Sicherheit Sicherheit Richtigkeit Richtigkeit Richtigkeit Richtigkeit Interoperabilität Interoperabilität Interoperabilität Interoperabilität Wiederherstellbarkeit Wiederherstellbarkeit Wiederherstellbarkeit Wiederherstellbarkeit Fehlertoleranz Fehlertoleranz Fehlertoleranz Fehlertoleranz Erlernbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Bedienbarkeit Bedienbarkeit Bedienbarkeit Bedienbarkeit Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Stabilität Stabilität Stabilität Stabilität Prüfbarkeit Prüfbarkeit Prüfbarkeit Prüfbarkeit Konformität Konformität Konformität Konformität Installierbarkeit Installierbarkeit Installierbarkeit Installierbarkeit Austauschbarkeit Austauschbarkeit Austauschbarkeit Austauschbarkeit Systematik entspricht der DIN-ISO-Norm 9126 Erlernbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Bedienbarkeit Bedienbarkeit Bedienbarkeit Bedienbarkeit Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Verbrauchsverhalten Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Modifizierbarkeit Stabilität Stabilität Stabilität Stabilität Prüfbarkeit Prüfbarkeit Prüfbarkeit Prüfbarkeit Konformität Konformität Konformität Konformität Installierbarkeit Installierbarkeit Installierbarkeit Installierbarkeit Austauschbarkeit Austauschbarkeit Austauschbarkeit Austauschbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Erlernbarkeit Bedienbarkeit Bedienbarkeit Bedienbarkeit Bedienbarkeit

74 FUNKTIONSTEST. Motivation Vorgehen 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? T-Systems Multimedia Solutions GmbH

75 FUNKTIONSTEST. Motivation Vorgehen Testelemente abgrenzen Priorisieren Testmethode Testspezifikation Komplexität Häufigkeit Schätzung durch AG Schätzung durch Entwicklung Äquivalenzklassen Grenzwertanalyse Zustandsbasiert Intuitiv Manuell Automatisiert SOA T-Systems Multimedia Solutions GmbH

76 Lasttest.

77 LASTTEST. Motivation Vorgehen Nutzen 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! 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? T-Systems Multimedia Solutions GmbH

78 LASTTEST. Überwachung der Agenten Ergebnis -analyse Erzeugung der Anfragen Serverüberwachung in Realzeit TrueLog Überprüfung der Antworten Testsystem Controller Last- Agenten Virtuelle Benutzer T-Systems Multimedia Solutions GmbH

79 Usability/Accessibility-Test.

80 USABILITY/ACCESSIBILITY-TEST. Motivation 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? T-Systems Multimedia Solutions GmbH

81 USABILITY. Motivation Vorgehen Nutzen Usability-Experten-Evaluation Umfassende Evaluation der Nutzungsoberfläche durch mindestens 2 Experten 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 Usability-Test mit Probanden Nutzertest durch 6-8 Probanden, welche typische Aufgaben am zu testenden System durchführen Eye-Tracking Analyse einer Schlüsselseite durch einen repräsentativen Probanden 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 T-Systems Multimedia Solutions GmbH

82 USABILITY/ACCESSIBILITY-TEST. Motivation Vorgehen Nutzen T-Systems Multimedia Solutions GmbH

83 Und noch viel mehr

84 Qualitäts- sicherungs- Beratung Datenschutz Code Quality Management Test- Management Funktionstest Testautomatisierung SOA -Test Security Usability/ Accessibility- Test Lasttest Abnahmetest Applikationsanalyse Application Monitoring

85 Data Privacy and Security Portfolio Anforderungs -management Fachkonzept DV-Konzept Sicherheitsanforderungen Sicherheits-/Datenschutzkonzept Projektberatung Code Review Implementierung Regressionstest/ Projektberatung Projektberatung Penetrationstest/ Zertifizierung Betrieb Deployment Test

86 8. Data Privacy and Security. Umfeld.

87 Data Privacy and Security Wissen der Angreifer Wissen der Angreifer Weitergabe von Informationen Schnelle Verbreitung Verstärkter Einsatz von Werkzeugen Notwendiges Wissen zum Ausnutzen von Schwachstellen sinkt Anzahl der möglichen Angreifer steigt Anzahl der Angreifer

88 Data Privacy and Security Formen von Bedrohungen Neue Angriffsformen mit alten Hilfsmitteln Häufige Angriffsformen, die nur einen Browser benötigen: Cross Site Scripting {SQL, Command, HTML, PHP, } Injection Informationspreisgabe Weitere erfolgreiche Angriffsformen: Social Engineering

89 Data Privacy and Security OWASP Top 10

90 Data Privacy and Security. Arten von Schwachstellen.

91 Data Privacy and Security Nutzerseitige Angriffe Cross Site Scripting Cross Site Tracing Inhaltsmanipulation Authentifizierung SQL - Injection Brute Force Unzureichende Authentisierung Schwache Passwort Wiederherstellung Cross Site Authentication Autorisierung Berechtigungen vorhersagen Unzureichende Autorisierung Unzureichende Sitzungs- beendigung Sitzungs Fixierung Informationsoffenlegung Auflisten Verzeichnis Informationsleck Pfadmanipulation Vorhersagbare Quellen Befehlsausführung Injection Angriffe (Einschleusung) SQL Injection Logische Angriffe Unzureichende Anti- Automation Unzureichende Prozessprüfung Cross Site Request Forgery Quelle: nach WASC04, WASC 2010

92 Data Privacy and Security. Durchführung Penetrationstest.

93 Data Privacy and Security Penetrationstest Anforderungs -management Fachkonzept DV-Konzept Sicherheitsanforderungen Sicherheits-/Datenschutzkonzept Projektberatung Code Review Implementierung Regressionstest/ Projektberatung Projektberatung Penetrationstest/ Zertifizierung Betrieb Deployment Test

94 Data Privacy and Security Penetrationstest Vorgehen Praktische Beispiele Anforderungsmanagement, Projektberatung. Anforderungen an Betrieb, Entwicklung und Fachseite wurden definiert. Fachkonzepte. Sicherheitskonzept wird erstellt (gilt als Testgrundlage). Datenschutzkonzept wird erstellt. Penetrationstest. Überprüfung der Wirksamkeit der Maßnahmen aus dem Sicherheitskonzept.

95 Data Privacy and Security Penetrationstest Vorbereitung Informationsbeschaffung Bewertung Aktive Eindringversuche Auswertung Vorgehen Praktische Beispiele

96 Data Privacy and Security Penetrationstest Vorgehen Praktische Beispiele

97 Danke für Ihre Aufmerksamkeit!

98 Kontakt Ute Seidel Telefon: Thomas Haase Telefon: