Fragen im Vorstellungsgespräch für ein QE-Praktikum: Übungsfragen und Einsteigerantworten

Übe Fragen, bei denen du eine kleine, gut erklärbare Testentscheidung zeigen kannst. Beginne mit den Impulsen unten, statt eine lange Liste von Definitionen auswendig zu lernen. Bereite für jede Frage eine direkte Einstiegsantwort und ein konkretes Beispiel vor.

Anforderungen und erwartetes Verhalten

• Was würdest du vor dem Testen eines Registrierungsformulars fragen?
• Wie würdest du vorgehen, wenn in der Anforderung nur steht: „Ein gültiges Passwort akzeptieren“?
• Was würdest du tun, wenn die schriftliche Anforderung und die Beispielansicht voneinander abweichen?

Testideen und Prioritäten

• Welche Prüfungen würdest du bei einem einfachen Formular zuerst versuchen und warum?
• Wie würdest du Beispiele nahe einer angegebenen Eingabegrenze auswählen?
• Was würdest du priorisieren, wenn du nur Zeit für zwei Prüfungen hättest?

Nachstellen von Problemen und Fehlerberichte

• Ein Teammitglied sagt, dass die Schaltfläche „Senden“ manchmal nicht funktioniert. Welche Informationen würdest du erfragen?
• Wie würdest du einen Bericht schreiben, dem eine andere Person folgen kann?
• Was würdest du sagen, wenn das Problem auf deinem Gerät nicht auftritt?

Zusammenarbeit und Lernen

• Erzähle von einer Situation, in der dein Projektteam ein unerwartetes Verhalten entdeckt hat.
• Wie würdest du mit einer Meinungsverschiedenheit darüber umgehen, ob etwas ein Fehler ist?
• Wie würdest du ein Testwerkzeug erlernen, das du noch nicht verwendet hast?

Wähle für deine erste Übungsrunde eine Frage aus jeder Gruppe. Beantworte zuerst die gestellte Frage, bevor du Fachbegriffe hinzufügst. Bei einer Frage zur Priorisierung brauchst du zum Beispiel eine Begründung für deine erste Prüfung und nicht bloß eine Liste möglicher Eingaben.

Wenn in der Stellenbeschreibung bestimmte Programmieraufgaben oder Werkzeuge genannt werden, bereite diese separat vor. Der umfassendere Leitfaden zu Fragen im Vorstellungsgespräch für ein technisches Praktikum kann dir dabei helfen. Dieser Leitfaden konzentriert sich darauf, wie du Aufgaben rund um Softwarequalität erklärst. Markiere nach deinem ersten Durchgang, bei welchen Antworten ein klareres Beispiel fehlt.

Eine vollständige Antwort von Einsteigerinnen und Einsteigern benennt die Situation, erklärt deine eigene Handlung und endet mit einer Beobachtung oder einem sinnvollen nächsten Schritt. Du musst keinen Vorfall aus einem Produktivsystem beschreiben. Die beiden Beispiele unten zeigen, wie du begrenzte Erfahrung mit einer konkreten Testaufgabe verknüpfen kannst.

Beispiel: einen Beitrag in einer Studienarbeit beschreiben

Frage: „Erzähle mir von einer Situation, in der du geholfen hast, die Qualität eines Projekts zu prüfen.“

„In einer Studienarbeit hat unsere Gruppe eine Aufgabenliste erstellt. Ich war dafür verantwortlich, den Bearbeitungsablauf zu prüfen. Gemeinsam mit meinem Teammitglied hielt ich das erwartete Verhalten fest. Dann versuchte ich, den Namen einer Aufgabe zu ändern, ihn leer zu lassen und eine Bearbeitung abzubrechen. Dabei bemerkte ich, dass sich der angezeigte Name beim Abbrechen trotzdem änderte. Ich dokumentierte die Schritte und zeigte den Unterschied zwischen Abbrechen und Speichern. Mein Teammitglied änderte die Bearbeitungslogik, und ich wiederholte dieselben Prüfungen. In dieser Version blieb beim Abbrechen der ursprüngliche Name erhalten. Als Nächstes würde ich prüfen, ob sich andere bearbeitbare Felder genauso verhalten.“

Achte auf den Umfang: Die Person benennt einen eigenen Beitrag und ein beobachtetes Ergebnis. Sie behauptet nicht, die gesamte Anwendung getestet zu haben. Passe den Aufbau an eine Arbeit an, die du tatsächlich geleistet hast. Die STAR-Methode kann dir helfen, eine Antwort zu einer Erfahrung zu strukturieren. Beschreibe dabei aber konkret, was du selbst getan hast.

Beispiel: die Überlegungen zu einem Registrierungsformular laut aussprechen

Frage: „Wie würdest du dieses Registrierungsformular testen?“

„Zuerst würde ich klären, was als erfolgreiche Registrierung gilt und welche Felder erforderlich sind. Nehmen wir an, die vereinbarte Regel lautet, dass Passwörter mindestens acht Zeichen lang sein müssen. Ich würde mit ansonsten gültigen Angaben und einem acht Zeichen langen Passwort beginnen und das Ergebnis dann mit einem sieben Zeichen langen Passwort vergleichen. Ich würde die Meldung prüfen und feststellen, ob ein Konto erstellt wurde, statt nur darauf zu achten, ob sich die Ansicht verändert. Außerdem würde ich fragen, was passieren soll, wenn eine E-Mail-Adresse bereits registriert ist. Bei wenig Zeit würde ich den Hauptablauf der Registrierung und eine Prüfung auf ein Pflichtfeld priorisieren und anschließend erklären, welche Prüfungen noch ausstehen.“

Die Annahme wird vor den Beispielen genannt, damit die interviewende Person sie ändern kann. Bei der Frage „Warum acht?“ solltest du antworten, dass diese Zahl aus der angenommenen Anforderung stammt und keine allgemeingültige Passwortregel ist. Übe die Antwort auf diese Rückfrage, ohne deine gesamte Antwort von vorn zu beginnen.

Kläre das erwartete Verhalten und nenne anschließend eine vorläufige Annahme, falls die interviewende Person möchte, dass du fortfährst. „Ich würde alles testen“ bietet keinen Ausgangspunkt. Ein kleines Beispiel mit einer Begründung lässt sich leichter besprechen und anpassen.

Nutze die folgende Abfolge bei einer Frage wie „Teste ein Feld für einen Benutzernamen“. Die Beispiele sind Möglichkeiten, laut über ein Problem nachzudenken, und kein vollständiger Lehrplan für technisches Testen.

Sie bieten dir die Gelegenheit, einer Person, die das unerwartete Ergebnis nicht selbst gesehen hat, verständlich zu machen, was passiert ist. Nenne die Handlung, das erwartete Verhalten und die tatsächliche Beobachtung, bevor du eine Ursache vorschlägst.

Die Anleitung von Mozilla zum Verfassen von Fehlerberichten wurde für das Melden von Fehlern im Kontext der Fehlerberichterstattung geschrieben. Sie empfiehlt präzise Schritte zum Nachstellen, erwartete und tatsächliche Ergebnisse sowie eine klare Trennung von Beobachtungen und Vermutungen. Wende diese Sorgfalt bei der Dokumentation auf diese Übung im Vorstellungsgespräch an.

Beispiel: ein Bericht zur Bearbeitung einer Aufgabe

Titel: Beim Abbrechen einer Änderung des Aufgabennamens ändert sich der angezeigte Name
Kontext: Aufgabenlistenprojekt aus einer Studienarbeit, geprüfte Version
Ausgangszustand: Eine Aufgabe mit dem Namen Kapitel 2 lesen ist vorhanden
Schritte:
1. Öffne das Bearbeitungsformular dieser Aufgabe.
2. Ersetze den Namen durch Kapitel 3 lesen.
3. Wähle Abbrechen.
Erwartet: Für die Aufgabe wird weiterhin Kapitel 2 lesen angezeigt.
Tatsächlich: Für die Aufgabe wird Kapitel 3 lesen angezeigt.
Beobachteter Umfang: In dieser Sitzung nach den oben genannten Schritten gesehen.
Noch nicht geprüft: Ob die Änderung nach erneutem Öffnen der Seite bestehen bleibt.

Erkläre, worauf die Erwartung beruht: Für diese Übung hat das Team vereinbart, dass „Abbrechen“ eine nicht gespeicherte Änderung verwirft. Ohne diese Vereinbarung solltest du erst fragen, was „Abbrechen“ bewirken soll, bevor du einen Verstoß gegen die Anforderung feststellst.

Trenne eine vermutete Ursache davon. „Der angezeigte Name hat sich nach dem Abbrechen geändert“ ist eine Beobachtung. „Die Anwendung hat zu früh gespeichert“ ist eine mögliche Erklärung, die untersucht werden muss. Wenn die interviewende Person nach einer Hypothese fragt, nenne sie als etwas, das geprüft werden sollte, und gib anschließend an, welche Belege sie stützen oder infrage stellen könnten.

Ein guter Bericht vermeidet auch vage Aussagen zur Häufigkeit. Wenn du die Schritte einmal ausprobiert hast, sag das. Wenn sich das Verhalten bei einem weiteren Versuch unterschied, halte diesen Unterschied und die relevanten Bedingungen fest. Beende deine Antwort mit einem Angebot für die nächste nützliche Prüfung, zum Beispiel die Seite erneut zu öffnen, statt eine Lösung zu versprechen, die du noch nicht untersucht hast.

Beschreibe, was du versucht hast, und frage nach dem fehlenden Kontext. Wenn du ein Problem nicht nachstellen kannst, grenzt das die Beobachtung ein. Es klärt jedoch nicht, ob der ursprüngliche Bericht zutraf.

Beispiel: Das Problem tritt bei dir nicht auf. Sage: „Ich habe die aufgeführten Schritte mit der Version durchgeführt, die mir vorliegt, und die Schaltfläche hat das Formular abgeschickt. Können wir den Ausgangszustand, die Eingabe und die Version vergleichen und dann gemeinsam dieselbe Abfolge ausprobieren?“ Wenn die Person, die das Problem zuerst gemeldet hat, eine andere Umgebung verwendet hat, halte diesen Unterschied fest, bevor du mehrere Bedingungen veränderst.

Wähle deine nächste Antwort danach, welche Informationen fehlen:

• Die Schritte sind unklar: Bitte die meldende Person, die Abfolge zu zeigen, einschließlich dessen, was unmittelbar davor passiert ist.
• Der Ausgangszustand ist anders: Vereinbart denselben Ausgangspunkt und wiederholt die Schritte.
• Das Verhalten tritt nur manchmal auf: Dokumentiere Versuche und Bedingungen, einschließlich der Versuche, bei denen es nicht auftritt.
• Du hast keinen Zugriff: Erkläre die Einschränkung und frage, wer die relevanten Belege prüfen kann.

Beispiel: Ein Teammitglied ist anderer Meinung über das erwartete Verhalten. Sage: „Wir sind uns einig, dass das Formular die Eingabe akzeptiert. Uneinig sind wir uns darüber, ob es das sollte. Können wir die Anforderung prüfen oder die für diese Entscheidung verantwortliche Person fragen?“ Damit benennst du die nötige Entscheidung, ohne aus der Diskussion ein Urteil über das Teammitglied zu machen.

Wenn eine Entwicklerin oder ein Entwickler um weitere Informationen bittet, gehe direkt auf die Bitte ein. Du könntest sagen: „Die Schritte und die sichtbare Meldung liegen mir vor, aber ich habe noch nicht geprüft, was nach dem Aktualisieren der Seite geschieht. Das kann ich ergänzen.“ Wenn du herausfindest, dass deine ursprüngliche Erwartung falsch war, korrigiere den Bericht und erkläre, wodurch sich dein Verständnis geändert hat.

Wenn du einen Fachbegriff nicht kennst, antworte kurz: „Ich habe das noch nicht verwendet. Kannst du erklären, welche Aufgabe ich damit erledigen soll?“ Stelle dann, falls passend, einen Bezug zu etwas her, das du kennst. Ersetze eine fehlende Antwort nicht durch eine Vermutung, die du als sicher darstellst.

Verwende ein Beispiel, bei dem du deine Arbeit vom Beitrag der Gruppe unterscheiden kannst. Eine Studienarbeit, eine persönliche Anwendung oder eine ehrenamtlich erstellte Website kann geeignetes Material liefern, wenn du die Aufgabe ehrlich erklärst und eine Prüfung beschreibst, die du tatsächlich durchgeführt hast.

Erstelle vor dem Vorstellungsgespräch eine kurze Belegnotiz zu einem Projekt:

• Welches Verhalten hast du geprüft?
• Was hast du persönlich getan?
• Was hast du beobachtet oder dokumentiert?
• Was würdest du mit mehr Zeit oder Zugriff als Nächstes prüfen?

Wenn du noch keine passende Erfahrung hast, führe eine kleine Übung an einem Projekt durch, das dir gehört oder das du testen darfst. Notiere das erwartete Verhalten, probiere eine normale und eine ungültige Eingabe aus und halte das Ergebnis fest. Bezeichne es im Gespräch als Übung. Stelle eine kurze Erkundung nicht so dar, als hättest du die Qualität eines veröffentlichten Produkts verantwortet.

Stelle am Ende des Vorstellungsgesprächs Fragen dazu, wie eine Person im Praktikum lernen und beitragen würde:

• „Wie prüft das Team die Testideen oder Fehlerberichte von Praktikantinnen und Praktikanten?“
• „Welche Werkzeuge würde ich zuerst kennenlernen, und wie wird die Einarbeitung unterstützt?“
• „Wer hilft einer Person im Praktikum weiter, wenn eine Anforderung unklar ist?“
• „Wie könnte ein sinnvoller erster Beitrag aussehen?“

Wähle zwei Fragen danach aus, was die interviewende Person bereits erklärt hat. Wenn Mentoring schon zur Sprache kam, knüpfe daran an: „Du hast erwähnt, dass Berichte gemeinsam geprüft werden. Worauf konzentriert sich diese Durchsicht üblicherweise?“ Für die organisatorischen Aspekte solcher Gespräche findest du hier Tipps zur Vorbereitung auf ein Vorstellungsgespräch für ein Praktikum. Richte deine Fragen auf die Stelle aus, statt ein allgemeines Abschlussskript aufzusagen.

Nutze SayNow AI, um zu üben, wie du deine Überlegungen laut erklärst. Im KI-Probevorstellungsgespräch übernimmt die KI in einem Sprachgespräch die Rolle der interviewenden Person, stellt Rückfragen und gibt dir nach Abschluss eine Bewertung mit schriftlichen Hinweisen. Das Feedback umfasst Sprechfluss, Inhaltsstruktur, Passung zum Szenario und Zielerreichung. Es prüft nicht, ob technische Antworten korrekt sind.

Beginne mit einem allgemeinen Vorstellungsgesprächsszenario und übe, deinen Projektbeitrag vorzustellen. Antworte laut, gehe auf eine Rückfrage ein und lies anschließend das Feedback mit einem Ziel: Deine eigene Handlung soll leichter erkennbar sein. Wiederhole die Antwort mit einem kürzeren Einstieg und einer klareren Beobachtung am Ende.

Übertrage diese überarbeitete Struktur auf deine Übungsfragen für das QE-Praktikum. Prüfe technische Einzelheiten anhand deiner Studienarbeit, der genannten Anforderung oder mit einer geeigneten Fachperson. Nutze das Üben, um deine Erklärung zu verbessern.

Übe laut zu antworten im Szenario „Vorstellungsgespräch“.

Führe ein kurzes Probevorstellungsgespräch durch, bei dem sich die Aufgabe ändert. Wiederhole nicht dieselbe Antwort, bis sie auswendig gelernt klingt. Beginne mit einer Frage zu deiner Erfahrung, einer unklaren Anforderung und einem Bericht, den du erklären musst.

1. Nenne dein Projektbeispiel und beschreibe deinen eigenen Beitrag.
2. Stelle eine klärende Frage zur Anforderung und nenne bei Bedarf eine Annahme.
3. Wähle zwei Testideen und erkläre die erwarteten Ergebnisse.
4. Beschreibe ein überraschendes Ergebnis anhand der Schritte, der Erwartung und der Beobachtung.
5. Beantworte eine Rückfrage, bei der sich eine Bedingung ändert, zum Beispiel weniger Zeit oder ein anderer Ausgangszustand.
6. Beende das Gespräch mit zwei Fragen zum Prüfprozess des Teams und zur Unterstützung beim Lernen.

Achte auf den Moment, in dem deine Antwort die Frage nicht mehr beantwortet. Wenn du den größten Teil der Zeit die Anwendung beschreibst, stelle deine Entscheidung an den Anfang. Das Pyramidenprinzip kann dir helfen, den Hauptpunkt vor die unterstützenden Einzelheiten zu setzen. Wenn du zusätzlich Motivation und Verfügbarkeit üben möchtest, nutze den umfassenderen Leitfaden zu Fragen im Vorstellungsgespräch für ein Praktikum.

Bei Fragen im Vorstellungsgespräch für ein QE-Praktikum solltest du in jeder Antwort eine Entscheidung verständlich machen: Was würdest du prüfen, warum ist es wichtig und was würde dir das Ergebnis sagen? Verbessere zum Abschluss der heutigen Übung die am wenigsten klare Antwort ein Mal und notiere dann die technische Frage, die du noch lernen musst.