# data[].attributes.body
- Organisationskonzept
---- RASCI-Matrix nach den ICT-Rollenbeschreibungen des Kanton Bern
---- Kommunikationskonzept
---- Vor- und Nachbedingungen
---- Plan B
---- Bestellprozesse / Ausbildung "Tool"
---- Abgrenzungen

# data[].attributes.headline
Breakout: Gliederung nach ICT-Rollen Kanton Bern

# data[].attributes.subject
Breakout: Gliederung nach ICT-Rollen Kanton Bern

# data[].attributes.body
Beschreibt Tätigkeiten, welche allenfalls manuell durch Tester vorgenommen werden.

# data[].attributes.body
Aus dem Anforderungsmanagement ergeben sich beispielsweise die Testfälle und Akzeptanzkriterien.

# data[].attributes.headline
Definition der inhaltlichen (fachlich) und technischen Testfälle

# data[].attributes.subject
Definition der inhaltlichen (fachlich) und technischen Testfälle

# data[].attributes.body
Wie werden die Ergebnisse dokumentiert, welches ist die Fehlertoleranz.

# data[].attributes.body
automatisiert die Release-Notes publizieren, damit auch darauf reagiert werden kann, bevor ein Testfall negativ ausfällt

# data[].attributes.headline
Herausforderung: Bei neuen Releases funktionieren oft die automatischen Test nicht mehr (z.B. veränderte Dialoge in der Applikation)

# data[].attributes.subject
Herausforderung: Bei neuen Releases funktionieren oft die automatischen Test nicht mehr (z.B. veränderte Dialoge in der Applikation)

# data[].attributes.body
Wir sind aktuell daran aus unserem über den Kanton konsolidierten Testfallkatalog das Smoke-Testset mit der Bedag zusammen primär für den Rich-Cllient zu automatisieren.

# data[].attributes.body
Die Testsets müssen manuell und zeitlich geplant angestossen werden können.

# data[].attributes.body
Es muss die Gesamtansicht der Arbeiten angesehen werden eines AP, nicht nur vom KWP aus. Was wird wie in einem Busines Case bearbeitet, nicht nur ein Tool isoliert betrachten.
Was für weitere Entwicklungen stehen auch an. (offen bleiben)

# data[].attributes.headline
Das AKV (RASCI) muss vorliegen, damit klar ist wer welche Aufgaben hat um eine Testautomatisation auf Stufe Kanton einführen zu können. 

# data[].attributes.subject
Das AKV (RASCI) muss vorliegen, damit klar ist wer welche Aufgaben hat um eine Testautomatisation auf Stufe Kanton einführen zu können. 

# data[].attributes.body
Reden wir von:
- 1. Einem automatisierten Prozess der Fach- und Konzernapplikationstests gegenüber dem KWP (z.B Je Applikation wird im Jira automatisch alle 4 Monate einen Testfall angelegt)
- oder -
- 2. Der SM kann durch Knopfdruck seine Applikation automatisch gegenüber dem neuen Client testen (z.B Für NESKO sind 50 Testfälle Programmiert die automatisch durchlaufen und am Schluss einen Report generieren)

-> Diese Frage ist für mich sehr relevant da wir Stand heute nicht mal den Prozess für das Testing klar geregelt haben. Würde das Jahresziel auf den Punkt 2 ansprechen sehe ich dies als eher nicht umsetzbar.

# data[].attributes.headline
Wie werden Ausnahmefälle / Special Cases angegangen?

# data[].attributes.subject
Wie werden Ausnahmefälle / Special Cases angegangen?

# data[].attributes.body
Ivan: Ich denke manuell ;-)

# data[].attributes.headline
Testautomatisierung - Tool und Priorisierung Testfälle

# data[].attributes.subject
Testautomatisierung - Tool und Priorisierung Testfälle

# data[].attributes.body
Bei der Testautomatisierung muss berücksichtigt werden, ob es sich um was für eine Applikationstechnologie es sich handelt (Client-Server, Web etc.). Dies steuert die Tool-Auswahl.

Des Weiteren sollen primär das Smoke-Testset und sekundär das Regressions-Testset automatisiert werden.

# data[].attributes.body
Welche brauchen wir und wo sind diese angesiedelt?

# data[].attributes.headline
Verantwortlich Tool und deren Weiterentwicklung

# data[].attributes.subject
Verantwortlich Tool und deren Weiterentwicklung

# data[].attributes.headline
Als Ausgangslage genaue Releasenotes von KWP um die Abhängigkeit zuerkennen.

# data[].attributes.subject
Als Ausgangslage genaue Releasenotes von KWP um die Abhängigkeit zuerkennen.

# data[].attributes.headline
Die wichtigsten Testfälle definieren (Generell) 

# data[].attributes.subject
Die wichtigsten Testfälle definieren (Generell) 

# data[].attributes.body
Die Resultate des Testings müssen bei Mehrmandanten Services auf einem Dashboard übersichtlich zur Verfügung stehen.

# data[].attributes.headline
Analyse der kritischen Funktionalitäten pro Applikation

# data[].attributes.subject
Analyse der kritischen Funktionalitäten pro Applikation

# data[].attributes.body
Ivan: Testfälle können entsprechend in ein Smoke Testset aufgenommen werden.

# data[].attributes.headline
Wer implementiert einen automatisierten Test?

# data[].attributes.subject
Wer implementiert einen automatisierten Test?

# data[].attributes.body
FAT, VDI, Kombinationen
LAN/WLAN

# data[].attributes.headline
Kann/muss jeder SM das Testtool selber bedienen können? 

# data[].attributes.subject
Kann/muss jeder SM das Testtool selber bedienen können? 

# data[].attributes.body
Applikation erfassen
Testfälle erfassen
Automatisation einrichten
Auswerten
....

# data[].attributes.headline
Einheitliches zentrales Board für die Testresultate und Auswertung. Mgmt der Bug inklusive

# data[].attributes.subject
Einheitliches zentrales Board für die Testresultate und Auswertung. Mgmt der Bug inklusive

# data[].attributes.body
Die im Kanton bekannten Testfälle /Testfallprotokolle müssen in einem ersten Schritt konsolidiert, anschliessend kategorisiert (Smoke, Regression etc.) und ebenfalls festgelegt werden, welche Testfälle in der Pflicht des KAIO sind und welche Testfälle durch die DIR/STA/JUS verwaltet und bei Bedarf durchgeführt werden.

# data[].attributes.headline
Kriterien für eine Releasefreigabe nach einem Test

# data[].attributes.subject
Kriterien für eine Releasefreigabe nach einem Test

# data[].attributes.body
Ivan: Sind wir im Moment gerade bei BE-GEVER eine Roll-Back Regelung zu erarbeiten

# data[].attributes.headline
Informationen über die Applikationen. Nicht jede Applikation hat die gleichen "Standard-UseCases"

# data[].attributes.subject
Informationen über die Applikationen. Nicht jede Applikation hat die gleichen "Standard-UseCases"

# data[].attributes.body
- Definition der Kriterien/Ziele/Tools
- Was ist gewünscht, wie wo wie tief und vor allem warum
- Ausnahmen
- Organisationsstruktur (AKV)
- Hilfsmittel

# data[].attributes.headline
Grund-Set an Use-Cases werden "automatisch" (z.B. mit dem Paketieren) als automatische Test erstellt

# data[].attributes.subject
Grund-Set an Use-Cases werden "automatisch" (z.B. mit dem Paketieren) als automatische Test erstellt

# data[].attributes.body
Welche Rollen gibt es und wer nimmt diese wahr? Was ist im KAIO, was in DIR/STA/JUS

# data[].attributes.body
Um pro Fach- oder Konzernapplikationen einen Test abzubilden wird heute auf das ICT-Portfolio zurückgegriffen.
Dieses ist oftmals veraltet und wird zu wenig von der DIR/STA/JUS gepflegt.
Vorraussetzung für eine Automatisierung wäre die Pflege der Daten in dem ICT-Portfolio

# data[].attributes.headline
Handling der Applikationen die sich nicht automatisieren lassen? 

# data[].attributes.subject
Handling der Applikationen die sich nicht automatisieren lassen? 

# data[].attributes.body
Auch solche, welche NICHT auf dem KWP installiert sind

# data[].attributes.headline
Spezialisten Team welche die Roboter bedienen können

# data[].attributes.subject
Spezialisten Team welche die Roboter bedienen können

# data[].attributes.body
Datenmanagement
Anonymisierung

# data[].attributes.headline
Beschreibung der Test-Cases, welche automatisiert getestet werden sollen

# data[].attributes.subject
Beschreibung der Test-Cases, welche automatisiert getestet werden sollen

# data[].attributes.headline
Akzeptanz und Rolle in der DIR/STA/JUS schaffen

# data[].attributes.subject
Akzeptanz und Rolle in der DIR/STA/JUS schaffen

# data[].attributes.body
Heute wird das Testing in der DIR/STA/JUS nicht klar geregelt. Jede Direktion sieht eine andere Rolle als Tester vor (z.B FIN -> SM, WEU-> FaV etc.)
Foglendes wird benötigt:
- Rolle und Akzeptanz schaffen
- Kommunikationskonzept (Wer wird wann informiert)
- Einheitliche Regelung im ganzen Kanton, es darf keine Sonderregelung geben