Qualitätssicherung bei der Softwareentwicklung – Wie nachhaltig kann man ohne Qualitätsstrategie arbeiten?

Wie kann es eigentlich sein, dass es immer noch Projekte gibt, die zwar keinen eigenen Tester, keine Testautomatisierung und keine spezifischen Qualitätschecks haben, aber dennoch neue Versionen veröffentlichen? Und diese sind dann auch noch gut und weisen keine verheerenden Fehler auf! Unser Head of Quality Alex Schladebeck geht diesem Umstand für Sie auf den Grund und zeigt, wie gute und nachhaltige Qualitätsstrategien aussehen.

 

Testen oder nicht testen – das ist hier die Frage

Als Testerin aus Leidenschaft fragt sich Alex Schladebeck bereits seit Jahren, wie neue Produktversionen ohne Tester oder eindeutige Qualitätsstrategie auf den Markt kommen können. Schließlich sagt ihre langjährige Erfahrung, dass ein Test Consultant und eine spezifische Teststrategie nötig sind, um gute Softwarequalität sicherzustellen. Und dennoch stößt sie immer wieder auf Projekte, bei denen dies nicht der Fall ist. Und diese laufen trotzdem gut. Jeder, der nicht Test-begeistert ist, führt genau diese Beispiele an, um zu sagen, dass Tests nicht nötig sind und man keine Qualitätssicherung braucht. Aber kann das wirklich stimmen?

 

Die implizite Strategie

Die Erkenntnis traf die Testerin wie der Schlag. Softwareprojekte, die trotz fehlender Teststandards qualitativ gut abschneiden, haben meist folgendes gemeinsam:

  • Ein gut dokumentierter und verankerter Tech-Stack, der im Projekt, im Unternehmen und in der Industrie bekannt ist
  • Ein gut eingespieltes Team erfahrener Entwickler, die in diesem Projekt seit mindestens 2 Jahren mit dem gleichen Tech-Stack arbeiten
  • In diesem Team hat jeder einen guten Überblick über die Architektur und kann die Auswirkungen neuer Entwicklungen oder Änderungen einschätzen
  • Großes Domain-Wissen unter den Entwicklern, so dass Missverständnisse seltener sind
  • Ein gutes Verhältnis zum Kunden dank problemloser Qualität in der Vergangenheit
  • Ein Teammitglied, das mehr Erfahrung hat und die Arbeit der anderen checkt
  • Die Möglichkeit, Fehler und Probleme schnell zu beheben, ohne den Kunden hierauf aufmerksam zu machen
  • Geringer direkter Kontakt zu Supportproblemen, da diese von einem 1st und 2nd Level Support behoben werden

Damit haben solche Teams im Grunde eine eigene Qualitätsstrategie bestehend aus:

  • Einem Umfeld aus gut bekannten Elementen des Tech-Stacks, der Architektur und der Entwicklungsumgebung
  • Ein erfahrenes und gut eingespieltes Team
  • Ein entspannter Kunde

Unter diesen Umständen werden seltener Fehler begangen, die jedoch keine größere Auswirkung haben.

 

Die Gefahren dieser Strategie

Eine solche implizite Qualitätsstrategie birgt allerdings folgende große Gefahren, wenn:

  • Ein erfahrenes Teammitglied geht und damit wichtiges Wissen abwandert
  • Neue unerfahrene Kollegen ins Team kommen
  • Es zu einem größeren Fehler kommt, bei dem der Kunde nicht mehr entspannt bleiben kann
  • Das Teammitglied geht, das die Gesamtübersicht hat
  • Ein neuer Tech-Stack oder eine neue Entwicklungsumgebung eingeführt wird - bisherige Arbeitsabläufe kommen hiermit aus dem Gleichgewicht

Sollte hiervon etwas eintreffen, stürzt die Qualität wie ein Kartenhaus zusammen. Denn die oben beschriebene implizite Strategie ist nicht nachhaltig. Und noch kritischer ist, dass das Team und der Kunde in einem falschen Gefühl von Sicherheit agieren. Ein Entwickler dieses Projekts versucht möglicherweise, diese Strategie auf ein neues Projekt zu übertragen, bei dem die Bedingungen nicht gleich sind. Damit droht die Qualität des neuen Softwareprodukts verloren zu gehen.

 

Führen Sie explizite Strategien ein         

Damit dies nicht geschieht, empfiehlt unser Head of Quality von Projektbeginn an Methoden der Qualitätssicherung festzulegen. Es gibt anerkannte Praktiken, die zu einer guten Qualitätsstrategie für die moderne Softwareentwicklung gehören. Keines der Merkmale ist dabei zwingend Teil des Quality Managements, da der Kontext immer anders sein wird. Teams sollten folgende Praktiken aber kennen und überlegen, ob sie im Projekt anwendbar sind:

  • Automatisierung
    • Pipelines bauen und testen
    • Testdatenbereitstellung
    • Testautomatisierung auf verschiedenen Ebenen wie API, Units, Integration, Benutzeroberfläche
  • Exploration
    • Exploratives Testen
    • Observability
  • Reviews
  • Entwicklungspraktiken für Qualität
    • Testgetriebene Entwicklung
    • Contract Testing
    • Pairing
    • Mob-Tests und Mob-Programmierung
    • 3 oder 4 Amigos Meetings
    • Fähigkeitsmatrizen (zur Vermeidung von Busfaktoren)
    • Erwartungsmatrizen (zur Vermeidung von Lücken)
    • Regelmäßiges Refactoring
    • „Comb Shaping“ für alle Rollen
    • Funktionsübergreifende Teams
  • Agile Methoden
    • Schnelle Rückkopplungszyklen
    • Kleine Storys
    • Reviews
  • Vorbeugende Maßnahmen
    • Testerbeteiligung von Anfang an
    • Design für Testbarkeit, Kontrollierbarkeit und Observability
    • Teamtraining unter dem Prinzip „Whole Team Quality“

Natürlich ist es schön, wenn der Projektkontext selbst bedeutet, dass Fehler weniger wahrscheinlich sind - genau wie oben beschrieben. Sich auf einen impliziten „einfachen Modus“ zu verlassen, ist jedoch nicht die Strategie, die langfristig oder bei zukünftigen Projekten Qualität garantiert.
Unabhängig davon, welche Aspekte aus der obigen Liste Sie für Ihre Qualitätsstrategie verwenden, sollten Sie diese konkret definieren und implementieren, um nachhaltig qualitative Software zu entwickeln.

 

Sie haben Fragen zum Thema Testen und Qualitätssicherung? Unsere Test Consultants helfen Ihnen gerne jederzeit weiter - von Workshops für Ihr Team bis zum Testen Ihrer Softwareprodukte. Schreiben Sie unseren Experten einfach eine E-Mail an info@bredex.de oder rufen Sie uns an unter 0531-243300.

Kontakt-Icon