Wer zahlt für (Regressions-) Tests? · Retesting and regression testing All test procedures resulting in incident reports must be rerun after defect correction. Regression testing

� www.steria-mummert.de

Qualitätssicherung im Spannungsfeld zwischen Projekt und Betrieb

Wer zahlt für (Regressions-) Tests?

Jens Borchers ASQF-Workshop am 6. November 2014 in Hamburg

� www.steria-mummert.deDiscover the Power of Sharing

07.11.2014 2

Wer zahlt für (Regressions-) Tests?

Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen schriftlichen Zustimmung von Steria Mummert Consulting.

Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen und die Einspeicherung und Verarbeitung in elektronischer Form. Eine Weitergabe an Dritte ist nicht gestattet.

Datum:

Steria Mummert Consulting GmbHHans-Henny-Jahnn-Weg 29, 22085 Hamburg

Telefon: +49 40 22703-6330Fax: +49 40 22703-2330

E-Mail: [email protected]

Vorsitzender des Aufsichtsrates: François EnaudGeschäftsführer: Urs Michael Krämer

Gesellschaftssitz: Hamburg - HRB 130 165 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351

Jens BorchersSenior Executive Manager

Application Management Services

06.11.2014

Qualitätssicherung im Spannungsfeld zwischen Projekt und Betrieb

Wer_zahlt_fuer_(Regressions-)_Tests_ASQF_2014-11-06_V10.pptx © Steria Mummert Consulting GmbH

� www.steria-mummert.deReferenz und Basis

07.11.2014 Wer_zahlt_fuer_(Regressions-)_Tests_ASQF_2014-11-06_V10.pptx © Steria Mummert Consulting GmbH

3

Vortrag auf der iqnite 2013

� www.steria-mummert.deAgenda

1 Regressionstest – die Grundlagen

2 Regressionstest im Entwicklungsprozess

3

Und wer bezahlt das Ganze?


4

4

Projekte vs. Betrieb – Wem „gehört“ die Regression?

� www.steria-mummert.deRegressionstest – Grundlagen


5

� Spillner/Linz: Basiswissen Softwaretest� „Erneuter Test eines bereits getesteten Programms bzw. einer Teilfunktionalität

nach deren Modifikation mit dem Ziel, nachzuweisen, dass durch die vorgenommenen Änderungen keine Fehler eingebaut oder (bisher maskierte Fehler) freigelegt wurden.“

� Wikipedia (Stand: 03.11.2014)

� Unter einem Regressionstest (…) versteht man (…) die Wiederholung von Testfällen, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler ("Regressionen") verursachen. Solche Modifikationen entstehen regelmäßig z. B. aufgrund der Pflege, Änderung und Korrektur von Software. (…). Im Gegensatz dazu ordnet Liggesmeyer en Regressionstest in die Gruppe der diversifizierenden Tests ein. Dadurch wird im Unterschied zu funktionsorientierten Testtechniken die Korrektheit der Testergebnisse nicht anhand der Spezifikation entschieden, sondern durch Vergleich der Ausgaben der aktuellen Version mit den Ausgaben des Vorgängers. Ein Testfall gilt beim Regressionstest als erfolgreich absolviert, wenn die Ausgaben identisch sind

Definitionen

� www.steria-mummert.deRegressionstest – Grundlagen


� ISTQB Glossary� Regression Testing: Testing of a previously tested program following

modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It isperformed when the software or its environment is changed.

� ISO/IEC 29119-2� 4.19 - regression testing

� testing following modifications to a test item or to its operational environment, toidentify whether regression failures occur

� NOTE The sufficiency of a set of regression test cases depends on the item under test and on the modifications to that item or its operational environment.

� 4.20 - retesting� re-execution of test cases that previously returned a "fail" result, to evaluate the

effectiveness of intervening corrective actions

� NOTE 1 Retesting is often combined with regression testing.

� NOTE 2 Retesting is also known as confirmation testing.

ISTQB und ISO/IEC 29119-2



� Retesting and regression testing� All test procedures resulting in incident reports must be rerun

after defect correction.� Regression testing during the system test sub-process is at the test

manager’s discretion.� In the final system test run, all test procedures must be executed.� The necessary retesting and regression testing to fulfill the completion

criteria must be performed. � It is estimated that at least 3 testing cycles will be performed, the last one

including a complete regression test.

Regressionstest – Grundlagen

ISO/IEC 29119-3


2

Regressionstest – die Grundlagen1

Regressionstest im Entwicklungsprozess

3



8

4



9

Teststufen und Quality-Gates im Softwareentwicklungsprozess

• Annahme der Software

• Durchführung Integrationstests

• Lieferung der Software an das technische Test-managementen

• Testverantwortung liegt beim Provider

• Last und Performance Test

• ISO 250xx REGRESSION

Betriebliche Abnahme

Quality-Gate I

Quality-Gate II

Integrations-management

Quality-Gate III

• Annahme der Software

• Installation• Durchführung

System / Abnahmetest

• FACHLICHEREGRESSION

Abnahme-management

• Bereitstellung der Software

• Durchführung von Entwicklertests undinternen QS Maßnahmen

Softwarelieferant(intern/extern)


Beispiel SCHUFA (2012)


10

Projekte („Change“)

„Wächter“

Regressionstests in den Projektphasen

Fachliche Regression(Fachprozesse)

Abnahmemanagement(Linienfunktion CtB)

Technische Regression(ISO 250xx)

(Linienfunktion RtB/IT-Provider)

Teilregression

Appl1

Teilregression

Appl2

Teilregression

Appl3

Teilregression

Appl4

Betrieb („Run“)


„Ideales“ Organisationsmodell im Entwicklungsprozess


3


Regressionstest im Entwicklungsprozess 2



11

4


� www.steria-mummert.deRegressionstest – Unterschiedliche Ziele


� Ziele an den Regressionstest im Projekt

� Sicherstellung bereits fertiggestellter Funktionen der Applikation

� Ermittlung ungewollter Nebenwirkungen geänderter Komponenten

� Gerade in agilen Entwicklungen ist permanente Regression Standard

� Aber eben nur innerhalb des eigenen Projekt-Scopes

� Ziele an den Regressionstest aus dem Betrieb� Absicherung des („gesamten“!) bestehenden Produktivbetriebs gegen

unerwünschte Seiteneffekte von Änderungen, die durch ein neues Release einer oder mehrerer Applikationen eingeführt werden sollen.

� Vermeidung von technischen und fachlichen Produktionsstörungen oder gar einem (Teil-) Stillstand des Produktionsbetriebs � also kein (signifikanter) Anstieg von Incidents nach

Produktionseinführung.� und vor allem keine Klasse 1 - Incidents

Projekte vs. Betrieb


13

Regressionstest – Testfall-Portfolio

� Beispiel SCHUFA-Kernanwendung (2012)� Das Kernsystem besteht aus zwei Plattformen (Anfrage- /

Nachmeldeverarbeitung) mit diversen Subsystemen:� Kernsystem in BEA Application Server (WLS)

� J2EE Anwendung mit mehreren Architekturschichten

� Subsysteme auf Unix-Rechnern sind über Gateways angebunden� Hostservices für Updates des juristischen Datenbestandes auf IBM-

Mainframe über WebSphere MQ

� Umfang des Regressionstests� 40 Haupt-Anwendungsfälle mit ca. 200 einzelnen Aktivitäten

� ca. 40.000 Testfälle, die in der Regel end-to-end durchgeführt werden

� Ausgeführt in einem guten umfangreicher Testläufe mit entsprechenden Datenarchiven

� Automatischer Vergleich der Ergebnisse mit vorherigem Release


Herausforderungen an einem konkreten Beispiel

� www.steria-mummert.deRegression im Rahmen von AMS


14

� Run the Business

� Produktionsbetrieb

� First und Second Level Support

� Customizing, termingerechte Job-

Ablaufsteuerung, System-Schnittstellen

� Produktionsübernahme aus CTB

� Wartung des produktiven Umfelds

� Erreichung von Skaleneffekten durch

Industrialisierung (ITIL, ISO 20000)

� Testunterstützung bei Incidents

� Change the Business

� Koordination der Anforderungen, Abstimmung, Angebotserstellung, Tracking der Umsetzung

� Koordination von mehreren Partnern

� Übergreifende Ressourcensteuerung für die einzelnen Releases

� Konzeption, Realisierung, Test der Anforderungen

� Regressionstest für Gesamtsystem

� Third Level Support

Application Management bei einer Großbank� www.steria-mummert.de


15

Regressionstest im Spannungsfeld Projekt/Betrieb

� CtB-Ziele:� Möglichst viele neue Geschäftsfunktionen in kurzer Zeit� Fokus auf fachliches Backlog – möglichst „hoch agil“ abarbeiten� Zumeist in mehreren parallelen Projekten� Primäre Sicht in die Zukunft – „Treiber“

� RtB-Ziele:� Der aktuelle Produktionsbetrieb ist „heilig“� Jede Änderung im Produktionsumfeld ist eine

potentielle Bedrohung� Nicht-funktionale Aspekte werden im

Entwicklungsprozess eher „vernachlässigt“� Primäre Sicht auf Vorhandenes – „Bewahrer“


Change the Business“ (CtB) vs. „Run the Business“ (RtB)


16

Regressionstest im Spannungsfeld CTB-RTB

� Variante 1 – den Entwicklungsprojekten� Pro‘s:

� Müssen ohnehin testen, warum nichtauch alle schon bestehenden Funktionen?

� Haben die Testfälle ohnehin im Zugriff� Con‘s:

� Andere Ziele -> primär neue Funktionalität � Nur limitiertes Weltbild des (Gesamt)-Betriebs

� Variante 2 – dem Betrieb� Pro‘s:

� Hohes Eigeninteresse� Sollten volles Bild der Produktion haben

� Con‘s:� Dediziertes Betriebs-Testteam kostet (viel) Geld� Meist weniger fachliches Know-how


Wem also „gehört“ der Regressionstest?


17

Regressionstest – Test Center Ansatz

� Zentrales Testteam zwischen CTB und RTB� Test-Center für Projekte

� Infrastruktur-Management � Methoden-Management� Testfall-Verwaltung und -Pflege (inkl. Daten)

� Verantwortlich für Regressionstests:� Funktionale Regression als Teil der

Abnahmeprozesse (letztes fachliches QG)� Betriebliche Aspekte

� Last und Performance (Klassiker!)� Installation und Fallback (für 7x24!)� weitere aus ISO/IEC 250xx

� Damit Vertreter aller Interessen� der „Regressions-Treuhänder“


Die vermutlich beste Lösung (aber nicht billig)


4


Regressionstest im Entwicklungsprozess 2



18

3 Projekte vs. Betrieb – Wem „gehört“ die Regression?


19

Regressionstest – und wer bezahlt?

� Regressionstests sind teuer!� i.d.R. Abdeckung des „Gesamt“-Systems notwendig� Hohe Infrastrukturkosten � Hohe Abwicklungskosten – auch trotz Automatisierung

� Zwei grundlegende Alternativmodelle zur Verrechnung� Betrieb zahlt und legt Kosten über gleichmäßige

Verrechnung auf alle Nutzer des Systems um� Projekte zahlen und legen Kosten auf die Verursacher

um� Alle Projekte, die einen Regressionstest

„provozieren“� In Abhängigkeit von Verteilungsschlüsseln (siehe

nachfolgend) oder gleichmäßig verteilt



20

Regressionstest – und wer bezahlt?

� Mögliche Verteilungsschlüssel� Anzahl Projekte, die Änderungen am Anwendungssystem

durchgeführt haben� Anzahl der fachlichen Anforderungen� Entwicklungsaufwand der Anforderungen� Fachliche Größenänderung („Function Points“)� Anzahl der geänderten technischen Artefakte� Umfang der Änderungen an Artefakten� Änderungen an der Systemtopologie

� Zuschläge� Anzahl der in der Regression gefundenen Fehler� Aufwand zur Behebung der Fehler

� inkl. erneuertem Regressionstest



21

Fazit

� Regression ist nicht attraktiv – niemand kann damit „glänzen“� Regression ist aber für den Betrieb unerlässlich!� Compliance-Anforderungen steigen immer weiter

� Verantwortungsschwerpunkt für die Regression � eher auf der RTB-Seite, dort aber schwierig zu etablieren � muss von CTB-Seite mitgetragen werden� Zentralisierte Lösung optimales Modell

� Regression kostet Geld! � Die Kosten müssen auf die Verursacher gerecht verteilt werden –

das sind primär die Projekte, die ein neues Release herstellen� Wer am Ende zahlt, hängt auch vom allgemeinen Verrechnungs-

Modell der IT-Kosten ab



22

The end…

Vielen Dank für Ihre Aufmerksamkeit –

Fragen und Anmerkungen willkommen!


Documents

Wer zahlt für (Regressions-) Tests? · Retesting and regression testing All test procedures resulting in incident reports must be rerun after defect correction. Regression testing