Brauch man wirklich eine Qualitätssicherung (QA)?

"QA or not QA, that is the question!"

Lesezeit ca 8 Minuten

Die Frage, ob Testing und QA in der Softwareentwicklung unverzichtbar sind, beschäftigt viele. Die Antwort darauf ist komplex und hängt von verschiedenen Faktoren ab, darunter die Projektnatur, die Zielgruppe und die Qualitätsanforderungen. In diesem Beitrag werde ich Licht ins Dunkel bringen und euch bei der Entscheidungsfindung unterstützen.

Ziel ist es, dass ihr am Ende dieses Blog-Beitrags nicht nur ein besseres Verständnis für Testing, QA und Qualitätssicherung habt, sondern auch in der Lage seid, die Frage "Brauche ich wirklich QA?" für euer Projekt oder Unternehmen präziser zu beantworten. Lasst uns gemeinsam einen Schritt näher an eine fundierte Entscheidung herankommen!

Die Grundeinstellung ist entscheidend!

"I dont always test my code...But when I do, I do it in production!"

Die Grundlage für die Frage nach QA und ihrer Antwort liegt bereits in der individuellen und persönlichen Einstellung zum Thema "Fehler".

Bin ich ein Perfektionist, der fehlerfrei arbeiten will oder jemand, der stark auf sein Image achtet? Oder sind mir Fehler gar unangenehm und peinlich? Dann gehöre ich eher zur Kategorie: "Ich brauche QA!".

Gehe ich jedoch eher mit der Einstellung konform, dass Fehler menschlich sind, oder habe eine lockere Einstellung gegenüber meines Images, bis hin zu "der Benutzer kann ruhig mit testen", dann würde ich sagen, dass diese Gruppe eher in den Bereich fällt: "Ich brauche keine QA!".

Diese zwei Gruppen sind natürlich stark vereinfacht dargestellt, um einen Überblick zu geben. Es gibt selbstverständlich auch viel dazwischen. Manche könnten zum Beispiel anerkennen, dass Fehler auftreten können, aber dennoch eine gewisse Qualitätssicherung für wichtig halten, um das Nutzererlebnis zu verbessern oder das Vertrauen der Kunden zu stärken. Letztendlich kann man durch diese Gruppierung die verschiedenen Einstellungen besser verstehen und entsprechend damit arbeiten.

Testing und die Psychologie

"Nobody is perfect, call me Nobody!"

Testing und die Psychologie spielen meiner Meinung nach eine entscheidende Rolle im Kontext der Frage, ob eine Qualitätssicherung (QA) notwendig ist oder nicht, da sie alle anderen Aspekte maßgeblich beeinflussen können.

Ein besonders wichtiger Aspekt ist die Selbstwahrnehmung der Arbeitsqualität. Dabei gibt es verschiedene Typen von Personen, von denen einige extrem unsicher sind und ständig Feedback benötigen, während andere selbstbewusst behaupten, nie Fehler zu machen.

Ein praxisnahes Beispiel verdeutlicht oft besser als theoretische Überlegungen: Nehmt ein Blatt Papier und einen Stift und schreibt einen Text, bis die Seite vollgeschrieben ist. Korrigiert dann euren Text und zählt die Fehler, die ihr gefunden habt. Anschließend gebt ihr den Text einer zweiten Person und bittet sie, ihn zu korrigieren. In den meisten Fällen wird die zweite Person weitere Fehler finden als ihr selbst nicht gefunden habt.

Warum ist das so? 

Weil wir Menschen sind und unsere eigenen Fehler oft nicht wahrnehmen. Dies liegt teilweise an psychologischen Mechanismen wie der Betriebsblindheit, bei der man dazu neigt, Fehler in eigenen Arbeiten zu übersehen. Die Anerkennung dieser menschlichen Tendenz ist entscheidend, um die Wichtigkeit von Testing und Qualitätssicherung zu verstehen und entsprechende Maßnahmen zu ergreifen.

Das Testobjekt ist relevant

"Does the flap of a butterfly’s wings in Brazil set off a tornado in Texas?"

Ein weiterer bedeutender Faktor bei der Klärung der Notwendigkeit von Qualitätssicherung (QA) ist zweifellos das zu testende "Testobjekt".

Komplexe WEB-Systeme mit Backend, Frontend und APIs stellen für Entwickler eine größere Herausforderung beim Testing dar im Vergleich zu einfachen "One-Page Landingpages", bei denen hauptsächlich das Look-and-Feel überprüft werden muss.

Bei komplexen Systemen sind umfangreiche Tests erforderlich, die verschiedene Aspekte wie Funktionalität, Performance, Sicherheit und Benutzerfreundlichkeit abdecken. Dabei kann die Implementierung von QA-Verfahren und -Tools entscheidend sein, um eine effektive Qualitätssicherung zu gewährleisten und mögliche Fehler frühzeitig zu erkennen. Automatisierte Testing-Methoden können dabei helfen, die Effizienz und Genauigkeit der Tests zu verbessern und gleichzeitig den Zeitaufwand zu reduzieren.

Risk-Management

"No risk, no fun? Get your thrills elsewhere!"

Das Risk-Management ist bei der Entscheidung, ob Qualitätssicherung (QA) benötigt wird oder nicht, ein entscheidendes und äußerst hilfreiches Werkzeug. Die Frage, die man sich hier stellen muss, ist:

Wie groß sind die Folgen, wenn meine Software nicht einwandfrei funktioniert?

Gefahr für Leib und Leben

Heutzutage wird viel über Software gesteuert, bei der auch indirekt Menschenleben in Gefahr sein könnten; sei es in autonom fahrenden Fahrzeugen oder in der Bordsoftware von Schiffen oder Flugzeugen.

Finanzielles Risiko

Welche Auswirkungen hat eine nicht korrekt funktionierende Software im Bereich finanzieller Ausfälle? Sei es, dass es zu Downtimes kommt und kein Kunde eine Bestellung machen kann, oder dass die Preise falsch angezeigt werden, Bestellungen nicht verarbeitet werden können oder die Payment-Schnittstellen nicht korrekt angebunden sind? Die Liste ist endlos!

Image und Vertrauen

Was passiert bei einem Imageverlust? Kann ich mir einen Imageverlust leisten? Kann beispielsweise ein User, der schlechte Bewertungen in sozialen Netzwerken abgibt, mein Geschäft beschädigen? Kann ein Kunde aufgrund einer fehlerhaften Software mein Unternehmen verklagen und damit eventuell in Schieflage bringen?

Liefer ich Software an einen Kunden aus und dieser findet (wiederholt) Fehler nach der Auslieferung der Software; wie tolerant ist der Kunde? 

Wie tolerant wärt ihr, wenn ihr euer Auto oder Fahrrad nach einer Reparatur zwei- bis dreimal wieder in die gleiche Werkstatt bringen müsstet, weil euch immer wieder neue Fehler auffallen? Ab welcher Anzahl an Fehlern würdet ihr eine neue Werkstatt suchen? Und würdet ihr die alte Werkstatt weiterempfehlen, wenn euch jemand danach fragt?

Wir leben leider in einer "Nicht-Fehler-Toleranten-Gesellschaft". 

Das bedeutet: Mach etwas neunmal richtig und einmal falsch; das Negative wird hervorgehoben und nicht neunmal das Lob ausgesprochen. Auch das sollte bei der eigenen Fehler-Toleranz der Software berücksichtigt werden.

Time to fix

Auch diese Frage ist im Bereich des Risk-Managements relevant: Wie lange brauche ich, um einen eventuell auftretenden Bug zu fixen? Habe ich Zugriff auf Entwickler? Habe ich selbst Zeit, den Bug zu fixen, oder bin ich bereits in andere Projekte eingebunden? Wie schnell kann ich ein Deployment durchführen, wenn der Bug behoben ist? Habe ich Testressourcen, um den Bugfix zu testen?

Wer ist mein Kunde?

Ist mein Kunde eventuell ein Freund oder Bekannter? Dann ist es eventuell nicht so schlimm, wenn Fehler übersehen werden. Ist mein Kunde ein Industriegigant, der eventuell noch eine interne QA-Abteilung hat und Software von externen nochmals prüft, dann ist es vielleicht doch ratsam, eine eigene QA zu haben.

Wirtschaftlicher Faktor vs Mindset

"Time is money!" / "If we dont test, we dont find bugs!"

Natürlich spielt auch die finanzielle Seite eine Rolle, wenn es um die Implementierung von Qualitätssicherung (QA) und Testing geht. 

Hier sollten folgende Fragen berücksichtigt werden:

Welche Kosten könnten mögliche Fehler verursachen? Durch eine Auflistung der potenziellen Risiken im Risk-Management könnte eine Wirtschaftlichkeitsberechnung durchgeführt werden: Ab wie vielen Bugs hätte sich eine QA gelohnt? Allerdings sind hier auch "hypothetische Fälle" enthalten, die schwer zu quantifizieren sind - ein typischer Fall von "was wäre wenn?".

Erst im Fehler- oder Ernstfall ist man froh, eine QA zu haben. Ein Beispiel hierfür sind gängige Versicherungen: Eine Fahrradversicherung mag mit ihren Beiträgen lästig sein, aber man ist froh, sie zu haben, wenn das Fahrrad gestohlen wird.

Das Mindset lautet hier: "Lieber haben und nicht nutzen als nicht haben und es brauchen". Übertragen auf die QA würde es heißen: "Lieber einen Tester in der Hand als einen Bug auf dem Dach!"

Die QA kann als Versicherung oder doppelter Boden oder als "Quality Gate" zwischen Software und Kunden betrachtet werden.

Hinzu kommt, dass ein QA-Mitarbeiter nicht nur Fehler findet, sondern auch viele weitere Leistungen erbringt, die ich in einem weiteren Blog-Beitrag erläutern werde.

Vergesst nicht: Eine gute QA sollte kein Engpass im Entwicklungsprozess sein, sondern eher ein Beschleuniger im Team. Mit guten automatisierten Tests kann die QA das DEV-Team unterstützen, indem sie schnelle und wichtige Testergebnisse mit breiter Testabdeckung liefert.

Auch das gängige QA 1x1 sollte beachtet werden: Der teuerste Fehler ist der, der in der Produktivumgebung gefunden wird. Hier werden Kosten zwischen 30x und 50x höher kalkuliert als wenn der Fehler während der Anforderungsanalyse entdeckt worden wäre. Frühzeitige Fehlererkennung ist also wirtschaftlicher und spart am Ende Zeit und Geld.

Ps.: Die meisten IT-Projekt-Budgets werden durch Softwarefehler überschritten.

Was ist also das Fazit?

Die Frage, ob Quality Assurance (QA) und Testing in der Softwareentwicklung unverzichtbar sind, ist von entscheidender Bedeutung. Sie hängt von zahlreichen Faktoren ab, darunter die Projektnatur, die Zielgruppe und die Qualitätsanforderungen. Eine fundierte Entscheidung erfordert eine umfassende Analyse dieser Aspekte.

Das Mindset und die individuelle Einstellung zu Fehlern spielen eine Schlüsselrolle bei der Beantwortung dieser Frage. Ein Verständnis der eigenen Fehler-Toleranz ist entscheidend für die Einschätzung der Notwendigkeit von QA-Maßnahmen.

Testing und die Psychologie spielen ebenfalls eine wichtige Rolle. Die menschliche Neigung, eigene Fehler zu übersehen, unterstreicht die Bedeutung von QA-Verfahren zur frühzeitigen Fehlererkennung und -behebung.

Die Art des zu testenden "Testobjekts" ist ebenfalls entscheidend. Komplexe Systeme erfordern umfangreiches Testing, während einfachere Projekte möglicherweise weniger aufwendige QA-Maßnahmen erfordern.
Das Risk-Management ist ein hilfreiches Werkzeug zur Bewertung potenzieller Risiken von Softwarefehlern. Von Gefahren für Leib und Leben bis hin zu finanziellen Risiken und Imageverlusten gibt es verschiedene Aspekte zu berücksichtigen.

Der wirtschaftliche Faktor und das Mindset sind ebenfalls von Bedeutung. Eine effektive QA kann als Versicherung betrachtet werden, die finanzielle und imagebezogene Risiken minimiert. Die frühzeitige Fehlererkennung und -behebung spart letztendlich Zeit und Geld.

Insgesamt ist es wichtig, die Bedeutung von QA und Testing zu erkennen und entsprechende Maßnahmen zu ergreifen, um die Qualität von Softwareprodukten zu gewährleisten und potenzielle Risiken zu minimieren. Denn wie oft gilt: Die meisten IT-Projekt-Budgets werden durch Softwarefehler überschritten.

Schlussworte

Wenn Ihr sicherstellen möchten, dass eure Softwareprodukte von höchster Qualität sind und potenzielle Risiken minimiert werden, dann solltet Ihr auf eine effektive Qualitätssicherung (QA) und umfassendes Testing setzen. Ich unterstütze euch sehr gerne auf diesem Weg! 

Ich hoffe, dieser Beitrag hat euch bei der Beantwortung der Frage "Brauche ich eine QA oder nicht?" geholfen. Sollten noch weitere Fragen offen sein, freue ich mich auf eure Anfrage und Kontakt, damit wir diese gemeinsam erläutern können. Natürlich bin ich auch offen für euer Feedback!

Autor: Julian Farizi / 2024 / QA or not QA