Go oder NoGo, wie entscheiden Sie?

Präsentation zum Thema: "Go oder NoGo, wie entscheiden Sie?"—  Präsentation transkript:

1 Go oder NoGo, wie entscheiden Sie?
Ein Testcockpit mit Führungskennzahlen Reto: Hallo alle zusammen Ich heisse Sie ganz herzlich willkommen zu unserer Präsentation. Der Titel unseres Vortrags heisst: Go or NoGo, wie entscheiden Sie? Ein Testcockpit mit Führungskennzahlen Öhh…Dominique, wieso hast du heute eigentlich eine Krawatte an…? Dominique: Testmanager Reto: dachte du seist Tester? Reto:…ich verstehe nichts mehr… Reto Wyss und Dominique Portmann Noser Engineering AG

2 Testen ≠ Testen Der Manager Der Techniker Was Reto:
Wahrscheinlich Ihnen allen, oder sicherlich den meisten von Ihnen…dürfte die Situation, dass das Management den Tester nicht so wirklich versteht nicht völlig unbekannt vorkommen… Aber ich sage Ihnen…seien Sie deswegen noch nicht beunruhigt…denn meistens verstehen die einen Tester die anderen Tester auch schon nicht… Und…um Sie komplett zu verwirren…verrate ich ihnen gleich auch noch ein kleines Geheimnis…Testen ist nämlich gar nicht immer gleich Testen… So, nachdem jetzt wahrscheinlich auch die letzten Klarheiten beseitigt wären…oder Dominique…??? …könntest du dich bitte unserem Publikum gerade mal vorstellen?

3 Leidenschaft Dominique Portmann Wer Dominique:
Leidenschaft heisst so, weil es Leiden - schafft… Seit mehr als 25 Jahren leide ich im Testumfeld. Angefangen in einer WEP, in zahlreichen SW-Projekten, Bei grösseren Migrationen von alten auf neuen IT- Systemen Bis heute, wo ich bei Noser die Business Unit Testengineering leite. Und Du Reto, willst Du dich auch vorstellen ?

4 Reto Wyss Wer Reto: Danke Dominique, mein Name ist Reto Wyss.
Ich bin Software-Ingenieur bei Noser seit nunmehr gut 3 Jahren. Wahnsinn, wie schnell die Zeit vergeht… Mein Fokus liegt auf der NI-Produkte-Palette. Ich bin meistens mit LabVIEW…sowie dessen Erweiterungen LabVIEW Real-Time und LabVIEW FPGA unterwegs. Und meine zweite Domäne ist NI TestStand, womit ich auch schon einige Projekte umsetzen durfte. Wie wir gleich noch sehen werden geht es bei TestStand hauptsächlich um Produktions-Endtests…

5 V-Modell Testing Montage Verpacken Fertigung Entwicklung Delta
Reto: Ein kleiner Hinweis. Sie sehen übrigens hier oben rechts, als kleine Orientierungshilfe immer wo wir uns gerade befinden oder was wir Ihnen auf dieser Folie rüberbringen möchten. Es geht momentan also darum ihnen aufzuzeigen warum Dominique und ich…obwohl wir beide von Testing sprechen, uns trotzdem oft nicht verstehen, uns quasi auf einem anderen Planeten befinden. Dominique: Genau, schau mal Reto. Wenn ich von Testing spreche befinde ich mich hier in der Entwicklung. Da geht es darum Anforderungen zu definieren und diese zu testen Daraus einen Systementwurf zu machen welcher getestet werden kann Und je nach Projektgrösse immer feingliedriger zu spezifizieren und diese Spezifikationen dann wieder zu testen. Es geht also im wesentlichen darum, ein Projekt zu überprüfen und zu begleiten bis es am Ende hoffentlich ein fertiges Produkt ist. Reto: Ah so, verstehe...Schau mal Dominique, ich bin meistens hier in der Fertigung, und bei mir geht es darum das fertige Produkt, nach der Montage durch einen Endtest für die Auslieferung freizugeben. Wir befinden uns also grundsätzlich schon mal in einer ganz anderen, nennen wir es mal, Organisation. Du in der Entwicklung wo du ein Projekt über die verschiedenen Projektphasen hinweg mit testen begleitest…und ich in der Produktion wo ich für ein Produkt einen Endtest durchführe.

6 Wording Socket Bugtracking Prüfen Sequenz Editor Regression
Delta Wording Socket Bugtracking Prüfen Sequenz Editor Regression Automatisierung Messequipment Use Cases Sequenzen Testabdeckung Datenbank Testschritte Paralleles Testen Testcase Anforderungen Report Prüfmodell Testprozess RPI Iteration Strategie Benutzerverwaltung Risiko Meilenstein Konfiguration Dominique: genau, und neben der unterschiedlichen Organisation verwenden wir eben oft auch ein unterschiedliches Wording. Das hat einerseits damit zu tun, dass wir uns wie gesagt in unterschiedlichen Organisationseinheiten bewegen. Und andererseits ist das natürlich auch Tool-getrieben. Fachhochschulen, historisch bedingte Ausdrücke, usw. tun ihr restliches dazu, dass wir eben leider…wie gesagt…oftmals den anderen nicht verstehen. Sequentielles Testen Fehlerklasse Batch Testen

7 TestStand - Endtest Zurück (Failed) Ausliefern (Passed) Delta
Reto: ok Dominique, dann will ich dir mal ein bisschen nachhelfen und dir kurz erklären um was es bei einem Produktionsendtest eben geht: Zuerst geht es um den Nachweis der Produktefunktionalität…im Unterschied zum Reifegrad eines Projekts in deinem Fall, wie wir das vorhin im V-Modell gesehen haben Dann müssen bei einem Endtest eventuell auch Nachweise erbracht werden, z.B. dass Sicherheitsaspekte oder Normen erfüllt oder eingehalten werden. Automatisierung ist ein wichtiges Thema. Und das Produkt braucht schlussendlich natürlich einen «Bestanden» oder «zur Auslieferung freigegeben»-Stempel…oder es muss, falls der Test nicht erfolgreich war, aussortiert werden und es wandert zurück um den Fehler zu beheben, bevor es erneut geprüft wird. Typische Merkmale von einem Endtest sind: Hohe Stückzahlen Und, es ist immer das gleiche Produkt. Das Produkt kann zwar unterschiedlicher Konfigurationen haben, aber grundsätzlich geht es immer um das gleiche Produkt welches hier geprüft wird.

8 Testen in Projekten In diesen Projektphasen «findet Testen statt»
Delta Testen in Projekten Dominique: Nun zeige ich, wo ich in einem Entwicklungsprojekt teste: z.B. Projekt, einmalig Meilensteine Reifegrad des Projekts bis zur Entstehung des fertigen Produkts Erfüllen von Normen Neutrale Sicht für Projektleiter Meilensteine im Projekt, go für nächste Phase Automatisieren Typische Merkmale hierbei sind: Nur 1 Produkt, aber dafür wird es bis zur Produktreife begleitet Jedes Projekt ist einzigartig In diesen Projektphasen «findet Testen statt»

9 Testing – notwendiges Übel oder Steuerungsinstrument?
Was wir wollen Testing – notwendiges Übel oder Steuerungsinstrument? Testing Testdaten Stakeholder Kosten / Nutzen Effizienz Tools Gemeinsames Vokabulare Reto: Also Dominique, wir haben jetzt 3 gute Gründe aufgezeigt warum wir uns oftmals nicht verstehen: 1.) Unterschiedliche Organisation 2.) unterschiedliches Wording, und 3.) unterschiedliche Tools Dominique, ich weiss du gibst mir recht wenn ich sage ,dass da noch ein ganz wichtiger Punkt fehlt…wir beide wissen nämlich aus unserer Erfahrung heraus, dass nicht nur wir uns besser verstehen wollen, sondern dass wir unbedingt auch mit dem Management einen gemeinsamen Nenner finden müssen. Weisst du noch? wir haben also angefangen nach Gemeinsamkeiten zu suchen. Wir haben uns Fragen gestellt wie: Gibt es einen gemeinsamen Nenner für verschiedene Testing-Organisationen, verschiedene Wordings und verschiedene Testing-Tools? Finden wir eine gemeinsame Sprache? Gibt es ein gemeinsames Ziel für Tester und Management Und je länger wir darüber nachgedacht haben desto stärker rückte das Bewusstsein, dass das Management fundamental wichtig ist immer mehr in den Vordergrund – wieso, da sehen wir dann später noch mehr dazu – und so haben sich dann je länger je mehr auch unsere Fragen nach oben abstrahiert. Interessant und zentral wurden plötzlich Fragen wie: Was hat das Management überhaupt für ein Interesse am Testen? Und, anstatt Testing nur als «notwendiges Übel» zu sehen ...aus Managersicht – was leider viel zu oft vorkommt…ist es nicht möglich aus dem Testing heraus die richtigen Zahlen und Schlüsse zu ziehen um dem Management ein Steuerungsinstrument in die Hand zu geben?

10 Cockpit Was wir brauchen
Dominique: Die einfache Antwort auf diese Fragen ist: JA! Was wir brauchen ist ein Cockpit, welches auf den Testdaten fusst und die Informationen daraus abstrahiert und ableitet welche für das Management interessant sind. „ Stellen sie sich einen Airbus A380 vor. In diesem Vogel werden tausende von Signalen erfasst, und zwar permanent, in Echtzeit. Wenn Sie dem Piloten alle diese Informationen anzeigen würden, wäre der Vogel wohl nicht allzu lange in der Luft. Wieso? -> es sind keine Pilotengerechten Informationen. Der Captain kann damit nichts anfangen, er versteht die Informationen nicht, der Vogel stürzt ab…! „ Stellen sie sich vor der Pilot hätte gar keine Informationen. Das Ergebnis ist dasselbe. Der Vogel stürzt ab. Wieso? -> es sind wiederum keine Pilotengerechten Informationen… Was wir also brauchen ist eine Hierarchie-gerechte Abstraktion und Ableitung von Daten die es dem Captain ermöglichen die Maschine zu steuern!!!“

11 Woher Datenpool Reto: Dominique, dieses Beispiel ist für mich sehr einleuchtend. Und bei uns im Testing - egal ob Entwicklung oder Endtest - ist es doch genau gleich wie in deinem Beispiel… Wir generieren zuerst mal ganz viele Daten. Und dieser Datenpool…welcher viel zu oft zwar existiert aber eben nicht oder zu wenig genutzt wird ist es…dieser Datenpool kann im wahrsten Sinne des Wortes Gold Wert sein!!! Dominique: Du meinst, Big Data makes you happy… Reto: ganz genau, wenn man weiss wie man sich die Daten zu Nutze machen kann… Dominique:…und hoffentlich nicht zur Spezies der NSA gehört… Reto: hoffentlich nicht…sonst dürfte ich wahrscheinlich nicht mit dir darüber sprechen… Aber im ernst…dieser Datenpool beinhaltet weit mehr Informationen wie nur ein finales Passed / Failed. Ich nenne einfach mal ein paar Beispiele: Dauer der Prüfung Dauer einer Reparatur im Fehlerfall Wer hat geprüft Usw. Und, der Pool beinhaltet natürlich auch die Historisierung, sprich die Daten aller bereits getesteten Prüflinge. Dass sie sich wenn sie einen Prüfstand erstellen Gedanken machen sollten welche Daten sie abspeichern wollen versteht sich und da gehe ich nicht weiter darauf ein. Schauen wir uns auf der nächsten Folie mal an für wen und wieso diese Daten so wertvoll sein können.

12 Nutzen dank Transparenz
Für wen und was Nutzen dank Transparenz Reto: Im Falle eines Endtest-Datenpools kommen mir spontan zwei Gruppen in den Sinn: 1. Qualitätsmanagement Stichwort: kontinuierlicher Verbesserungsprozess -> Mit den richtigen Daten kriegt das Qualitätsmanagement ein Instrument zur Hand um systematisch Probleme aufzudecken, diese zu quantifizieren und qualifizieren und durch geeignete Massnahmen diese zu eliminieren und somit baren Wert für ein Unternehmen zu schaffen. 2. oberstes Management Stichworte : Zeit, Ressourcen, Geld -> Einspar- / Optimierungspotential -> Controlling: Mit den richtigen Tabellen und Diagrammen bekommt das Management ebenso ein Instrument zur Hand das es ihm ermöglicht mit harten Fakten zu agieren und aktiv zu steuern

13 Nutzen dank Transparenz
Für wen und was Nutzen dank Transparenz User Story Dominique: Im Verlauf eines Projekts fallen sehr viele und sehr verschiedene Daten an. Zu Beginn sprechen wir mit Business Analysten, hier geht es oft um User Storys, Dann muss mit der Projektleitung die Teststrategie definiert werden, hier geht es Um Risiken und den RPI, Dann mit den Testanalysten und Testdesignern über Test – Cases, Und immer wieder mit fast allen um den Fortschritt sowie um Metriken für die Testabdeckung.

14 Nutzen dank Transparenz - Pyramide
Für wen und was Nutzen dank Transparenz - Pyramide CEO CIO Produkte – Verantwortlicher Projektleiter Entwicklungsleiter Teamleiter Entwickler Tester Dominique: Wenn ich das nochmal reflektiere geht es also darum aus dem Datenpool Informationen Hierarchie-gerecht zu abstrahieren. Und meine Erfahrung kann ich am besten mit einer Pyramide vergleichen. Die Daten werden je nach Ansprechperson in unterschiedlichen «Mengen» benötigt. Unten in der Pyramide liegt «Big-Data», oder unser Datenpool mit allen Testresultaten in allen Details. Zuoberst benötigt es als maximale Zusammenfassung nur eine Info: «ein grünes Licht» für den CEO. Je näher die Entscheidungsträger am Projekt sind, desto mehr «Detail-Informationen» sind nötig. Welcher Test hat mit welchem Resultat abgeschlossen, wieviel liegt der Wert aus der Toleranz… Für jede Entscheidungsstufe müssen die Daten aus dem Pool unterschiedlich aufbereitet und der Flughöhe angepasst werden. Das bedeutet, dass die Manager dann zufrieden sind, wenn sie die für ihre Entscheidungen nötigen Informationen erhalten. Reto: Interessant. Eine meiner Erfahrungen ist die, dass das oberste Management…oft via Qualitätsmanagement von «Optimierungspotential» Wind kriegt. Dann laufen plötzlich Manager mit Dollar-Zeichen in den Augen in den Produktionshallen umher und kandidieren als «beste Freundeanwärter» der Tester… Plötzlich verstehen sie sich…welche Tools eingesetzt werden sollen oder wieviel diese Kosten ist nicht mehr so wichtig…die Tester bekommen die Unterstützung von ganz oben und sind voll legitimiert sich in ihrer Testingwelt auszuleben.

15 Ein Steuerungsinstrument – Cockpit
Für wen und was Ein Steuerungsinstrument – Cockpit Dominique: Dieses typische Cockpit liefert phasengerecht die nötigen «Vitalitätsdaten» vom Projekt. Dies ermöglicht dem Management, den Entscheid für die nächste Phase zu treffen.

16 Für wen und was Cockpit Dominique: die Daten aus dem Pool werden Phasengerecht dargestellt. Reto: Aha, wenn ich das also richtig interpretiere, dann sehen wir auf der X-Achse die einzelnen Meilensteine oder Releases von einem Entwicklungsprojekt. Und wenn ich das zweite Diagramm anschaue, dann sehe ich dass die Summe aller gefundenen Fehler immer weiter zunimmt, während man im dritten Diagramm sehen kann, dass die Anzahl noch offener Fehler natürlich irgendwann abnehmen sollte. Ok, und wenn das nicht so ist, dann sieht der Manager oder Verantwortliche dass etwas nicht stimmt und kann jetzt entsprechend Massnahen einleiten. Er hat also durch das Cockpit ein Instrumentarium erhalten um das Projekt zu steuern?! Dominique: Genau so ist es. Bei uns im Testing während eines Entwicklungsprozesses setzen wir dieses Instrument ein um dem Management zu rapportieren und geben ihm somit eine faktenbasierte Grundlage zum Projekt-Controlling, oder eben steuern wie wir es vorher genannt haben. Reto: Das ist also ein Beispiel aus einem realen Projekt das ihr umgesetzt habt? Dominique: genau.

17 Beispiel TestStand: Endtest Smartphone (SP)
Für wen und was Beispiel TestStand: Endtest Smartphone (SP) Fail-Analyse Januar Failed: 17 %, davon: Fehlerhafte Antenne: 64 % (1088 Stk.) Ursache: falsche Montage Ø-Reparaturzeit: 54 Min. Arbeitskosten: 100 CHF / h Antenne: Rep.-Kosten: 98k CHF Februar Analyse, danach Massnahme: Mitarbeiterschulung Antennenmontage März Massnahme greift Failed: 9 %, davon: Fehlerhafte Antenne: 3 % (27 Stk.) Antenne: Rep.-Kosten: 2700 CHF  Produktionsprozess verbessert, Einsparung pro Monat 95k CHF Reto: Toll Dominique, dann möchte ich dir auch mal aufzeigen was man aus einem Endtest-Datenpool für interessante Informationen gewinnen kann. Aus diesem Beispiel wird schnell klar, dass es einen Manager vielleicht weniger interessiert, ob ein einzelner Testschritt oder ein einzelnes Produkt passed oder failed hat… Was ihn aber ganz sicher interessieren dürfte sind die Zahlen aus folgendem Beispiel: Du sieht hier anhand der blauen Linie dass im Januar 10’000 Smartphones durch den Endtest gegangen sind. Die grüne Linie hier unten zeigt uns auf dass dabei 17% fehlerhaft waren Von diesen 17% wiederum hatten 64% denselben Fehler. Nähmlich eine falsch montierte Antenne. Die Prüfer brauchten im Durchschnitt 54 Minuten um den Fehler zu beheben und ihren Fehlerbehebungsprozess wie verlangt zu dokumentieren. Bei einem Stundenansatz von 100 CHF / h ergeben sich Kosten von 98 kCHF, alleine im Monat Januar für die Behebung des immer gleichen Fehlers mit der Antenne. Im Februar sieht nicht viel besser aus, allerdings hat die GL reagiert und eine Mitarbeiterschulung abgeordnet um die Problematik der Antennenmontage zu entschärfen. Im März sehen wir nun, dass die Massnahme gegriffen hat. Es gibt insgesamt nur noch 9% fehlerhafter Smartphones und davon gar nur noch 3% wegen einer falsch montierten Antenne. Die verursachten Kosten wegen einer falsch montierten Antenne belaufen sich noch auf 2’700 CHF. Pro Monat spart der Hersteller ab März also rund 95 kCHF ein, weil er aus dem Datenpool die richtigen Daten extrahiert und aufbereitet hat damit das Management geeignete Massnahmen treffen konnte. Dieses simple Beispiel zeigt hoffentlich auf welchen Wert ein Datenpool darstellen kann, wenn man daraus die richtigen Daten ableitet und dem Management so ein Steuerungsinstrument zur Verfügung stellt.

18 Umsetzung Cockpit (NI DIAdem)
Wie Umsetzung Cockpit (NI DIAdem) Reto: Um noch den Übergang zu machen um von den Testdaten aus unserem Pool zu einem Cockpit für Führungskräfte zu gelangen schauen wir uns noch kurz an wie sich das bewerkstelligen lässt. Man kann sagen, dass sich prinzipiell jedes Tool welches mit Files und Datenbanken zurechtkommt eignet. Wenn wir das auf NI-Tools herunterbrechen, eignen sich sicherlich LabVIEW und DIAdem. Für die unter Ihnen die es nicht kennen, DIAdem ist ein Datenanalysetool und bestens geeignet um insbesondere aus Files nach Daten zu suchen, zu verarbeiten und darzustellen. DIAdem stellt eine grosse Palette für verschiedenen Darstellungsformen zur Verfügung, seien es Tabellen oder Graphen, usw. Weitere Informationen dazu finden Sie auf der NI-Internetseite oder vielleicht gibt es heute ja auch den ein oder anderen Vortrag zu diesem Thema den sie sich zu Gemüte führen können. Das gleiche gilt natürlich auch für LabVIEW.

19 Reflektion Fazit DO: Zusammengefasst wollten wir Ihnen hier und heute aufzeigen, dass im Bereich Testing grosses Potential für viele für Firmen schlummert. Um dieses Potential abzuschöpfen ist es wichtig, es mit viel Fingerspitzengefühl anzupacken. Es muss für Tst u Mgt eine gemeinsame Sprache gefundenen werden. Wir sind zum Schluss gelangt, dass viele Fragen rund ums Testing wie mit welchem Tool testen wir - welche Testdaten müssen erhoben werden - Wie wird rapportiert viel einfacher zu beantworten sind, wenn man die Sichtweise um 180° dreht und sich zuerst fragt welche Wertschöpfung können und sollen unsere Testdaten erbringen. Setzen den Datenpool ins Zentrum und fragen Sie sich: welchen Nutzen kann daraus für ihr Management generiert werden. Wie können die Daten zu ein Steuerungsinstrument, einem Cockpit für den Piloten werden. Wenn wir Tester dem Management ein Steuerungsinstrument geben, damit sie «managen» oder eben steuern können, dann müssen wir nicht weiter über Tools oder technische Details diskutieren, denn das Testen ist durch den Mehrwert bereits «legitimiert» oder amortisiert. Die Gemeinsamkeit, oder der kleinste gemeinsame Nenner liegt also bei Datenpool. Daraus kann je für jede Stufe der Pyramide ein passendes Cockpit abgeleitet werden. Unsere Erfahrung zeigt: Für das Management ist ein gutes Cockpit garantiert ein Volltreffer! Mit den richtigen Daten: Lässt sich die Qualität ihrer Produkte nachhaltig verbessern - Kann ein Projekt jederzeit gesteuert werden -Findet man die gemeinsame Sprachbasis, vom Testing bis zum Management - Lässt sich viel Geld sparen, wie wir gesehen haben