3) Technische und professionelle Fragen: Hier trennen sie QS von „QA“
Jetzt wird’s konkret. In der Schweiz sind viele QS-Rollen entweder stark produktionsnah (Maschinenbau/Industrie) oder stark reguliert (Medtech/Pharma). Du musst nicht alles können – aber du musst sauber einordnen können, was du wie angehst. Und ja: Begriffe wie Test Engineer, Software Test Engineer oder Validierungsingenieur tauchen in CH-Stellenanzeigen oft als Spezialisierungen auf.
Q: Wie baust du einen Prüfplan (Control Plan) für ein neues Produkt auf?
Why they ask it: Sie testen, ob du von Risiko → Merkmal → Methode → Frequenz denken kannst.
Answer framework: „CTQ-Kette“ (Kundenanforderung → CTQ → Prozessschritt → Prüfmittel → Reaktionsplan).
Example answer: „Ich starte bei Anforderungen und Risiken: CTQs aus Spezifikation, FMEA und Lessons Learned. Dann mappe ich CTQs auf Prozessschritte und definiere pro Merkmal Messmethode, Stichprobe/Frequenz und Akzeptanzkriterien. Wichtig ist der Reaktionsplan: Was passiert bei Trend, bei OOS, bei Messmittelproblem? Am Ende prüfe ich, ob der Plan in der Linie lebbar ist – sonst ist er nur Papier.“
Common mistake: Prüfplan als Liste von Messungen statt als Steuerungsinstrument.
Q: Erklär den Unterschied zwischen Korrektur, Korrekturmaßnahme und CAPA – mit Beispiel.
Why they ask it: CAPA-Qualität ist ein Klassiker in Audits.
Answer framework: „3-Ebenen“ + Wirksamkeitscheck.
Example answer: „Korrektur ist das unmittelbare Beheben am Produkt, z. B. Nacharbeit oder Sortierung. Korrekturmaßnahme verhindert das Wiederauftreten der konkreten Abweichung, z. B. Werkzeug tauschen und Parameter fixieren. CAPA geht systemisch: Ursache im Prozess/Training/Design eliminieren und Wirksamkeit nachweisen, z. B. Standard anpassen, Schulung, Audit, Trendanalyse nach 30/60 Tagen.“
Common mistake: CAPA als „Ticket schließen“ behandeln ohne Wirksamkeitsnachweis.
Q: Welche Normen/Standards sind für deine Arbeit am relevantesten – und wie setzt du sie praktisch um?
Why they ask it: In CH zählen Normenkenntnis und Umsetzung, nicht Zitierfähigkeit.
Answer framework: „Norm → Prozess → Evidenz“.
Example answer: „Das hängt von der Branche ab: In Medtech ist ISO 13485 zentral, in Automotive IATF 16949, allgemein ISO 9001 als Basis. Praktisch übersetze ich Normanforderungen in Prozesse: z. B. Lenkung dokumentierter Information, Lieferantenqualifizierung, Abweichungsmanagement. Und ich denke immer an Evidenz: Audit Trail, Schulungsnachweise, Freigaben, Risikoakten.“
Common mistake: Normen aufzählen, aber keine Umsetzung im Alltag erklären.
Q: Wie führst du eine Messsystemanalyse (MSA) durch, und wann ist sie „gut genug“?
Why they ask it: Ohne fähige Messung ist jede Qualitätsentscheidung wacklig.
Answer framework: „Zweck–Design–Entscheid“.
Example answer: „Ich kläre zuerst den Zweck: Prozessfreigabe, Wareneingang oder Fehleranalyse – das bestimmt die Strenge. Dann wähle ich das Design: z. B. Gage R&R mit mehreren Prüfern und Teilen, inklusive Wiederholungen. ‚Gut genug‘ ist es, wenn die Messunsicherheit die Entscheidungsgrenze nicht dominiert; bei knappen Toleranzen brauche ich ein deutlich besseres System oder eine andere Messmethode.“
Common mistake: Prozentwerte auswendig lernen, aber den Entscheidungsbezug nicht erklären.
Q: Wie gehst du bei Lieferantenproblemen vor (8D, SCAR, Audit)?
Why they ask it: CH-Unternehmen sind oft stark in Lieferketten eingebunden – Lieferanten-QS ist Alltag.
Answer framework: 8D in 4 Sätzen (Containment → Root Cause → Corrective Action → Prevent Recurrence).
Example answer: „Ich starte mit Containment: klare Sperrung, Sortierung, Rückverfolgbarkeit und Kommunikation, damit kein schlechtes Material weiterläuft. Dann fordere ich eine strukturierte Ursachenanalyse (8D/SCAR) und prüfe, ob die Daten belastbar sind. Maßnahmen müssen messbar sein, inklusive Wirksamkeitscheck. Wenn es wiederholt passiert oder kritisch ist, plane ich ein Lieferantenaudit mit Fokus auf Prozessfähigkeit, Change Control und Prüfstrategie.“
Common mistake: Sofort ein Audit fordern, ohne Containment und Datenbasis.
Q: Welche Tools nutzt du typischerweise – und wie stellst du Datenintegrität sicher?
Why they ask it: Sie wollen Praxis: QMS/ERP/MES, Tickets, Statistik – und saubere Rechte.
Answer framework: „Tool–Use Case–Control“.
Example answer: „Je nach Setup arbeite ich mit eQMS (z. B. TrackWise, MasterControl oder vergleichbar), ERP wie SAP für Chargen/Material, und oft Minitab für Statistik. Entscheidend ist nicht der Tool-Name, sondern die Kontrolle: Rollen/Rechte, Audit Trail, Pflichtfelder, Versionierung und klare Workflows für Abweichungen, CAPA und Change Control. Ich prüfe außerdem, ob Reports reproduzierbar sind und Rohdaten auffindbar bleiben.“
Common mistake: Tool-Buzzwords droppen, ohne Governance und Datenintegrität.
Q: Du bist als QS-Ingenieur in einem Transfer/Ramp-up. Welche Freigaben brauchst du, bevor du „Go“ sagst?
Why they ask it: Sie testen, ob du Gate-Logik und Risiko-Freigaben kennst.
Answer framework: „Gate-Checkliste als Story“ (Prozessfähig → Prüfmittel → Dokumente → Schulung → Risiko).
Example answer: „Ich brauche Prozessnachweise (z. B. Erstbemusterung/FAI, Prozessfähigkeit wo sinnvoll), freigegebene Prüfpläne und Arbeitsanweisungen, qualifizierte Prüfmittel inklusive MSA, und Schulungsnachweise der Operatoren. Dazu: offene Abweichungen/CAPA bewertet, Lieferantenstatus klar, Rückverfolgbarkeit steht. Wenn etwas fehlt, entscheide ich nicht aus Prinzip dagegen – ich definiere ein kontrolliertes Start-Szenario mit Zusatzprüfungen und klarer Exit-Strategie.“
Common mistake: „Go/No-Go“ als Bauchentscheidung statt als dokumentiertes Gate.
Q: Was machst du, wenn dein eQMS/ERP ausfällt – aber eine Chargenfreigabe heute raus muss?
Why they ask it: Das ist die „Tool fails“-Frage: Compliance unter Stress.
Answer framework: „Contain–Fallback–Reconcile“.
Example answer: „Erstens stoppe ich riskante Schritte: keine Freigabe ohne kontrollierten Prozess. Zweitens nutze ich einen definierten Fallback: papierbasierte Notfallformulare mit eindeutiger ID, Unterschriftenregel, Zeitstempel und späterer Nachpflege. Drittens mache ich Reconciliation: sobald das System wieder läuft, werden Daten vollständig übertragen, Abweichungen dokumentiert, und ich prüfe den Audit Trail. Wenn es keinen Notfallprozess gibt, ist das selbst eine Abweichung, die ich sofort adressiere.“
Common mistake: „Dann mache ich es halt per E-Mail“ – ohne kontrollierte Notfalllenkung.
Q: Wie würdest du Software-Qualität bewerten, wenn du als Software Test Engineer in ein mechatronisches Produktteam kommst?
Why they ask it: Sie prüfen, ob du Systemdenken hast (Hardware + Software + Risiko).
Answer framework: „Risk-based testing“ + Traceability.
Example answer: „Ich starte mit Risiken und Anforderungen: Welche Funktionen sind sicherheits- oder compliancekritisch? Dann baue ich Traceability von Anforderungen zu Testfällen und Ergebnissen auf. Ich kombiniere Unit/Integration/Systemtests mit klaren Akzeptanzkriterien und schaue auf Nichtfunktionales wie Robustheit und Logging. Wichtig ist die Schnittstelle zur Hardware: reproduzierbare Testumgebungen, Versionierung und klare Freigabekriterien.“
Common mistake: Nur Testarten aufzählen, ohne Risiko- und Traceability-Logik.
Q: Wie unterscheidet sich Validierung von Verifizierung – und wo passieren typische Fehler?
Why they ask it: Das ist eine klassische Frage für Rollen mit Validierungsingenieur-Anteil.
Answer framework: „Build the thing right vs. build the right thing“ + Beispiel.
Example answer: „Verifizierung prüft, ob wir nach Spezifikation gebaut haben – z. B. Tests gegen definierte Anforderungen. Validierung prüft, ob das Produkt im realen Use Case den Bedarf erfüllt. Typische Fehler: Validierung wird zu spät gemacht oder ohne repräsentative Nutzung; Verifizierung wird mit unklaren Anforderungen durchgeführt, sodass Tests zwar ‚grün‘ sind, aber am Kunden vorbei.“
Common mistake: Begriffe verwechseln oder nur theoretisch erklären.