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

„Patch me if you can“ – Software-Updates sind Pflicht!

Auf einem Netzwerk-Treffen in der letzten Woche wurde eine wertvolle Lektion erteilt:
Sicherheits-Updates („Security-Patches“) gibt es nur von großen Herstellern. Und ich rede von den wirklich großen Herstellern, wie Oracle, Microsoft, Apple.

Die Unternehmen, die auch groß sind, aber nicht die Alleinstellungsmerkmale wie diese Unternehmen besitzen, z.B. Samsung, liefern weniger häufig oder nur verspätet Sicherheit-Updates für bereits veröffentlichte Produkte.

Woran liegt das? Natürlich können wir nur mutmaßen, aber verschiedene Gründe kommen in Frage:

  • Entweder der Lieferant will die Entwicklungs-Abteilung bzw. die Qualitätssicherung nicht mit zusätzlichen Aufgaben belasten, indem man für bereits abgelöste Produkte Updates bereitstellt. Die Updates müssen ja komplett geprüft werden, um weitere Fehler auszuschließen
  • Die Marketing-Abteilung oder das Produkt-Management hat entschieden, dass es für Kunden Kaufkriterium ist, auf dem aktuellen Stand zu sein. Dies kann man natürlich erreichen, indem man nur für neue Produkte Updates bereitstellt, wenn überhaupt.

Auf dem deutschen Markt wird so etwas kritisch gesehen, da die hiesigen Anwender sehr sicherheitsbewusst sind.

Abgesehen davon ist jeder Lieferant im Rahmen der Produkthaftung zur Bereitstellung eines einwandfreien Produktes verpflichtet, berichtet heise online.

Welche Lehren können wir aus dieser Tatsache ziehen?

  1. Die Software sollte beim ersten Release schon so gut sein, dass sie keine baldigen Updates benötigt. Da hilft es, wenn man professionelle Hilfe bei der Erstellung von Testplänen hat, und eine unabhängige Mannschaft, die die Tests durchführt. Dies hilft, einen unverstellten Blick aus Nutzersicht zu erlangen.
  2. Die internen Strukturen kann man durch Tests „von außen“ nur schwer erreichen. Daher unterstützten wir auch bei weiteren Test-Aktivitäten wie Code-Reviews und der Erstellung und Pflege automatischer Tests.
  3. Strukturierte Testpläne helfen dabei, reproduzierbare und vergleichbare Ergebnisse zu erreichen. Wenn einmal etwas „durchrutscht“ und ein Update erforderlich macht, oder ein Funktionsupdate angeboten werden soll, kann man so erkennen, wie die Qualität im Vergleich zur letzten Version war.
  4. Uns ist klar, dass die Bereitstellung kritischer Software-Updates immer zur Unzeit nötig sind. In Zeiten von erhöhtem Arbeitsaufkommen kann es erforderlich sein, weitere Softwaretester ausleihen zu können. Daher bieten wir Ihnen unsere Mannschaft als zusätzlichen Tester-Pool an.

Sie sehen, dass die Augmenvis GmbH mit ihrem QA4Software-Team Ihnen bei vielen Belangen zur Seite stehen kann.

Sprechen Sie uns an, damit wir mit Ihnen ein individuelles Konzept ausarbeiten können. Eine Mail an contact@augmenvis.de genügt.

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“.

 

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/