Bist Du verantwortlich für Software-Projekte in Deinem Unternehmen und mit Software-Problemen konfrontiert? Möchtest Du deren Qualität verbessern und hast keine Ahnung, wo du anfangen sollst? Dann wird dieser Artikel Dir beim Start der Umsetzung von QA-Prozessen helfen!
QS steht für Qualitätssicherung und ist ein sehr wichtiges Thema in der komplexen Welt der Softwareentwicklung. Wir beobachten unsere Software und finden heraus, dass sie von den Kundenerwartungen abweicht. Eine Abweichung in der Software wird Bug genannt. Wenn wir den Bug aus der Software entfernen, bedeutet es nicht automatisch, dass sie jetzt fehlerfrei funktioniert. Anforderung ist die Bezeichnung für Kundenerwartungen zu einem System und es könnte sein, dass der Bug sich auch dort versteckt. Das klingt ja schon schwierig und kompliziert, oder? Deswegen benötigen wir engagierte QA-Ingenieure!
Lass uns mit dem Sicherungs-Anteil an QS beginnen. Spoiler: Niemand in der Industrie kann Dir versichern, dass Deine Software fehlerlos ist. Jede Software hat mindestens einen Bug, die Frage ist: Wissen wir, was es ist, wo es ist und ist es ok für uns, dass andere (Endbenutzer, Konkurrenten, Hacker) ihn auch finden? Wie können wir sichergehen, dass wir alle relevanten Bugs in unserer Software kennen? Wir testen die Software und auch alle andere dazugehörigen Artefakte! Wir können alle Arten von Dokumenten, Designs und Code auch testen. Tester haben eine komplette Toolbox, um Informationen über das System im Test zu sammeln.
Nach einiger Zeit beim Testen beobachtet man, dass es irgendeine Art Muster darin gibt (Tester sind wirklich gut im Erkennen versteckter Muster), wie Bugs auftreten oder wieder auftreten. Wenn Du solch ein Muster entdeckst, dann möchtest Du sicherlich die Menge der bekannten Bugs oder der Bug-Arten in Deiner Software zukünftig verringern. Wir können dabei in zwei Schritte unterteilen:
Warum und wie hat ein Defekt einen Weg in die Software gefunden? Mögliche Fragestellungen dafür sind: Ist unsere Systemarchitektur zu komplex? Schlechte (oder keine) technische Unterlagen? Vage Anforderungen, zu viele Anforderungen, sich widersprechende Anforderungen? Haben wir Mitarbeiter mit den notwendigen Fähigkeiten, um die Software zu entwerfen / umzusetzen / zu testen?
Für die oben genannten Probleme, können wir folgende Ansätze überlegen: Wie können wir unsere Softwarearchitektur designen, sodass dass sie verständiger ist? Ist die Komplexität wirklich notwendig? Sollten wir möglicherweise eine Reihe Richtlinien und Standards definieren, um diese Art des Ausfalls zukünftig zu verhindern? Um die Qualität der Anforderungen zu verbessern, könnten wir eine Checkliste davon erstellen, was gute Anforderungen abdecken sollten, oder ein spezifisches Tool verwenden.
Zusammenfassend lässt sich sagen: mit Hilfe der analytischen Techniken sammeln wir Informationen über die Software, mit Hilfe der konstruktiven Software-Qualitätssicherungsmethoden verhindern wir das Wiederauftreten der Bugs mit einer bekannten Quelle.
Jetzt müssen wir den Qualitäts-Anteil von QS besprechen. Um das Thema besser zu verstehen, lass uns die Analogie eines Stuhls verwenden. Wenn wir neue Stühle für unser Esszimmer benötigen, gehen wir zum Geschäft, sehen 20-30 unterschiedliche Arten von Stühlen und fühlen uns verloren. Wie man das rechte Modell findet? Welchen Stuhl können wir als qualitativ gut beschreiben? Unterschiedliche Leute erachten unterschiedliche Dinge für wichtig. Für mich ist es wichtig, dass die Stühle zum Rest des Innenraums optimal passen und dass sie stabil und leicht zu reinigen sind (wegen der Kinder). Für meinen Sohn hat Priorität, dass er auf ihnen ohne Angst schaukeln kann, so dass er keinesfalls rückwärts umkippt. Die beste Herangehensweise ist, eine Liste von Anforderungen zu erstellen. Benötigen wir Armlehnen? Sollten die Stühle stapelbar sein? Welches Material / welcher Stil / welche Farbe?
Wir tun das Gleiche mit Software. Wir erstellen eine Liste von Anforderungen und messen deren Einhaltungsgrad. Das einzige Problem: Softwareentwicklung ist ein sehr komplizierter Prozess und viele Kunden haben ein mangelndes Verständnis davon. Kundenanforderungen haben aber bis zu 50% Einfluss auf den Projekterfolg. Deshalb sprechen wir von Qualitätsattributen. Eine Methode, um Qualitätsattributen und Metriken einzustufen, ist der Standard ISO/IEC 25010:2011.
Bild von Kristīne Corbus
Genauso wie beim Testen, können Qualitätsaspekte auf alle Arten von Quellen angewendet werden: Software, Untersysteme, Dokumente, einzelne Anforderungen, Design und Code. Wenn Du ein Projekt beginnst, solltest Du entscheiden, welche Qualitätsaspekte Du abdecken möchtest und was Du als Maß verwendest. Wähle es mit Bedacht, denn was Du misst, wirst Du verbessern.
Zur Veranschaulichung der Qualität hatte ich das Beispiel gewählt, wie man aus einer Reihe Stühle den passenden auswählt, aber Software ist ein sehr komplexes System, eher wie ein Haus. Ziemlich häufig in Entwicklungsteams hören wir von Kunden, die sagen: „Wir haben noch nicht alle endgültige Anforderungen, aber ihr könnt bereits beginnen und implementieren, was wir haben.“ Das ist aus vielen Gründen falsch, aber ich erwähne exemplarisch zwei davon.
Erstens: die Anforderungs-Baseline ist ein Teil des Vertrages zwischen Kunden und Diensterbringer und sollte mit einem SLA (Service-Level-Agreement) abgestimmt werden. Zweitens: Stelle Dir vor, ein Haus zu errichten und, wenn die Erbauer halbwegs fertig sind, auf die Idee zu kommen, einen Swimmingpool in den Keller einzubauen. Ob das funktionieren wird? Nein. Dasselbe geschieht mit einer Software. Dass Du den Quellcode nicht lesen und die Software-Architektur selbst nicht sehen kannst, bedeutet nicht, dass es nicht da ist. Deine Software hat eine Struktur und deren Entwicklung erfordert die Erfüllung bestimmter Richtlinien.
Zusammenfassend ist Softwareentwicklung (SD) ein komplexer Prozess, der Spezialisten aus verschiedenen Bereichen erfordert. Qualitätssicherung ist eine Disziplin, die SD verfolgt, beginnend mit der Sammlung von Anforderungen, und endend mit dem Testen von Rollback Scenarios. Dies hat als Ziel, Störungen so bald wie möglich zu finden, sie zu analysieren und den Prozess zu verbessern, um diese Art von Bugs zu verringern.
Bild von Kristīne Corbus
Warum wir das tun? Weil die Verhinderung und Verkleinerung von Störungen so früh wie möglich weniger kosten als die Nacharbeit, die bei der Behebung des Bugs anfällt. In diesem Fall können wir von Einbauqualität sprechen. Es ist eine intelligente Geschäftsentscheidung, in eine wirkungsvollen Software-Qualitätssicherung zu investieren.
trendig
