1-Interview Questions(Deutsch)

Photo by Christina @ wocintechchat.com on Unsplash

1. Erzählen Sie mir von sich?

Zunächst möchte ich Ihnen dafür danken, dass Sie mir diese Gelegenheit gegeben haben.

Mein Name ist…

— —

Vielen Dank.

2. Beschreiben Sie Ihre Rolle?

• Ich bin verantwortlich für die Entwicklung und Wartung unseres “Test Automation Framework” auf Basis des POM und das Hinzufügen neuer Tests Fälle zu unserer automatisierten Regressionssuite.

• Ich habe verschiedene Arten von Tests durchgeführt, wie zum Beispiel; Funktionstests, Smoke-Tests, Regressionstests und Back-End-Tests

• Ich bin in meinem letzten Projekt dafür verantwortlich, Regressionstests durchzuführen, wenn Entwickler der Anwendung oder dem Ende des Sprints neue Funktionen hinzufügen.

• Als ich in das Unternehmen eintrat, hatten wir einen großen Regressionsanzug, den wir automatisieren mussten. Die Regressionsabdeckung für die Automatisierung war, um %10 sehr niedrig. Wir hatten sehr wenig automatisierte Testfälle. Daher haben wir viel Zeit mit Running Regression verbracht. Da sie nicht genug Zeit hatten, um alle Testfälle aus der Regressionssuite auszuführen, hatten wir viele neue Fehler, so dass eine Automatisierung für das Projekt wirklich erforderlich war. Seit ich beigetreten bin, haben sie die Anwendungsfunktionalität analysiert.

In den letzten zwei Jahren habe ich den Regressionsanzug analysiert, ich habe mir priorisierte Testfälle ausgedacht wie: Welche Funktionalität wird am häufigsten verwendet, welche Funktionalität ist am kritischsten, welche Funktionalitäten werden lange dauern, um manuell ausgeführt zu werden, welche Funktionalitäten diese oft brechen.

• Ich habe mein Automatisierungs-Framework von Grund auf neu entwickelt.

• Ich automatisiere Testfälle. Sobald ich Testfälle automatisiert habe, plane ich einige von ihnen für einen täglichen Smoketest, der so oft wie nötig wiederholt wird. Der Smoketest schickt dann seinen Bericht an mich und mein Team.

• Ich führe die gesamte Regressionssuits vor jeder Anwendungsversion aus. Ich analysiere das Testergebnis. Ich stelle einen Pass-Fail-Bericht zur Verfügung. Ich überwache die Ausführung, um zu sehen, ob etwas nicht stimmt, sobald es fehlschlägt. Wenn es aufgrund meines Codes fehlschlägt, muss ich meinen Code reparieren. (Vielleicht war die Anwendung während dieser Zeit ausgefallen, und ich habe mein Skript zur falschen Zeit ausgeführt.) Wenn es wirklich einen Defekt gibt, protokolliere ich den Defekt und teste ihn erneut, bis er behoben ist.

• Als funktionsübergreifendes Teammitglied helfe ich den Funktionstestern, bringe ihnen grundlegende Automatisierungsframeworks, Java und Selenium bei, um sie zu einem Teil des Teams zu machen, um die Produktivität des Teams zu verbessern. Zumindest können sie Testfälle ausführen und die Ergebnisse analysieren.

• Als CROSS FUNCTIONAL-Teammitglied versuche ich auch, dem Funktionstestteam bei Bedarf bei der Ausführung manueller Testfälle zu helfen. Und wenn es einen Defekt gibt, den ich reproduzieren kann, protokolliere ich den Defekt an JIRA.

• Ich unterstütze auch die Produktion in jeder größeren Version. Normalerweise ist der Produktionssupport am Wochenende. Ich werde kommen und nach der Bereitstellung “schreibgeschützte” Testfälle in der Produktionsumgebung ausführen. Wenn es ein Problem bei der Bereitstellung gibt, muss ich mich sofort mit Dev und QA in Verbindung setzen, um das Problem so schnell wie möglich zu beheben.

• Im Sprint-Grooming-Meeting gebe ich immer Feedback zu den User Stories, um sicherzustellen, dass es sich um etwas Testbares und Messbares handelt. Zum Beispiel: Es gab eine User Story, die nach dieser und jener Änderung in der Anwendung sagte, dass sich die Leistung verbessern sollte. Ich habe die Geschäftsleute gefragt, was Sie mit Leistungsverbesserung meinen. Wie messen Sie die Verbesserung? Danach haben sie sich bessere User Stories ausgedacht (Anforderung in agile)

• Darüber hinaus kann ich Ihnen sagen, dass eine meiner Aufgaben, die ich wirklich genieße, User Story generierende Sitzungen sind, weil es aus der Perspektive eines Benutzers sehr interessant ist. Weil wir diejenigen sind, die die Anwendung die ganze Zeit testen. Ich denke aus der Perspektive des Endbenutzers. Ich denke, ich tue Gutes, indem ich mich in die Perspektive des Endbenutzers versetze. Wenn wir also User Story-Sitzungen versuchen, machen wir unsere Akzeptanzkriterien viel besser. Business Analyst gehen also die User Stories durch, sie gehen die Akzeptanzkriterien durch, wir stellen Fragen, die wir Feedback geben, verbessern User Stories und machen unser Team so produktiver. Weil wir bessere, klare Akzeptanzkriterien haben. Das macht uns, unsere Anforderungen besser, unser Code besser, klarer und wir vermeiden einige Mängel in Bezug auf die User Story-Generierungssitzung selbst, anstatt eine unklare User Story zu haben, unklaren Code zu erstellen, etwas falsch zu machen.

• Außerdem nehme ich als Teil des Agile Scrum Teams an den verschiedenen Walkthroughs Meetings für die Anforderungsprüfungen teil und gebe dem BA wertvolles Feedback.

• Das sind so ziemlich 80% meiner Rolle als Automatisierungsingenieur in meinem aktuellen Projekt.