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.

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.

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 kann, 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 richtig Software 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/