Negativität aus Negativtests herausnehmen

Missverständnisse führen oft dazu, dass Tester den schlechten Ruf bekommen, die Software zu „brechen“. Entwickler und Stakeholder nennen das vielleicht negative Tests, aber das Ergebnis ist ein besseres Produkt, und das ist alles positiv.

Tester sind die ersten Benutzer neuer Software und sie sind unerlässlich, um sie nutzbar zu machen. Am Ende hat jeder das gleiche Ziel, das bestmögliche Produkt zu liefern. Es ist also immer gut, Tester neue Fehler entdecken und entdecken zu lassen - je mehr Fehler gefunden werden, desto besser! Durch die Förderung von Erkundungstests zu Beginn des Softwareentwicklungslebenszyklus werden Aktivitäten zur Fehlersuche früher verschoben, wenn sie einfacher und kostengünstiger zu beheben sind.

Natürlich hängen viele der Fehler, die ich finde, nicht mit den funktionalen Anforderungen zusammen. Leistungsprobleme sind ein häufiges Beispiel. In den meisten Fällen geben die Anforderungen nicht an, wie lange etwas dauern soll, aber ein Tester kann leicht erkennen, wenn etwas nicht stimmt. Wenn ich ungeduldig auf unsere Software warte, werden es auch unsere Kunden tun. Und würden Sie das nicht lieber von mir hören, wenn wir es noch reparieren können, als später von unseren Kunden?

Was genau testen wir?

Es ist 8:30 Uhr, und unser Produktmanager betritt unser Büro und fragt: „Wo ist der Projektleiter?“

"Er ist gerade ausgestiegen", sagt der Hauptentwickler. "Wie können wir Ihnen helfen?"

"Wie ist der Status der User Story für die Migration der Datenbank von MySQL nach MariaDB?"

"Wir sind im Rückstand, weil einige Schlüsselelemente der MySQL-Primärtabellen nicht einfach auf MariaDB migriert werden können", antwortet der Hauptentwickler.

Der Tonfall des Produktmanagers wird sofort schärfer. „Wie viel dahinter? Tage, Wochen? "

Unser Hauptentwickler antwortet wahrheitsgemäß: "Noch mindestens vier Tage."

Es herrscht Stille im Raum. Schließlich sagt der Produktmanager: „Können Sie dem Projektleiter mitteilen, dass er in meinem Büro vorbeikommt? Ich muss mit ihm reden. “ Er dreht sich um und geht.

Es ist klar, dass der Produktmanager mit dem Fortschritt unserer User Story nicht zufrieden ist, und alle Entwickler und Tester fühlen sich jetzt gestresst.

Während unseres Planungstreffens später an diesem Tag berücksichtigt das Team alle möglichen Pfade: den glücklichen Pfad, den unglücklichen Pfad sowie Eck- und Randfälle. Danach sitze ich in meiner Kabine und teste die User Story. Obwohl die meisten Aufgaben noch nicht abgeschlossen sind, entscheide ich mich für einige negative Tests. Aus Neugier beginne ich, zu Bereichen zu navigieren, die nicht mit den Datenbankänderungen zusammenhängen, und finde einen kritischen Fehler.

Zu diesem Zeitpunkt kommt der Projektleiter aus dem Büro des Produktmanagers zurück und er sieht nicht glücklich aus. Ich gehe zum Projektleiter und informiere ihn, dass ich bei der Durchführung negativer Tests einen kritischen Fehler auf der Anmeldeseite gefunden habe.

"Sie testen etwas anderes als die User Story?" er antwortete. „Bitte versuchen Sie keine lustigen, negativen Dinge, nur um die Anwendung zu brechen. Wir rennen hinterher und ich glaube nicht, dass ein normaler Benutzer auf diesen Defekt stoßen wird. “

"Okay", sage ich, "ich werde den Fehler melden und weitermachen."

Privat frage ich mich jedoch: Wer oder was ist ein "normaler Benutzer"?

Testen für die reale Welt

Das Missverständnis, dass ein Software-Qualitätsingenieur das Produkt kaputt macht, besteht weiterhin. Die Tester selbst werden ausrufen: „Sehen Sie? Ich habe die Software kaputt gemacht - sie kaputt, wenn Sie hier klicken! “

Natürlich haben sie das nicht wirklich getan. Software bricht nicht; es macht einfach das, wofür es entworfen und codiert wurde, zum Guten oder zum Schlechten.

Apropos Design, ein weiterer verbreiteter Mythos ist, dass alle Fehler Codierungsfehler und Programmierfehler sind, obwohl tatsächlich eine Mehrheit während der Anforderungen und des Designs eingeführt wird. Softwarequalitätsingenieure untersuchen Systeme, schauen sich an, was das System tut, und ermitteln und melden dann, wo und wie die Software defekt ist. Sie ermitteln, wann das System unter Last oder Stress ausfällt oder wie jeder Benutzer herumstochert.

Es ist also ein Tester Verpflichtung über den positiven glücklichen Weg hinausgehen und das nicht so glückliche offenbaren.

Positive Tests sind das Klicken zur richtigen Zeit am richtigen Ort. Es ist unwahrscheinlich, dass ein Benutzer nur das tut. Benutzer klicken auf das, was sie wollen, wann sie wollen. Wir können einen Benutzer nicht so automatisieren, dass er immer das Gleiche auf die gleiche Weise tut. Daher können wir uns nicht auf unsere automatisierten Tests verlassen, um die menschliche Interaktion abzudecken.

Deshalb mag ich den Begriff Negativtests nicht - er ist nicht negativ!

Ich bevorzuge "Tests in der realen Welt". Jeder Benutzer verwendet das Produkt auf einzigartige Weise, und wir können Benutzer nicht miteinander vergleichen oder erwarten, dass sie auf demselben Pfad durch die Anwendung navigieren. Benutzer folgen nicht dem glücklichen Pfad. Benutzer folgen nicht den Anweisungen oder lesen ehrlich gesagt normalerweise sogar die Dokumentation. Benutzer fordern das Produkt heraus.

Als Tester ist es für uns daher entscheidend, auch das Produkt herauszufordern. Wir müssen unsere Tests variieren, um herauszufinden, wie das Produkt reagiert. Hervorragende Tests beschränken sich nicht nur darauf zu zeigen, dass das Produkt ein erwartetes Ergebnis erzielen kann. Es bedeutet zu lernen, was das Produkt tut, wenn Benutzer etwas tun, was niemand vorhergesagt hat.

Unsere Aufgabe als Softwarequalitätsingenieure ist es, wie echte Benutzer zu handeln und zu denken. Wir müssen außerhalb unseres Testplans testen und das Skript verlassen. Entwickler und Stakeholder nennen das vielleicht negative Tests, aber das Ergebnis ist ein besseres Produkt, und das ist alles positiv. 

Gespräch ändern

Jede Software birgt das potenzielle Risiko, nicht wie erwartet zu funktionieren. Daher ist es wichtig, mindestens zu überprüfen, ob die Software nicht abstürzt, wenn sich jemand anmeldet. Ich habe keine negativen Tests durchgeführt, als ich den Fehler auf der Anmeldeseite gefunden habe. Ich habe die Software untersucht.

Es liegt also an mir, dies positiv zu kommunizieren. Unsere Worte haben einen großen Einfluss darauf, wie andere unseren Job wahrnehmen und verstehen.

Als ich meinem Projektleiter sagte, dass ich bei der Durchführung negativer Tests einen Fehler gefunden habe, ist es verständlich, dass seine Reaktion nicht akzeptabel war. Wenn ich stattdessen gesagt hätte: "Während ich die Anmeldeseite getestet habe, habe ich einen kritischen Fehler entdeckt", wäre seine Reaktion wahrscheinlich gewesen: "Gehen Sie und reichen Sie den Fehler ein, und wir werden ihn uns später ansehen."

Also denke ich, wir sollten aufhören zu benutzen positiv gegen negativ Terminologie. Sprechen wir stattdessen über "Entdeckung" und "Untersuchung". Es ist weniger verwirrend, expliziter und vermeidet das potenzielle Problem, dass Entwickler und Manager etwas Wertvolles sagen wie: "Oh, Sie sind nur negativ."

Durch die Änderung meines Wortschatzes konnte ich meine Kommunikation mit Stakeholdern und Entwicklern verbessern. Ich kann einen anderen Blickwinkel der Gleichung erkennen und konnte reibungslos mit Entwicklern sprechen. Jetzt sieht das Team meine Arbeit darin, das Produkt positiv zu verbessern, anstatt negativ zu versuchen, die Software zu beschädigen.

Versuchen Sie, Ihren Wortschatz von "positiv" und "negativ" in beschreibendere Verben zu ändern, die Ihre Erkundung erklären. Das Team ist empfänglicher für Gespräche und schätzt Ihre Arbeit möglicherweise sogar mehr.