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

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!

SoftwareQS als Dienstleistung, damit der Fehler nicht zum Kunden gelangt.

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.

Was macht gute Software aus? (AAU – anonyme Apple User zur Qualität)

 

Hallo, ich bin Andreas und ich bin Mac-User!
Was für den einen oder anderen abfälligen Blick im Team sorgt..
Doch, dass ich Apple-Produkte nutze hat einen Grund!
Und der liegt in der Software-Qualität.

Ein kleiner Blick in die Vergangenheit:

2008; nach meinem ersten Jahr der Selbstständigkeit (Vertriebsaussendienst, Road-Warrior) reichte mein 1,6k€ teures Windows-Notebook, nach 2 Jahren imtäglichem Einsatz, den Löffel. Es musste also leistungsfähiger Ersatz her. Da auch das Enterprise-Office-Paket stark angejahrt war, ging die Rechnerei los. Neues Notebook+Office-Paket+X+Y+Z= viel Geld.

Zu dieser Zeit warb Apple mächtig um Umsteiger von Windows, mit Boot Camp und Parallels Desktop. Daher wagte ich das Experiment, da auch der Windows-Ersatz teuer geworden wäre, und schaute, was die Mac-Welt zu bieten hat. Gut, das Design und die Qualität der Komponenten hatten natürlich auch einen gewissen Einfluss. So kam ich zu meinem ersten MacBookPro mit iWork.
Die Feststellung nach wenigen Wochen? Große Verwunderung. Es war tatsächlich möglich an einem System zu arbeiten, das stabil läuft!
Keine Abstürzenden Office-Anwendungen, die einen um Stunden zurückwerfen, weil mal wieder vergessen wurde Zwischenstände zu speichern. Kein Blue-screen. Sofortige Einsatzbereitschaft nach dem Wecken aus dem Stand-by. System-Neustart.. wie geht das?

Kurz um, das Ding lief einfach und nervte nicht.
Selbige Beobachtung machte ich beim Wechsel von meinem Motorola Milestone auf mein erstes iPhone. Snappy in der Bedienung, stabil und funktional.
Langsam zeigten sich auch die Vorteile des Öko-Systems. Smartphone und Mac-Book funktionierten einfach zusammen. Keine Schmerzen, einfach nur Funktion.

Doch warum schreibe ich das auf dieser Seite??
Diese Erfahrung war für mich prägend in Sachen Software-Qualität!

Ok, mittlerweile bin ich in dieser Richtung auch verwöhnt und ertrage geringe Qualität in Software oder dem UI nur noch schwer. Seit dieser Zeit verstand ich Michaels Job des Softwaretesters und Software Qualitätsmanagers erst richtig.
MacOS und iOS laufen in ganz weiten Strecken absolut problemlos. Man kann davon ausgehen, dass schon während der Entwicklung kontinuierliches Testing stattgefunden hat. Und dass im Team einige Software-Qualitätsmanager sich viele Gedanken gemacht haben, wie man diese Software richtig testet. Da waren sicher gigabyteweise Testpläne erstellt, die jeden noch so unwahrscheinlichen Fall abdeckten. Diese Testpläne wurden durchgearbeitet, dann wurde gefixt. Und dann wurden sie noch einmal durchgearbeitet, dann wurde gefixt, und so weiter und so fort.

Dieser Aufwand kostet natürlich Zeit und Geld, einer der Gründe warum Produkte mit dem angebissenen Apfel doch etwas teurer sind als das Plaste-Notebook mit WindowsXYZ vom ortsansässigen Elektronik-Markt.
Auf lange Frist macht sich diese Qualität aber auch bemerkbar!

Eine Bitte an alle Softwareentwickler:

Wenn Ihr Software entwickelt, dann lasst sie bitte von einer anderen Person, die nicht in der Entwicklung beteiligt war, testen. Gut wäre es wenn Ihr hier für selbst einen umfangreichen Testplan erstellt habt. Noch besser ist es, wenn dieser Testplan von jemandem, basierend auf eurer Dokumentation oder Spezifikation erstellt hat. Diese unabhängige Person sollte den Plan nur abarbeiten und testen bis sie die Nase voll hat. Und dann bittet die nächste Person das Selbe zu tun. Und dann eine dritte Person. Und den nächsten, und den nächsten. Denn nur so, durch Softwaretest und Bugfixing, wird daraus ein Stück Software, was man gerne benutzt, weil es einfach funktioniert!

Wir helfen euch hierbei gerne, wenn Ihr selbst keine Zeit, keine Lust oder nicht genügend belastbare Mitarbeiter oder Bekannte habt 😉

Schaut hierzu vorbei auf: www.qa4software.deQA4software by AugMenVis

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!