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

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!

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/

Das ideale Bugticket und seine Rolle in der Softwarequalitätssicherung

Heute beschäftigen wir uns mit dem idealen Bug-Ticket.

Das ideale Bugticket existiert nicht… denn der Wunsch aller Software-Entwickler – und das schließt die Qualitätssicherung mit ein – ist eine fehlerfreie Software.
Da dieser Wunsch wohl ein Traum bleiben wird, wollen wir uns mit der Frage befassen, welche Angaben ein solches Bugticket umfassen sollte.

 Angaben im idealen Bugticket

  • Überschrift – die Überschrift sollte präzise auf den ersten Blick die Auswirkung und Ursache eines Fehlers darstellen.
    Ein schlechtes Beispiel wäre wohl „Datenverlust in Applikation“
    Gut hingegen „Datei wird nicht überschrieben, wenn Button Speichern gedrückt wird“
  • Die Beschreibung – sie sollte detailliert erklären, was der konkrete Fehler ist. Außerdem muss sie eine Beschreibung enthalten, wie der Fehler reproduziert werden kann. Welche konkreten Schritte sind zu unternehmen.
    Dies ist zwingend erforderlich für den Entwickler, der den Fehler finden soll, und für den Tester, der nachher die Behebung des Fehlers feststellen muss.
    Ein Fehler, der nicht reproduzierbar ist, kann nicht behoben werden!
    Vergessen Sie nicht zu erwähnen, in welcher Version der Fehler auftrat. Eine Behebung findet manchmal Wochen oder Monate später statt, und der Fehler ist auf dieser Version dann schon „zufällig“ durch jemand anderen behoben worden.
  • Arbeiten Sie im Projekt mit einer Komponenten-Einteilung, oder sonstigen Zuweisung?
    Dann tun Sie Ihren Kollegen einen Gefallen, und wählen Sie gleich die richtige Komponente aus. Eine falsche Komponente sorgt im Zweifelsfall dafür, dass ein Ticket nicht bearbeitet werden kann.
  • Haben Sie eine bestimmte Konfiguration Ihres Programms, die erforderlich ist, um den Fehler zu reproduzieren?
    Nutzen Sie die Möglichkeit, Dokumente an das Bugticket anzuhängen.
    Dasselbe gilt für Logdateien, auch diese sind häufig hilfreich bei der Fehlerfindung
  • Einteilung eines Fehlers in Bezug auf die Schwere:
    In manchen Ticketing-Systemen ist nur es möglich, eine Wahl zwischen „Hoch“, „Mittel“, „niedrig“ zu treffen.
    Andere Systeme hingegen erlaube eine Einteilung in 2 Dimensionen: Dringlichkeit und Schwere des Fehlers. Diese Einteilung werden wir zu einem späteren Zeitpunkt detailliert behandeln.An dieser Stelle nur soviel: Die Dringlichkeit gibt an, wie schnell ein Fehler behoben werden muss („spät“, „sofort – die Testabteilung kann sonst nicht weiter arbeiten“). Die Schwere des Fehlers hingegen gibt an, mit welchen Folgen ein Fehler verbunden ist (kritischer Fehler – „Datenverlust“, kosmetischer Fehler – „Tippfehler“).Auch ein Tippfehler kann ein release verhindern, zum Beispiel, wenn die Email-Adresse des Unternehmens falsch eingetragen ist.

Test-Ebenen und Test-Akteure

Software-Test-ToolboxDas Testen der Software kann sowohl durch den Lieferanten / Hersteller geschehen, wie auch durch den Kunden, der seinen Einsatzzweck umgesetzt sehen will.
Auf Seiten des Herstellers wird der Test dann noch in verschiedene Ebenen unterteilt.

Testebenen

  • Unit-Test / Komponenten-Test

    Dies ist die Ebene, die dem Quellcode am nächsten ist. Es werden einzelne Software-Module getestet. Ziel des Tests ist es, dass die einzelnen Module die geplante Funktionalität für sich bereit stellen können.
    Diese Art von Test obliegt typischerweise dem Entwickler. Wobei wir auch hier gern für Sie da sind und Hilfestellung zu leisten. Dafür setzen wir ein Gerüst auf und implementieren erste Tests.

  • Integrations-Test

    Hier werden einzelne Komponenten miteinander getestet. Ziel dieses Tests ist es, die definierten Schnittstellen zwischen den Komponenten zu testen. Diese Teststufe ist ebenfalls noch recht nah am Code. Sie umfasst aber mehrere Komponenten und damit ggf. schon mehrere Entwickler. Dies ist immer auch abhängig von der Größe des Teams.

  • System-Test

    Dieser Test umfasst das Gesamt-System, und findet auf einer Test-Umgebung statt, kann also noch durch das liefernde Unternehmen abgebildet werden. Es werden sowohl funktionale wie auch nicht-funktionale Anforderungen überprüft.

Dem Kunden obliegt letztlich der
  • Abnahme-Test

    Die Durchführung erfolgt nicht mehr anhand von Testdaten auf einer Testumgebung, sondern in der Produktiv-Umgebung, mit realen Daten.

Wir sind in der Lage, Sie als Hersteller während der Entwicklung zu begleiten und Ihnen bei der Test-Entwicklung und -Durchführung zu unterstützen.
Aber auch Kunden, die eine Sonder-Entwicklung in Auftrag gegeben haben,  helfen wir gern. Und stellen sicher, dass das Lastenheft umfassend überprüft wird.
Durch unsere langjährige Erfahrung können wir Ihnen in beiden Fällen helfen.  Besonders beim Abbauen der Sprachbarrieren, die zwischen den häufig technisch geprägten Entwicklungs-Abteilungen und den Fachabteilungen bestehen. Dadurch erreichen Sie das richtige Ergebnis in kürzerer Zeit!

Das Handwerkszeug des Projektteams

In diesem Post soll es um das Handwerks-Zeug aller Akteure in der Software-Entwicklung gehen.
Welche Tools benötigen die Akteure nun, um ihre Aufgaben zu erfüllen?
Wo notiert der Product Owner seine Anforderung? Wo speichert der Entwickler seinen Quellcode? Und worauf greift der Tester zurück, wenn er das Produkt installieren will?
Es gibt mindestens 3 Werkzeuge, die für ein Gelingen vorhanden sein sollten. Weitere Werkzeuge können sinnvoll sein, abhängig von der Situation.
  1. Das Ticketing-System,

    auch als „Bug-Tracker“ bezeichnet, ist eigentlich viel mehr als eine Sammlung
    Es ist die zentrale Anlaufstelle, um alle Änderungswünsche „mundgerecht“ zerlegt auszutauschen:
    * Der Product-Owner kommuniziert seine Wünsche
    * Die Qualitätssicherung meldet Programmfehler („Bugs“), die während vor der Veröffentlichung, dem Release des Produkts aufgefallen sind
    * Der Support meldet Programmfehler, die von Kunden berichtet wurdenJedes Ticket besitzt seine eigene Geschichte, und man kann im Prozess verfolgen, wer ein Ticket bearbeitet hat, und ob bzw. wie es gelöst wurde.Das Ticket-System bildet sozusagen den Dreh- und Angelpunkt der Planung und gibt detaillierten Aufschluss über die Historie bzw. die zukünftige Planung.

  2. Das Repository, auch als Projektarchiv bezeichnet

    Es beinhaltet den nachvollziehbaren Versionsstand einer Software.
    Hier werden alle Quelldateien der Entwicklung eingestellt und alle Änderungen nachvollzogen. Dies ist sozusagen Ihr Kapital, Ihr Projektschatz.
    Sie sind in der Lage Änderungen bis zum Beginn des Projekts zurückzuverfolgen und, falls erforderlich, wieder rückgängig zu machen.

  3. Der Build-Server

    Im Rahmen der Nachverfolgbarkeit ist der Build-Server die Umgebung, die aus einem Software-Stand aus dem Repository immer wieder dieselbe Version an Software liefern kann – auch nach Jahren!Nur die Software, die vom Build-Server gebaut worden ist, kann als vertrauenswürdig und reproduzierbar angesehen werden.Einmal fertig konfiguriert, liefert der Build-Server eine Software-Version, die Sie direkt auf Ihrer Zielumgebung installieren können.

Theoretisch ist es natürlich auch möglich, die Anforderungen per Email zu senden, anstatt Bugtickets zu schreiben, dem Entwickler zu zeigen, was „schief läuft“. Man nimmt dann allerdings in Kauf, dass man nach einigen Jahren nicht mehr weiss, wie man sich mal geeinigt hat. Auf ein Ticketingsystem hat jeder Zugriff, die Mails sind typischerweise nur für persönlich durch einen Mitarbeiter zugreifbar.
Und auch ohne Repository kann man die Daten archivieren: Man erstellt einfach ZIP-Dateien mit dem Tageswerk. Nur fragen Sie sich dann, wann denn die Änderung X eingeflossen ist. Spätestens, wenn Sie mehrere Entwickler auf einem Projekt haben, wird es jedoch unübersichtlich!
Ein Build-Server ist sicherlich die Komponente, die am ehest verzichtbar ist. Eine Software „von Hand“ compiliert und ausgeliefert werden. Allerdings wird man vermutlich Schritte vergessen, die Reihenfolge der Schritte verändern oder vergessen, eine Datei zu übertragen. Und dann haben Sie die Software beim Kunden, und sie läuft nicht.
Glauben Sie nicht? Alles schon erlebt…