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

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.