Was ist Softwaretesting? Unit- und E2E-Tests

01Was sind Softwaretests, und warum braucht man sie?

Softwaretests sind der Weg, zu beweisen, dass Ihr Code wirklich das tut, was Sie wollen. Dass in einem Onlineshop ein Rabattcode korrekt berechnet wird, dass in einer Hotelsoftware dasselbe Zimmer nicht doppelt gebucht werden kann oder dass ein Formular fehlerhafte Daten abweist, wird durch Tests abgesichert.

Bei Projekten ohne Tests birgt jede neue Funktion das Risiko, etwas zu beschädigen, das vorher funktionierte. Das nennt man Regression. Automatisierte Tests senken dieses Risiko; nach einer Änderung zeigen sie innerhalb von Minuten, was kaputtgegangen ist.

Der Zeitpunkt, zu dem ein Fehler gefunden wird, bestimmt die Kosten. Ein Fehler, der während der Entwicklung auffällt, ist in wenigen Minuten behoben; ein Fehler, den im Livesystem der Kunde entdeckt, kostet Geld, Zeit und Vertrauen.

02Testarten: Unit, Integration, E2E

Testarten unterscheiden sich nach dem Bereich, den sie abdecken, und nach ihrer Geschwindigkeit. Kleine Teile zu testen ist schnell und günstig; das gesamte System zu testen ist langsam, aber realitätsnah.

Was ist ein Unit-Test?

Ein Unit-Test prüft eine einzelne Funktion oder Klasse isoliert von der Außenwelt. Datenbank, Netzwerk oder Dateisystem kommen nicht ins Spiel; falls nötig, werden sie durch Attrappen (Mocks) nachgebildet. Er läuft in Millisekunden und zeigt die Fehlerstelle punktgenau an.

Integrationstest

Ein Integrationstest verifiziert, dass mehrere Teile gemeinsam richtig funktionieren: Anwendung und Datenbank, Dienst und Dienst, System und externe API. Die Schnittstellen aus unserem Beitrag Was ist eine API? werden am häufigsten auf dieser Ebene getestet. Bei Abläufen wie Zahlung, Versand und Marktplatz-Anbindung sind diese Tests besonders wichtig.

E2E-Test

Ein E2E-Test (End-to-End-Test) nutzt das System wie ein echter Anwender: Er öffnet den Browser, legt ein Produkt in den Warenkorb, geht zum Zahlungsschritt und prüft, ob die Bestellung entsteht. Er ist der realistischste Test, aber auch der langsamste und störanfälligste.

03Testpyramide: Wie viel von welchem Test?

Die Testpyramide ist ein verbreitetes Modell dafür, wie viel von welcher Testart geschrieben werden sollte. An der Basis stehen viele schnelle Unit-Tests, in der Mitte weniger Integrationstests und an der Spitze nur wenige E2E-Tests, die ausschließlich die kritischen Abläufe abdecken.

Ein häufiger Fehler ist die umgedrehte Pyramide, bei der man versucht, alles per E2E-Test zu verifizieren. Dann wird die Testlaufzeit lang, Tests brechen ohne Grund, und das Team verliert mit der Zeit das Vertrauen in die Tests.

Ein festes Verhältnis gibt es nicht; die Art des Projekts ist ausschlaggebend. Bei rechenintensiver Software überwiegen Unit-Tests, bei einem Projekt mit vielen angebundenen Fremdsystemen steigt der Anteil der Integrationstests.

04Beispiel mit Jest und Playwright

In der JavaScript-Welt sind Jest und Vitest verbreitete Wahlmöglichkeiten für Unit-Tests, Playwright und Cypress für E2E-Tests. Unten sehen Sie einen einfachen Unit-Test für eine Rabattfunktion.

Wenn Sie Typfehler schon vor dem Schreiben von Tests abfangen möchten, lesen Sie auch unseren Beitrag Was ist TypeScript?; das Typsystem nimmt den Tests etwas Last ab, ersetzt sie aber nicht.

// indirim.js
export function indirimUygula(tutar, oran) {
  if (oran < 0 || oran > 100) throw new Error('Ungültiger Prozentsatz');
  return Math.round(tutar * (100 - oran)) / 100;
}

// indirim.test.js
import { indirimUygula } from './indirim.js';

test('20 Prozent Rabatt wird korrekt berechnet', () => {
  expect(indirimUygula(200, 20)).toBe(160);
});

test('ungültiger Wert löst einen Fehler aus', () => {
  expect(() => indirimUygula(200, 120)).toThrow();
});

import { test, expect } from '@playwright/test';

test('Produkt wird in den Warenkorb gelegt', async ({ page }) => {
  await page.goto('https://ornek-magaza.test/urun/zeytinyagi');
  await page.getByRole('button', { name: 'Sepete Ekle' }).click();
  await expect(page.getByTestId('sepet-adet')).toHaveText('1');
});

05Testautomatisierung und CI-Prozess

Testautomatisierung bedeutet, dass Tests nicht von Hand, sondern bei jeder Codeänderung automatisch ausgeführt werden. Sobald Code ins Repository gepusht wird, führt eine CI-Pipeline (Continuous Integration) die Tests aus; schlägt einer fehl, geht die Änderung nicht live.

Dieser Ablauf wird wertvoller, je größer das Team wird. Alle unterliegen derselben Qualitätslatte, und Fehler werden abgefangen, bevor sie beim Kunden ankommen.

1. Der Entwickler nimmt die Änderung in einem Branch vor und pusht sie ins Repository.
2. Die CI-Pipeline installiert die Abhängigkeiten und führt Unit- und Integrationstests aus.
3. E2E-Tests für die kritischen Abläufe laufen in der Testumgebung.
4. Bestehen alle Tests, geht der Code nach dem Code-Review live.

06Weitere Testarten

Richtig zu arbeiten genügt nicht; Software muss auch schnell, sicher und benutzbar sein. Deshalb gibt es neben funktionalen Tests weitere Testarten.

• Performance-Test: Misst, wie sich das System unter Last verhält. Die Seitengeschwindigkeit gehört auch zur Speed- und Performance-Optimierung.
• Sicherheitstest: Sucht nach unbefugtem Zugriff, Injection und ähnlichen Schwachstellen.
• Usability-Test: Prüft, ob echte Nutzer die Oberfläche mühelos bedienen können; er ist ein natürlicher Teil des UI/UX-Designs.
• Barrierefreiheitstest: Prüft die Eignung für Screenreader- und Tastaturnutzer.
• Visueller Regressionstest: Vergleicht Screenshots und erkennt unerwartete Designverschiebungen.
• Tests kompilierter Module: Auch Teile wie die Wasm-Module aus unserem Beitrag Was ist WebAssembly? brauchen eine eigene Testpipeline.

07Häufige Fehler beim Testen

Tests zu schreiben ist eine Fertigkeit; schlecht geschriebene Tests können zur Last werden, statt zu helfen. Die häufigsten Fehler sind diese.

• An der Abdeckungsquote hängen bleiben: Ein hoher Wert bedeutet nicht, dass die Tests gut sind; wichtig ist, dass kritisches Verhalten getestet wird.
• Den internen Aufbau der Anwendung testen: Wird der Code umstrukturiert, brechen die Tests ohne Grund. Testen Sie das Verhalten.
• Störanfällige E2E-Tests: Nutzen Sie statt fester Wartezeiten Konstrukte, die auf das Erscheinen des Elements warten.
• Tests an Livedaten koppeln: Tests sollten ihre eigenen Daten vorbereiten und anschließend aufräumen.
• Einen fehlgeschlagenen Test deaktivieren und vergessen: Das zerstört das Vertrauen in die Tests schnell.

08Wo sollte man mit dem Testen anfangen?

Ein Projekt ganz ohne Tests mit einem Schlag um Hunderte Tests zu ergänzen, ist unrealistisch. Effizienter ist es, an der riskantesten Stelle zu beginnen und schrittweise voranzugehen. Schon ein Test pro behobenem Fehler bildet innerhalb weniger Monate ein ernstzunehmendes Sicherheitsnetz.

Anfangs sollte man nicht auf perfekte Abdeckung, sondern auf verlässliche Tests zielen. Wenige Tests, die jedes Mal konsistente Ergebnisse liefern, sind wertvoller als viele instabile.

1. Listen Sie die Funktionen rund um Geld, Lagerbestand und Nutzerdaten auf.
2. Schreiben Sie für diese Funktionen zuerst Unit-Tests.
3. Ergänzen Sie Integrationstests an den Stellen, die externe Systeme anbinden.
4. Richten Sie E2E-Tests für die zwei, drei kritischsten Nutzerabläufe ein.
5. Binden Sie die Tests an die CI-Pipeline an und gehen Sie mit einem roten Test nicht live.

09Was bringen Tests einem Unternehmen?

Für Unternehmer sind Tests eine unsichtbare, aber spürbare Investition. Deshalb ist es wichtig, bei der Entwicklung von individuellen Softwarelösungen die kritischen Abläufe durch Tests abzusichern. Eine Zahlungsseite, die am Aktionstag ausfällt, oder ein Shop, der falschen Lagerbestand anzeigt, wird weit teurer als der Testaufwand.

Wenn Bestell-, Rechnungs- und Lagerabläufe zwischen mehreren Systemen laufen, steigt die Fehlerwahrscheinlichkeit. Deshalb senkt eine getestete, vorhersehbare Struktur bei E-Commerce-Integrationen und beim Shopsystem langfristig die Wartungskosten.