Welche Softwaretests gibt es und welche braucht mein digitales Produkt?

Professionelles Softwaretesting ist weit mehr als das Ausprobieren einer fertigen App kurz vor dem Launch. Die Frage «funktioniert es?» lässt sich bei digitalen Produkten nicht so einfach mit Ja oder Nein beantworten.
Eine Anwendung kann alle vorgesehenen Funktionen korrekt ausführen und trotzdem langsam oder schwierig zu bedienen sein, Sicherheitslücken aufweisen, auf bestimmten Geräten nicht funktionieren, oder bei hoher Last zusammenbrechen.
Gute Softwarequalität umfasst also verschiedene Aspekte und ob eine Software «funktioniert», kommt darauf an, worauf man achtet. Entsprechend gibt es unterschiedliche Methoden und Arten, sie zu testen.

In diesem Blogpost zeigen wir, welche Testmethoden es gibt, wie sie sich einordnen lassen und wie entschieden wird, welche Testmethode für welches Produkt zu welchem Zeitpunkt die Richtige ist. 

Die verschiedenen Dimensionen von Softwaretesting

Softwaretesting begleitet die Entwicklung eines digitalen Produktes idealerweise von Anfang an. Dabei wird nicht nur geprüft, ob einzelne Funktionen korrekt umgesetzt wurden. Je nach Produkt und dessen Anforderungen, können unterschiedliche Qualitätsmerkmale entscheidend sein. Dazu gehören beispielsweise Stabilität, Performance, Sicherheit, Nutzungsfreundlichkeit oder Barrierefreiheit.

Um die verschiedenen Tests sinnvoll einzuordnen, hilft eine grundlegende Unterscheidung von zwei Dimensionen. Diese hat das ISTQB, die weltweit führende Zertifizierungsstelle für Softwaretesting, in ihrem offiziellen Glossar etabliert: 

• Teststufen beschreiben, wo im Entwicklungsprozess, beziehungsweise auf welcher Ebene getestet wird: das kann von einer einzelnen Codezeile bis zum Gesamtsystem gehen. 

• Testarten beschreiben, was geprüft wird, also auf welcher Qualitätseigenschaft der Fokus liegt - eben Merkmale wie Stabilität, Performance oder Sicherheit. 

Eine Testart kann dabei auf unterschiedlichen Teststufen zum Einsatz kommen. Funktionalität kann zum Beispiel sowohl auf der Ebene einer einzelnen Komponente als auch über einen vollständigen Nutzungsablauf hinweg getestet werden.

Die Dimensionen beantworten zwei unterschiedliche Fragen: Auf welcher Ebene testen wir und welche Qualitätseigenschaft wollen wir prüfen?

Welche Software-Tests gibt es und wie lassen sie sich einordnen?

Teststufen: Auf welcher Ebene wird geprüft? 

Testing beginnt klein und auf der untersten Stufe: bei einzelnen Code-Einheiten. Danach wird es Schritt für Schritt auf das gesamte System ausgeweitet. Dieser Aufbau ist sinnvoll, denn je früher Fehler erkannt werden, desto einfacher und schneller lassen sie sich in der Regel beheben. 

Ein hilfreiches Modell, um die verschiedenen Teststufen einzuordnen, ist die Testing-Pyramide. Sie bildet die Teststufen ab und zeigt auf einen Blick, wie Tests idealerweise verteilt sind und warum.

Unit Testing
Unit Tests prüfen einzelne, isolierte Einheiten des Quellcodes und stellen sicher, dass diese in sich wie vorgesehen funktionieren. 

Ein typisches Beispiel: In einem Onlineshop kann ein Produkt dem Warenkorb hinzugefügt werden. Ein Unit Test prüft dabei nicht, ob der Button klickbar ist oder die Seite korrekt aussieht, sondern ob die zugrunde liegende Logik stimmt: Wurde das Produkt korrekt erfasst? Stimmt die Anzahl? Wird der Gesamtpreis richtig berechnet und gespeichert? Genau diese Business-Logik wird isoliert geprüft, unabhängig vom Rest der Applikation.

Das Ziel ist es, Fehler so früh wie möglich zu lokalisieren: Schlägt ein Unit Test fehl, ist der betroffene Codebereich direkt identifizierbar. Unit Tests werden von Entwickler*innen erstellt, laufen in der Regel automatisiert und begleiten die Entwicklung von Anfang an.

Component Testing
Sobald einzelne Einheiten getestet sind, werden grössere, in sich abgeschlossene Komponenten eines Systems überprüft, also beispielsweise ein ganzes Modul oder ein Service. Component Tests prüfen das Verhalten einer Komponente möglichst isoliert von anderen Teilen des Systems. Die Abhängigkeiten zu anderen Teilen des Systems werden nicht berücksichtigt.

Zurück zu unserem Warenkorb-Beispiel, bei dem ein Produkt dem Warenkorb hinzugefügt wird: Ein Component Test prüft dabei nicht die Business-Logik dahinter, sondern ob die Komponente sich korrekt verhält: Wird der “Zum Warenkorb hinzufügen-Button” deaktiviert, sobald das Produkt bereits im Warenkorb ist? Erscheint die Erfolgsmeldung nach dem Klick? Zeigt die Komponente einen Ladezustand, während die Anfrage läuft? Genau dieses Verhalten wird isoliert geprüft.

Integration Testing
Integration Testing prüft, ob voneinander abhängige Komponenten korrekt miteinander interagieren: ob Daten korrekt übergeben werden, ob Logiken zusammen funktionieren und ob sich das System als Ganzes verhält wie erwartet.

Beim Warenkorb-Beispiel kann geprüft werden, ob eine Bestellung nicht nur innerhalb einer Komponente korrekt verarbeitet wird, sondern die Bestellung auch tatsächlich korrekt in der Datenbank landet. Hier zeigen sich Fehler, die bei isolierten Unit oder Component Tests nicht sichtbar werden: Die einzelnen Teile funktionieren zwar in sich, aber nicht miteinander.

API Testing
API Tests sind mitunter Teil von Integrationstests, fokussieren sich aber auf die Kommunikation zwischen definierten Schnittstellen. Sie prüfen, ob APIs die richtigen Daten zurückgeben, korrekt auf Anfragen reagieren und unter verschiedenen Bedingungen stabil bleiben, unabhängig davon, was an der Oberfläche passiert.

Beispiel: Ein Produkt wird dem Warenkorb hinzugefügt. Ein API Test prüft die Schnittstelle dahinter - gibt der Endpoint die erwarteten Daten und Statuscodes zurück? Reagiert die Schnittstelle korrekt, wenn ein Produkt nicht mehr verfügbar ist? Diese Kommunikation kann unabhängig vom Rest des Systems mit Software wie Postman oder mit eigenen Scripts getestet werden.

End-to-End Testing
End-to-End Tests simulieren vollständige Abläufe aus der Perspektive aller Nutzenden die mit der Applikation oder Software in Berührung kommen. Mehrere User Stories werden zusammenhängend getestet, um das Zusammenspiel des gesamten Systems zu kontrollieren und sicherzustellen, dass Daten über verschiedene Systemgrenzen hinweg korrekt fliessen. Diese Tests kommen in der Regel gegen Ende eines Entwicklungszyklus zum Einsatz.

Aus unserem Warenkorb-Beispiel wird nun ein vollständiger Ablauf: Produkt suchen, in den Warenkorb legen, Checkout abschliessen, Bestellbestätigung erhalten - das sind alles Teile die irgend ein User Interface (UI) betreffen, mit dem ein*e Enduser*in arbeitet. Das ist aber nicht alles: In diesem Beispiel gehört zum End-to-End Test beispielsweise auch, ob das ERP dann die korrekte Rüstliste für Mitarbeitende im Lager generiert. Ein End-to-End Test prüft also, ob die Prozesse von Anfang bis Ende wie vorgesehen funktionieren. 

Testarten: Was wird geprüft?

Während Teststufen beschreiben, auf welcher Ebene getestet wird, beschreiben Testarten, auf welche Qualitätseigenschaft der Fokus gerichtet ist. Eine Testart kann auf mehreren Teststufen gleichzeitig eingesetzt werden: Regressionstests zum Beispiel laufen sowohl auf Unit- als auch auf Systemebene. Welche Testart relevant ist, hängt stark vom jeweiligen Produkt und dessen Anforderungen ab.

Die folgenden Abschnitte zeigen, welche Testarten es gibt, worauf sie fokussieren und welche Tests zu ihnen gehören.

Funktionalität, Stabilität und Zuverlässigkeit 

Diese Tests stellen sicher, dass die App auf allen relevanten Geräten stabil läuft, Änderungen keine bestehenden Funktionen kaputt machen und dass die Installation reibungslos funktioniert.

Smoke Testing
Smoke Tests sind schnelle Grundlagenprüfungen zu Beginn jedes Testzyklus: Läuft der Build überhaupt stabil genug, um mit ausführlichen Tests anzufangen? Sie decken kritische Probleme früh auf, bevor Zeit in aufwändigere Tests investiert wird. 

Funktionales Testing
Beim funktionalen Testing wird geprüft, ob jede Funktion einer Applikation das tut, was in den Anforderungen und Akzeptanzkriterien festgehalten wurde. Eingaben werden gemacht, Abläufe durchgespielt und das Ergebnis mit dem Soll verglichen. Es geht darum zu verifizieren: Tut die Software, was sie tun soll?

Regression Testing
Wenn etwas Neues gebaut wird, kann Bestehendes kaputtgehen - manchmal unbemerkt. Regressionstests stellen sicher, dass bereits funktionierende Features auch nach Änderungen noch einwandfrei laufen. In einem kontinuierlichen Entwicklungsprozess sind sie ein festes Sicherheitsnetz.

Compatibility Testing
Compatibility Testing prüft, ob eine Anwendung auf unterschiedlichen Geräten, Betriebssystemen, Plattformversionen oder Browsern korrekt funktioniert und wie sie sich bei verschiedenen Bildschirmgrössen und -auflösungen verhält. Bevor Tests sinnvoll geplant werden können, muss daher klar sein, auf welchen Geräten, Plattformen und Browsern die Applikation laufen soll.

Installation Testing
Der erste Kontakt mit einer App beginnt mit der Installation. Läuft diese schief, ist der erste Eindruck selten positiv. Beim Installation Testing wird geprüft, ob eine Software auf allen Zielsystemen korrekt installiert werden kann und ob Updates und Deinstallationen reibungslos funktionieren. Besondere Aufmerksamkeit verdienen dabei Update-Tests: Insbesondere bei nativen Apps können neue Versionen Datenbankmigrationen oder geänderte Datenstrukturen mitbringen. Läuft das schief, verlieren Nutzende im schlimmsten Fall ihre Daten.

Performance und Sicherheit

Eine funktionierende Anwendung muss auch unter den erwarteten Bedingungen leistungsfähig und sicher bleiben. Bei den folgenden Testarten geht es darum zu schauen, wie robust und sicher eine Software bzw. ein Softwareteil ist. 

Last- und Stresstests
Bei Lasttests wird eine definierte Anzahl gleichzeitiger Nutzer*innen simuliert, zum Beispiel 1'000 Personen, die parallel auf bestimmte Funktionen zugreifen. Das zeigt, wie das System unter erhöhter Last reagiert und ob es auch zu Spitzenzeiten stabil bleibt.

Stresstests gehen noch einen Schritt weiter: Das System wird bis an seine Grenzen gebracht, bis es ausfällt. Ziel ist nicht nur, die Belastungsgrenze zu kennen, sondern auch zu beobachten, wie sich das System nach einem Ausfall verhält und ob es sich selbständig erholt.

Security Testing
Security Tests prüfen Anwendungen und Systeme auf Schwachstellen, die von Angreifenden ausgenutzt werden könnten. Dazu gehören Schwachstellen-Scans, Sicherheitsaudits und Penetrationstests. Ein Penetrationstest (kurz Pen Test) ist ein kontrollierter Angriff auf die Sicherheit einer Applikation: Expert*innen versuchen - oft zusammen mit KI - gezielt, Lücken in einer Anwendung, API oder Infrastruktur aufzudecken, bevor es echte Angreifende tun.

Nutzungserlebnis und Barrierefreiheit

Ein digitales Produkt kann technisch einwandfrei funktionieren und sein Ziel trotzdem verfehlen, wenn Menschen es nicht verstehen oder es nicht effizient bedienen können. Mit folgenden Testarten wird abgeklärt, ob und wie gut eine Software zugänglich und bedienbar ist. Damit eine Software genutzt wird und im besten Fall auch geliebt wird, ist diese Kategorie natürlich zentral.

Usability Testing
Usability Tests messen, wie effektiv, effizient und zufriedenstellend eine Anwendung bedienbar ist. Echte Nutzende führen dabei definierte Aufgaben durch, während beobachtet wird, wo sie ins Stocken geraten. Insbesondere in frühen Entwicklungsphasen eignen sich auch heuristische Evaluierungen mit UX-Expert*innen. Usability-Probleme früh zu erkennen spart Kosten, weil Anpassungen zu diesem Zeitpunkt einfacher und günstiger sind als nach dem Launch. Sie sind ausserdem in vielen Fällen absolut entscheidend für den Erfolg einer Anwendung. 

Accessibility Testing
Accessibility Testing prüft die digitale Barrierefreiheit einer Anwendung: Wie gut kann eine Software von Menschen mit einer Sehschwäche oder motorischen Einschränkungen bedient werden? Getestet wird unter anderem mit Hilfstechnologien wie Screenreadern. Als Referenzstandard gelten die Web Content Accessibility Guidelines (WCAG). Barrierefreiheit ist nicht nur eine ethische Frage, sondern in vielen Kontexten auch eine rechtliche - ausserdem verbessert eine hohe Barrierefreiheit die User Experience für alle.

Mehr über Accessibility aus Perspektive einer sehbehinderten Person gibt es im Blogpost «Ohne Licht im hellen Netz - warum Accessibility wichtig ist und was es zu beachten gibt».
Mehr über das Testen von Accessbility gibts im Blogpost «Barrierefreiheit in digitalen Produkten aus der Sicht einer Softwaretesterin» zu lesen.

Spezialisierte Tests für besondere Anforderungen

Manche Projekte erfordern Tests, die über die Standardmethoden hinausgehen, weil die Nutzungsbedingungen speziell sind, die Zielgruppe besondere Anforderungen stellt oder das System auf unerwartetes Verhalten geprüft werden muss. Deshalb können zusätzliche Testmethoden sinnvoll sein. 

Interruption Testing
Interruption Testing ist für mobile Apps relevant: Es prüft, wie sich eine Anwendung verhält, wenn der User Flow unerwartet unterbrochen wird. Typische Szenarien sind eingehende Anrufe oder Nachrichten, App-Wechsel, das Sperren des Bildschirms, ein Netzwerkwechsel oder ein Akkuausfall. Ziel ist es sicherzustellen, dass die App nach der Unterbrechung stabil weiterläuft, ohne Datenverlust und ohne Fehlverhalten.

Chaos Testing
Chaos Testing ist unkonventionell, aber wirkungsvoll: Es simuliert zufälliges, unkontrolliertes Nutzungsverhalten, als würde jemand wahllos tippen, scrollen und wischen. Diese Methode deckt Stabilitätsprobleme und Abstürze auf, die in strukturierten Tests oft nicht auftauchen. Sie ergänzt gezielte Tests insbesondere, indem sie hilft, Edge Cases aufzudecken: Fehler oder Abstürze, die sich erst in Ausnahmefällen zeigen. 

In-the-Wild Testing
Beim In-the-Wild Testing werden Anwendungen unter realen Einsatzbedingungen geprüft. Statt im Büro unter Laborbedingungen zu testen, wird die App dort geprüft, wo sie tatsächlich verwendet wird: draussen, in Bewegung, mit den realen Gegebenheiten der Zielgruppe. Für eine Sport-App bedeutet das beispielsweise: tatsächlich Sport treiben. So werden Probleme sichtbar, die im kontrollierten Testumfeld kaum aufgetaucht wären. Hier besteht natürlich ein enger Zusammenhang mit Usability Tests und User Research, weil dort die alltägliche Handhabung und die entstehenden Mehrwerte oder Probleme erkannt werden sollen. 

Diese Kategorisierung und die Erläuterungen sind natürlich nicht abschliessend. Softwaretesting entwickelt sich, zusammen mit Softwareentwicklung, kontinuierlich weiter. Unser Quality Assurance & Testing Team bleibt am Ball!

Welche Tests braucht mein digitales Produkt? 

Nach all diesen Testmethoden könnte der Eindruck entstehen: Je mehr getestet wird, desto besser. So einfach ist es aber nicht.

Eine kleine Web-Anwendung braucht eine andere Teststrategie als eine sicherheitskritische Plattform mit Tausenden gleichzeitigen Nutzer*innen. Entscheidend ist deshalb nicht, möglichst viele verschiedene Tests durchzuführen, sondern die für das Produkt relevanten Risiken mit angemessenem Aufwand abzudecken.

Anforderungen, Risiken und Kontext bestimmen die Teststrategie

Welche Tests sinnvoll sind, hängt von verschiedenen Faktoren ab. Dazu gehören insbesondere die funktionalen und nicht-funktionalen Anforderungen, die Risiken des Produkts, der Nutzungskontext und die Zielgruppe. Auch Entwicklungsstand, Projektgrösse, technische Architektur und verfügbares Budget spielen eine Rolle.

Bei einer Anwendung, die grosse Mengen sensibler Daten verarbeitet, erhält Security Testing beispielsweise ein anderes Gewicht als bei einer einfachen Informationswebsite. Wird mit sehr hohen Zugriffszahlen gerechnet, werden Last- und Performance-Tests wichtiger. Und eine mobile Anwendung, die hauptsächlich unterwegs verwendet wird, stellt wiederum andere Anforderungen an das Testing als eine Desktop-Anwendung für einen klar definierten Arbeitsplatz.

Gute Testplanung setzt deshalb dort an, wo Fehler die grössten Auswirkungen hätten oder besonders wahrscheinlich sind.

Testkonzeption als Grundlage

Welche Testmethoden eingesetzt werden, sollte nicht spontan entschieden werden. Eine systematische Testplanung klärt unter anderem:

Was soll getestet werden? Welche Anforderungen müssen erfüllt sein? Wo liegen die grössten Risiken? Welche Geräte, Plattformen und Nutzungssituationen müssen berücksichtigt werden? Welche Tests werden automatisiert und welche manuell durchgeführt? Und welcher Testaufwand ist im Verhältnis zum Projekt sinnvoll?

Daraus entsteht ein Testkonzept, das festhält, welche Testarten und Teststufen zum Einsatz kommen, wie Testfälle aus Anforderungen und Akzeptanzkriterien abgeleitet werden und wann welche Tests im Projektverlauf stattfinden.

Diese Planung ist nicht einmalig. Anforderungen verändern sich, Produkte entwickeln sich weiter und neue Risiken können entstehen. Entsprechend wird auch das Testvorgehen während des Projekts laufend überprüft und angepasst.

So wird Softwaretesting zur kontinuierlichen Qualitätssicherung innerhalb der Entwicklung – statt zu einem Kontrollpunkt kurz vor dem Release.

Was automatisieren wir, was testen wir manuell?

Ein wichtiger Bestandteil der Testkonzeption ist die Frage, welche Tests automatisiert und welche manuell durchgeführt werden. Nicht jeder Test muss manuell durchgeführt werden – und nicht jeder sollte automatisiert werden.

Wiederkehrende und klar reproduzierbare Tests eignen sich besonders gut für Automatisierung. Vor allem Unit-, API- und Integrationstests können dadurch häufig und mit schnellem Feedback ausgeführt werden. So lassen sich Fehler früh erkennen und der manuelle Testaufwand reduzieren.

Andere Qualitätsaspekte benötigen dagegen menschliche Beurteilung oder sind aufwändig zu automatisieren. Gerade bei explorativen Tests, Usability oder sehr spezifischen Nutzungssituationen bleibt manuelles Testing deshalb wichtig.

Die Testing-Pyramide hilft dabei, eine sinnvolle Balance zu finden: viele schnelle und stabile Tests auf den unteren Ebenen und gezielt eingesetzte, umfassendere Tests auf höheren Ebenen.

Fazit: Nicht möglichst viel testen, sondern das Richtige

Professionelles Softwaretesting bedeutet nicht, jede verfügbare Testmethode einzusetzen. Entscheidend ist die richtige Kombination – abgestimmt auf das Produkt, seine Anforderungen und Risiken sowie die jeweilige Phase der Entwicklung.

Teststufen helfen dabei zu verstehen, auf welcher Ebene getestet wird. Testarten richten den Fokus darauf, welche Qualitätseigenschaften geprüft werden. Eine durchdachte Testkonzeption bringt beide Perspektiven zusammen und entscheidet, wo und wann welcher Test den grössten Mehrwert für dein digitales Produkt schafft.

Unser Quality Assurance Team evaluiert für jedes Projekt, welche Tests sinnvoll sind, plant sie systematisch und dokumentiert die Ergebnisse transparent. Testing bieten wir sowohl als integrierten Bestandteil unserer Entwicklungsprojekte als auch als eigenständige Leistung für bestehende digitale Produkte an – bis hin zur Beratung bei der Entwicklung einer passenden Testingstrategie.

Melde dich gerne bei uns, wenn du Unterstützung im Bereich Softwaretesting wünschst!

Dieser Blogbeitrag ist in Zusammenarbeit mit Martin Mattli, Head of Operations & Quality Management, entstanden und verbindet die Erfahrungen und Perspektiven unseres gesamten Quality-Assurance-Teams.