Programm ASA2011 (Programm Agrar Sektor Administration 2011)

Transkript

1 Eidgenössisches Volkswirtschaftsdepartement EVD Bundesamt für Landwirtschaft Direktionsbereich Direktzahlungen und Ländliche Entwicklung Programm ASA2011 (Programm Agrar Sektor Administration 2011) ASA2011 Klassifizierung * Status ** Projektname Projektabkürzung Projektnummer Projektleiter Auftraggeber Autoren Genehmigende Verteiler Intern In Prüfung ASA2011 ASA2011 Dieter Wälti Christian Hofer Oliver Wittwer Projektausschuss Programmleiter, Projektausschuss * Nicht klassifiziert, Intern, Vertraulich ** In Arbeit, In Prüfung, Abgeschlossen Änderungskontrolle, Prüfung, Genehmigung Version Datum Beschreibung, Bemerkung Name oder Rolle Versand für PA Oliver Wittwer Überarbeitung nach Feedback ISCeco Oliver Wittwer Überarbeitung nach 2. Feedback AWK Oliver Wittwer Überarbeitung nach Feedback AWK Oliver Wittwer Ergänzung Inhalte, Einarbeitung Feedback Pa Oliver Wittwer Struktur und Inhaltsgerüst Oliver Wittwer ASA2011 V1.0.doc /33

2 Definitionen, Akronyme und Abkürzungen Wort Testobjekt Testart Teststufe Benutzer G2C Benutzer G2E Benutzer G2G ESB BZV Sedex DWH ETL Bedeutung Ein Testobjekt ist der Gegenstand eines Tests, der als Einheit getestet wird. Dabei kann es sich um eine einzelne Komponenten oder um ein ganzes System handelt. Die Testart bestimmt, wie resp. nach welchen Kriterien oder Qualitätsaspekten getestet wird. Pro Test können mehrere Testarten angewendet werden. Die Teststufe bestimmt den Reifegrad oder den Entwicklungsstand eines Systems: Zuerst werden die Komponenten gebaut und getestet (auf der Entwicklerplattform). Sind die Komponenten getestet, werden sie auf der Integrationsplattform zusammengebaut (integriert) und gemeinsam getestet. Sind alle Komponenten integriert, wird das ganze System getestet. Anschliessend werden sämtliche Komponenten als Release auf die Vorproduktionsumgebung deployed und abgenommen (Abnahmetests). Nach dem Deployment auf die Produktivumgebung werden die Inbetriebnahmetests durchgeführt. Benutzer Government to Customer Benutzer Government to Employee Benutzer Government to Government Enterprise Service Bus Benutzer- und Zugriffsverwaltung Secure data exchange Data-Warehouse Extract, Transform, Load, ein Prozess, der Daten aus mehreren Datenquellen in einer Zieldatenbank vereinigt Referenzen Nr. Dokument (Version, Datum) [1] Kern ASA: «Systemarchitektur», V1.3, [2] LMK-S Masterplan, V0.8, [3] ISO/IEC :2001: Software engineering -- Product quality -- Part 1: Quality model [4] ASA2011 KE Projektplan Realisierung und Einführung, V.1.0, ASA2011 V1.0.doc /33

3 Inhaltsverzeichnis 1 Einleitung Zweck des Dokuments Abgrenzung Übersicht über das Programm ASA Einführung und Ziele Termine und Organisation Architektur und Systemelemente Testvorgehen Teststrategie Grundsätze Qualitätsmodell Schwerpunkte der Tests Testobjekte Testarten Teststufen Testplattformen ISCeco Deployment-Fristen Meilensteine Testplattformen bundesexterne Um-Systeme Testablauf und Dokumentation Mängelbehebung und Änderungsbedarf Testorganisation Beteiligte Stellen Rollen und Verantwortlichkeiten Übersicht der Rollen Testmanager ASA Testverantwortlicher Projekt Zusammenarbeit Planung Testplanung Testgrobspezifikationen Berichterstattung Integration von Um-Systemen Testinfrastruktur ISCeco Abbildungsverzeichnis Abbildung 1: Der Masterplan für das LMK-S-Portfolio... 7 Abbildung 2: Verfügbarkeit der Infrastruktur (Stand Ende Mai 2010 [4])... 8 Abbildung 3: Gesamtarchitektur des Programms ASA Abbildung 4: Teststufen im V-Modell Abbildung 5: Teststufen und Meilensteine Abbildung 6: Testablauf mit den zu erstellenden Testdokumenten ASA2011 V1.0.doc /33

4 Tabellenverzeichnis Tabelle 1: Zusammenstellung der Systeme und Komponenten von ASA Tabelle 2: Qualitätsmerkmale nach ISO 9126 [3] Tabelle 3: Testobjekte im Programm ASA2011 (nach heutigem Kenntnisstand) Tabelle 4: Testarten Tabelle 5: Testarten und Testobjekt-Kategorien Tabelle 6: Beschreibung der Teststufen Tabelle 7: Teststufen und Testarten Tabelle 8: Plattformen beim ISCeco Tabelle 9: Meilensteine und Voraussetzungen (ISCeco) Tabelle 10: Meilensteine und Voraussetzungen (Um-Systeme) Tabelle 11: Überblick Testdokumente Tabelle 12: Testdokumentation auf verschiedenen Teststufen Tabelle 13: Beteiligte Stellen in der Testorganisation ASA Tabelle 14: Rollen und Verantwortlichkeiten in der Testorganisation ASA Tabelle 15: Beteiligte Stellen/Rollen auf den verschiedenen Teststufen Tabelle 16: Beispiel für die Testgrobspezifikation eines Tests ASA2011 V1.0.doc /33

5 1 Einleitung 1.1 Zweck des Dokuments Tests bilden einen wesentlichen Bestandteil der Qualitätssicherung. Sie dienen dazu, die Funktionalität von Software und Systemen an den Anforderungen und ihre Qualität zu messen, und um Softwarefehler zu ermitteln. Das beschreibt die Vorgehensweise und die Rahmenbedingungen für die Testaktivitäten im Programm ASA2011. Dabei sind die folgenden Aspekt abgedeckt: Definition der Testorganisation mit den Rollen und den damit verbundenen Aufgaben und Verantwortlichkeiten Überblick über weitere beteiligten Stellen, die im Rahmen der Tests eine Rolle spielen. Definition des Testablaufs und Vorgaben zur Testdokumentation Überblick über die mit den Tests abzudeckenden Testobjekte Überblick über die für die Tests vorgesehene Infrastruktur (Testumgebungen) Dieses Dokument dient als Grundlage für die Planung, Design, Vorbereitung, Steuerung und Durchführung sämtlicher Tests im Rahmen der Realisierung der Systeme in den Projekten Kern ASA und Acontrol im Programm ASA2011 sowie für die Integration der Um-Systeme. 1.2 Abgrenzung Das liefert keine detaillierte Planung und Spezifikation der Tests. Die Planung, das Design und die Vorbereitung der Tests inklusive der Erstellung der Testdokumentation ist Aufgabe der entsprechenden in diesem Dokument definierten Rollen und werden in der Realisierungsphase erfolgen. Die Projekte von ASA2011, die zurzeit noch in der Konzept oder Voranalyse sind (Astat-2, GIS,) werden zu einem späteren Zeitpunkt in einer aktualisierten Version des s integriert werden. ASA2011 V1.0.doc /33

6 2 Übersicht über das Programm ASA Einführung und Ziele Im Bereich der Agrarsektoradministration (Direktzahlungen, Kontrollwesen) sind verschiedene Verwaltungsstellen und private Organisationen tätig, die für ihre Aufgaben historisch bedingt unterschiedliche Informationssysteme einsetzen. Heutige Anforderungen können indes infolge heterogener Systemlandschaft, Medienbrüchen und unbefriedigender Datenqualität und -aktualität immer schwerer erfüllt werden, was das Bundesamt für Landwirtschaft (BLW) im 2006 veranlasst hat, zusammen mit den Kantonen das Programm Agrarsektoradministration 2011 (ASA2011) zu lancieren mit der folgenden Zielsetzung: 1. Vereinfachung der Administration im Agrarsektor o Vermeidung von Doppelspurigkeiten (einmalige Datenerfassung) o Koordination der Kontrollen in der Primärproduktion 2. Optimierte Datengrundlage für alle Bedarfsträger o Erhöhte Datenaktualität und verbesserte Datenqualität o Gemeinsames schweizweit vernetztes Personen- und Betriebsregister (standortbezogen) o Reduktion von Medienbrüchen 3. Aufbau eines zukunftsgerichteten Informationssystems o Optimierung des Datenaustausches o Zentrales Internetportal für Landwirte, Behörden und Organisationen Im Rahmen der Detailkonzeptphase von ASA2011 wurde eine Gesamtsystemarchitektur [1] entworfen, welche dem SOA-Ansatz folgt (s.u.). Die wichtigsten Elemente dieser Gesamtsystemarchitektur sind: Zentrales Portal ( als Zugangspunkt für alle Anwendungen im Bereich der Agrarsektoradministration Zentrale Benutzer- und Zugriffsverwaltung mit Single-Sign-On-Funktionalität Synchroner und asynchroner Intermediär für den Austausch von Daten bzw. Aufruf von Services Implementierung neuer Funktionalitäten in Form von Services Einbindung bestehender Systeme über Service-Schnittstellen 2.2 Termine und Organisation Die zeitliche Abfolge der verschiedenen Einführungen geht aus dem Masterplan von ASA2011 (s.u.) hervor, der die Basis für die Testplanung darstellt. Weitere Erläuterungen zum LMK-S-Masterplan sind in [2] aufgeführt. ASA2011 V1.0.doc /33

7 Abbildung 1: Der Masterplan für das LMK-S-Portfolio Die projektübergreifende Koordination schliesst die folgenden Vorhaben des LMK-S-Portfolios ein: Kern ASA (Projekt von ASA2011) Acontrol (Projekt von ASA2011) Integrationsprojekte HODUFLU, DBMilch, Obst.ch, TVKPlus Anbindung der Kantonssysteme Die Systemplattform für ASA2011 besteht aus den drei Umgebungen Integration, Vorproduktion und Produktion. Nachfolgender Terminplan (Abbildung 2) zeigt die Verfügbarkeit der Umgebungen. ASA2011 V1.0.doc /33

8 Integrationsplattform Aufbau Plattform Testintegration TS Performance Testing Integration Acontrol, TVKplus Tests* Maintenance der Plattform Integration AGIS Tests* Integration AGIS Tests* Integration Kantonssysteme Tests* Vorproduktionsplattform techn. Konzeption und Skalierung Betriebskonzept Aufbau Plattform Integr. AC TVK+ Deliveries Tests* Maintenance der Plattform Integration AGIS Delivery Tests* Integration AGIS Delivery Tests* Integration Kantonssystem Delivery Tests* Produktionsplattform techn. Konzeption und Skalierung Betriebskonzept Aufbau Plattform Performance Tests Staging AC TVK+ Tests* Maintenance der Plattform Staging AGIS Tests* Staging AGIS Tests* Staging Kantonss Tests* Kantonale Landwirtschaftssysteme Anpasungen XML 2010 sedex-test zu AGIS, Int. PF Tests* zu Int. PF Anpassungen XML 2011 Tests* zu V.Prod Tests* zu Prod Implementationsdesign BBS, Datenzugang Implementationsdesign AGIS (Output) AGIS-Anpassungen XML 2010 AGIS-Anpassungen XML 2011 Plattform produktiv TVKplus, AC produktiv AGIS produktiv Mai Juni Juli August September Oktober November Dezember Januar Februar März April Mai Juni Juli * Funktionale Tests, Akzeptanztests und automatisierte Performance Tests Projektausschuss Strateg Abbildung 2: Verfügbarkeit der Infrastruktur (Stand Ende Mai 2010 [4]) Die Programmorganisation ASA2011 umfasst vier Projekte (Kern ASA, Acontrol, Astat-2, GIS-ASA). Die Organisation und Durchführung der Tests erfolgt innerhalb dieser Programmorganisation und Projekte (siehe auch [4]). Die Abstimmung der Abhängigkeiten und der einzelnen Lieferungen, sowie die Planung der Detailtermine erfolgt zwischen den Teilprojekten. Die wichtigsten Partner in der Realisierungsphase sind neben dem BLW: ISCeco: Integration und Betrieb der zentralen durch den Bund betriebenen Systemkomponenten Ipt: Integration der Systeme beim ISCeco Anbieter von Kantonssystemen: Umsetzung der Schnittstellenanpassungen auf Seite der kantonalen Systeme für die Agrarsektoradministration Identitas: Entwicklung der Equidendatenbank (Projekt TVK+) Weitere Lieferanten: Entwicklungsarbeiten, Umsetzung von Anpassungen Zwischen den Teilprojekten erfolgt die Abstimmung der Abhängigkeiten und der einzelnen Lieferungen und Planung der Detailtermine. 2.3 Architektur und Systemelemente Die nachfolgende Darstellung zeigt die Gesamtarchitektur des Programms ASA2011 mit dem Portal und der Benutzer- und Zugriffsverwaltung, Acontrol und TVKplus als Neuentwicklungen und den zwei zentralen Kommunikationsintermediären ESB und sedex auf. ASA2011 V1.0.doc /33

9 Internet Benutzer G2C (z.b. Landwirte, Tierärzte, Private) SSZ ISCeco Portal Portal(e) Server Content Management Astat-2 BLW-eigene Systeme Obst.ch HODUFLU AGIS Acontrol SOA-ISvet Zentrale Dienste Datenzugang ID BBS Weitere Systeme (z.b. GIS Services) BV-Netz Benutzer G2E (Mitarbeiter BLW, BVET, BAG) DMZ (Access-Zone) Web Entry UI Server Personalisierung Administration Web Applikation Integration P UI AS WS UI AS WS UI AS AS AS AS WS WS WS WS Kontroll- Plattform Synchroner Intermediär (ESB) WS WS WS AS WS KTV-Netz Benutzer G2G (Mitarbeiter Kantone) IAMv2 AM IdM LDAP Authentisierungs- Dienste WS Web Service AM Access Management IdM AS Asynchroner Service Val Identity Management Validierung UI User Interface ID ID Mapping Service P Portlet P-ID Personen-ID Mapping Service WS Val WS P-ID ASA-BZV Privates Netz UI WS AS UI Privates Netz WS AS Asynchroner Intermediär (sedex) KTV-Netz KTV-Netz KTV-Netz WS AS UI VBS Weitere Netze WS AS BLW-nahe TVKplus DBMilch Kantonssystem SwissTopo Weitere Systeme BUR Services Systeme WS AS EDI WS AS Abbildung 3: Gesamtarchitektur des Programms ASA2011 In der nachfolgenden Übersicht sind die in Abbildung 3 dargestellten Applikationen und Komponenten erklärt (weitere Erklärungen zur Architektur sind im Dokument Kern ASA: «Systemarchitektur» [1] beschrieben). Diese Aufstellung dient als Gesamtüberblick über die in ASA2011 beteiligten Elemente und geht über den Scope dieses es hinaus. Die im Rahmen des es relevanten Elemente (Testobjekte) sind im Kapitel 3.2 in der Tabelle 3 aufgeführt. ASA2011 V1.0.doc /33

10 Komponente/System Kat 1 Beschreibung Netzwerk Portal ( N Das Portal stellt den Einstiegspunkt für alle Benutzer und den Single-Sign-On-Zugriff für die in ASA2011 integrierten Systeme dar. Benutzer- und Zugriffsverwaltung N Die Benutzer- und Zugriffsverwaltung regelt die Zugriffsrechte der Benutzer für die in agate integrierten Teilnehmersysteme. Astat-2 N Geplantes System zur Erstellung von Auswertungen. Pilotsystem AMD wird derzeit in Betrieb genommen. Obst.ch A Obst.ch ist eine bestehende Applikation zur Verwaltung von Daten aus dem Obstbau. Dazu gehört die Verwaltung von Parzellendaten und deren Bestand und die Erstellung einer jährlichen Ernteschätzung.Im Rahmen von ASA2011 wird diese Applikation in das Portal Agate integriert. HODUFLU A HODUFLU ist die bestehende Applikation zur Verwaltung von Daten aus dem Bereich Hofdünger. Dazu gehört die Verwaltung von Hofdüngerflüssen und Hofdüngerverträgen. Im Rahmen von ASA2011 wird diese Applikation in das Portal Agate integriert. AGIS A AGIS ist die bestehende Applikation zur Verwaltung von Register- (Personen- und Betriebsdaten), Struktur- und Beitragsdaten und von Direktzahlungen. In AGIS erfolgt auch die Berechnung von Beitragszahlungen. AGIS wird im Rahmen des Programms für die neue SOA-Architektur erweitert und stellt neu Services zur Verwaltung von Daten zur Verfügung. Acontrol N Acontrol ist die neue Applikation zur Verwaltung von Inspektionsdaten. Zusammen mit SOA-ISvet bildet Acontrol die neue Kontroll- Plattform. SOA-ISvet N SOA-ISvert ist die zukünftige serviceorientierte Weiterentwicklung von Kodavet. Die Applikation wird im Projekt SOA-ISvet des BVET entwickelt. Zusammen mit Acontrol bildet SOA-ISvet die neue Kontroll-Plattform. ID N Der Dienst ID wird neu entwickelt und dient zur Konvertierung von IDs verschiedener Systeme. Datenzugang N Der Dienst Datenzugang wird neu entwickelt und dient zur Freigabe des Zugangs zu bestimmten Daten für Dritte. Zum Beispiel kann mit diesem Dienst Label-Organisationen der Zugang und die Einsicht in Kontrolldaten gewährleistet werden. BBS N Der Dienst BBS wird neu entwickelt und dient zur Berechnung von Direktzahlungsbeiträgen. Weitere Systeme (1) - Zukünftige Systeme, wie z.b. GIS Services oder eine Service Provisioning Infrastruktur sollen grundsätzlich in Form von Services an den ESB und ggf. an sedex angebunden werden und in dieser Form mit den anderen Systemen interagieren. Synchroner Intermediär ESB A SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco SSZ- ISCeco Über den ESB erfolgt die Kommunikation von synchronen Nachrichten zwischen den Applikationen und Services des Pro- SSZ- ISCeco 1 Kategorie: N = System wird neu entwickelt; A = das bestehende System wird angepasst/erweitert; B = das bestehende System wird ohne funktionale Erweiterungen und Anpassungen wie bisher genutzt ASA2011 V1.0.doc /33

11 Komponente/System Kat 1 Beschreibung Netzwerk gramms ASA 2011 in Form von Webserviceaufrufen. Der ESB besteht und wird für ASA 2011 als Kommunikationsbus genutzt. Anpassungen können sich im Bereich Zugriffskontrolle ergeben. Asynchroner Intermediär sedex A Der asynchrone Intermediär sedex wird zum asynchronen Versand sehr grosser Nachrichten (bis 100 MB) zwischen den Applikationen und Services des Programms ASA 2011 verwendet.sedex besteht und wird für ASA 2011 als Kommunikationsbus genutzt. Erweiterungen sind mittelfristig im Bereich sedex Web Service Proxy nötig (Unterstützung von WS-Security und Aufruf beliebiger Web Services). SSZ- ISCeco TVKplus N TVD ist die bestehende Applikation zur Verwaltung der Daten aus der Tierhaltung. TVKplus ist als Nachfolgeapplikation die neue Applikation zur Verwaltung von Tierverkehrsdaten und wird neu entwickelt. Im Rahmen von ASA 2011 wird diese Applikation in das Portal Agate integriert. DBMilch A DBMilch ist die bestehende Applikation zur Verwaltung der Daten aus der Milchwirtschaft. Dazu gehört die Verwaltung von Milchmengen und Milchkaufverträgen. Im Rahmen von ASA 2011 wird diese Applikation in das Portal Agate integriert. Kantonssystem A Es gibt die fünf verschiedenen Kantonssysteme, die grundsätzlich denselben Zweck haben. Sie dienen zur Erfassung der Register- (Personen- und Betriebsdaten), Struktur- und Beitragsdaten als Basis zur Kalkulation der Direktzahlungen. Die Systeme sind: Agricola Agridea GELAN LAWIS System Wallis Die Kantonssysteme treten mittelfristig als Service Consumer auf. So nutzen sie z.b. Services, die AGIS zur Verwaltung der Strukturdaten einsetzt. Desweiteren werden sie in den Single-Sign-On-Verbund des Portals Agate integriert. SwissTopo Services B Von SwissTopo bereitgestellte Web-Services, die z.b. zum Bezug von Kartenmaterial für GIS Anwendungen genutzt werden könnten. BUR A Das vom BFS bereitgestellte BUR (Betriebs- und Unternehmensregister) kann einerseits mit landwirtschaftlichen Registerdaten beliefert werden, andererseits können Registerdaten und insbesondere die BUR-Nummer bezogen werden. Im EVD werden die Datenabfragen aus BUR über die Einheitsschnittstelle BUDIS zentral organisiert. BUDIS hält keine eigenen Daten sondern cashed die BUR-Daten und bietet darauf gewisse Auswertungsservices an. Weitere Systeme (2) - In diese Kategorie fallen z.b. Labelorganisationen, die via Services Zugriff auf ausgewählte Informationen erhalten. Tabelle 1: Zusammenstellung der Systeme und Komponenten von ASA2011. Privates Netz Privates Netz KTV-Netz VBS EDI Weitere Netze ASA2011 V1.0.doc /33

12 3 Testvorgehen Das in diesem Kapitel beschriebene Testvorgehen gibt eine Vorgabe für die Strukturierung der Tests, die im Rahmen der Realisierung durchgeführt werden sollen. Die einzelnen Tests sind aufgrund dieses es von den verantwortlichen Rollen im Rahmen der Realisierung im Detail zu planen, vorzubereiten und durchzuführen. Ein Test bezieht sich dabei auf ein Testobjekt (Kapitel 3.2). Ein Testobjekt wird im Rahmen eines Tests als Einheit getestet. Bei einem Test werden dabei einer oder mehrere Testarten (Kapitel 3.3) angewendet, die unterschiedliche Qualitätsaspekte des Testobjektes überprüfen. Ein Test folgt dabei einem vordefinierten Testablauf und muss gemäss Vorgaben dokumentiert werden (Kapitel 3.7). Die Realisierung des Systems erfolgt in Entwicklungsschritten auf verschiedenen Plattformen. Der jeweils folgende Entwicklungsschritt erfolgt, nachdem das System einen bestimmten Reifegrad erreicht hat. Die Reifegrade werden durch Teststufen (Kapitel 3.4) definiert und getestet (Staging). In Zusammenhang mit der Integration der bundesexternen Um-Systeme wie TVKplus und der Kantonssysteme fallen die Interoperabilitäts- und Integrationstests in den Zuständigkeitsbereich des BLW, während für Überprüfung der Anpassungen (Komponenten- und Systemtests) der jeweiligen Systemauftraggeber verantwortlich ist. 3.1 Teststrategie Grundsätze Die Komplexität des Programms ASA2011, der enge Zeitrahmen für die Realisierung, sowie die neuen Architekturvorgaben (SOA) stellen sehr hohe Herausforderungen an die Realisierungspartner. Insbesondere die grosse Anzahl zu realisierenden und anzubindenden Komponenten, sowie die Anzahl der beteiligten Partner erfordern es, dass während der Integration ein zügiges und flexibles Testen möglich ist. In dieser Stufe wird daher für die Dokumentation der Tests ein pragmatischer Ansatz gewählt, bei dem nur ein Minimum an Dokumenten gefordert wird. Bei den Systemtests, Abnahmetests und Inbetriebnahmetests wird dagegen eine formellere Testdokumentation gefordert. Die Voraussetzung für die Meilensteine zwischen den verschiedenen Teststufen des Entwicklungs- und Integrationsprozesses (Kapitel 3.5.2) müssen auf allen Stufen strikt eingehalten werden. Dies verhindert, dass Stufen vermischt oder übersprungen werden. ASA2011 V1.0.doc /33

13 3.1.2 Qualitätsmodell Bei sämtlichen Tests sollten sich die Testaspekte nach den Qualitätsmerkmalen gemäss dem Standard ISO 9126 orientieren. Der Standard stellt ein Modell dar, das die Qualitätskriterien von Software beschreibt. Die Qualitätsmerkmale sind in der folgenden Tabelle aufgelistet: Qualitätsmerkmale nach ISO 9126 Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit (Betreibbarkeit) Übertragbarkeit Teilmerkmale Angemessenheit Richtigkeit Interoperabilität Sicherheit Ordnungsmäßigkeit Reife Fehlertoleranz Robustheit Wiederherstellbarkeit Konformität Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Konformität Zeitverhalten Verbrauchsverhalten Konformität Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit Anpassbarkeit Installierbarkeit Koexistenz Austauschbarkeit Konformität Tabelle 2: Qualitätsmerkmale nach ISO 9126 [3] Schwerpunkte der Tests Im Programm ASA2011 gibt es eine Vielzahl von Systemkomponenten, die von verschiedenen Partnern entwickelt oder angepasst werden, und zwischen denen ein Austausch von Daten stattfinden wird. Ein Hauptziel sämtlicher Tests ist der Nachweis, dass die Anforderungen sowohl funktionale als auch nichtfunktionale erfüllt sind. Dies ist die grundlegende Voraussetzung, dass das spätere System seine Aufgaben zuverlässig erfüllen kann. Da Teile des Systems mit grossen Datenmengen und Datenflüssen operieren werden, ist es besonders wichtig, dass allfällige Performance-Engpässe frühzeitig erkannt und behoben werden können. Aus diesem Grund müssen Performance-Aspekte bei allen Tests der performancerelevanten Teile besonders beachtet und explizit getestet werden. ASA2011 V1.0.doc /33

14 3.2 Testobjekte Unter Testobjekte werden Teile von Systemen oder Systeme verstanden, die als Einheit getestet werden. Ein Testobjekt ist der zu prüfende Gegenstand, der im Rahmen eines Tests geprüft wird. Je nach Art des Testobjekts werden sehr unterschiedliche Testaspekte in verschiedenen Testarten (siehe Kapitel 3.3) geprüft. Es können die folgenden fünf Testobjekt-Kategorien unterschieden werden: Infrastruktur: Unter Infrastruktur werden alle physischen Systeme (Server, Datenspeicher Netzwerkkomponenten) mit der für ihren Betrieb notwendigen Betriebssysteme und Software verstanden. Systeme, Anwendungen und Services: Unter Systemen, Anwendungen und Services werden individuelle Software-Entwicklungen oder Standard-Softwarelösungen verstanden, die als Teilsysteme oder Komponenten im Gesamtsystem eingesetzt werden. Systeme müssen als Verbund von Komponenten oder Teilsysteme als Ganzes getestet werden, um die Erfüllung der Anforderungen an das System als auch die korrekte Unterstützung der Geschäftsprozesse (aus Sicht Benutzer) zu gewährleisten. Daten: Unter Daten werden sämtliche Datenbestände oder Datenbanken verstanden, die im Rahmen der Realisierung oder zum Betrieb der Systeme benötigt werden und aktiver Bestandteil der Systeme sind. Zur Testobjekt-Kategorie Daten gehören auch Testdaten, die im Rahmen der Realisierung benötigt werden. Konfigurationsdaten von Applikationen oder Systemen gehören nicht zur Testobjekt-Kategorie Daten. Sie sind Bestandteile der jeweiligen Applikation. Datenflüsse und IT-Prozesse: Bei komplexeren Systemen oder Lösungen, die aus mehreren eigenständigen Teilsystemen oder komplexen Komponenten bestehen, werden einzelne Datenflüsse oder IT-Prozesse als eigenständige Testobjekte betrachtet. Sie müssen separat getestet werden, da die korrekte Funktionsweise der einzelnen Teilsysteme oder Komponenten keine Garantie für das Funktionieren dieser Datenflüsse oder IT-Prozesse bietet. Zu Datenflüsse und IT-Prozesse gehören insbesondere Daten und Systeme von anderen Anbietern/Projekten, die an die zu realisierenden Systeme angebunden oder integriert werden. Um-Systeme: Bei Um-Systemen handelt es sich um bestehende Anwendungen und Systeme, die an die Systeme von ASA2011 angebunden oder in diese integriert werden müssen. Die im Programm ASA2011 identifizierten Testobjekte sind in der folgenden Tabelle unter Angabe des für die Realisierung verantwortlichen Projektes, des Lieferanten und der realisierungsverantwortlichen übergeordneten Stelle aufgelistet. Diese Auflistung entspricht dem heutigen Kenntnisstand. Sie dient lediglich als Planungsbasis für die durchzuführenden Tests. Es liegt in der Verantwortung der entsprechenden Rollen, bei der Testplanung und Testvorbereitung die geeigneten Testobjekte zu definieren und in den Tests zu berücksichtigen, was eine Verfeinerung oder Erweiterung dieser Auflistung nicht ausschliesst. ASA2011 V1.0.doc /33

15 Testobjekt Projekt Lieferant Realisierungsverantwortliche Stelle Infrastruktur ESB egov RAI ISCeco GS EVD / ISCeco Applikationsserver egov RAI ISCeco GS EVD / ISCeco Portal Kern ASA <offen> BLW BZV Kern ASA <offen> BLW Sedex Kern ASA BFS BLW DWH, ETL Astat2 IBM BLW Systeme, Anwendungen und Services Acontrol Acontrol BEDAG BLW BZV Kern ASA <offen> BLW Portal Agate Kern ASA <offen> BLW Portlet(s) Acontrol Acontrol Bedag BLW Erweiterungen ISVet für Acontrol Acontrol Bedag BVET BurWeb Kern ASA BFS/BIT BFS Cognos-Auswertungen Astat2 IBM BLW BBS Kern ASA <offen> BLW Zugang Dritte Kern ASA <offen> BLW ID-Mapping-Service Kern ASA <offen> BLW Agrardatenerfassungsservice GIS <offen> BLW AGIS Kern ASA ITpearls BLW Portlets mit Agate-Inhalten Kern ASA <offen> BLW Services zur Verwaltung der Benutzerdaten Kern ASA <offen> BLW GUI zur Verwaltung der Benutzerdaten Kern ASA <offen> BLW Daten Benutzerdaten Kern ASA Kern ASA BLW Geoinformationen GIS <offen> BLW AGIS Register- und Strukturdaten Kern ASA Kern ASA BLW Datenflüsse und IT-Prozesse Registerdaten: KS -> AGIS -> BUR Kern ASA <offen> BLW Authentisierung und Autorisierung Kern ASA <offen> BLW (SSO) Benutzerverwaltungsprozesse Kern ASA <offen> BLW Strukturdaten, Beitragsdaten: KS -> Kern ASA <offen> BLW AGIS Supportprozesse, Help Desk <offen> <offen> BLW Acontrol (Portal- und BZV-Integration) Acontrol Bedag BLW Um-Systeme Anpassung (und Integration) Kantons- Kantonsprojekte Kantonssystem- Kantone (BLW) ASA2011 V1.0.doc /33

16 Testobjekt Projekt Lieferant Realisierungsverantwortliche Stelle systeme (Portal- und BZV-Integration, Sedex-Anbindung) TVKplus (und Portal- und BZV- Integration) (Kern ASA) TVKplus (Kern ASA) lieferanten (Integration: Kern ASA) Identitas Obst.ch (Portal- und BZV-Integration) Integrationsprojekt <offen> BLW Hoduflu (Portal- und BZV-Integration) Integrationsprojekt <offen> BLW AMD (Portal- und BZV-Integration) Integrationsprojekt <offen> BLW DBMilch (Portal- und BZV-Integration) Integrationsprojekt TSM Treuhand BLW 3.3 Testarten Identitas (BLW) Tabelle 3: Testobjekte im Programm ASA2011 (nach heutigem Kenntnisstand). Je nach Art des Testobjektes werden unterschiedliche Schwerpunkte in den Test gesetzt, wobei diese sich nach dem Qualitätsmodell im Kapitel richten. Zur Abdeckung verschiedener Schwerpunkte werden Testarten definiert. Die Testart gibt vor, wie das Testobjekt getestet werden soll, d.h. nach welchen Aspekten und mit welchen Methoden. In der Tabelle 4 sind die im Programm einzusetzenden Testarten beschrieben: Testart Funktionaler Test Interoperabilitätstest Benutzerschnittstellentest Performancetest Sicherheitstest Schnittstellentest Wiederinbetriebnahmetest Installationstest Regressionstest Beschreibung Überprüft bei einem Testobjekt die Erfüllung der funktionalen Anforderungen. Zu den funktionalen Anforderungen gehören sämtliche Anforderungen, die definieren, WAS das Testobjekt tun soll. Testet die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz mehrerer Komponenten. Diese Testart ist insbesondere auch bei der Anbindung von Um-Systemen wichtig. Testet die Benutzerschnittstelle des Systems auf Korrektheit, Vollständigkeit, Bedienbarkeit und Stabilität. Mit Performancetests werden die Antwortzeiten des Systems von verschiedenen Use Cases unter verschiedenen Belastungsprofilen (bestimmte Anzahl User im Normalbetrieb, bei Hochbetrieb, usw.) gemessen. Mit den sen kann die Erfüllung oder Nicht-Erfüllung der Anforderungen oder Vertragsbedingungen bezüglich Mengengerüste/Performance nachgewiesen werden. Mit den Tests können auch das Systemverhalten unter besonders hohen Speicher-, CPU-, o.ä. -Anforderungen analysiert werden (Lasttest). Testet ein System gegen potentielle Sicherheitslücken. Testet die Funktionalität der Schnittstelle gegen ihre Spezifikation ohne Beteiligung der abhängigen Komponenten und/oder unter Beteiligung eines Simulators, der die anderen beteiligten Komponenten oder Systeme simuliert. Testet ob ein System nach einem Abschalten oder Zusammenbruch (z.b. ausgelöst durch Stresstest) wieder in Betrieb genommen werden kann. Testen der Softwareinstallationsroutinen ggf. in verschiedenen Systemumgebungen (z.b. verschiedene Hardware oder unterschiedliche Betriebssystemversionen). Eine Regressionstest oder auch Fehlernachtest kommt nach der Behebung von Mängeln oder Korrektur von Fehlern zum Einsatz. Er prüft, ob die Mängel/Fehler behoben wurden und das System mit den geänderten Modulen funktioniert. Tabelle 4: Testarten. ASA2011 V1.0.doc /33

17 Die verschiedenen Testarten lassen sich grundsätzlich den Testobjekt-Kategorien zuordnen. Funktionale Tests kommen dabei in jeder Kategorie zum Einsatz, da an jede Testobjekt-Kategorie bestimmte Anforderungen festgelegt wurden. Tabelle 5 zeigt, welche Testarten bei welchen Testobjekt-Kategorien schwerpunktmässig zur Anwendung gelangen: Funktionaler Test Testobjekt-Kategorie* Infrastruktur Systeme, Anwendungen und Services Daten Datenflüsse und IT-Prozesse Um-Systeme (Anpassung) Um-Systeme (Integration) * Tests gleicher Art unterscheiden sich je nach Stufe wesentlich. Z.B. richten sich Funktionale Tests nach den Anforderungen der entsprechenden Testobjekt-Kategorie. 3.4 Teststufen Interoperabilitätstest Benutzerschnittstellentest Performancetest Sicherheitstest Tabelle 5: Testarten und Testobjekt-Kategorien. Die Realisierung der Systeme erfolgt schrittweise: Zuerst werden einzelne Komponenten und Schnittstellen gebaut und getestet. Danach erfolgt der Zusammenbau dieser Komponenten zu Teilsystemen und/oder Gesamtsystemen. Diese werden anschliessend als Ganzes getestet. Um diese Realisierungsschritte und die damit verbundenen Tests zu strukturieren, wird nach dem V-Modell (Abbildung 4) vorgegangen. Dabei durchlaufen die Komponenten, Teilsysteme und Systeme vier verschiedene Teststufen, die sich nach dem Integrations- und Reifegrad des Systems richten. Die Teststufen sind in der Tabelle 6 beschrieben: Schnittstellentest Wiederinbetriebnahmetest Installationstest Regressionstest ASA2011 V1.0.doc /33

18 Teststufe Beschreibung Verantwortlich Komponententest Der Komponententest, auch Modultest oder Unit Test genannt, ist ein Test auf der tiefsten Ebene. Dabei werden einzelne Komponenten auf korrekte Funktionalität getestet. Häufig wird der Modultest durch den Lieferanten durchgeführt. Die Testobjekte sind einzelne abgegrenzte Module, also Unterprogramme, Units oder Klassen. Lieferant Integrationstest Systemtest Abnahmetest Inbetriebnahmetest Im Integrationstest oder Interaktionstest wird die Zusammenarbeit voneinander abhängiger Komponenten getestet. Die Testobjekte sind Teilsysteme oder ein Komponentenverbund. Beim Systemtest steht die Funktionalität des Systems als Ganzes im Vordergrund. Dabei wird geprüft, ob alle Komponenten und Schnittstellen des Systems korrekt zusammenarbeiten. Beim Abnahmetest wird das gesamte System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet. Dabei wird auch die Unterstützung der Geschäftsprozesse durch das System verifiziert. Der Abnahmetest ist der letzte Schritt vor Produktivschaltung des Systems. Der Inbetriebnahmetest ist der letzte Test nach der Installation des Systems auf der Produktionsumgebung. Er verifiziert, dass das System als Gesamtes funktioniert und in Betrieb genommen werden kann. Tabelle 6: Beschreibung der Teststufen. Integrator Integrator Projekt Betreiber Abbildung 4: Teststufen im V-Modell. ASA2011 V1.0.doc /33

19 Die Anwendung verschiedener Testarten kann grob den Teststufen zugeordnet werden. Diese Zuordnung ist jedoch keine verbindliche Vorgabe, sondern stellt nur einen Anhaltspunkt dar: Funktionaler Test Interoperabilitätstest Benutzerschnittstellentest Teststufe* Komponententest Integrationstest Systemtest Abnahmetest Inbetriebnahmetest * Tests gleicher Art unterscheiden sich je nach Stufe wesentlich. Z.B. richten sich Funktionale Tests nach den Anforderungen auf der entsprechenden Stufe. 3.5 Testplattformen ISCeco Performancetest Sicherheitstest Schnittstellentest Tabelle 7: Teststufen und Testarten. Beim ISCeco finden die Teststufen auf verschiedenen Plattformen (Test- und Systemumgebungen) statt. Die eingesetzten Plattformen sind in der folgenden Tabelle beschrieben: Plattform Beschreibung Verantwortlich Teststufen Entwicklungsumgebung Integration Vorproduktion Produktion Auf der Entwicklungsumgebung werden die Systemkomponenten und Applikationen entwickelt. Die Bereitstellung der Entwicklungsumgebung ist Sache des jeweiligen Lieferanten. Die Integrationsumgebung bildet die erste Stufe der Systemintegration. Sie wird beim Systembetreiber betrieben. Auf der Integrationsumgebung wird einerseits die Zusammenarbeit verschiedener Komponenten getestet, andererseits das System zusammengebaut. Hier werden auch die Releases für die Vorproduktionsumgebung erstellt. Auf der Vorproduktionsumgebung wird das Gesamtsystem lauffähig installiert und getestet. Dabei werden bereits produktionsnahe Bedingungen angestrebt. Es wird mit produktiven Daten gearbeitet und die Umgebung entspricht grundsätzlich der Produktionsumgebung. Die Produktionsumgebung ist die Umgebung, auf der das System später betrieben wird. Tabelle 8: Plattformen beim ISCeco. Wiederinbetriebnahmetest Installationstest Lieferanten (BEDAG, ) Integrator (ISCeco) Betreiber (ISCeco) Betreiber (ISCeco) Regressionstest Komponententests Integrationstests Systemtests Abnahmetests Inbetriebnahmetests ASA2011 V1.0.doc /33

20 3.5.1 Deployment-Fristen Bei ASA2011 handelt es sich um ein komplexes System mit vielen Komponenten und beteiligten Parteien. Insbesondere die Integration stellt eine Herausforderung in den Projekten dar. Daher muss die Vorbereitung und Durchführung möglichst flexibel und rasch erfolgen können. Die mit dem Deployment einer Systemkonfiguration auf der Vorproduktionsumgebung verbundenen Tests verlaufen dagegen formeller (siehe Tabelle 12 im Kapitel 3.4). Aufgrund dieses wesentlichen Unterschiedes werden für die verschiedenen Plattformen unterschiedliche Deployment-Fristen festgelegt. Sie erlauben es der testenden Partei, nach Anmeldung eines Tests innerhalb dieser Frist eine für den Test passende Konfiguration auf der entsprechenden Plattform bereitgestellt zu bekommen. Das ISCeco, das die Plattformen zur Verfügung stellt, ist verpflichtet, innerhalb dieser Fristen die Plattform entsprechend vorzubereiten und anschliessend die Tests wenn nötig zu unterstützen. Die Deployment-Fristen sind wie folgt angesetzt: Integrationsumgebung: 5 Arbeitstage Vorproduktionsumgebung: 10 Arbeitstage Meilensteine Mit Hilfe der Teststufen soll verifiziert werden, dass das System einen bestimmten Reifegrad erreicht hat. Die Erreichung des jeweiligen Reifegrades gilt als Meilenstein. Es gibt vier Meilensteine. Erst nach Erreichung eines Meilensteines kann die nächste Teststufe freigegeben werden. Mit der Freigabe der nächsten Teststufe ist meistens ein Wechsel der Umgebung verbunden. Die Abbildung 5 zeigt den Realisierungsprozess über die Teststufen auf den verschiedenen Umgebungen mit den dazugehörigen Meilensteinen. Abbildung 5: Teststufen und Meilensteine. ASA2011 V1.0.doc /33

21 An die Erreichung der Meilensteine sind Bedingungen geknüpft. Diese sind in der folgenden Tabelle angegeben: Was Alle Teststufen Meilenstein 1 Meilenstein 2 Meilenstein 3 Meilenstein 4 Voraussetzungen Sämtliche Tests auf der aktuellen Teststufe sind durchgeführt und dokumentiert Die Testprotokolle sind abgenommen und freigegeben Die einzelnen Komponenten und Schnittstellen erfüllen die an sie gestellten funktionale und nichtfunktionalen Anforderungen Die Integration sämtlicher Komponenten ist erfolgreich durchgeführt (erfolgreiche Integrationstests) Das System funktioniert als Ganzes (erfolgreiche Systemtests) Bereinigte Mängellisten Die für die nächste Stufe zu installierende Konfiguration ist definiert Beschlossene Changes sind dokumentiert Die Abnahme des Systems wurde durchgeführt Die Testbericht liegt vor und empfiehlt die Freigabe der nächsten Stufe Das System liegt in einem definierten Release vor Beschlossene Changes sind dokumentiert Das System ist erfolgreich auf der Produktionsplattform installiert und konfiguriert Der Inbetriebnahmetest wurde erfolgreich durchgeführt (Sämtliche Komponenten laufen und arbeiten korrekt zusammen) Tabelle 9: Meilensteine und Voraussetzungen (ISCeco). 3.6 Testplattformen bundesexterne Um-Systeme Die Bereitstellung geeigneter Testplattformen für Test und Abnahme der bundesexternen Um-Systeme liegt in der Verantwortung der jeweiligen Betreiber bzw. Auftraggeber. Sie sorgen dafür, dass Interoperabilitäts- bzw. Integrationstests ihres Systems mit weiteren Systemen in der Integrationsumgebung des ISCeco in einer Test-/Integrationsumgebung durchgeführt werden können; vorgängig dazu System- und Schnittstellentests erfolgreich durchgeführt worden sind. In Anlehnung an Tabelle 9 gelten folgende Meilensteine: Was Alle Teststufen Meilenstein 1 Meilenstein 2 Meilenstein 3 Meilenstein 4 Voraussetzungen Sämtliche Tests auf der aktuellen Teststufe sind durchgeführt und dokumentiert Die Testprotokolle sind abgenommen und freigegeben Die einzelnen Komponenten und Schnittstellen erfüllen die an sie gestellten funktionalen und nichtfunktionalen Anforderungen Die Integration sämtlicher Komponenten ist erfolgreich durchgeführt (erfolgreiche Integrationstests) Das System funktioniert als Ganzes (erfolgreiche Systemtests) Die für die nächste Stufe zu installierende Konfiguration ist definiert Die Abnahme des Systems wurde durchgeführt Das System liegt in einem definierten Release vor Das System ist erfolgreich auf der Produktionsplattform installiert und konfiguriert Der Inbetriebnahmetest wurde erfolgreich durchgeführt Tabelle 10: Meilensteine und Voraussetzungen (Um-Systeme). ASA2011 V1.0.doc /33

22 3.7 Testablauf und Dokumentation Alle Tests werden grundsätzlich dokumentiert. Der Umfang der Dokumentation richtet sich nach der Teststufe (siehe Tabelle 12). Die Dokumentation beginnt dabei zumeist bereits bei der Planung der Testaktivitäten. Der Testablauf mit seinen n und den pro zu erstellenden Dokumenten ist in der folgenden Abbildung dargestellt. Die Beschreibung dieser Dokumente ist in der Tabelle 11 gegeben. Abbildung 6: Testablauf mit den zu erstellenden Testdokumenten. Lieferobjekt Beschreibung Abdeckung Testplan mit Testgrobspezifikationen Testspezifikation Testdrehbuch Testprotokoll Testbericht Mängelliste Im Testplan werden die Tests mit den zu untersuchenden Testobjekten und den anzuwendenden Testarten, die involvierten Personen, der Ressourcenbedarf und die Termine festgelegt. Der Testplan muss die Testgrobspezifikationen für jeden Test enthalten (siehe Kapitel 4.4.2) Die Testspezifikation definiert die Testfälle, die Testumgebung, die Testmethoden, Prüfvorschriften und die Abgrenzung zu anderen Tests Das Testdrehbuch beinhaltet Detailangaben zur Vorbereitung, Durchführung und Nachbearbeitung der Tests in Form einer Arbeitsanleitung mit der detaillierten Beschreibung der Testfälle und den einzelnen Testschritten. Das Testprotokoll enthält die vom Tester verfassten Aufzeichnungen über den Verlauf der Tests, vor allem die Gegenüberstellung von erwartetem und erzieltem. Aus dem Testprotokoll muss ersichtlich sein, welche Anforderungen getestet wurden und ob die Anforderungen erfüllt wurden. Der Testbericht beinhaltet zu einem oder mehreren Tests die Zusammenfassung der Testaktivitäten und Testergebnisse, die Bewertung der Tests, Konsequenzen, sowie Empfehlung zum weiteren Vorgehen. Die Mängelliste fasst die Fehler aus den Testprotokollen zusammen. Sie ist eine Aufgabenliste für den Lieferanten, in der er den Behebungsstatus für jeden Fehler erfassen kann. Tabelle 11: Überblick Testdokumente. Pro Projekt/Teilprojekt Pro Test Pro Test Pro testende Person und Test Pro Projekt/Teilprojekt Pro Projekt/Teilprojekt ASA2011 V1.0.doc /33

23 Der Formalitätsgrad der Tests wächst mit den Teststufen. Auf der Teststufe Komponententests ist es zum Beispiel nicht notwendig, ein Testdrehbuch für jeden Test zu erstellen. Auf den höheren Stufen ist eine vollständige Dokumentation wichtig. Welche Dokumente auf welcher Teststufe zu erstellen sind, zeigt die folgenden Tabelle: Testplan Testspezifikation Testdrehbuch Testprotokoll Testbericht Mängelliste Teststufe Bemerkungen Komponententest Bei den Komponententests dokumentiert das Testprotokoll die durchgeführten Tests Cases. Es weist nach oder bestätigt, dass die Komponente alle Anforderungen erfüllt und keine Fehler mehr nachgewiesen werden konnten. Integrationstest 1 3 Um Flexibilität und kurze Reaktionszeiten bei den Integrationstests zu erlauben, wird auf die Erstellung der Testspezifikation und des Testdrehbuchs verzichtet. Dafür ist die Erstellung der Testgrobspezifikationen im Rahmen der Testplanung umso wichtiger, ebenfalls der Nachweis der durchgeführten Test Cases und der Testresultate im Testprotokoll. Systemtest Die Tests auf diesen Teststufen erfordern eine systematische Vorbereitung. Daher wird eine formelle Abnahmetest Dokumentation gefordert. Sollten Dokumente zusammengefasst erstell werden, muss trotzdem er- Inbetriebnahmetest sichtlich sein, wie die Anforderungen getestet wurden. 1 Das Dokument ist nur einmal zu erstellen und beinhaltet alle geplanten Tests mit den Testgrobspezifikationen für das entsprechende System. 2 Die Dokumente können ggf. zusammengefasst in einem Dokument erstellt werden. 3 Falls Mängel aufgetreten sind, die nicht behoben werden konnten. Tabelle 12: Testdokumentation auf verschiedenen Teststufen. Trotz Verzicht auf die formelle Dokumentation mittels Testspezifikation und Testdrehbuch auf den Teststufen Komponententests und Integrationstests ist es wichtig, dass die Tests sauber vorbereitet werden und sämtliche zu testenden Aspekte bereits vor den Tests bekannt sind. Die vollständige Identifizierung der zu testenden Eigenschaften und Abdeckung durch die Tests ist zwingend notwendig, um das Risiko für später auftretende Fehler zu minimieren. ASA2011 V1.0.doc /33

24 3.8 Mängelbehebung und Änderungsbedarf Mängel, die im Rahmen von Komponenten- und Integrationstests entdeckt werden, werden von den entsprechenden Verantwortlichen selbständig behoben. Es wird vorausgesetzt, dass zum Zeitpunkt der Integration der Komponenten und Schnittstellen (nach Abschluss der Komponententests) die Komponenten fehlerlos arbeiten, und dass bei den Systemtests (nach den Integrationstests) die Integration der Komponenten keine Probleme bereitet. Die Behebung von Mängeln muss daher durch Regressions- oder Nachtests selbständig durch die Verantwortlichen verifiziert werden. Änderungen an Komponenten und geänderte Testund Systemkonfigurationen sind im Rahmen des Konfigurationsmanagement sauber zu dokumentieren. Mängel, die im Rahmen von Abnahmetests identifiziert werden, werden in einer konsolidierten Mängelliste dokumentiert. Der Testverantwortliche Projekt ist verantwortlich für eine geordnete Mängelbehebung, die damit verbundene Release-Planung, ein sauberes Change Management, und die Planung und Umsetzung von Nach- oder Regressionstests. Für die Mängelerfassung wird die folgende Klassifikation verwendet: Kritisch: Ein Fehler, der den Betrieb, die Weiterverarbeitung von Daten verhindert oder weitere Tests unterbindet. Schwer: Ein Fehler, der den produktiven Betrieb stark behindert. Gering: Ein Fehler, mit dem ein produktiver Betrieb mit leichter Behinderung möglich ist. Nebensächlich: Ein Fehler, der den produktiven Betrieb nicht behindert. Die konsolidierte Mängelliste wird mit dem Lieferant besprochen und es muss eine Lösung zum weiteren Vorgehen und zur Mängelbehebung gefunden werden. Im jeweiligen Projekt oder Teilprojekt muss eine Eskalationsstelle festgelegt werden. Eine Eskalation an diese Stelle ist dann notwendig, wenn eine fristgerechte Mängelbehebung der kritischen und schweren Fehler nicht möglich ist, kritische oder schwere Mängel nicht behebbar sind, die Mängelbehebung nicht im Rahmen der vereinbarten Kosten möglich ist. ASA2011 V1.0.doc /33

25 4 Testorganisation 4.1 Beteiligte Stellen Im Programm ASA2011 sind diverse Stellen (Firmen und Organisationen) beteiligt. Ihre Aufgaben in der Testorganisation sind in der folgenden Tabelle zusammengefasst. Die in den Aufgabenbeschreibungen bezeichneten Rollen (kursiv) sind im nachfolgenden Kapitel beschrieben. Organisation/ Firma BLW Bereich Fach- Teilprojekte Aufgabe in der Testorganisation ASA2011 Das BLW ist Auftraggeber und stellt die Projektleiter der Projekte. Sie sind verantwortlich für die fachlichen Belange der Systeme, insbesondere die fachlichen Aspekte bei der Vorbereitung, Durchführung und Auswertung der Tests auf Stufe Abnahmetest. AWK IT-Teilprojekte AWK unterstützt das BLW in den Projekten als IT-Spezialisten. Die IT- Teilprojekte sind verantwortlich für die Besetzung der Rollen Testverantwortlicher Projekt in den Projekten. Der Testverantwortliche Projekt ist für die gesamten Testaktivitäten auf Stufe Abnahmetest und Inbetriebnahmetest verantwortlich. AWK stellt die Rolle des Integrations- und Systemtestverantwortlichen zur Verfügung, der im Rahmen der Testorganisation verantwortlich ist für die Planung, Design, Vorbereitung und Durchführung der Integrationstests und der Systemtests. Zu den Aufgaben dieser Rolle gehören auch die Einsatzplanung für die Tests, die Spezifikation der Testkonfiguration und die Abstimmung mit den testenden Parteien. Die Rolle des Testmanagers ASA2011 wird durch AWK gestellt. BLW ipt Umsetzungskoordinatorin Teilprojekt Integration Die UK stellt auf der Kommunikations- und Koordinationsebene das Bindeglied zwischen dem Programm ASA2011 und den Kantonen dar. Sie wird nach Bedarf unterstützt durch die IT-Teilprojekte, das Teilprojekt Integration und den Testmanager ASA2011 Ipt ist als Integrator verantwortlich für die Integration der Systeme auf der Integrationsumgebung. ISCeco Betreiber Das ISCeco ist als Betreiber verantwortlich für den produktiven Betrieb der Systeme. Es stellt dafür die Vorproduktionsumgebung und die Produktionsumgebung bereit. Zur Verantwortung gehören auch das Deployment von Releases und die Vorbereitung und Durchführung von Inbetriebnahmetests. Für die Integrations- und Systemtests stellt das ISCeco die Integrationsumgebung zur Verfügung und ist für deren Betrieb und die Bereitstellung der Testkonfigurationen verantwortlich. <offen> Lieferant Portal Der Lieferant Portal ist verantwortlich für die Realisierung des Portals. <offen> Lieferant BZV Der Lieferant BZV (Benutzer- und Zugriffsverwaltung) ist verantwortlich für die Realisierung des Systems für die Benutzer- und Zugriffsverwaltung. Bedag Diverse Lieferant Acontrol Anbieter Kantonssysteme Bedag realisiert die zentralen Komponenten für das System Acontrol. Sie ist verantwortlich für die Entwicklungsplattform und für die Tests auf Stufe Komponententests (stellen der Rolle Testbeauftragter Lieferant und Tester). Auf Stufe Integrationstest und Systemtest stellt sie die nötigen Ressourcen zur Unterstützung der Testaktivitäten zur Verfügung. Die diversen Anbieter der anzupassenden Kantonssysteme (LAWIS, GE- LAN, AGRICOLA, AGRIDEA, VS) sind verantwortlich für die Anpassung und Anbindung dieser Systeme an die Systeme von ASA2011. ASA2011 V1.0.doc /33

26 Organisation/ Firma Bereich Betreiber Kantonssysteme Aufgabe in der Testorganisation ASA2011 Die diversen Betreiber der anzupassenden Kantonssysteme sind verantwortlich für den Betrieb dieser Systeme und die korrekte Zusammenarbeit mit den Systemen von ASA2011. IT Pearls Lieferant AGIS Der Lieferant AGIS ist verantwortlich für die Anpassungen am System AGIS. Identitas Lieferant und Betreiber TVKplus Der Lieferant TVKplus ist verantwortlich für die Anpassungen am System TVKplus. Tabelle 13: Beteiligte Stellen in der Testorganisation ASA Rollen und Verantwortlichkeiten Übersicht der Rollen Für die Testorganisation im Programm ASA2011 werden verschiedene Rollen eingesetzt. Die Rollen und ihre Aufgaben und Verantwortlichkeiten sind in der folgenden Tabelle beschrieben: Rolle in Testorganisation Testmanager ASA2011 Testverantwortlicher Projekt Aus Organisationseinheit Programm ASA 2011 Projekte ASA 2011 Aufgaben und Verantwortung Gesamtverantwortung: Vorgabe von Testziele, Teststrategie, Testprozess und Vorgehen () Review des Testplanes, der Testspezifikationen, Testresultate und Testberichte Freigabe der Teststufen Planung, Design, Vorbereitung und Durchführung von Integrationstests: Testplanung mit Testgrobspezifikationen Bereitstellen eigener Ressourcen und Personen Organisation der zur Unterstützung benötigten Ressourcen, Personen und Infrastruktur Testdesign: Erstellung Test Cases Koordination Testvorbereitung Koordination Testdurchführung Planung, Design, Vorbereitung und Durchführung von Systemtests: Testplanung mit Testgrobspezifikationen Bereitstellen eigener Ressourcen und Personen Organisation der zur Unterstützung benötigten Ressourcen, Personen und Infrastruktur Testdesign: Erstellung Test Cases Koordination Testvorbereitung Koordination Testdurchführung Planung, Design, Vorbereitung, Steuerung und Durchführung von Abnahmetests: Bereitstellen eigener Ressourcen und Personen Organisation der zur Unterstützung benötigten Ressourcen, Personen und Infrastruktur Testdesign: Erstellung Test Cases Testvorbereitung Testdurchführung Testdokumentation Planung, Design, Vorbereitung, Steuerung und Begleitung von Inbetriebnahmetests: Testdesign: Erstellung Test Cases (gesamthaft) ASA2011 V1.0.doc /33