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

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

 

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

Bug-Triage – was soll das?

In diesem Artikel widmen wir uns der „Bug-Triage“.
Es handelt sich dabei um einen Teil-Prozess, der Software-Entwicklung, der in den späteren Projektphasen zum Tragen kommt.
Eine Triage wird abgehalten, um die anfallenden Bug-Tickets nach Schwere einzuteilen bzw. die bisher getroffenen Einschätzungen zu revidieren.
Der Begriff ist entliehen aus der Beurteilung von Verletzten in Großschadenslagen. Das medizinische Personal muss hier sinnvoll eingesetzt werden, da es mehr Patienten gibt als man gleichzeitig behandeln kann. Daher wurde dieses Verfahren entwickelt, um schnell festzustellen, welche Patienten dringend Hilfe bedürfen – wegen lebensgefährlicher Verletzung, und welche Patienten nur leicht verletzt sind.
Und in der Software-Entwicklung?
Hier ist eine Bug-Triage anzuberaumen, wenn die Zeit bis zum Liefertermin nicht mehr ausreicht, um alle offenen Bugtickets bearbeiten zu können. Dies ist leider häufig der Fall. Es wird immer wieder Fehler geben, die man nicht rechtzeitig beheben kann.
Zum Glück haben wir in der Software-Entwicklung manchmal die Alternative, ein Release zu verschieben, aber das ist weder die Entscheidung der Qualitätssicherung noch die Entscheidung der Entwickler.
In der Bug-Triage sitzen deshalb typischerweise mindestens folgende Rollen vereint an einem Tisch:
  • ein Vertreter der Software-Qualitätssicherung – er kann Auskunft über die einzelnen Bugtickets geben, und einschätzen, wie schwerwiegend ein Fehler ist
  • ein Vertreter der Entwicklung – er kann Auskunft darüber geben, wie aufwändig ein Fehler zu beheben ist, und ob ggf. Seiteneffekte zu beachten sind, die der Qualitätssicherung noch nicht bekannt sind
  • eine Vertreter des Projekt-Managements – er kann abschätzen, ob man einen Fehler im Produkt eher akzeptieren kann als einen verschobenen Liefertermin – oder umgekehrt.
Manchmal wird auch explizit noch der Product Owner, der die Produktverantwortung im Haus trägt, diesen Treffen beiwohnen.
Ziel dieser Treffen ist es, sich möglichst schnell auf einen Weg zu einigen, wie mit den Patienten – also den einzelnen Fehlern – umgegangen werden soll. Welcher Fehler ist „lebensgefährlich“ und wird daher sofort behandelt? Welche Fehler ist „hinnehmbar“, und die Behandlung kann auf später vertagt werden?
Um das Treffen effizient zu gestalten, sollte allen Parteien genügend Gelegenheit gegeben werden, die Bugreports vorab zu lesen, und eine Klassifikation im Sinne eines Schweregrads und Aufwands vornehmen zu können. So können einzelne Analysen im Treffen vermieden werden.
Üblicherweise wird man die Bewertung eines Bugtickets in Bezug auf Schwere und Dringlichkeit überarbeiten. Zusätzlich wird man einen Schwellwert setzen, bis zu dem Fehler noch bearbeitet werden – bzw. welche Fehler im Release noch enthalten sein werden.
Wann ist eine solche Bug-Triage sinnvoll?
Die Triage wird in dem Moment erforderlich, wenn man merkt, dass die Projektzeit „knapp“ wird, wenn also der Liefertermin bei Fehlerfreiheit nicht garantiert werden kann.
Was sind die Risiken, wenn man diese Triage nicht durchführt?
Die Partei, die im Unternehmen den stärksten Einfluss hat, wird siegen.
  • die Software-Qualitätssicherung könnte das optimale Produkt fordern, ohne Rücksicht auf den Liefertermin
  • die Entwicklung arbeitet möglicherweise nicht an den wichtigen Bugtickets
  • das Projekt-Management muss ein Produkt liefern, welches mehr Fehler besitzt als erforderlich

Die Rollen in der Software-Entwicklung

In diesem Blog-Post beleuchten wir die verschiedenen Akteure.
Diese Rollen sind Ihnen wahrscheinlich wohlbekannt, sie sollen dennoch einmal kurz umrissen werden, letztlich auch, damit die Namensgebung klar wird.

Die Rollen sind im Wesentlichen die folgenden:

1. der Product Owner / der Produktverantwortliche
Der Produktverantwortliche bestimmt die Zielrichtung, in die ein Projekt entwickelt werden soll. Diese Zielrichtung kommuniziert er in Form eines Lastenheft an die Entwicklung, damit diese für ihn das Produkt entwickelt.
2. Der Entwickler
Er setzt das Lastenheft um, um eine bestehende Software zu erweitern, oder um eine Software von Grund auf zu entwickeln.
Bis auf das Lastenheft ist er frei in der Wahl seiner Mittel.
3. Der Qualitätssicherer / Tester
Die Software-Qualitätssicherung ist dafür verantwortlich, sicherzustellen, dass das Lastenheft umgesetzt wurde. Bei einem bereits bestehenden Produkt stellt er darüber hinaus sicher, dass die alte Funktionalität immer noch gegeben ist.

Je nach Größe eines Projekts kommen noch verschiedene Rollen zum Tragen, sei es eine Dokumentationsabteilung, eine Support-Abteilung, eine Marketing-Abteilung.
Je größer das Projekt, desto notwendiger ist eine Projektsteuerung, besetzt durch einen Projekt-Manager.

Die oben explizit genannten Rollen stehen in ständigem Austausch miteinander, um gegebenenfalls Änderungen am Zielprodukt vornehmen zu können, wenn sich die Umstände ändern.