Einstufung der Bug-Prioritäten

Im letzten Jahr haben wir das Thema „Bug-Triage“ beschrieben, und dort festgestellt, dass die Bug-Triage bei der Beurteilung von Bugtickets darauf angewiesen ist, dass die Priorisierung („priority“) und der Schweregrad („severity“) richtig gesetzt wurde.

Wenn man nun in der Flut von Bug-Tickets „ertrinkt“, woher weiß das Triage-Team denn nun, was wichtig ist, und was nicht? Einstufung der Bug-Prioritäten weiterlesen

Gibt’s dafür auch eine App? [Requirements Engineering]

Wenn Sie sich heute als Kunde für ein neues Produkt entscheiden, sei es eine Waschmaschine, ein neuer Fernseher, oder vielleicht demnächst eine neue Pumpe für den Gartenteich, so interessieren Sie sich vielleicht nicht nur für die Qualität des eigentlichen Produkts, sondern auch für den erhöhten Komfort, den eine „App“ mitbringt. Es wäre doch schön, informiert zu werden, wenn die Wäsche fertig ist. Wäre es nicht schön, den Springbrunnen im Garten einschalten zu können, ohne aufstehen zu müssen?

Gibt’s dafür auch eine App? [Requirements Engineering] weiterlesen

Teure Fehler im ersten Praxistest bei 60 Millionen € Software-Projekt

Wie heute im Web zu lesen war, hat die Bundesagentur für Arbeit ein Software-Projekt eingestampft.

Das Erschreckende dabei: Das Projekt lief seit 4 Jahren und hat schon 60 Millionen Euro gekostet.

Das Traurige dabei: Die Entwicklung wird nicht weiter verfolgt, weil beim ersten Praxistest Fehler auftreten, die man sehr gut vermeiden kann.
Im vorliegenden Fall handelt es sich um ein Problem, das Kontonummern nachträglich nicht mehr geändert werden können. Wenn man deswegen ein Projekt einstampft, muss der Fehler sehr tief sitzen. Vielleicht hat eine Entwicklungsabteilung die Kontonummer als Primärschlüssel verwendet?

Fakt ist, dass die Fehler, die hier aufgetreten sind, nicht erst bei der Codierung, gemacht wurden. Hier sind Fehler in der Planung aufgetreten. Diese Fehler kann man leicht vermeiden, wenn man regelmäßige Feedbacks einholt, und auch Unbeteiligte einmal über die Input-Dokumente schauen lässt.

Software-Qualitätssicherung ist „Devil’s Advocate“

Die entwicklungsbegleitende Qualitätssicherung spielt an der Stelle den Anwalt des Teufels, und untersucht schon während der Planungsphase die entstehenden Dokumente. Hier wird das große Ganze im Auge behalten. Die Ergebnisse der Entwicklungsabteilung, die auf Details konzentriert ist, werden so immer wieder einer Plausibilitätsprüfung unterzogen.

Um das leisten zu können, muss die Qualitätssicherung aber nicht als die Stelle verstanden werden, die „am Ende drauf schaut, ob keine Bugs mehr drin sind“, sondern als Partner der Entwicklung, als verlängerter Arm des Kunden, damit die Entwicklung den richtigen Weg verfolgen kann, und sich auf die Details konzentrieren kann.

Gerade in kleinen Teams reicht die Manpower häufig nicht, um diese Tiefe in der Qualitätssicherung auch zu leisten. Wenn dann falsche Design-Entscheidungen getroffen werden, drohen Nacharbeiten, Lieferverzug und Imageschaden.

Soweit sollte man es nicht kommen lassen. Wir stehen gern als Mittler und „Anwalt des Teufels zur Verfügung“.

 

Was bringt mir das Code Refactoring?

Eine der größten Entwicklungen zum Beispiel in der Automotive-Industrie war der Entwicklung der Baukasten-Systeme, bzw. Modularer Plattformen. Hierzu wurden alle Komponenten der Produktpalette unter die Lupe genommen und geschaut, wie man diese so gestalten kann, dass sie möglichst vielfältig eingesetzt werden. Das gipfelte nun darin, dass die Vorderachse bei einigen Herstellern von der Kompaktklasse, über die SUVs bis hin zu kleinen Lieferwagen in 8 verschiedenen Modellen zum Einsatz kommt. Gibt es nun große Weiterentwicklungen an dieser Komponente profitieren direkt 8 Modelle davon.

Ich denke, ihr merkt, wo ich hin möchte?
Häufig entsteht Software daraus, dass ein Entwickler auf dem weißen Stück Papier anfängt und los schreibt. Es werden Funktionen ergänzt, Code kopiert und Ausgaben an verschiedenen Stellen eingesetzt. Einige Tausend Zeilen Code später
ist der Spaghetti-Knoten dann perfekt. Jede Änderung birgt nun die Gefahr, dass sie den Code an anderer Stelle zum Einsturz bringt. Die Qualität der Software ist somit stark gefährdet und die Wartbarkeit nicht mehr gegeben.
Code Refactoring ist nun also der Umbau
dieses Legacy Codes in den Modularen Baukasten der Automobilindustrie hier bei uns in der Software-Qualitätssicherung und der Software-Entwicklung.

Was machen wir nun bei Code Refactoring?

Zu erst einmal muss man sich den gesamten Code einmal anschauen und überlegen, in welche Funktionseinheiten man ihn unterteilen kann. Dann fängt man an Nudel für Nudel aus dem Knoten herauszuziehen. Diese herausgelöste Funktionalität kann nun als eigene Komponente separat gepflegt und bei Bedarf immer wieder aufgerufen werden.
Wenn man mit der ersten Runde fertig ist, geht es in die nächste Runde. Hierbei schaut man sich die einzelnen Funktionseinheiten an und schaut, ob es sinnvoll ist diese weiter herunter zu brechen, in noch kleiner Einheiten. Vielleicht habe ich ja in zwei Einheiten eine Funktion, die ich an beiden Stellen verwenden möchte?
Am Ende ist der gesamte Code soweit herunter gebrochen, dass ich viele einzigartige Funktionen und Komponenten als eigene Einheit vorliegen habe. Wenn ich nun eine eingeführte Variable ändern möchte, brauche ich dies NUR EINMAL zu machen.

Durch die Modularität erhöht sich ganz nebenbei die Testbarkeit, denn ich kann die Komponenten losgelöst mit Unittests versehen. Der Software-Test beginnt schon während der Entwicklung und Bugs fallen schneller auf.
Bei Erweiterungen des Funktionsumfangs brauchen wir nicht mehr durch den gesamten Code zu wandern und zu schauen, an welchen Stellen ich die neue Funktionalität mit einbinden muss. Vielleicht lässt sich die eine oder andere Komponente ja auch in einem anderen Projekt verwenden?

Round-up

Unter dem Strich bekommen wir durch Code Refactoring also,
bessere Wartbarkeit für alle beteiligten und Nachfolger
mehr Übersicht, auch für Neueinsteiger im Projekt
Modularität die Zeit spart bei neuen Projekten
– Erhöhung der Zukunftssicherheit
Zeitersparnis bei der (Weiter-)Entwicklung
– Vereinfachung beim Software-Testing

Um es einmal plakativ zu sagen – und mit einem Augenzwickern: Coding as easy as Lego!

Unser Credo – Der Fehler darf nicht bis zum Kunden gelangen!

Es ist vielleicht auch mal interesssant zu erfahren, was einen Qualitätssicherer antreibt und welche Beweggründe es gibt, die Produkte aus einem anderen Blickwinkel zu betrachten.

Daher möchte ich auf die Frage eingehen: Wie komme ich zur Qualitätssicherung?

Nach dem Studium war ich auf der Suche nach einer Aufgabe in der Software-Entwicklung, idealerweise im spannenden Feld des Mobilfunks. Dabei habe ich bei Ericsson (dem Netzwerkausrüster) erfahren, wie wichtig die Qualitätssicherung ist.

Wenn man für Software in Vermittlungsstellen, die sich bereits im Feld im Einsatz befindet, Updates bereit stellt, dann stellt man besser sicher, dass die Software keine Fehler enthält – sonst sind plötzlich Millionen Kunden offline.

Stellen Sie sich einfach vor, wie ein einzelner Fehler dafür sorgt, dass eine Großstadt nicht mehr telefonieren kann – und Sie haben die Größenordnung im Blick.

Um sicherzustellen, dass ein Update das Problem löst und nicht weitere Problem erstellt, wurde bei Ericsson auf Team-Arbeit gesetzt. Allein in unserer Gruppe waren 5 (!) Leute in wechselnder Zusammensetzung tätig, die sich gegenseitig kontrolliert haben.

Diese Akribie und Vorsicht waren für mich prägend, als ich beim nächsten Arbeitgeber als Qualitätssicherer einstieg. Wenn man in die Situation kommt, dass man den Kollegen vom Support Rede und Antwort stehen muss, warum sich heute schon x Leute nach einem Update mit exakt demselben Fehler – der im Zweifel einen Produktionsausfall nach sich zieht – gemeldet haben, weiß man, wie wichtig die Qualität des eigenen Produkts ist. Deswegen lautet seitdem lautet mein Credo „Jeder Fehler, der nicht durch mich, sondern durch den Kunden entdeckt wird, ist mir peinlich!“

Wie an anderer Stelle erklärt, hat man als Qualitätssicherer nicht das letzte Wort, ob ein Fehler behoben wird – aber man hat zumindest gute Argumente.

Deswegen vertraue ich auf vollständige Testpläne, auf ein 4-Augen-Prinzip und darauf, dass man reproduzierbare Arbeit abliefert.

Es gibt für jedes Unternehmen die richtige Methodik, um Testpläne zu entwickeln und abzuarbeiten. Die einen leben mit Word-Vorlagen hervorragend, die anderen haben ausgeklügelte Ticketing-Systeme. An mancher Stelle kann man Testautomatisierung betreiben, an anderer Stelle ist die „User experience“ (oder „Popometrie“ – wie es im Kfz-Bereich heißt) wichtig.

Es gibt nicht das ewig selbe Konzept, das auf alle Unternehmen anzuwenden ist. Wir erarbeiten gern das optimale Konzept mit Ihnen.

In meinen Augen ist es wichtig, dass man unabhängige Tester findet, die das Produkt kennen, aber es nicht im Schlaf bedienen können. Und da bieten wir uns gern an.

Unit-Tests / Test driven development … ein kurzer Blick in den Alltag

Hier mal ein kurzer Einblick in den täglichen Arbeitsalltag.

Dieser belegt, wieso Testing auch bei trivialen Aufgaben nicht vernachlässigt werden sollte.

Die Aufgabenstellung war recht einfach:
Ein Programm (geschrieben in C/C++) sollte seine Versionsnummer ausgeben, wenn der Benutzer als einzigen Parameter „–version“ mitgibt.

Der Positiv-Test stellte recht schnell sicher, dass die Aufgabenstellung erfüllt war:

program.exe –version
lieferte

program Version 1.2.0.2345

Soweit, so schön, das Programm beendete sich danach auch wie eigentlich sinnvoll. Dummerweise stand das schon so nicht in der Anforderung – ein Fehler von demjenigen, der die Anforderung geschrieben hatte – gut, dass der Entwickler mitgedacht hatte!

Auf Negativ-Tests wurde zunächst verzichtet.
Wie hätten diese aussehen können?

  • Aufruf des Programms ohne Parameter
  • Aufruf des Programms mit einem anderen Parameter
  • Aufruf des Programms mit mehr als einem Parameter

Das Resultat?

  • Dummerweise beendete sich das Programm nun auch, wenn der falsche Parameter übergeben wurde.
  • Nachdem dieser Fehler behoben wurde, stellte sich heraus, dass die Applikation aufgrund einer Speicherzugriffsverletzung abstürzte, und zwar regelmäßig bei jedem Aufruf.

Da die Software so vom gesamten Team nicht weiter getestet werden konnte, wurde die Änderung schnell wieder zurückgezogen.

Was lernt man aus dieser Geschichte?

  • auch die kleinste Änderung sollte man sich zu zweit anschauen, oder zumindest im Abstand von einigen Stunden noch einmal mit unverstelltem Blick
  • Test-driven-development – also die Arbeitsweise, zunächst Unit-Tests zu entwickeln, und diese dann zu erfüllen, ist hilfreich.
  • Negativ-Tests sind nicht „lästig“ oder „unnütz“, sondern das Salz in der Suppe.

Ich wünsche allen Entwickler-Kollegen ein schönes – bugfreies Wochenende!

Softwarefehler in kritischen Umgebungen vermeiden durch Systemtests

Es gibt Situationen, in denen Softwarefehler lebensgefährlich werden können.

Dies zeigte sich in den vergangenen Tagen, als in den USA ein Sicherheitsleck in einem Herzschrittmacher bekannt wurde.

Dieser Vorfall ist jedoch nicht das erste Mal binnen eines guten Jahres, in dem intelligente Implantante in den Focus der Entwickler gerieten. Auf dem 32. Chaos Communication Congress Ende 2015 hatte eine Sicherheitsexpertin, die selbst einen Herzschrittmacher trägt, auf das Problem hingewiesen, wie auch auf der Seite heise.de des Computermagazins c’t zu lesen war.

Dies sind nur zwei Beispiele, in denen deutlich wird, welche Relevanz Softwarefehler heutzutage für das menschliche Leben haben können.

Systemtests nicht vernachlässigen!

Dennoch ist auch bei weniger kritischen Produkten ein umfassender Systemtest nicht zu vernachlässigen. Denn zusätzlich zu der lebensgefährlichen Situation, in die ein Softwarefehler einen Anwender bringen kann, kommen hier häufig die hohen Kosten für ein Update, ja teilweise die Unmöglichkeit, die Software zu aktualisieren.

Insofern ist auch beim Softwaretest Expertenwissen erforderlich. Wenn dieses jedoch nicht im Hause vorhanden ist, da die Software nur einen kleinen Anteil am Gesamtprodukt hat, bietet sich der Kontakt zu externen Dienstleistern an. Wir unterstützen wir Sie gern, z.B. beim Erstellen eines Testplans und bei der Ausführung der Tests. Auch bei der Entwicklung eines kompletten Entwicklungsprozesses stehen wir gern beratend zur Seite.

Sprechen Sie uns an, z.B. per Email über contact@qa4software.de

Testing durch 4-Augen-Prinzip

Warum muss eine Software durch spezialisierte Tester geprüft werden?

Warum kann man den Systemtest nicht durch den Entwickler vornehmen lassen?

Gerade jetzt, nach der Weihnachtszeit drängt sich der Vergleich mit einem mehrgängigen Menü auf:

Sie haben eine Vorspeise, eine Hauptspeise und einen Nachtisch für Gäste ausgesucht. Sie versuchen sich an Rezepten, die neu sind, denn Sie wollen die Gäste ja überraschen.

Wenn im Rezept steht, dass Sie mit „reichlich Dill“ abschmecken sollen, wieviel ist dann „reichlich“. Oder der „Schuss Rotwein“ – wieviel ist das? Wenn Sie schon häufiger gekocht haben, werden Sie diese Frage beantworten können mit „Das habe ich im Gefühl“.

Sie brauchen niemanden neben sich, der Ihnen sagt, ob die Suppe die richtige Konsistenz hat, oder die Kartoffeln gar sind.

Aber bei der „Zubereitung von Software“? Haben Sie da auch alles im „Gefühl“?

Gerade wenn es um die Frage geht, ob die Anforderungen des Kunden auch so umgesetzt wurden, wie er es sich wünschte, kann eine zweite Meinung die Chance erhöhen, auf Anhieb den Kundenwunsch komplett umzusetzen.

Wenn es nicht um eine Neuentwicklung geht, sondern um eine Softwareerweiterung, sind Sie als Entwickler vielleicht so sehr auf die neuen Funktionen konzentriert, dass Sie alte Funktionalität übersehen und dann versehentlich zerstören oder entfernen.

Dies macht deutlich, wie wichtig ein detaillierter Testplan und ein unabhängiger Tester sind. Wir bieten Ihnen an der Stelle gern unsere Erfahrung und unsere Werkzeuge, um Testpläne zu erstellen und zu pflegen. Diese Testpläne können dann regelmäßig durchgeführt werden, und das Produkt so auf gleichbleibende Qualität geprüft werden.

Wenn Sie Interesse oder weitere Fragen haben, erreichen Sie uns unter contact@augmenvis.de und besuchen Sie uns auf http://www.qa4software.de/