Wer nach Qualitätstests für Software sucht, fragt meist nach drei verschiedenen Aufgaben zugleich. Die Qualitätssicherung (QA) gestaltet den Prozess so, dass weniger Fehler entstehen, die Qualitätskontrolle (QC) prüft das Produkt, das Ihr Team gebaut hat, auf Probleme, und das Testen ist die praktische Arbeit, die den Großteil der Belege für die QC liefert.
Wer diese drei Aufgaben verwechselt, zahlt bei der Besetzung eines Projekts drauf. Ein Unternehmen mit schwachem Prozess stellt womöglich jemanden ein, der nur Testfälle abarbeitet, während ein Startup mit zu wenigen Testern einen Berater dafür bezahlt, den Arbeitsablauf neu zu gestalten. In beiden Fällen fließt das Budget in die falsche Art von Hilfe.
Dieser Leitfaden erklärt QA, QC und Testen in einfachen Worten und stützt sich auf die offiziellen Definitionen des ISTQB, das Softwaretester international zertifiziert. Sie sehen außerdem, wie die Aufgaben in einem echten Projekt zusammenspielen und was Sie vor einer Einstellung fragen sollten. Wenn Sie alle drei lieber einem einzigen Partner übergeben, arbeitet unser engagiertes QA-Team genau so.
Warum sind Qualitätstests für Software eigentlich drei verschiedene Aufgaben?
Jede der drei Aufgaben beantwortet eine andere Frage. Die QA fragt, ob das Team so arbeitet, dass gute Software entsteht, und die QC entscheidet, ob genau dieses Release bereit für die Auslieferung ist. Das Testen fragt, wo das Produkt bricht, und sammelt die Belege, die die QC für diese Entscheidung braucht.
Qualitätssicherung verhindert Fehler im Prozess
Das ISTQB-Glossar definiert Qualitätssicherung als „Aktivitäten, die darauf fokussieren, Vertrauen in die Erfüllung der Qualitätsanforderungen zu erzeugen“. Im Alltag heißt das: Die QA etabliert Arbeitsgewohnheiten, die Bugs verhindern, die Tester als Fehlerzustände oder Defekte bezeichnen.
Im Tagesgeschäft besteht QA-Arbeit vor allem aus Planung und dem Vereinbaren von Regeln. Ein QA-Spezialist prüft die schriftliche Beschreibung jedes Features und stellt sicher, dass sie klar genug ist, um es zu entwickeln und zu testen. Zur Aufgabe gehört auch, festzulegen, was „fertig“ bedeutet, was vor jedem Release getestet wird und wie Probleme gemeldet und nachverfolgt werden. Erreicht ein Bug trotzdem die Nutzer, sucht die QA nach der Lücke im Prozess, die ihn durchgelassen hat.
Qualitätskontrolle findet Fehler im Produkt
Die Qualitätskontrolle ist die prüfende Seite. Das ISTQB-Glossar beschreibt QC als „Aktivitäten, die der Bewertung der Qualität einer Komponente oder eines Systems dienen“. Einfach gesagt vergleicht die QC, was Ihr Team tatsächlich gebaut hat, mit dem, was Sie geplant hatten.
QC findet statt, sobald es etwas zu prüfen gibt, etwa einen einzelnen Bildschirm, ein neues Feature oder ein komplettes Release. Tester teilen diese Arbeit in zwei Teile, die als Verifizierung und Validierung bekannt sind:
- Verifizierung: Entspricht das Produkt dem schriftlichen Plan?
- Validierung: Bekommen echte Nutzer vom Produkt, was sie brauchen?
Testen ist der wichtigste Weg zur Qualitätskontrolle
Testen bedeutet, die Software gezielt zu benutzen, um Probleme zu finden, bevor Ihre Kunden es tun. Der ISTQB-Lehrplan sagt, dass Testen und QA „nicht dasselbe“ sind, und nennt das Testen „eine wesentliche Form der Qualitätskontrolle“. Mit anderen Worten: Testen ist ein Teil der QC, und die QC arbeitet Seite an Seite mit der QA.
Beim manuellen Testen arbeitet sich ein Mensch so durch die App, wie es ein Kunde tun würde. Dieser praktische Ansatz findet verwirrende Bildschirme und seltsames Verhalten, die skriptbasierte Prüfungen oft übersehen. Beim automatisierten Testen wiederholen kleine Programme dieselben Schritte schnell bei jeder neuen Version. Beide Arten liefern dasselbe Ergebnis: Belege dafür, wie das Produkt gerade funktioniert.
QA vs. QC vs. Testen auf einen Blick
QA vs. QC vs. Testen läuft auf drei Schwerpunkte hinaus: den Prozess, das Produkt und die praktischen Prüfungen dazwischen.
Leitfrage
Arbeiten wir so, dass gute Software entsteht?
Ist dieses Release gut genug für die Auslieferung?
Wo und wie bricht die Software?
Schwerpunkt
Der Prozess
Das Produkt
Konkrete Features und Nutzerabläufe
Ziel
Fehler verhindern
Fehler finden
Fehler finden und beschreiben
Zeitpunkt
Vor und während der gesamten Entwicklung
Sobald es etwas zu prüfen gibt
Während und nach der Entwicklung, vor jedem Release
Typische Arbeit
Anforderungsreviews, Testpläne, Release-Kriterien, Prozessverbesserungen
Testläufe, Einstufung von Bugs nach Schweregrad, Release-Entscheidungen
Testfälle ausführen, die App erkunden, Bug-Reports schreiben
Verantwortlich
Alle im Projekt, angeleitet von QA-Spezialisten
Das QA- oder Testteam
Tester und QA-Engineers
Das ISTQB ergänzt, dass QA „in der Verantwortung aller Projektbeteiligten liegt“. Keine einzelne Einstellung und kein einzelner Dienstleister kann die Qualität also allein verantworten.
Wie passt der Qualitätssicherungsprozess für Software zum Testen?
In einem gut aufgestellten Team bilden QA, QC und Testen einen Kreislauf. Die QA legt die Regeln fest, das Testen sammelt Belege, und die QC macht aus den Ergebnissen eine Release-Entscheidung. Nach jedem Launch prüft das Team, was schiefgelaufen ist, und passt den Plan für den nächsten Zyklus an. Diesen Kreislauf von einem Release zum nächsten am Laufen zu halten, ist die Aufgabe des Qualitätssicherungsprozesses für Software, und unser Leitfaden zum QA-Prozess geht jeden Schritt durch.
Wie wir QA, QC und Testen für DrAnsay aufgeteilt haben
Für DrAnsay, eine deutsche Online-Rezeptplattform mit 700.000 Patienten, haben wir alle drei Aufgaben von Grund auf eingerichtet. Zu Beginn hatte DrAnsay kein internes QA-Team, und wiederkehrende Bugs erreichten immer wieder Patienten, während sie Rezepte bestellten.
So verteilte sich die Arbeit auf QA, Testen und QC:
- Qualitätssicherung: Wir haben zunächst die Web- und Mobile-Apps erkundet und die Erkenntnisse in einen Testplan überführt. Unsere Engineers haben außerdem Feature-Dokumente und Designs vor der Entwicklung geprüft, sodass Lücken sichtbar wurden, bevor jemand Code schrieb. Testfälle, Pläne zur erneuten Prüfung bestehender Features und das Bug-Tracking wanderten in ein einziges Tool, Qase.io, damit alle dasselbe Bild hatten.
- Testen: Unsere Engineers haben den Bestellablauf für Rezepte im Web und auf Mobilgeräten von Hand durchlaufen. Außerdem haben wir mehr als 40 automatisierte Tests mit Playwright geschrieben, einem weit verbreiteten Tool zur Browser-Automatisierung, und zwar für die wichtigsten User Journeys. Diese Tests laufen täglich und melden ihre Ergebnisse im Slack-Kanal des Teams.
- Qualitätskontrolle: Die Ergebnisse zeigten dem DrAnsay-Team, was behoben werden musste, bevor eine neue Version live gehen konnte.
Wir haben mehr als 150 Bugs gemeldet, und über 60 davon haben die Produktion nie erreicht. Die Bestellungen bei DrAnsay stiegen um 15 %, und abgebrochene Bestellvorgänge gingen um 18 % zurück.
Eine einzige Testrunde kurz vor dem Launch findet Bugs zu spät. Deshalb beziehen wir die QA schon bei den ersten Feature-Beschreibungen ein und prüfen weiter durch alle Phasen des Softwaretestens.
Was passiert, wenn QA oder QC versagt?
Zwei große Ausfälle aus dem Jahr 2025 zeigen den Unterschied zwischen einer Prozesslücke und einem übersehenen Fehler.
Cloudflare ist ein Netzwerkanbieter, auf den sich viele Websites für Geschwindigkeit und Sicherheit verlassen. Am 18. November 2025 erlebte das Unternehmen nach eigener Aussage seinen schwersten Ausfall seit 2019. Eine Änderung an Datenbankberechtigungen ließ eine interne Konfigurationsdatei auf die doppelte Größe anwachsen. Das Programm, das sie lädt, hatte ein Limit von 200 Einträgen und stürzte ab, sobald sich die übergroße Version im Netzwerk verbreitet hatte. Cloudflares Lösung ist eine Prozessänderung: Das Unternehmen will Dateien, die seine eigenen Systeme erzeugen, genauso streng prüfen wie Eingaben von Nutzern. Der Ausfall ist eine QA-Lektion, denn die Lücke lag in den Regeln dafür, was geprüft wird.
Im Oktober 2025 traf ein schwerer Ausfall eine US-Region von Amazon Web Services (AWS), der Cloud-Plattform hinter vielen Apps. AWS führte die Ursache auf das zurück, was der Bericht eine latente Race Condition nennt. Der Begriff beschreibt einen versteckten Timing-Fehler, der nur auftritt, wenn zwei automatisierte Prozesse gleichzeitig dieselben Datensätze aktualisieren. Zu den Korrekturen von AWS gehört eine zusätzliche Testsuite, also ein neuer Satz wiederholbarer Prüfungen, für eines der Wiederherstellungssysteme des Unternehmens. Der AWS-Ausfall ist eine QC-Lektion, weil ein Fehler an den bestehenden Schutzmechanismen vorbeikam.
Ihre eigenen Vorfälle lassen sich genauso einordnen. Fragen Sie nach jedem schweren Bug, ob der Prozess das Risiko zugelassen hat oder ob die Prüfungen den Fehler übersehen haben. Die Antwort zeigt Ihnen, ob Ihre QA, Ihre QC oder beides Nachholbedarf hat.
Löst Quality Engineering die QA ab?
Nein, Quality Engineering (QE) ist eine breitere Art, dieselben drei Aufgaben zu organisieren. Der Begriff QE taucht oft in Stellenanzeigen und in Angeboten von Dienstleistern auf. Das ISTQB-Glossar beschreibt Qualitätstechnik als Praktiken, bei denen „die Stakeholder gemeinsam die Verantwortung“ für die Qualität tragen. Stakeholder sind hier alle, die bei der Software mitreden, von Entwicklern und Testern bis zu Product Ownern.
Die Idee geht auf den QA-Grundsatz zurück, dass Qualität Aufgabe des ganzen Teams ist. In einem QE-Modell schreiben Entwickler automatisierte Prüfungen für ihren eigenen Code, Tester gestalten Features früh mit, und Product Owner legen fest, was vor dem Release bestanden sein muss. QA, QC und Testen finden innerhalb von QE weiterhin statt, die Definitionen weiter oben in diesem Leitfaden gelten also unverändert.
Wen stellen Sie ein, wenn Sie einen QA-Engineer einstellen?
Berufsbezeichnungen machen die Sache noch verwirrender. Nach unserer Erfahrung verbringt der typische „QA-Engineer“ den Großteil der Woche mit praktischer Arbeit: Testfälle schreiben, Prüfungen durchführen und Bugs melden. Prozessarbeit füllt die übrigen Stunden, und ihr Anteil wächst meist mit der Seniorität. Wer mit diesem Titel eingestellt wird, deckt also viel QC ab, aber nur einen Teil der QA.
Ein reiner Testauftrag kann trotzdem genau die richtige Wahl sein. Für Chesapeake Technology testen wir SonarWiz, eine Desktop-Software, mit der mehr als 4.000 Organisationen den Meeresboden kartieren. Der Kunde hatte bereits eigene Testfälle, also konzentrierten sich unsere Engineers darauf, sie auszuführen. SonarWiz ist ein komplexes Produkt, das über 60 Sonar-Datenformate liest. Allein im ersten Auftrag kamen mehr als 50 Bugs ans Licht, darunter ein kleiner Metadatenfehler, der Kartenkoordinaten um Tausende Kilometer verschob.
Auch Dienstleister gehen nicht immer präzise mit Bezeichnungen um, und das gilt auch für uns. Unsere Fallstudie beschreibt das Projekt für Elsewhen, eine Londoner Beratung für digitale Produkte, als QA-Audit. In der Praxis haben wir eine neu gestaltete Website auf Funktionalität, Optik, Barrierefreiheit, Sichtbarkeit in Suchmaschinen und Geschwindigkeit getestet. Von den gemeldeten Bugs betrafen 41 % die Designkonsistenz, und 20 % wirkten sich auf Nutzer mit Behinderungen aus. Jede Prüfung betraf das Produkt selbst, nach den ISTQB-Definitionen war das Projekt also QC.
Bevor Sie eine Person oder einen Dienstleister für Qualitätstests Ihrer Software beauftragen, stellen Sie ein paar direkte Fragen:
- Prüfen Sie unsere Anforderungen und unseren Release-Prozess, oder testen Sie nur, was wir Ihnen übergeben?
- Wer schreibt die Testfälle, und wer hält sie aktuell?
- Wie gelangen die Testergebnisse zu unseren Entwicklern, und wer entscheidet, ob ein Release ausgeliefert wird?
- Was ändert sich an unserem Prozess, wenn dieselbe Art von Bug immer wieder auftritt?
Die Antworten zeigen Ihnen, ob Sie QA, QC, Testen oder eine Mischung aus allen dreien einkaufen.
Die richtigen Begriffe wecken die richtigen Erwartungen
Wenn Sie den Unterschied zwischen QA, QC und Testen kennen, wissen Sie, was Sie von einer neuen Fachkraft, einem Dienstleister oder einer Überprüfung der Arbeitsweise Ihres Teams erwarten können. Achten Sie bei der Suche nach Dienstleistungen für Qualitätstests Ihrer Software auf drei Dinge:
- Einen Prozess, der Fehler verhindert
- Prüfungen, die die Bugs finden, die trotzdem durchrutschen
- Regelmäßige Reviews, die aus jedem übersehenen Bug eine dauerhafte Lösung machen
Bei QAwerk deckt ein einziges Team sowohl die Prozessseite als auch das praktische Testen ab, sodass Sie nicht mehrere Anbieter koordinieren müssen. Um herauszufinden, ob Ihr Projekt mehr QA, QC oder Testen braucht, sprechen Sie mit unseren QA-Engineers.
FAQ
Was ist der Unterschied zwischen QA, QC und Testen?
Bei Qualitätstests für Software sind QA, QC und Testen drei zusammenhängende Aufgaben. Stellen Sie sich eine Restaurantküche vor: QA sind die Rezepte und Hygieneregeln, die verhindern, dass schlechte Gerichte entstehen, QC ist die Entscheidung des Küchenchefs, ob jeder Teller gut genug zum Servieren ist, und Testen ist das Abschmecken, an dem sich der Koch orientiert. QA verhindert Fehler, während QC und Testen sie finden.
Gehört Testen zur QA oder zur QC?
Testen gehört zur Qualitätskontrolle. Laut ISTQB, dem internationalen Gremium, das Tester zertifiziert, ist Testen eine wesentliche Form der QC. Die Software selbst zu untersuchen, ist genau das, wofür es QC gibt. Die QA arbeitet eine Ebene darüber und entscheidet, wann getestet wird, wie viel genug ist und was sich ändert, wenn dieselben Bugs immer wiederkehren.
Macht ein QA-Engineer Qualitätssicherung oder Testen?
Die meisten QA-Engineers machen beides, in unterschiedlichen Anteilen. In einem typischen Team verbringen Junior- und Mid-Level-Fachkräfte den Großteil ihrer Zeit mit praktischem Testen. Senior Engineers und QA-Leads übernehmen mehr Prozessarbeit, etwa das Prüfen von Feature-Anforderungen und das Festlegen von Release-Kriterien. Die Titel variieren stark, lesen Sie also die aufgeführten Aufgaben in einer Stellenbeschreibung oder einem Angebot, um die tatsächliche Aufteilung zu sehen.
Kann ein einziges Team sowohl QA als auch QC übernehmen?
Ja, und für kleine und mittlere Unternehmen ist ein einziges Team oft die einfachste Lösung. Wer jedes Release testet, sieht auch, woher die Bugs kommen, und kann den zugrunde liegenden Prozess ohne Übergabe zwischen Dienstleistern verbessern. Klären Sie vor der Unterschrift, dass der vereinbarte Umfang neben den Testläufen auch Planungs- und Review-Arbeit abdeckt.
Brauchen kleine Teams einen eigenen QA-Prozess?
Ein kleines Team braucht einen schlanken QA-Prozess. Drei Gewohnheiten decken meist die Grundlagen ab: ein kurzer Testplan, ein gemeinsamer Ort für das Bug-Tracking und eine klare Regel, was vor jedem Release bestanden sein muss. Ohne diese Routine wird Testen zu zufälligem Herumklicken, und dieselben Probleme kehren in jeder neuen Version zurück.
Sehen Sie, wie eine E-Rezept-Plattform mehr als 40 Playwright-Tests mit täglichen Slack-Benachrichtigungen automatisiert und die Bestellungen bei 700.000 Patienten um 15 % gesteigert hat.
