Bestellung / Behandlung von Tausenden von Mängeln kurz vor der Freigabe
Diese Frage wurde mir in einem Interview mit einem wirklich guten Unternehmen gestellt. Nachfolgend werde ich die Frage in Form unserer Interaktion (M: ich & ich: Interviewer) stellen. Obwohl es keine endgültigen Antworten gibt, muss ich wissen, was Idee / Antwort, die der Interviewer wirklich wollte :
I: Das Szenario ist, dass Sie und 2 andere aus dem Testteam bestehen. Sie, der Leiter, sind der einzige, der Automatisierung durchführen kann, andere können nur manuelle Tests durchführen. Sie haben fast 10.000 Fehler, die aufgetreten sind, und Sie haben 4-5 Wochen oder weniger Zeit, bevor dieses Produkt ausgeliefert wird. Was werden Sie tun, um sicherzustellen, dass das Produkt rechtzeitig geliefert wird?
M: Filtern Sie die Fehler nach Priorität und testen Sie sie erneut. Führen Sie in der Zwischenzeit ein Protokoll darüber, welche Funktionen einer stärkeren Regression ausgesetzt sind, und beginnen Sie daher, sie zu automatisieren. Ähnliche oder verwandte Fehler werden anderen zur weiteren Prüfung gegeben.
I: Angenommen, keiner der Fehler wurde mit einer Priorität markiert. Was werden Sie tun?
M: Ich werde nach Datumsangaben filtern. Bei jeder Art von SDLC, auch bei der agilen, werden die Kernkomponenten zuerst entwickelt. Wenn es Kernfehler gibt, müssen sie zuerst behoben werden.
I: (missbilligend) Was ist, wenn in einem späteren Sprint eine sehr wichtige Funktionalität hinzugefügt wird? Wie werden Sie Ihre Teamkollegen und Ihre Fähigkeit zur Automatisierung einsetzen?
M: Zusammen mit dem Datum muss ich als Tester den Kern und die wichtigen Funktionen des Produkts bis zum Datum kennen. Wenn Sie dies berücksichtigen, werden Sie die Kernbereiche jedes Sprints finden, an denen Sie arbeiten müssen (über Teamkameraden antwortete das Gleiche wie vorher).
Ich: Angenommen, die Fehler wurden nicht mit der Zeitachse jedes Sprints markiert. Was werden Sie tun?
M: Ich werde die Fehlerliste mit Schlüsselwörtern durchsuchen, die die wichtigen Funktionen darstellen, ohne die das Produkt nicht freigegeben werden kann. Ich werde die Käfer von dort auswählen.
I: (wieder missbilligend) Mit einem Schlüsselwort erhalten Sie so viele Ergebnisse, werden Sie sie einzeln durchgehen?
M: (verliert langsam die Hoffnung) Ich werde einfach den Titel durchgehen und mich entscheiden.
I: Im Allgemeinen sind Titel nicht so erklärend. Wie werden Sie damit umgehen?
M: Ich werde das Produkt selbst testen und nach ähnlichen Fehlern suchen, mit denen ich konfrontiert bin, anstatt zu versuchen, Fehler zu beheben, da ich eine Entscheidung für die Produktlieferung treffen muss.
I: Also wirst du diese vielen Fehler ignorieren? Stakeholder sind möglicherweise nicht einverstanden. (Danach habe ich es total verloren und plapperte einfach weiter und ich erinnere mich nicht, was noch gefragt wurde. Auch überall wurde das Management / die Arbeit der 2 anderen manuellen Tester gefragt)
Dies war ein Interview für Sr. SDET.
Antworten
Zusätzlich zu den anderen Antworten würde ich sagen, dass der Interviewer sucht, wie Sie als Neuzugang in einem Team mit einer Situation ohne Gewinn umgehen würden. Ehrlich gesagt würde ich vermuten, dass sich das Unternehmen in der Vergangenheit zumindest in einer solchen Situation befunden hat. Im schlimmsten Fall (ich gebe frei zu, dass ich zynisch bin) wird sich etwas Ähnliches gegenübersehen, wer auch immer die Position bekommt.
Als Interviewer möchte ich so etwas von der Person, die ich interviewt habe:
Zunächst möchte ich wissen, wie diese Fehler organisiert sind, insbesondere Priorität, Schweregrad und Risiko. Ich gehe davon aus, dass ich in diese Situation gerate und nicht von Anfang an involviert war, weil diese Art von Situation darauf hindeutet, dass irgendwo etwas schief gelaufen ist.
Wenn die Fehler nicht so organisiert sind, dass Priorität, Schweregrad und Risiko berücksichtigt werden, möchte ich mit den anderen Testern, dem Projektmanagement und der Entwicklung sprechen, um festzustellen, welche Probleme, von denen sie wissen, das größte Risiko für die geplante Bereitstellung darstellen Datum.
Wenn es eine solche Organisation gibt, würde ich gerne mit Testern, Projektmanagement und Entwicklung sprechen, um die Fehler mit dem höchsten Risiko zu bestätigen. Im Idealfall würde ich nach einer Möglichkeit suchen, eine Liste von Fehlern zu erstellen, die behoben werden müssen, bevor das Produkt veröffentlicht werden kann. Bei 10.000 Fehlern wird die Erstellung dieser Liste einige Zeit in Anspruch nehmen. Dies setzt voraus, dass es keine Fehler gibt, die Tester nicht finden konnten, da die gemeldeten Fehler sie verbergen oder blockieren.
Sobald ich eine Vorstellung davon habe, wie schlimm die Situation ist, kann ich entscheiden, ob es meiner Meinung nach möglich ist, die Anwendung wie geplant freizugeben. Wenn die meisten Fehler ein relativ geringes Risiko aufweisen und die Fehler mit hohem Risiko relativ leicht zu beheben scheinen, würde ich mein Team auf die Fehler mit hohem Risiko konzentrieren und mit dem Projektmanager und allen anderen Teamleitern zusammenarbeiten, um das höchste Risiko zu erzielen (hoher Schweregrad, der am wahrscheinlichsten im Feld auftritt und / oder Bereiche der Anwendung blockiert) Fehler behoben und getestet.
Wenn ich keine Möglichkeit sehe, das Produkt rechtzeitig freizugeben, würde ich mit dem Projektmanager und meinem Chef sprechen, um herauszufinden, ob es eine Möglichkeit gibt, eine eingeschränkte Beta-Version mit soliden Funktionen zu erstellen oder die Veröffentlichung zu verzögern. Da ich neu in der Position bin, weiß ich nicht, ob es Vertragsanforderungen oder andere Faktoren gibt, die außerhalb meiner Kontrolle liegen und die das Datum der Veröffentlichung unbeweglich machen könnten.
Ich würde auch sicherstellen, dass ich nach der Veröffentlichung mit den Leitern aller beteiligten Teams zusammenarbeite, um herauszufinden, wie eine solche Situation zustande kam und welche Maßnahmen wir ergreifen könnten, um zu verhindern, dass sie erneut auftritt, und wie wir zusammenarbeiten können Reduzieren Sie den Bug-Rückstand.
Beachten Sie, dass dies nichts mit der SDET-Rolle zu tun hat. Aus der Frage geht hervor, dass der Interviewer erwartet, dass ein SDET auch als Testleiter fungiert - ich denke nicht, dass dies eine besonders gute Sache ist, und ehrlich gesagt möchte ich wissen, ob dies etwas ist, was das Unternehmen von seinem erwartet SDETs.
Es ist erwähnenswert, dass Interviews, obwohl sie Situationen mit hohem Stress sind, versuchen, seitwärts zu denken und die Auswirkungen der gestellten Fragen zu untersuchen, anstatt einzutauchen. Es ist schwierig, dies zu tun, weil Sie gestresst sind und versuchen, Ihr Bestes zu geben. Wenn Sie sich jedoch etwas Zeit nehmen können, um sich mental zu fragen, wonach der Interviewer mit der Frage sucht, können Sie normalerweise eine bessere Antwort geben.
Das erste, was mir in den Sinn kommt, ist: Haben diese Tests jemals zuvor funktioniert? Wenn ja, dann keine Panik. Entweder in der Codebasis oder im Testframework hat sich etwas geändert, was wahrscheinlich dazu führt, dass Gruppen von ihnen fehlschlagen. Finden Sie das heraus und sehen Sie, ob Sie mehrere tausend Fehler auf einmal beseitigen können. Sie müssen immer noch die manuell durchgelesenen durchlesen und sie noch einmal überprüfen, aber vielleicht dauert das nur ein paar Tage.
Wenn sie vorher noch nie überprüft wurden, würde ich immer noch etwas Ähnliches tun - suchen Sie nach Gemeinsamkeiten, mit denen Sie große Gruppen auf einmal reparieren können.
Andernfalls gibt es dort so viel Lärm, dass Sie möglicherweise etwas Kritisches übersehen, das fehlschlägt.
Akzeptieren Sie danach, dass Sie möglicherweise nicht in der Lage sind, alles zu erreichen und sich auf den Codepfad des Geldmachers zu konzentrieren. Die Dinge, die funktionieren müssen oder das Geschäft klappt. Nachdem Sie einige weitere gelöscht haben, überprüfen Sie jeden zweiten oder dritten Tag, ob es weitere gruppierte Fehler gibt, wie zuvor erwähnt, und versuchen Sie, einige weitere Gruppen zu löschen.
Hinweis: Beantwortung dieser Frage aus Sicht eines SDET - jemand, der die fehlerhafte Codebasis selbst reparieren kann.
Wenn der Interviewer Fehler erwähnte und keinen Testfehler (wenn der Testfehler fehlschlug, lesen Sie die Antwort von @Lewis
Zuallererst ist es eine große rote Fahne, 10000 aktive Fehler in einem Produkt zu haben.
Und Sie sollten niemals ein solches Produkt veröffentlichen. Aber wenn die Entscheidung des Managements noch zu veröffentlichen ist, dann
Die Antwort, die der Interviewer erwartete, wäre " Schwere ".
Das Team sollte sich darauf konzentrieren, Fehler mit hohem Schweregrad zuerst zu beheben, wenn keine Prioritäten vorhanden sind, und sich in der Warteschleife niedrig halten, wenn dies keine dringende Anforderung ist und die tatsächliche Geschäftslogik nicht beeinträchtigt.
Konzentrieren Sie sich zunächst auf die Automatisierung des Rauchtests und dann auf die Automatisierung aller Regressionssuiten
Gruppieren Sie die Fehler und sehen Sie, wo das Fehlerclustering auftritt. Testen Sie das Modul nach Abschluss der Korrektur gründlich.
Testen Sie vor der Veröffentlichung manuell alle Rauchtestszenarien (Logik für kritische Unternehmen).
Auch 10000 Fehler mit in Folge Defekt Maskierung , wo diese Fehler einige kritische Fehler maskieren innerhalb des Produkts.
Sobald die Korrektur abgeschlossen ist, sollten die Module strenger getestet werden, um nach kritischeren Fehlern zu suchen
Wenn ich also im Interview wäre, würde ich antworten wie:
- 10000 Fehler in einem Projekt wären eine große rote Fahne. Dies zeigt, dass es keinen ordnungsgemäßen Fehlerbehebungsprozess und keine Schätzung gab. Ich würde mir sicherlich Sorgen über das Clustering und die Maskierung von Fehlern machen, was bedeutet, dass die meisten Fehler auf ein einzelnes Modul konzentriert sind und so viele Fehler andere kritische Fehler maskieren können, die erst identifiziert werden, nachdem das Modul gründlich behoben und erneut getestet wurde . Aus diesem Grund wird empfohlen, das Veröffentlichungsdatum weiter zu verschieben.
Während das Entwicklungsteam mit der Behebung der Fehler beschäftigt ist, werden wir damit beginnen, die Anwendungsfälle für Rauchtests und Anwendungsfälle für Fehler zu automatisieren. Sobald der Fix eingetroffen ist, weisen wir die manuellen Tester den erneuten Testaufgaben zu und führen selbst strenge Ad-hoc-Tests für das Modul durch, um maskierte kritische Fehler zu finden.
- Wenn es keine Priorität gibt, wäre es untätig, zuerst kritische oder schwerwiegende Fehler erneut zu untersuchen und auch die Lebensdauer der Fehler zu untersuchen und zu verstehen, warum Fehler nicht so lange behoben wurden, um den Gesamtprozess in Zukunft zu verbessern.
In Bezug auf die Fehler mit geringem Schweregrad müssen wir eine Teamentscheidung über die Zeitachse und die Freigabeentscheidung treffen, ob die erste Version mit diesen Fehlern veröffentlicht werden soll, diese jedoch weiterhin dokumentieren und bei Bedarf umgehen. Geben Sie nach Möglichkeit auch das nächste Veröffentlichungsdatum für die mögliche Korrektur an.
Als Senior QA sollten Sie also Ihre starke Meinung vertreten, um "NEIN" zu bleiben, wenn Sie rote Fahnen sehen. Sei nicht zu flexibel
Die anderen Antworten hier sind gut, wenn es darum geht, eine konkrete Antwort zu geben.
Viele Interviewer stellen jedoch vage Fragen ohne eine bestimmte Antwort, weil sie wissen möchten, wie Sie denken oder verstehen, wenn Sie Annahmen über die Frage treffen. Sie möchten, dass Sie ihnen klärende Fragen stellen, um Einzelheiten zu erfahren. Dies hilft Ihnen bei Ihrer Antwort.
Das Szenario ist, dass Sie und 2 andere aus dem Testteam bestehen. Sie, der Leiter, sind der einzige, der Automatisierung durchführen kann, andere können nur manuelle Tests durchführen. Sie haben fast 10.000 Fehler, die aufgetreten sind, und Sie haben 4-5 Wochen oder weniger Zeit, bevor dieses Produkt ausgeliefert wird. Was werden Sie tun, um sicherzustellen, dass das Produkt rechtzeitig geliefert wird?
Einige Fragen zu stellen:
- Wie erfahren sind die manuellen Qa-Tester?
- Sind die manuellen Tester in diesem Projekt erfahren? Oder sind sie auch neu im Projekt?
- Müssen alle 10.000 vor dem Liefertermin repariert werden?
- Gibt es eine Bug-Tracker-Software, die die Teams verwenden? Wenn ja, was?
- Wie werden die bekannten Fehler verfolgt? Haben sie eine Priorität, Schweregrad aufgeführt? Sind sie nach Funktionen gruppiert / markiert?
- Gibt es derzeit automatisierte Tests für Software? Wenn ja, wie viele Unit-Tests, Integrationstests, UI-Tests? Oder muss ich alle automatisierten Tests / Frameworks innerhalb von 4 bis 5 Wochen von Grund auf neu erstellen?
- Für wie viele Tests sind die Entwickler verantwortlich? Erstellen sie Unit- / Integrationstests?
- Sind die 10.000 Fehler UI-Fehler? Oder eine Mischung aus Fehlern, die mit Unit-Tests, Integrationstests und UI-Tests getestet werden können?
- Welche Geräte müssen zum Testen verwendet werden?
- Welches Qualitätsniveau müssen wir erreichen, um Benutzer und Stakeholder zufrieden zu stellen? Wie nehmen Stakeholder Qualität wahr?
- Wie bestimmen Stakeholder einen erfolgreichen Projektstart?
- Was ist die Teamdefinition von erledigt?
- Wird das Team nach der Projektfreigabe Zeit haben, um Fehler zu beheben? Oder fahren wir mit dem nächsten Projekt fort? Wie viel Zeit werden wir haben, wenn wir Zeit bekommen?
- Verwendet das Team Agile SDLC oder Waterfall SDLC?
Es gibt unendlich viele Fragen, die Sie stellen können, um eine Klärung zu erhalten, die Sie benötigen, um eine gut durchdachte Antwort zu geben.
Aus dem obigen ausführlichen Gespräch heraus forderte der Interviewer immer wieder Einzelheiten dazu auf, wie die manuellen Tester in Ihren Plan aufgenommen werden sollen. Dies gibt Ihnen einen großen Hinweis darauf, wonach der Interviewer sucht: Er möchte nicht, dass Sie die volle Last des Testens dieses Projekts selbst übernehmen. Sie möchten als SDET / QA-Ingenieur auf Senior-Ebene wissen, wie Sie ein Team von Junior-Testern betreuen / führen.
Denken Sie daran, Interviews sollten keine Befragung sein, bei der Sie nur ihre Fragen beantworten. Interviews sollten ein Gespräch sein, in dem Sie alles fragen können, was zur Klärung ihrer Fragen beiträgt.