IHK-Aufgaben Qualitätsmanagement
Diese Lektion sammelt typische IHK-Prüfungsaufgaben aus dem Bereich Qualitätsmanagement. Die Aufgaben decken alle Themen des Kurses ab – von ISO-Normen über Testmethoden bis zum PDCA-Zyklus. Löse jede Aufgabe zuerst selbst, bevor du die Lösung aufklappst. In der Prüfung zählen oft die Begründungen genauso viel wie die richtige Zuordnung.
1) ISO-Normen und Qualitätsbegriffe
Aufgabe 1 – ISO 25010 Merkmale zuordnen
Ordne die folgenden Szenarien dem passenden ISO-25010-Qualitätsmerkmal zu: (a) Eine App stürzt ab, wenn mehr als 1.000 Nutzer gleichzeitig aktiv sind. (b) Ein Nutzer findet die Einstellungen nicht, obwohl er sie schon dreimal benutzt hat. (c) Eine Webanwendung lässt sich auf Wunsch des Kunden auf einem neuen Cloudanbieter betreiben, ohne Codeänderungen. (d) Ein Passwort wird im Klartext in der Datenbank gespeichert. (e) Ein Bugfix für ein Modul verursacht unerwartet Fehler in fünf anderen Modulen.
(a) App stürzt bei Last ab → Leistungseffizienz (Performance unter Last)
(b) Nutzer findet Einstellungen nicht → Benutzbarkeit (Erlernbarkeit, Bedienbarkeit)
(c) Wechsel auf neuen Cloudanbieter ohne Codeänderung → Übertragbarkeit / Portierbarkeit
(d) Passwort im Klartext gespeichert → Sicherheit (fehlende Vertraulichkeit)
(e) Bugfix verursacht Fehler in anderen Modulen → Wartbarkeit (fehlende Modularität, hohe Kopplung)
In der IHK-Prüfung werden oft 2–3 solcher Zuordnungen abgefragt. Merke: Sicherheit ≠ Zuverlässigkeit – Sicherheit betrifft Datenschutz und Zugriffsschutz, Zuverlässigkeit betrifft Stabilität und Fehlertoleranz.
Aufgabe 2 – QS vs. QM unterscheiden
Entscheide für jede Maßnahme: Ist es eine Maßnahme der Qualitätssicherung (QS) oder des Qualitätsmanagements (QM)? Begründe kurz. (a) Das Unternehmen lässt sich nach ISO 9001 zertifizieren. (b) Vor jedem Release wird ein Systemtest durchgeführt. (c) Ein QM-Beauftragter wird benannt, der alle QM-Aktivitäten koordiniert. (d) Jeder Pull Request muss von einem zweiten Entwickler reviewed werden (Vier-Augen-Prinzip). (e) Die Geschäftsführung definiert das Qualitätsziel: max. 1 % Fehlerrate in Produktion.
(a) ISO-9001-Zertifizierung → QM (strategischer Rahmen für die gesamte Organisation)
(b) Systemtest vor Release → QS (operative Prüfmaßnahme für ein konkretes Produkt)
(c) QM-Beauftragter benennen → QM (organisatorische Verankerung des Qualitätssystems)
(d) Vier-Augen-Prinzip Code Review → QS (operative Maßnahme zur Fehlererkennung im Prozess)
(e) Qualitätsziel definieren → QM (Qualitätsplanung als Teil des QM)
Faustregel: QS = konkrete Prüfmaßnahmen am Produkt oder Prozessschritt. QM = alles, was die Organisation als Ganzes qualitätsfähig macht (Ziele, Strukturen, Standards, Zertifizierungen).
2) Testmethoden
Aufgabe 3 – Äquivalenzklassen und Grenzwerte
Eine Funktion zur Validierung einer Bestellmenge akzeptiert nur ganzzahlige Werte zwischen 1 und 99 (inklusive). Bestimme: (a) die gültigen und ungültigen Äquivalenzklassen, (b) die Repräsentanten der Äquivalenzklassen und (c) die Grenzwerte, die getestet werden müssen.
(a) Äquivalenzklassen:
• Gültige Klasse: Ganzzahlen 1–99
• Ungültige Klasse 1: Zahlen ≤ 0 (zu klein oder negativ)
• Ungültige Klasse 2: Zahlen ≥ 100 (zu groß)
• Ungültige Klasse 3: Nicht-ganzzahlige Werte (z.B. 5,5)
• Ungültige Klasse 4: Keine Zahl (z.B. „abc", leer)
(b) Repräsentanten: Gültig: 50 | Ungültig: −5, 150, 1,5, „abc"
(c) Grenzwerte: 0, 1, 99, 100 – plus jeweils einen Wert daneben: −1, 2, 98, 101
Mindest-Testfälle: 5 (Äquivalenzklassen) + 8 Grenzwerte = 13 Testfälle
Grenzwerte 0 und 100 sind die ersten ungültigen Werte außerhalb des Bereichs. 1 und 99 sind die Grenzen innerhalb. Beide müssen getestet werden – Programmierer machen Off-by-One-Fehler besonders oft an diesen Stellen.
3) Fehleranalyse und Verbesserungsmethoden
Aufgabe 4 – 5-Why-Analyse
In einem IT-Unternehmen werden regelmäßig Sicherheitsupdates mit 3–4 Wochen Verzögerung eingespielt. Führe eine 5-Why-Analyse durch und leite eine konkrete Maßnahme ab. Beginn: „Updates werden zu spät eingespielt."
Problem: Updates werden 3–4 Wochen zu spät eingespielt.
Warum 1: Der zuständige Admin hat keine Zeit dafür.
Warum 2: Er ist mit Supportaufgaben überlastet.
Warum 3: Supportaufgaben haben keine definierten Prioritäten – alles ist gleichdringend.
Warum 4: Es gibt kein Ticketsystem mit Priorisierung – alles läuft per E-Mail.
Warum 5 → Wurzelursache: Es gibt keinen strukturierten IT-Betriebsprozess mit klaren Prioritäten für sicherheitskritische Aufgaben.
Maßnahme: Ticketsystem einführen (z.B. JIRA/Jira). Sicherheitsupdates als Kategorie „Kritisch" definieren, die immer innerhalb von 48h bearbeitet werden müssen. Aufgabenverteilung überprüfen.
Beachte: Die Wurzelursache ist nie „der Admin hat keine Zeit". Das ist ein Symptom. Die Ursache ist immer ein fehlender oder schlecht gestalteter Prozess.
Aufgabe 5 – PDCA-Zyklus anwenden
Ein Entwicklungsteam stellt fest, dass die Defect Escape Rate bei 18 % liegt (Ziel: unter 5 %). Beschreibe, wie das Team den PDCA-Zyklus konkret anwenden würde, um das Problem zu lösen. Nenne für jede Phase mindestens eine konkrete Maßnahme.
Plan: Ursachenanalyse mit Ishikawa-Diagramm → Hauptursache: keine automatisierten Tests, Testphase zu kurz, unklare Testfallspezifikation. Maßnahme: Einführung von Unit Tests für alle neuen Features, Ziel-Coverage 70 %. Pilot: Team A, 2 Sprints.
Do: Team A schreibt für alle neuen Features Unit Tests vor dem Merge. Testfallspezifikation wird als Pflicht vor dem Sprint Planning eingeführt.
Check: Nach 2 Sprints: Defect Escape Rate von Team A: 6 % (vorher 18 %). Code Coverage: 74 %. Ziel fast erreicht. Entwicklungszeit +12 %.
Act: Maßnahmen auf alle Teams ausrollen. Unit Tests als Pflicht in die Definition of Done aufnehmen. Coverage-Ziel auf 80 % erhöhen. Nächster PDCA-Zyklus: Ziel 3 % Defect Escape Rate.
Ergebnis: Defect Escape Rate von 18 % auf 6 % in 2 Sprints – Ziel von 5 % fast erreicht.
Aufgabe 6 – Testprotokoll bewerten
Ein Junior-Entwickler legt dir sein Testprotokoll vor. Es enthält: Datum, seinen Namen, eine Liste von 8 Funktionen, die er „getestet" hat, und einen einzigen Kommentar: „Alles funktioniert." Was fehlt in diesem Protokoll? Nenne mindestens 5 fehlende Elemente und erkläre kurz, warum sie wichtig sind.
1. Testfall-IDs: Ohne IDs können Testfälle nicht eindeutig referenziert, nachverfolgt oder nachgetestet werden.
2. Konkrete Testeingaben: „Getestet" sagt nichts darüber aus, ob Grenzwerte, ungültige Eingaben oder Fehlerfälle geprüft wurden.
3. Erwartetes vs. tatsächliches Ergebnis: Ohne diese Gegenüberstellung ist unklar, wonach er überhaupt gesucht hat und ob das Ergebnis wirklich korrekt ist.
4. Status je Testfall (PASS/FAIL/BLOCKED): „Alles funktioniert" ist keine überprüfbare Aussage – jeder Testfall braucht einen klaren Status.
5. Softwareversion / Testumgebung: Ohne Versionsnummer ist das Protokoll nicht reproduzierbar – welche Version wurde getestet? In welcher Umgebung?
6. Fehlertickets bei FAIL: Gefundene Fehler brauchen eine Bug-ID – ohne Verlinkung ist unklar, ob sie behoben und nachgetestet wurden.
Dieses Protokoll ist wertlos für eine formale Abnahme – es beweist nicht, dass die Software korrekt getestet wurde.
Kurs-Zusammenfassung – Was du nach K03 können solltest
| Thema | Kernaussage | Lektion |
|---|---|---|
| ISO 25010 | 8 Qualitätsmerkmale für Software (Funktion, Leistung, Sicherheit, Wartbarkeit…) | L1 |
| QS vs. QM | QS = operativ am Produkt. QM = strategisch in der Organisation. QS ist Teil von QM. | L2 |
| Black/White-Box | Black-Box: Nutzersicht ohne Codekenntnisse. White-Box: Innere Logik, Coverage-Messung. | L3 |
| Ishikawa | Ursache-Wirkungs-Diagramm: Fischgräte, Breite der Ursachen visualisieren | L4 |
| 5-Why | 5× „Warum?" bis zur Wurzelursache. Sucht Systeme, nicht Schuldige. | L5 |
| PDCA | Plan → Do → Check → Act. Endloser Verbesserungskreislauf. Act = Standardisieren. | L6 |
| KVP | Kaizen: Dauerhaft, in kleinen Schritten, alle Mitarbeitenden einbeziehen. | L7 |
| KPIs | SMART-Kennzahlen: Defect Escape Rate, MTTR, Coverage, CSAT. | L8 |
| Testprotokoll | ID, Eingabe, Erwartung, Ergebnis, Status (PASS/FAIL/BLOCKED), Bug-ID. | L9 |
In der IHK-Prüfung werden Qualitätsthemen oft in Kombination abgefragt: „Beschreibe, wie du bei einem Softwareausfall vorgehen würdest" kann Ishikawa + 5-Why + PDCA + KPIs + Testprotokoll in einer Aufgabe vereinen. Übe deshalb, Methoden situativ zu verbinden – nicht nur isoliert.