Beiträge

Consulting Kunde Ziele

Was bedeutet eigentlich Beratung?

Consultant

Der Begriff „Consultant“ ist in den letzten Jahren sehr inflationär verwendet worden und geniest damit leider einen ähnlichen Ruf wie das BWL-Studium; nett, aber der Anspruch der Brauchbarkeit muss in der Realität unter Beweis gestellt werden. Da gibt es die „Junior Consultant“, die „Senior Consultant“, die „Principal Consultant“ oder einfach nur die Consultants. Manchmal kann ich mich des Eindrucks nicht erwehren, dass die Akzentuierung, ob jemand Junior oder Senior Consultant ist, primär am Alter festgemacht wird. Wenn es darum geht kundengerechte Konzepte zu realisieren, die die Lebensdauer von PowerPoint-Folien übertreffen, trennt sich die Spreu vom Weizen. Beratung erfordert in erster Linie Kommunikationskompetenz und jede Menge Softskills. Die bekommt man nicht durch Zertifikate und nur bedingt durch überfüllte PowerPoint-Folien, die den Kunden mehr abschrecken als ansprechen.

Beratung = Zuhören + Mehrwert

Beratung basiert auf zwei wesentliche, wenn nicht sogar essentiellen Säulen: Zuhören und Mehrwert schaffen. Idealerweise enabled man den Kunden die vorgeschlagene Lösung selbstständig umzusetzen und setzt während dieser Rollout- oder Etablierungsphase auf Coaching und / oder Mentoring. Der Berater fungiert hierbei als Ideengeber und Mentor auf dem Weg zur kundengerechten Lösung. Es ist auch nicht Fall den Kunden mit alternativen Vorschlägen zu konfrontieren. Dies sollte allerdings nie in einen Wettbewerb der Ideen ausarten. Oft ist die sanfte Lösung der bessere Weg und eine ideale Lösung braucht immer mehrere Iterationen.

Aus eigener Erfahrung kann ich bestätigen wie wichtig die Chemie zwischen dem Kunden und der externen Beratung ist. Berater, die ihre Alpha-Männchen-Mentalität nicht im Griff haben machen unter Umständen mehr kaputt als ganz. Es gab schon Situationen in der geballtes Wissen, gepaart mit einer lautstarker Stimme zum vorzeitigen Abbruch des Meetings und der direkten Rückgabe des Besucherausweises geführt haben. Mein persönliches Mantra ist nach über zwanzig Jahren kundenseitiger Unterstützung:

  1. Für keine der gestellten Herausforderungen braucht man einen Nobelpreis.
  2. Lösungen sind immer iterative und inkrementell
  3. Erhöhe deinen Mehrwert durch stetige vertrauensbildende Massnahme

Meine Kunden sagen mir immer, dass ich das alleine gemacht hätte und ich antworte jedes Mal sinngemäss, dass ich ohne unsere Brainstroming-Sessions und gemeinsame Vorführungen nie so gute Ideen zu Papier gebracht hätte.

Consulting Schiff Erfolg

Beratung ist immer eine gemeinsame Reise mit dem Kunden zusammen. Mal fährt man durch stürmisches Gewässer und muss Klippen umschiffen. Dann wieder hat man Rückenwind und kommt seinem Ziel schneller näher. Auch muss man eventuell mal auf dem Weg zum Ziel in einen Hafen einen Zwischenstopp einlegen um Reparaturen durchzuführen, eine alternative Route eventuell zu diskutieren, oder sogar mit einer anderen Crew die Fahrt fortsetzen. Immer mit dem Blick auf‘s gemeinsame Ziel.

 

Dein Kontakt

Harald Schmidt

Harald Schmidt
Email: harald.schmidt@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/

Erfolgsfaktor Testautomatisierung

Erfolgsfaktor Testautomatisierung (Teil 2)

Nach fast zwei Jahrzehnten Erfahrung im Bereich Test- und Qualitätsmanagement und die damit einhergehende Bewältigung von Herausforderungen, lies mich im ersten Teil die aus meiner Sicht massgeblichen Erfolgsfaktoren unserer heutigen Zeit skizzieren. Sicherlich waren die aufgeführten Punkte subjektiver Natur. Bestätigt wird dies allerdings durch das allseitige Bestreben agile Prozess und CI/CD als Service-Leistung in den Unternehmen zu etablieren. Ziel ist hierbei schnellstmöglich Anforderungen zu realisieren und ebenso schnelle eine gesicherte und belastbare Qualitätsaussage zu erhalten.

Mit dem Bestreben effizientere Prozesse und Services für die Entwicklung von Software zu etablieren ändert nichts an der Tatsache, dass aus Sicht Test-Management stets zwei Säulen als Basis der aktiven Qualitätssicherung herangezogen werden:

  1. Regression Testing: Die bestehende Implementierung muss immer noch den aktuell gültigen Anforderungen entsprechen.
  2. Progression Testing: Neue Features des aktuellen Sprints müssen wie gefordert umgesetzt worden sein.

Die Erfahrung hat gezeigt, dass gegen Ende der Entwicklungsphase nicht immer genügend Zeit für die Durchführung aller geplanter Tests vorhanden ist. Dabei spielt es keine Rolle, ob man sich in einem agilen Projekt mit einem kontinuierlichem Testansatz befindet, oder ein klassisches Projekt mit Wasserfall-Approachunterstützt. Zeit ist immer ein Killer-Faktor und das Testing muss oft die Verzögerungen der Entwicklung durch Nachtschichten oder Wochenendarbeit kompensieren. An dieser Stelle soll erwähnt sein, dass die Einführung von Risk-based Testing als Strategie zur Effizienzsteigerung bei der Priorisierung und Ausführung der Testfälle an immer stärkerer Bedeutung gewinnt. Dies wird ein eigener Beitrag sein.

Die Qualitätssicherung kann das Testobjekt nicht gesund testen, aber durch geeignete Massnahmen aufzeigen wo die Lücken zwischen Realisierung und Anforderungen bestehen. Die Umsetzung sollte in dem hier vorgestellten Continuous Test Automation (CTA) Approach vorgestellt werden. CTA konzentriert sich primär auf zwei Ziele:

  1. Die frühestmögliche Aufdeckung von Abweichungen gegenüber den Anforderungen
  2. Kontinuierliches Q-Feedback an das Team und seine Stakeholder

Die frühestmögliche Aufdeckung von Abweichungen schlägt folgende beiden Massnahmen zur kontinuierlichen Qualitätsverbesserung vor:

  • Aus Whitebox-Sicht wird die konsequente Einführung des Test Driven Development (TDD) seitens der Entwicklung empfohlen. Das setzt Disziplin seitens der Entwickler voraus, garantiert aber im Gegenzug für alle Beteiligten nachvollziehbare und somit verifizierbare Die Entwicklung und Administration von Unit-Tests wird von den meisten Entwicklungsumgebungen heute standardmässig unterstützt.
  • Aus Blackbox-Sicht gestaltet sich die Verifikation des Produktinkrements etwas anspruchsvoller, da man ab einer gewissen Komplexität, verbunden mit dem Anspruch der Nachvollziehbarkeit und Transparenz, sowie dem permanenten Mangel an Zeit, um eine Testautomatisierung nicht herum kommen wird.

Die Automatisierung von Testfällen setzt voraus, dass diese in einer adäquaten Umgebung ausführbar sind und das Produktinkrement ein gewisses Mass an Invarianz aufweist. Ist dies der Fall, können mittels geeigneter Capture/Replay-Tools in einer ersten Iteration relativ schnell reproduzierbare Ergebnisse erzielt werden. In diesem Schritt sollte es nicht primär um die Wiederverwendbarkeit von einzelnen Testschritten gehen, sondern vielmehr um die Frage, ob die im Fokus stehenden Business-Szenarien von denAnforderungen abweisen. Die aufgezeichneten Testszenarien sollten jederzeit eine erneute Verifikation erlauben. Erst in zweiter Linie, verbunden mit einem gewissem Reifegrad, sollte das Refactoring der Tests stattfinden. Findet dies zu früh statt, würde diese Aufgabe in Detailbetrachtungen enden, ohne für die Stakeholdern einen ersichtlichen Nutzen zu haben. An dieser Stelle sei gesagt, dass Testautomatisierungletztendlich auch ein eigenständiges Entwicklungsprojekt ist, dass iterativ und inkrementell voran getrieben werden muss, um den eigenen Qualitätszielen zu genügen.

Das zweite Ziel “Kontinuierliches Q-Feedback” wird durch die wiederkehrende Ausführung zuvor implementierter Test-Skripte in Form von Testsets etabliert. Diese können manuell oder automatisiert via Scheduler ausgeführt werden. Wichtig ist hierbei, dass sich das Team auf ein sinnvolles und abgestimmtesVorgehen einigt. Hier einige Beispiele:

  • Erst wenn alle Unit-Tests “passed” sind, werden die automatisierten User-Tests durchgeführt. Hiermit wird sichergestellt, dass das Entwicklungsteam ein gewisses Mass an Grundqualität liefert und nicht Features einfach über den Zaun wirft, um getestet zu werden.
  • Jeden Morgen wird ein Early Morning Check ausgeführt der verifiziert, ob die integrierten Schnittstellen des Lieferanten immer noch zu Verfügung steh Während der Testdurchführungsphase nimmt das den möglichen Frust aus dem Testteam und die Business-Abnahme kann sich neu organisieren, wenn die notwendigen Schnittstellen nicht zur Verfügung stehen.
  • Die Bereitstellung einer virtuellen Maschine, zum Beispiel einer Data Warehouse Umgebung mit ihren Daten und Schnittstellen, wird erst durch die automatisierte Abarbeitung von Prüfpunkten und Anhand ihres Ergebnisses für die Anwender freigegeben. Dies reduziert das Risiko von der zeitlichen Verfügbarkeit eines Prüfers anhängig zu sein.

All diese Massnahme and Ansätze schaffe ein Höchstmass an Transparenz und geben zugleich eine gute Grundlage für durchzuführende Sprint Retrospektiven.

Erfolgsfaktor Testautomatisierung

SPF Illustration (c) Copyright 2020

 

Fazit

Jede Idee ist nur so gut wie die Akzeptanz und Qualität ihrer Umsetzung. Hinzu kommt die notwendige Einsicht, dass der zuvor betriebene Aufwand der Testautomatisierung sich mittel- bis langfristig rechnen wird. Die Vorteile einer CTA (Continuous Test Automation) sind vielfältig und fangen bei der Verfügbarkeit und Transparenz der Testergebnisse an, gehen weiter zu einer Objektivierung und Personenunabhängigkeit und könnten dann sogar in einem Managed Service mit entsprechender Kostenkontrolle ausgelagert werden.

Dein Kontakt

Harald Schmidt

Harald Schmidt
Email: harald.schmidt@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/

Erfolgsfaktor Testautomatisierung

Erfolgsfaktor Testautomatisierung (Teil 1)

Betrachtet man den heutigen Stand der Qualitätssicherung für Software, wird man geneigt sein festzustellen, dass mit zunehmender Komplexität die manuelle Durchführung von Testfällen ansatzweise auf verlorenem Posten steht. Dies hat primär zwei Gründen: Zum einen sieht man sich mit der Tatsache konfrontiert, dass mittels fehlerhafter Produkte fehlerfreie Produkte realisiert werden sollen. Zum anderen steigt der Grand der negativen Seiteneffekte bei zunehmender Komplexität undefiniert an. Da diese Seiteneffekte erst mit geeigneten Tests identifiziert werden können, steigt auch die Anzahl der durchzuführenden Testfälle entsprechend an. Diese Spirale aus bestmöglicher Testabdeckung und Bewusstsein gegenüber dem immanenten Risiko führt zu einer exorbitanten Anzahl von Testfällen, die aus manueller Sicht nur schwer zu handhaben ist. Priorisierung der Testausführung und Ausbau der Testmannschaft reduzieren das Problem nur bedingt.

Interpretiert man die Software-Entwicklung als Teil einer Lieferkette innerhalb eines Produktionsprozesses, drängt sich das Bild einer Stahlwalzstrasse auf. Am Anfang der Walzstrasse wird das Blech mit einem maximalen Druck in die Walzstrasse reingepresst. Am Ende der Walzstrasse wird das gewalzte Blech mit der maximalen Geschwindigkeit heraus gezogen. Die Qualität der Bleche wird während des Produktionsprozesses kontinuierlich und ohne Unterbrechung geprüft. Aus Erfahrung kann ich sagen, dass das mathematische Modell einer solchen Software sehr komplex ist und zusätzliches Fingerspitzengefühl verlangt. Die Beschaffenheit der gelieferten Coils haben Fertigungstoleranzen und auch die Walzstrasse selbst hat Materialeigenschaften, die es zu berücksichtigen gilt. Es kann eben nicht alles simuliert werden. Wenn der Zug oder der Schub nicht abgestimmt ist, reisst das Blech mit einem ohrenbetäubenden Knall und der Produktionsprozess steht still. Leiser, aber mit einem ebenso grossen Business Impact steht die Software-Entwicklung still, wenn zu sehr geschoben und zu viel gezogen wird.

Erfolgsfaktor Testautomatisierung

SPF Illustration (c) Copyright 2020

Daraus lassen sich folgende Erkenntnisse herleiten:

  • Erwartungshaltung und Verfügbarkeit der Ergebnisse müssen bezüglich Umsetzungsgeschwindigkeit im Einklang stehen. Sonst knallt es im Produktionsprozess.
  • Qualitätskontrolle ist ein Service an den Produktionsprozess, der permanent und, entsprechend der Produktionsgeschwindigkeit, automatisiert stattfinden sollte.

Sicherlich gibt es noch wesentlich mehr Erkenntnisse aus dem oben genannten Beispiel. Für die weitere Diskussion konzentrieren wir uns auf die beiden oben genannten Punkte. Der erste Teil bezieht sich auf die Umsetzung oder Realisierung von Requirements. Der zweite Punkt bezieht sich auf die Rolle des Testings innerhalb des Sprints. Studien und eigene Erfahrungen belegen, dass sich nach der Änderung der bestehenden Software immer wieder Fehler einschleichen, die vorher erfolgreich eliminiert worden sind. Dies hat vielschichtige Gründe. Zum einen kann das Problem durch eine Fehlsteuerung im Build-Prozess auftreten. Zum anderen kann auch die Versionierung der zuvor durchgeführten Änderungen im falschen Branch stecken geblieben sein.  Mangelndes Wissen oder die damit verbundene Fehleinschätzung einer geplanten Änderung kann ebenfalls eine Fehlerquelle darstellen. Auch sollte an dieser Stelle nicht vergessen werden, dass die Software-Entwicklung seit jeher der Herausforderung unterliegt, mit fehlerhafter Software fehlerfreie Software zu erstellen.

Hinzu kommt, dass in Zeiten von Continuous Integration und Continuous Development (CI/CD), gepaart mit agilen Methoden und Sprints von zwei bis vier Wochen, die Automatisierung von Tests zu einem der wesentlichen Erfolgsfaktoren für den gesamten Entwicklungsprozess wird. Bekanntlich führen mehrere Wege nach Rom. Im zweiten Teil dieses Beitrags wird eine mögliche Lösung der in diesem Beitrag geschilderten Herausforderungen skizziert.

Dein Kontakt

Harald Schmidt

Harald Schmidt
Email: harald.schmidt@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/