Software-Qualitätssicherung für die SCHUFA-Kernanwendungen Organisation, Prozesse und Werkzeuge

Transkript

1 Software-Qualitätssicherung für die SCHUFA-Kernanwendungen Organisation, Prozesse und Werkzeuge Jens Borchers SCHUFA Holding AG Informatik-Kolloquium am 16. April 2012 im Intershop Tower in Jena Agenda 1 SCHUFA-Kennzahlen und Grundlegendes zum Testen 2 Aufbau der Testorganisation und -prozesse 3 Testautomatisierung zur Effizienzverbesserung 4 Aktuelle Herausforderungen 5 Kurzes Fazit Seite 2 1

2 Agenda 1 SCHUFA-Kennzahlen und Grundlegendes zum Testen 2 Aufbau der Testorganisation und -prozesse 3 Testautomatisierung zur Effizienzverbesserung 4 Aktuelle Herausforderungen 5 Kurzes Fazit Seite 3 Unternehmensvorstellung Verwaltet den derzeit größten Datenpool in Deutschland zur Beurteilung des aktuellen Zahlungsverhaltens natürlicher Personen Herkunft der Daten: Vertragspartner (Gegenseitigkeitsprinzip) Amtsgerichte (öffentlich!) Insolvenzverzeichnisse (öffentlich!) Auskünfte an: Banken, Handel, Telcos, usw. Die Verbraucher selbst: insbesondere BDSG neu seit ! An Dritte im Verbraucherauftrag Online-Services Seite 4 2

3 Unternehmensvorstellung: Nein SCHUFA ist keine Behörde! Sondern eine Aktiengesellschaft Genossenschaftsbanken 7,9% Handel und andere 13,1% Kreditbanken 36,4% Privatbanken 17,9% Anteilseignerstruktur Sparkassen 24,7% Seite 5 Unternehmensvorstellung: Konzern-Kennzahlen Datenbestand Personen zu denen Daten gespeichert sind (Mio.) Gespeicherte Informationen (Mio.) Informationsangebot Auskünfte und Nachmeldungen (Mio.) Anteil Scores (in Verbindung mit Auskünften) Eigenauskünfte ( 34 BDSG und Bonitätsauskünfte) Geschäftsdaten Umsatz in T Ergebnis der gewöhnlichen Geschäftstätigkeit in T * Standorte (seit BDSG kein Publikumsverkehr mehr) Mitarbeiter (Jahresende) ,4 62% , ,4 69% * Seite 6 3

4 Unternehmensübergreifende Services SCHUFA SCHUFA-Services sind wesentliche Bestandteile der Geschäftsprozesse unserer Vertragspartner müssen 100% korrekt funktionieren, weil sonst kritische Entscheidungen nicht getroffen werden können: Bekommt diese Person einen Kredit... einen Handyvertrag... eine Versandlieferung gegen Rechnung? müssen schnell sein, weil der Kunde am Schalter wartet jemand am PC wartet Seite 7 Grobe Systemtopologie für die Kern- Auskunfteianwendung im Laufe der Migration abgelöst Host Unix-Systeme Anfragen / Meldungen Host / IBM Grossrechner ßrechner z/os / Zeichensatz: EBCDIC (Host Anwendung programmiert in Assembler) XML1SCDI SCDASCDI FileData SCM (Schufa Connection Manager) Batch Controller DSS Input Filter Data Meldungen SCDI XML 16 Application Server / BEA Weblogic r UNIX (Solaris) / Zeichensatz: ASCII r NAV Neue Anfrage Verarbeitung r (J2EE - Java 2 Enterprise Edition) MASS/R3 Uniserv w DSS-Score DSS Logs Host XML GW1 SIML 1.0 -SCDI Format Mapping Host Weiche (VP -sensitiv) Data XML2 SCDI (out) GUI Userinterface XML Gateway 2, SIML 1.0, (SIML 2.0) DSS (Präsentationsschicht) MONLOG-DB SAS Ablaufsteuerung Anfrage / Meldung Kommunikation über TCP/IP, HTTPS Geschäftslogik IDF (internes Dat enformat) Host Service (Connector) Service Request wird in Pers DB geschrieben Pers DB r/w Replikation zur NAV Pers -DB Kommunikation DB Doku Server (XML Doku -> *.pdf / Fax) Pers DB Archiv r Replizierte Daten der Host Pers-DB r/w FIST r/w Vorgangs DB -> neuer Speicher (EBMW) r/w ZAMxx w Statistik Sätze Leistungssätze Datawarehouse r Mass/R2 MASS/R2 w XML Daten Druck, schreiben SAP (Sammler/Z ähler) SAP Faktura r User (SCDA, SAS) r VP-DV SAP GP Erzeugt VP -DV Zustand User Verwaltung r/w (nur für GUI) Seite 8 4

5 Systemtopologie für elektronische Services Vertragspartner- Anbindungen File Transfer SCDI via native SNA 3745 Berlin 1 Berlin 2 SCDI FTP over IP SCDI / SNA SIML 1 SIML 2 CG VP Hub SWS Meldungen Anfragen 7x24 Jens Borchers - Software-Qualitätssicherung für SCHUFA-Kernanwendungen - Informatik Seite 9 Konzern-Kennzahlen und ihre Auswirkungen auf Test und Abnahme Datenbestand Personen zu denen Daten gespeichert sind (Mio.) Gespeicherte Informationen (Mio.) Informationsangebot Auskünfte und Nachmeldungen (Mio.) Anteil Scores (in Verbindung mit Auskünften) Eigenauskünfte ( 34 BDSG und Bonitätsauskünfte) Geschäftsdaten Umsatz in T Standorte Mitarbeiter (Jahresende) ,4 62% , ,4 69% Seite 10 5

6 Testen der SCHUFA-Bonitätsprodukte etwas Kombinatorik Jeder Verbraucher in der Produktionsdatenbank hat durchschnittlich 7 Merkmale aus ca. 100 möglichen Merkmalen (Haupt- und Untermerkmale) von 0 (neuer Verbraucher oder ohne Merkmale) bis über 200 Es gibt 3 große Produkte Auskünfte, Nachmeldungen, Meldungen Es gibt 4 Vertragspartner-Arten (A, B, D, F) mit unterschiedlichem Inhaltsauskunft zum selben Verbraucher Es gibt 9 Kommunikationskanäle mit unterschiedlichen Protokollen 4 synchron: SCDI-DIALOG, SIML1, SIML2, (Webservices) 5 Batch: DATA, SCDI-FILE, SIML1-Batch, SIML2-Batch, (Webservices) Es gibt 8+x mögliche Angaben allein zur Identifikation des Verbrauchers 8 Basisangaben + zusätzliche Adressen + Kontonummer +. Seite 11 Agenda 1 SCHUFA-Kennzahlen und Grundlegendes zum Testen 2 Aufbau der Testorganisation und -prozesse 3 Testautomatisierung zur Effizienzverbesserung 4 Aktuelle Herausforderungen 5 Kurzes Fazit Seite 12 6

7 Grundlegende Entwicklungs- und Teststrategie Entwicklung strikt auf Basis vorab geplanter Release-Inhalte not agile at all, d.h. hohe Hürden auch für kleine Änderungen derzeitige Frequenz: 4 große Releases pro Jahr bis Mitte 2011 hoher Funktionalitätszuwachs pro Release durch Hostmigration nur (extrem wenige!) Hotfixes zwischen Releases Ziel: Null-Fehler -Produktion für alle Funktionen mit direkter Außenwirkung Test- Schule nach Bret Pettichord (2007, (Download: Wir folgen primär der Quality School, d.h. Testen ist der Gatekeeper Testen hat nur Abweichungen der Software gegenüber Spezifikationen zu identifizieren, es erzeugt keine neuen Anforderungen Teststrategie bestimmt durch Risikoeinstufung der einzelnen Funktionen Alle Funktionen mit direkter Außerwirkung gehören zu Klasse 1 Seite 13 Spezifikationen vs. Testfälle wie gehen wir damit um? Spezifikation entstehen auf Basis von Anwendungsfällen Aktivität und Sub-Anwendungsfall als Hauptartefakte Anwendungsfall-Diagramm als Orientierung Pro Anwendungsfall entstehen diverse strukturierte Dokumente Verbale (teil-formale) Spezifikation pro Aktivität diverse abhängige Dokumente für referenzierte Objekte etc. Alle Artefakte werden in Konfigurationsmanagement verwaltet Strenge Check-out-/ Check-in-Verfahren Gesamtumfang: einige Tausend Dokumente pro Release: mehrere 100 neue bzw. angepasste Dokumente Spezifikationen gehen zeitgleich an Tester und Softwareentwicklung Tester sind Teilnehmer der Spezifikations-Review-Teams Seite 14 7

8 Spezifikationen vs. Testfälle Vorder- und Rückseite der Software Software Seite 15 V-Modell Verteilung der Aufgaben intern/extern Systemanforderungsanalyse Fachspezifikationen Abnahme und Nutzung Systemarchitektur SCHUFA Systemintegration Systementwurf Architektur Integrations-Tests Lieferant Softwarearchitektur Unit-Tests Softwareerstellung Seite 16 8

9 Teststufen und -umgebungen bei SCHUFA Integrationstest Einbeziehung neuer Systemtopologie Eingeschränkte Umgebungen (z.b. Host-Verfügbarkeit, andere Subsysteme) Smoketests der neuen Funktionen, erste kleine Regressionsrunde Systemtest und fachlicher Abnahmetest Diverse parallele Abnahmeumgebungen als Reinraum betreibbar Hier werden die fachlichen Spezifikationen detailliert herangezogen! Betrieblicher Abnahmetest (durch IT-Provider) Systeme entspricht 1:1 dem Produktiv-System Fachliche Aspekte eher untergeordnet, Verfügbarkeit und Last im Vordergrund Seite 17 Release- und Testmanagement Quality Gates Produktions- Betrieb Entwicklungsund Integrationsteams Abnahmeteam/ Testmanagement Definition/ Anforderungen an Neue Services Einbindung Betrieb Fachliche Entwicklung- Betriebliche Abnahme- Umgebungen Abnahme- Umgebungen Umgebung Einzel- Integrations- Fachlicher BzA prüfung Test HdF Abnahmetest Lieferanten- Umgebungen Modul-System- Test Lieferant 1 Modul-System- Test Lieferant n Produktions- Umgebung Releasefreigabe QG1 QG2 QG3 Betrieblicher Abnahmetest Release to Produktion Testmanagement Release Development Release Test Release Management Release Rollout Seite 18 9

10 Testorganisation für die fachlichen Abnahmetests ISTQB- Zertifizierungen als Leitfaden Fachliches Abnahmeteam Testfactory Seite 19 Agenda 1 SCHUFA-Kennzahlen und Grundlegendes zum Testen 2 Aufbau der Testorganisation und -prozesse 3 Testautomatisierung zur Effizienzverbesserung 4 Aktuelle Herausforderungen 5 Kurzes Fazit Seite 20 10

11 Testautomatisierung Frühe Konzentration auf Automatisierung der häufig benötigten Prozesse Verwalten von Datenarchiven Rüstprozesse Vergleichoperatoren Oberflächentest Treiber für nachrichtenbasierte Tests Prüfung der Testeingangsbedingungen mit statischer Analyse Seite 21 Statische Codeanalyse - Einsatz von Sotograph und Sotoarc System- Verantwortlicher Entwickler Architekt Qualitätsverantwortlicher Sotoweb Server Tägliche Reports im Nightly Build Report bei Lieferung an QG1 Lokale Installation der SOTO-Tools Nur Zugriff auf SOTO-Web Seite 22 11

12 Testvorgehen im Bereich Automatisierung Automatische Durchführung aller Testfälle für jeden Release-Wechsel fachliche Testfälle das Mehrfache an technischen Testfällen Sicherung aller Testergebnisse Automatischer Vergleich der Ergebnisse mit dem jeweiligen Baseline-Testergebnis Erstellen von Auswertungen als Basis für die fachliche Bewertung von Abweichungsfällen Bewertung der Abweichungen durch das Fachteam Revisionssichere Ablage Seite 23 TOSCA bei der SCHUFA TOSCA Philosophie Seit 2009 ist TOSCA das zentrale Testverwaltungswerkzeug auch als Ersatz für ein klassisches Capture/Replay-Tool Quelle: Tricentis-Dokumentation Seite 24 12

13 TOSCA bei der SCHUFA TOSCA Philosophie Testfallbeschreibung durch Fachtester/innen kein Programmier-Know-how bei Fachtestern Aber alle ISTQB-zertifiziert! Aktivität und Sub-Anwendungsfall als Haupttreiber der Testfallerstellung Reduzierung des Wartungsaufwands durch Trennung von Testabläufen Testdaten Maskendefinitionen Kein Capture/Replay Testfallbeschreibung/-automatisierung beginnt parallel zur Entwicklung Testtreiber für verschiedene Technologien (HTML, SAP, Java, Host, ) Erweiterung des Frameworks durch dedizierte Test Engineers Seite 25 Erreichter Stand für Kernauskunftei-Anwendung Regressionstest voller Regressionstest in ca. 15 Werktagen (alle drei Produktlinien) alle Rüst- und Vergleichsprozesse nahezu 100% automatisiert fachliche Testfälle, jeweils über mehrere Kanäle und Oberflächen alle GUI-Tests über TOSCA alle Nachrichtenschnittstellen durch Gatefeeder aber auch im Zusammenspiel mit TOSCA Automatisierungsquote für neue Funktionen 100% bei nachrichtenbasierten Tests > 85% bei GUI-Tests Wir automatisieren wenn möglich auch schon die erste Testrunde! Aber: Nicht immer sinnvoll! Seite 26 13

14 Agenda 1 SCHUFA-Kennzahlen und Grundlegendes zum Testen 2 Aufbau der Testorganisation und -prozesse 3 Testautomatisierung zur Effizienzverbesserung 4 Aktuelle Herausforderungen 5 Kurzes Fazit Seite 27 Aktuelle Herausforderungen TPI-Assessments Durchführung von 2 externen TPI-Assessments 2004 / 2009 Deutliche Verbesserung im Automatisierungsbereich noch Optimierung im Bereich Aufwandsschätzung, Testfalloptimierung Seite 28 14

15 Aktuelle Herausforderungen Erweiterung der Konzepte auf andere Anwendungen Mission critical -Einstufung Konzentration auf Systeme mit direkter Außenwirkung Rein interne Systeme klassisch durch Fachbereiche Ausweitung der Konzepte auf agile Entwicklung Spagat zwischen Agilität und Rigidität Automatisierung ist nicht allein die Lösung, aber unverzichtbar ggf. neue Definition von Teststufen erforderlich Weitere methodische Optimierung der Regressions- und Abnahmetests Wirklich nur noch reine Black box? Testabdeckungsmessung auf Fachebene Aufwandsschätzung und Reporting Qualitäts- Dashboard Seite 29 Agenda 1 SCHUFA-Kennzahlen und Grundlegendes zum Testen 2 Aufbau der Testorganisation und -prozesse 3 Testautomatisierung zur Effizienzverbesserung 4 Aktuelle Herausforderungen 5 Kurzes Fazit Seite 30 15

16 Fazit Hohe Automatisierung bringt Geschwindigkeit und damit auch Agilität verhindert menschliche Fehler und damit unnötige Fehlersuchen verschafft alle Mitarbeitern die Zeit, sich um Wichtigeres zu kümmern als zum x-ten Mal den selben Testfall einzugeben Automatisierung allein ist aber auch nicht die Lösung Rigide Prozesse Methodisches und fachliches Know-how der Fachtester im Fall SCHUFA sehr spezielles Domain Knowledge Risikobasierte Testkonzeption bleibt wichtig Seite 31 Vielen Dank für Ihre Aufmerksamkeit! Jens Borchers SCHUFA Holding AG Kormoranweg Wiesbaden Tel.: +49 (0) jens.borchers@schufa.de 16