Aufgabenbegründungsmuster und Antimuster

Inhalt

• 1. Antipatterns: schlechte Begründung
  
  • 1.1. Offensichtlich
  • 1.2. Ich schwöre bei Mama!
  • 1.3. Hasen sind beleidigt
• 2. Gute Rechtfertigungsmuster
  
  • 2.1. Pruflink
    
    • Link zu Anforderungen
    • Anforderungen selbst
    • Internetverbindung
    • Kundenbrief
    • ROI
    • Statistiken
  • 2.2. Einheitlichkeit
  • 2.3. Problem oder # Lebensschmerz
• 3. Wenn die Begründung nicht benötigt wird
• 4. Zusammenfassung

Wenn Sie eine Aufgabe starten, muss sie begründet sein. Sie müssen den Entwickler davon überzeugen, dass:

• das ist wirklich ein Fehler;
• es muss behoben werden;
• es muss genau wie gesagt repariert werden.

Und manchmal liest du Fehler (insbesondere Fehler von Anfängern) und fragst dich:

- Warum ist das ein Fehler?

Zum Beispiel heißt es: „Laden Sie den Bericht herunter, wir erhalten 57.6. Und es sollte sein - 57,9 ".



Das Schreiben der Begründung wird die Probleme lösen:

• Kollegen lenken mit Fragen ab: „Warum ist das ein Fehler?“, Die aus dem Zusammenhang gerissen werden.
• Einen Monat später haben Sie selbst vergessen, aber in der Tat, warum es ein Fehler war ...

Siehe auch:
Warum eine Begründung in einem Fehler erforderlich ist - genauer gesagt, warum im Allgemeinen eine Begründung vorliegt.

Hunderte von Anfängertestern (Studenten) haben mich durchlaufen. Gerade bei ihren Aufgaben begann ich die Frage zu stellen: "Warum ist das ein Fehler?" ... Sie fragen die Jungs und im Gegenzug erhalten Sie "Ja, das ist offensichtlich!". Na irgendwie nicht sehr =))

Durch eine Reihe von Aufgaben und Fragen: "Warum?" Es entstanden Reaktionsmuster. Ich habe die guten und schlechten Muster hervorgehoben. Ich möchte über sie sprechen.

Dieser Artikel ist für:

• Anfängertester - lernen Sie, wie Sie Ihren Standpunkt richtig erklären;
• Testmanager - um einen Link zu ihren Padawans zu geben und dann ohne weitere Erklärung auf Antimuster zu verweisen.

1. Antipatterns: schlechte Begründung

1.1. Offensichtlich

Warum schreiben Tester überhaupt keine Begründung für einen Fehler? Ja, weil es ihnen offensichtlich erscheint. Und sie projizieren ihre Gedanken auf alle. Es ist für mich offensichtlich = es ist für jeden offensichtlich, warum etwas zu schreiben?

In Wirklichkeit ist dies jedoch nicht der Fall, da sich jede Person in einem bestimmten Kontext befindet. Und was für Sie offensichtlich ist, ist überhaupt keine Tatsache, die für jemand anderen offensichtlich ist.

Schauen wir uns einfache Beispiele an. Lesen Sie das Wort, das ich unten schreiben werde - was haben Sie gedacht, als Sie es gelesen haben? Welche Assoziationen kamen mir in den Sinn?

LOCK

Ein Türschloss oder eine riesige Steinfestung?

EHE

Eine Hochzeit oder ein kaputtes iPhone?
...

Ja, das sind Homonyme. Aber sie zeigen sehr deutlich das Problem "es ist offensichtlich". Es ist für Sie offensichtlich, dass das Schloss ein Schloss ist, und für mich, dass es ein Schloss ist.

Und wenn Sie in einem Fehler schreiben:

Ergebnis
57.6

Erwartetes Ergebnis
Offensichtlich sollte es 57,9 geben

Das beantwortet meine Frage "WARUM?" Nicht. Was bedeutet "offensichtlich"? Erkläre es mir bitte. Es ist mir nicht klar, sonst würde ich nicht noch einmal fragen. Aber der Autor ist offensichtlich und er denkt, dass jeder auch.



Wenn wir über die Erfahrungen von Anfängern sprechen, dann hat einer meiner Schüler diese Idee am besten formuliert:

"Ich habe nicht verstanden, warum ich Fehler überhaupt rechtfertigen sollte, bis ich die Fehler anderer Schüler gelesen habe."

Sie können sehr lange feststellen, dass es für jeden "offensichtlich" ist, dass es anders ist und ich nicht in Ihrem Kontext bin, und vieles mehr ... Aber der Autor der Aufgabe wird bedenken, dass sie einfach Fehler an ihm finden, der Rest von ihnen versteht es nicht, aber es geht ihm gut!

Und wenn Sie nur die Fehler anderer Leute lesen, beginnen Sie zu denken: „Hmmm, warum denkt er das? Ich dachte anders. " Dann kommt das Verständnis, dass Ihr „offensichtliches“ nicht für jeden offensichtlich ist.

Als ich in den Bug-Tracker ging und einen solchen Bug von einem Schüler sah: „Wir geben den Namen Sharipat ein, er wird als männlich definiert. Und es sollte wie eine Frau sein! " Warum sollte es wie eine Frau sein? Ich sehe mir diesen Namen an - nun, Sharipat und Sharipat, sieht aus wie ein Mann. Ich frage:

- Warum hast du dich so entschieden? Warum weiblich?
- Ja, weil meine Frau so heißt!

Und das erklärt mir zumindest schon, warum er die Aufgabe angefangen hat. Wenn wir Anwendungen testen, probieren wir zuerst einfache Daten aus, Dinge, die wir wissen. Wir versuchen unseren Namen, den Namen unserer Frau, unseres Bruders, unserer Schwester ...

Er versuchte den Namen seiner Frau einzugeben und entdeckte einen Fehler. Und wenn er sogar das erwartete Ergebnis schrieb: „Geschlecht ist weiblich, das ist ein weiblicher Name - mein Name ist das“, dann verschwand zumindest die Frage „Warum hast du überhaupt mit dieser Aufgabe begonnen?“.

Eine solche Rechtfertigung reicht natürlich nicht aus. Google "ungewöhnliche Namen", weil es uns nicht verboten ist, den Nachttisch unseres Sohnes zu benennen, aber lohnt es sich, dieses Wort als den richtigen männlichen Namen zu betrachten?

Hier ist es also notwendig zu googeln, wie lauten die Namen im Allgemeinen, um das Problem zu lokalisieren - das Problem mit russischen Namen? Kasachisch? Ukrainisch? Aber sollte das System sie verarbeiten können? Usw. Vielleicht überhaupt kein Fehler ...
Und doch erlaubt "der Name meiner Frau ist es zumindest" dem Autor, uns in seinen Kontext einzuführen und erklärt, warum er beschlossen hat, die Aufgabe zu beginnen.

Und denken Sie daran, Beweise können durch den Kontext diktiert werden. Sie haben das große Modul des Systems sorgfältig studiert, Sie wissen alles gründlich. Daher ist es für Sie völlig offensichtlich, dass "dieser Chip HIER SO funktionieren sollte". Wenn Sie jedoch in ein oder zwei Monaten zur Aufgabe zurückkehren, arbeiten Sie bereits an einem anderen Modul, und es wird schwieriger, sich daran zu erinnern, warum dies so sein wird.

Selbst der dümmste Bleistift ist schärfer als der schärfste Internetspeicher

Wenn Sie einen Fehler starten und das erwartete Ergebnis für Sie offensichtlich erscheint, halten Sie inne und denken Sie: „Warum denke ich das?“. Und schreiben Sie die Antwort auf diese Frage auf.

1.2. Ich schwöre bei Mama!

Wenn ein Schüler versteht, dass das Schreiben von gar nichts, "weil es offensichtlich ist", nicht fehlschlägt, geht er zur nächsten Stufe der Wut, Verleugnung und Rechtfertigung von Fehlern über, die "Ich schwöre bei Mama!" In diesem Fall sagen wir nur, dass es so richtig ist, ohne zu erklären, warum.



Das heißt, die Begründung sieht ungefähr so ​​aus:

Ergebnis
57.6

Erwartetes Ergebnis
57.9 weil es so richtig ist

Aber eine solche Begründung beantwortet meine Frage „Aber warum?“ Wieder nicht. Warum hast du entschieden, dass das so richtig ist? Ich bin immer noch kein Wang oder Telepath und ich weiß nicht, warum Sie das für richtig halten.

Tatsächlich unterscheidet sich dies nicht wesentlich von der Situation, "überhaupt nichts geschrieben zu haben, weil es offensichtlich ist". Deshalb nenne ich dies die zweite Stufe - genau in diesem Szenario entwickeln sich Ereignisse normalerweise zuerst „offensichtlich“, dann „ja, also genau richtig“. Schauen wir uns ein Beispiel aus dem Leben der Studenten an:

Peter und die Indianer

Unser System ist in der Lage, Namen nach Fällen zu beugen. Ein Student überprüft den Namen Peter. Weißt du, wie es sich neigt? Im Nominativ wird es durch den Buchstaben E und in allen anderen geschrieben - durch E. "Peter, aber Peter."

Und so gehe ich in den Bug-Tracker und lese einen solchen Bug: "Peter beugt sich über die Fälle durch den Buchstaben e, sollte aber durch e."

Ich frage:

"Warum denkst du so?"
- Nun, es ist offensichtlich, dass es durch E notwendig ist (erste Stufe)
"Warum denkst du, ist das offensichtlich?"
- Aber das ist so nach den Regeln der russischen Sprache!
- Nach welchen Regeln?
- Soll ich die Regeln der russischen Sprache ausführen und googeln? (zweite Stufe - also richtig, glauben Sie mir)
- JA! Ja, genau das sollten Sie tun. Denn dies wird die Begründung für den Fehler sein. Vielleicht ist Ihr Entwickler Inder und Sie sind auch Inder. Und Sie kennen die Regeln der russischen Sprache nicht! Geben Sie ihnen einen Link und alle Fragen verschwinden sofort.

Natürlich müssen Sie nicht bis zum Äußersten gehen und Links zu Wörterbüchern geben, wenn Sie einen Tippfehler oder ein fehlendes Komma mit einem Fehler versehen. Trotzdem ist Peter ein nicht triviales Beispiel, dies ist eine Ausnahme von der Regel. Es funktioniert immer so, aber für Peter ist es anders.

Daher wird hier der Link nützlich sein. Besonders wenn der Entwickler fragte: "Ist es wirklich so richtig?" Sie können ihn der Dummheit und des Analphabetismus beschuldigen und die Beziehung ruinieren. Und Sie können einen Link geben, der Ihre Sichtweise sanft bestätigt.

Aber ok, nehmen wir ein anderes Beispiel, nicht die Regeln der russischen Sprache, die "so offensichtlich" sind.

Email.rf

Meine Schüler mögen diese Aufgabe sehr (fast jeder Stream erstellt sie):

- Ich versuche mich bei email.ru zu registrieren und kann es nicht. Das ist ein Fehler!
- Warum?
- Wie ist das warum? Wir leben in Russland, jeder hat solche E-Mails!

Ich erzählte diesen Fall auf der DUMP-Konferenz und hatte einen vollen Audienzraum. Ich bat darum, die Hände derer zu heben, die eine solche E-Mail haben. Von 200 Personen hoben drei Personen die Hände.

Die Tatsache, dass wir in Russland leben, bedeutet nicht, dass jeder solche E-Mails hat. Nun ja, ja ... und zahme Bären und Nistpuppen ...

Hier besteht kein Kausalzusammenhang, es ist einfach schwierig, Ihre Idee aufzugeben. Immerhin habe ich hier einen Fehler gefunden! Wie kann das kein Fehler sein? So cool. Russland natürlich! Nein, nicht offensichtlich? Trotzdem, Russland, sicherlich gibt es viele.

Diese Begründung lautet eher: „Ich bin zu faul, um zu googeln und nach Fakten zu suchen. Glaube dem Wort. " Wenn wir keine Fakten und Beweise haben, besteht der Wunsch, seine Rechtfertigung zu verschleiern und "Wahrscheinlich, wahrscheinlich, sicher ..." zu schreiben.



Aber das sind STOP-Wörter! Wenn Sie den Wunsch haben, sie zu schreiben, haben Sie keine wirklichen Fakten. Also überleg es dir einfach. Und warum müssen wir eine Aufgabe erledigen, die auf der Vorstellungskraft eines Testers basiert? Beweisen Sie Ihre Theorie!

Und wenn es keine Fakten gibt? Dann lohnt es sich nicht einmal, mit der Aufgabe zu beginnen. Ja, es ist schwierig, "Ihren eigenen nativen" Fehler abzulehnen. Aber auch das muss können.

Email.ru - Fakten

Was könnten die Fakten sein?

Erstens können wir unsere Website für einige Regierungskunden erstellen, die sich in der domain.rf registrieren müssen. Unternehmensstandard, sie haben keine Wahl.

Oder wir haben wirklich viele solcher Kunden, das zeigen Statistiken. Zum Beispiel gibt es viele Fehler in den Protokollen "Versuch, sich über eine solche Domäne zu registrieren". Und vielleicht lohnt es sich dann, diese Funktion zu entwickeln. Um potenzielle Kunden nicht zu verlieren.

Basierend auf diesen Fakten trifft PM (Projektmanager) eine Entscheidung, ob wir die Aufgabe erledigen oder nicht. Und wenn wir wollen, wann dann. Oder er sagt: "Nun, es gibt Fehler, und nun, es gibt weniger als 1% der gesamten Registrierungen, wir werden sie nicht machen."

Anstelle des abstrakten "Ja, solche Leute existieren definitiv!" Gib die FAKTEN.

Und wenn Sie die Aufgabe einstellen, verwenden Sie Prinzip 5, warum. Fragen Sie sich beim Aufschreiben des erwarteten Ergebnisses: „Warum erwarte ich das?“ Die erste Antwort lautet "Dies ist offensichtlich", aber stellen Sie erneut die Frage "Warum?". Und wenn Sie feststellen, dass es keine Daten gibt, scheint es Ihnen nur so - suchen Sie nach den Fakten oder besprechen Sie die Situation mit Kollegen.

1.3. Hasen sind beleidigt

Wenn es keine Fakten gibt, Sie den Fehler aber nicht ablehnen möchten, gehen die Schüler zur nächsten Stufe der Wut, Verleugnung und Rechtfertigung von Fehlern ... Druck auf die Emotionen:

Ich versuche mich mit dem Namen Cthulhu zu registrieren, aber das System tut dies nicht. Sollte geben, sonst ... Ich war beleidigt und ging und DU! Einen Kunden verloren!

Und sicherlich sind alle gleich wie ich, also haben Sie ALLE Kunden verloren, und sie haben auch eine Klage wegen Beleidigung eingereicht und das ganze Geld genommen!

Und andere Autos ...

Wenn ich persönlich etwas nicht mag, ist es natürlich sehr wütend, mein Problem zu ignorieren. Was bedeutet "Normale Personen registrieren sich nicht mit diesem Namen?" Bin ich verrückt ?! Wie ich will, heißt es, wie kannst du mir etwas verbieten ?!

Und dann schaltet sich die Projektion ein - wenn es mir nicht gefällt, werden es andere Benutzer nicht mögen! Wenn nicht alle, dann zumindest viele. Daher ist dies definitiv ein Fehler und muss behoben werden. Nun, oder zumindest im Rahmen der Ausbildung aufbrechen, wenn wir über Studenten sprechen.

Der beleidigte Benutzer ist jedoch die schlechteste Rechtfertigung, die jemals sein kann. Weil sie jeden Unsinn rechtfertigen können:

• Gibt es keine Katze auf der Hauptkatze? Nun, das ist es! Ich war beleidigt und GEGANGEN! UND SIE! Einen Kunden verloren !!
• Ich habe mich registriert und wurde nicht dafür bezahlt? Ich war beleidigt und ging ... UND DU! Nun, du verstehst es!

Alles kann passieren und mich beleidigen. Der Knopf ist grün, aber ich wollte einen roten, das System hat mir keine Pizza als Geschenk angeboten ... Als Benutzer kann ich mich über alles ärgern. Aber wen interessiert das? Trotzdem werden Sie nicht gefallen, Ressentiments sind unvermeidlich. Und Drohung ist im Allgemeinen das Letzte.

Alles begann mit einem der Schüler, der gerade diesen geheimen Satz sagte:
- Ah, Sie möchten sich nicht über die Domain der Russischen Föderation registrieren lassen? Und als Benutzer, den ich zu registrieren versuchte, sah ich diese offensichtliche Situation und GEGANGEN! UND SIE! Einen Kunden verloren!

Dann sagte mein Freund, dass solche Reden "Hasen waren beleidigt" sehr ähnlich sind. Ich weiß nicht, woher sie diese Analogie hat, aber es hat allen gefallen.

Der Student bemerkte, dass er aufgeregt war. Ging nach einer Rechtfertigung ohne Emotionen. Und wir haben den Namen Antipattern.

Denken Sie an eine einfache Regel: Der Fehler sollte keine Emotionen enthalten!

Emotionen sind ein vorübergehendes Phänomen. Es ist jetzt so, dass Sie vor aufrichtiger Wut lodern und dies in böswilligen Kommentaren wie "Nur ein Idiot könnte Code wie diesen schreiben" ausdrücken möchten. Aber denken Sie an jede Situation, in der ein Kind neben Ihnen launisch war und wegen eines ungekauften Spielzeugs oder Eises einen Wutanfall für die Mutter arrangierte. Genießen Sie als externer Beobachter diese Szene? Aber Ihre Hysterie im Bug-Tracker sieht genauso aus!

Wenn Sie also wirklich wollen, sagen Sie alles mündlich. Besprechen Sie mit dem Entwickler die Aufgabe im Raucherraum und verteidigen Sie vehement Ihre Position. Aber sobald wir am Computer angekommen sind - wir entfernen die Emotionen, schreiben wir nur die Fakten. Ohne "wenn ja wenn" und ohne "und DU!" Den Kunden verloren! “

Denken Sie daran, dass sie nach ein, zwei oder drei Jahren zu den Aufgaben zurückkehren. Und dann werden sogar Sie Ihren eigenen Wutanfall zimperlich betrachten. Immerhin gibt es keine vergangenen Emotionen mehr, das sieht lächerlich aus. Also die maximalen Emotionen verbal - im Raucherzimmer! Und in einem Bug irgendwie ohne sie.



Und schreiben Sie in der Begründung nicht über mega-beleidigte Hasen. Manchmal kommt eine solche Verteidigung der Aufgabe zum Lächerlichen:

Der Student fand einen Tippfehler im Angebot des Benutzers. Setzen Sie einen Fehler mit kritischer Priorität. Als er gebeten wurde, die Priorität zu klären, war er sehr empört:

- Das System hat mich getäuscht, ich kann ihr nicht vertrauen !!!

Er war wahrscheinlich besorgt, dass sich die Frage in "Dies ist überhaupt kein Fehler" verwandeln würde, also begann er, seinen Fehler zu verteidigen. Aber es macht niemandem etwas aus, dass dies ein Fehler ist. Aber warum ist es kritisch? Wer liest das Angebot?

- Ich lese! Daher sehe ich, dass das System schlecht ist. Wenn es dort einen Tippfehler gibt, was kann es dann tun? Und wie soll man es jetzt glauben ?!

Aber "Ich lese" - "Jeder liest". Und dann gab der Student selbst zu, dass er nicht JEDE Lizenzvereinbarung sorgfältig liest, die bei der Installation der Programme in uns eingeht. Also mit dem Angebot die gleiche Geschichte. Obwohl alles in Ordnung ist, lesen sie es nicht. Wenn etwas nicht angenehm ist, richten Sie sich bereits an Regeln.

"Das System hat mich getäuscht und ich kann es jetzt nicht glauben" wegen eines Tippfehlers auf der zehnten Seite des Textes, den nur wenige Leute lesen ... Nun ... Schreiben Sie dies nicht in einem Fehler, sagen Sie es Ihrem RM nicht.

Also entfernen wir Emotionen aus dem Bug. Und was können wir dort lassen? Natürlich die Fakten!

Anstatt über Emotionen zu schreiben, werden „Hasen sicherlich beleidigt sein, sie werden gehen und Sie werden Kunden verlieren“:

- Statistiken sammeln;
- Schätzung der Arbeitskosten;
- den ROI zählen;
- Benutzer interviewen;
- Vergleichen Sie das Produkt mit Wettbewerbern;

Und anstatt eines hysterischen Eichhörnchens wirst du ein cooler Tester, der nachdenkliche Fehler macht!

2. Gute Rechtfertigungsmuster

Wie kann man Fehler richtig rechtfertigen? Was muss im erwarteten Ergebnis geschrieben werden, damit Ihr Fehler wie geschrieben behoben wird? Und sie haben nicht zehnmal gefragt, warum es so richtig ist.

Drei Antimuster wurden oben diskutiert. Lassen Sie uns drei gute Muster zur Rechtfertigung von Fehlern diskutieren.

2.1. Pruflink

Das kann sein:

• Link zu Anforderungen
• Die Anforderungen selbst (Word-Datei, vorhanden ...)
• Internetverbindung
• Geschätzter ROI
• Kundenbrief
• Statistiken

Link zu Anforderungen

Der einfachste Fehler ist, wenn es eine TK gibt und das System nicht wie dort beschrieben funktioniert.

Also schreiben wir in das erwartete Ergebnis: "57.9, weil es so in der Arbeitserklärung steht." Hmm, hmm ... Warte eine Minute. Es klingt wie "Ich schwöre bei Mama" ...

Ja, in dieser Formulierung klingt es so. Bestätigen Sie daher Ihre Worte mit einem Link. Andernfalls liest der Entwickler den Fehler und benötigt:

• erkennen, um welche Art von TK es sich handelt;
• finde TK selbst;
• finde den spezifischen Ort in Frage;
• zu verstehen ...

Ist es nicht einfacher, nur den letzten Artikel zu belassen? Immerhin kann der Entwickler an 10 verschiedenen Projekten arbeiten, deren Dokumentation an 10 verschiedenen Orten verteilt ist. Die Suche nach TK dauert 5 bis 10 Minuten, und das Hinzufügen eines Links für Sie ist eine Frage von Sekunden. Schließlich testen Sie jetzt TK, was bedeutet, dass es offen und vor Ihren Augen ist. Kopieren Sie den Link und fügen Sie ihn ein!

Respektieren Sie die Zeit der Kollegen und sie werden Ihnen dankbar sein.

Anforderungen selbst

Wenn die Anforderungen NICHT in einem Confluence- oder anderen Cloud-System, sondern in einem normalen Word gespeichert sind, hängen Sie das zu testende Dokument an.



Möglicherweise testen Sie veraltete Anforderungen. Und wenn Sie eine direkte Word-Datei anhängen, gegen die Sie prüfen, kann der Analyst sie sehen und sagen: „Oh, warten Sie, wir haben bereits zehnmal alles geändert. Ich habe vergessen, sie hochzuladen. Warte! "

Wenn Sie dies nicht tun, verbringen Sie drei Stunden mit dem Entwickler, der sagt: "Aber ich habe einen anderen!". Sie werden rennen, seine und dann Ihre Anforderungen beobachten und dann nach einem Analysten suchen, um zu klären, wer Recht hat ...

Und so haben Sie sofort die Anforderungen eingegeben, der Entwickler sagte, "etwas ist eine Art Müll", leitete die Analyse um. Der Analytiker hat sie geschrieben, und wenn er Ihr Wort öffnet, wird er sofort verstehen, ob er veraltet ist oder nicht. Das spart Zeit!

Internetverbindung

Wie wir uns erinnern, sind die Anforderungen bei weitem nicht immer. Und stattdessen vielleicht ... Link zum Internet! Ja, warum nicht?

Wenn wir uns an unser Beispiel „Peter, Peter“ erinnern, ist es selbst dann, wenn wir Anforderungen im System haben, unwahrscheinlich, dass dort „Das System funktioniert nach den Regeln der russischen Sprache“ steht und alle Regeln der russischen Sprache aufgelistet sind. Natürlich schreibt niemand so. Und dennoch stellt sich heraus, dass Sie, wenn Sie sich auf die Regeln der russischen Sprache beziehen möchten, diese googeln müssen.

Oder wenn Sie ein Beispiel von Sharipat nehmen. Woher hast du wieder, dass dies ein normaler weiblicher Name ist? Wir googeln alle Arten von kasachischen und anderen Namen, finden Sharipat, finden andere ähnliche Namen und geben einen Link zu dieser Seite.

Und hier kann der Entwickler, auch wenn er Ihnen nicht zustimmt, kommen und sagen: "Sehen Sie, Sie haben einen Link zur Site angegeben, aber dies ist eine Art gelbe Presse, sie schreiben immer Müll." Wenn Sie den Link nicht angegeben haben, muss der Entwickler selbst googeln, selbst nach allen Arten von Websites suchen und erst dann wird er verstehen, dass Sie möglicherweise falsche Informationen angegriffen haben. Sparen Sie ihm Zeit und geben Sie sofort einen Link zum Internet.



Ja, hier müssen Sie verstehen, dass nicht jeder Link nützlich und gerechtfertigt ist, aber es wird zumindest zeigen, warum Sie denken, dass dies wirklich ein Fehler ist. Es ist nicht meine "Mutter, die dir schwört", aber mit einer Begründung!

Kundenbrief Die

Begründung könnte darin bestehen, einen Kundenbrief zu senden. Wir haben sogar ein separates Feld, Business Justification, in dem wir aufschreiben, welcher Kunde diese Funktion angefordert hat. Und wenn wir dann unseren Fehler lesen, sehen wir sofort:

- Ja, der Business Case ist leer. Dies bedeutet, dass wir dieses Problem selbst gefunden haben und glauben, dass es behoben werden muss.

Oder:

- Ja, ein solcher Kunde hat sich am 1. August 2015 über das Problem beschwert

Und wenn wir mit diesem Kunden klären müssen, was genau nicht zu ihm passt, können wir diesen Brief leicht finden, da wir alle Informationen haben (wer, wann, wie der Brief heißt). Wenn ich diese Informationen kenne, werde ich in 5 Sekunden einen Brief in meinem Outlook finden. Wenn diese Informationen nicht vorhanden sind, muss ich zu Outlook gehen und zwischen 10 verschiedenen Vätern suchen - welcher Kunde hat sie angefordert und in welchem ​​Brief?

Wenn wir außerdem feststellen, dass diese Funktion von mehreren verschiedenen Kunden angefordert wurde, wird die Priorität sofort erhöht. Da wir verstehen:

- Ja, hier hat sich der Kunde 1 dann beschwert, nach ein paar Wochen / Monaten hat sich der Kunde erneut beschwert. Hmmmm, aber es gibt sicherlich eine Menge anderer Kunden, die ebenfalls leiden, aber schweigen. Weinen Sie, stechen Sie, aber essen Sie den Kaktus weiter. Schließlich wird nicht jeder uns schreiben und ein Problem melden ...



Je mehr Beschwerden, desto höher die Priorität. Da wir verstehen, dass dies ein echter Benutzer ist, der sich beschwert, haben sie wirklich solche Probleme. Und selbst wenn wir sechs Monate oder ein Jahr später auf den Fehler zurückkommen, wird es dank des beigefügten Briefes oder zumindest eines Links immer möglich sein, den Verlauf der Aufgabe zu erhöhen.

ROI

Wir können versuchen, das ROI-Payback-Verhältnis zu berechnen. Müssen wir diese Funktion wirklich erstellen oder diesen Fehler beheben? Wird dies die richtige Wirkung bringen?

Es ist eine Sache, eine halbe Stunde lang eine geringfügige Änderung vorzunehmen, die Hunderten von Benutzern hilft. Es ist völlig anders - aufgrund der Hysterie eines Benutzers zwei Wochen, um die Arbeit des Systems zu wiederholen, was für alle anderen geeignet ist.

Wenn wir den ROI berechnet haben und feststellen, dass das Spiel die Kerze wert ist, setzen wir die Berechnungen in die Aufgabe ein. Aber manchmal stellt sich nach Berechnungen heraus, dass Sie die Aufgabe nicht erledigen müssen. Und das ist normal! So haben wir dem Team Zeit gespart, um unnötige Funktionen zu besprechen.

Deshalb denken wir über die Gründe nach - denn manchmal scheint es "Ah, was für ein Fehler, was für ein Fehler!", Und dann fangen Sie an, über die Gründe nachzudenken ... Und Sie verstehen, dass dieser Müll, kein Fehler, es nicht wert ist, gestartet zu werden ...

Zum Beispiel arbeiten wir mit einer mobilen Anwendung, und es gibt ein Debug-Panel für Tester, das ungefähr so ​​aussieht:



Wow, wow! Es gibt ein wenig Blau, es gibt ein wenig Rot, der Text ist nicht vollständig sichtbar, die Schriftarten sind verstreut ... Ein offensichtlicher Fehler! Wie wurde das vor mir nicht bemerkt? Dringende Freigabe, muss umgestaltet werden!

Wie zu rechtfertigen? "Was meinst du damit, wenn ein Benutzer DIESES sieht, wird er sofort beleidigt sein und gehen." Hör auf . -. , [2]. . , , !

… , ? . , , . ? !

, . . . ? ? , , .

— , !

Statistiken

Sammeln Sie Statistiken und investieren Sie in die Aufgabe:

- die Anzahl der Fehler in den Protokollen;
- die Anzahl der Beschwerden im technischen Support;
- die Anzahl der Klicks auf die Schaltfläche;
- die Anzahl der Benutzer, die zum Zeitpunkt der Bestellung abgereist sind (Tab geschlossen);
- ...

Das heißt, wenn Sie der Meinung sind, dass das Standardformular für die Bestellung im Online-Shop "schlecht" ist und verbessert werden muss, begründen Sie es. Warum ist es schlecht? Um die Adresse einzugeben, müssen Sie Ihren Index kennen und 10 erforderliche Felder ausfüllen? Ist es wirklich schlimm oder nervt es dich nur?

Beachten Sie, dass Entwickler das „Offensichtliche“ in ihrer Software möglicherweise nicht sehen. Immerhin haben sie es entwickelt, getestet ... Sie sehen es ständig 100 Mal am Tag, sie sind bereits an die Schnittstelle gewöhnt. Selbst wenn es wirklich veraltet ist, brauchen Sie Fakten.

Und die Fakten sind einfach zu sammeln - wir bitten Sie, Statistiken zu erstellen, um zu sehen, wann der Benutzer die Seite verlässt. Und wenn er Pizza in den Korb legte und dann anfing, die Felder auszufüllen und nach 5-7 spuckte und ging, ist das nicht sehr cool. Und wenn sich jeder Dritte so verhält, lohnt es sich auf jeden Fall, etwas zu verbessern!

Wenn Sie sich an email.ru erinnern, können Sie sich die Protokolle ansehen. Gibt es Fehler wie "Der Versuch, sich für eine solche E-Mail zu registrieren, wird abgelehnt"? Vielleicht existieren sie überhaupt nicht, aber wir haben bereits eine Reihe von beleidigten Benutzern gefunden, aufgrund derer die Website buchstäblich Millionen verloren hat.

Warum sind Statistiken besser als Emotionen? Weil wir, IT-Profis und normale Benutzer zwei verschiedene Welten sind. Was für uns bequem ist, ist für sie unpraktisch. Umgekehrt.



Angenommen, wir machen Buchhaltungssoftware. Es scheint uns: "Fu, niemand arbeitet mit der Maus, wir müssen sicherstellen, dass alles über die Befehlszeile funktioniert, damit die Maus nicht berührt werden muss!" Wir verbringen viel Zeit mit dieser Funktionalität, aber echte Benutzer verwenden sie überhaupt nicht. Weil sie eine Maus brauchen, um zu picken, auf die große Taste zu drücken ... Aber was für Programmierer praktisch ist, ist ihnen im Allgemeinen egal, weil sie sich mit etwas völlig anderem wohl fühlen.

Und wenn Sie allen mitteilen möchten, was Benutzer benötigen, studieren Sie zuerst die Usability-Tests und sagen Sie dann, ob die Hasen beleidigt sind oder nicht.

In unserem System sammeln wir anonyme Statistiken, welche Funktionen verwendet werden und welche nicht. Es gibt so viele Filter in einem Webformular, die schwer zu pflegen sind. Werden sie gebraucht? Sie können nicht einfach aufnehmen und entfernen, es lohnt sich, dies zu überprüfen.

Daher sind die Statistiken normalerweise sehr überraschend. Wir dachten, dieser Filter wurde überhaupt nicht verwendet, aber tatsächlich funktionierte er jede Stunde. Und andererseits hatten sie große Hoffnungen, aber niemand braucht ihn ...

Nur Statistiken sagen ehrlich über die Existenz des Problems aus. Wenn es keine Statistiken gibt, wird es nur Geschmack sein. Und jeder hat unterschiedliche Geschmäcker. Der Tester möchte den roten Knopf, der Entwickler den grünen und der Designer den blauen. Suchen Sie nach Fakten und geben Sie ihnen einen Pruflink!

2.2. Einheitlichkeit

Wenn es keinen Pruflink gibt, können wir auf die Einheitlichkeit im System verweisen. Denn wenn das System immer so funktioniert und es dann plötzlich anders funktioniert, kann dies der Grund für den Fehler sein.

Zum Beispiel, wenn unser System wie ein Puntoswitch funktioniert (dies ist, wenn ich auf Russisch drucke und vergesse, das Layout zu ändern, und das System es selbst wechselt). Ich kann "Olga" oder "Jkmuf" eingeben, das System verwandelt die zweite Option in die erste.

Dies geschieht bei allen Arten von Regierungsanwendungen. Manchmal arbeiten sie selbst nach dem gleichen Prinzip. Sie müssen sich eindeutig wie in Ihrem Reisepass registrieren. Da wir in Russland leben, erfolgt die Registrierung auf Russisch, daher werden wir englische Buchstaben korrigieren. Sie haben offensichtlich vergessen, das Layout zu ändern, Mann!

Jkmuf → Olga

Okay, aber was ist, wenn ich versuche, den Namen "Julia" einzugeben? Es beginnt mit dem Buchstaben U, und dieser Buchstabe entspricht nicht dem Buchstaben des russischen Alphabets, sondern einem Sonderzeichen:

> → Yu

Und das ist eine ganz andere Äquivalenzklasse!

Das heißt, wenn wir verstehen, dass das System wie ein Puntoswitcher funktioniert, haben wir mindestens zwei Äquivalenzklassen: Es gibt russische Buchstaben, die lateinischen Buchstaben entsprechen, und solche, die einem Sonderzeichen entsprechen.

Dies sind völlig unterschiedliche Klassen, sie müssen überprüft werden! Und wenn wir ein Sonderzeichen drucken, erkennt das System es möglicherweise nicht. Und dann starten wir einen Fehler - ich tippe das Symbol>, ich erwarte, dass das System es in den Buchstaben U übersetzt, aber nichts passiert. Warum erwarte ich das? Weil das System BEREITS so funktioniert, denn wenn ich Jkmuf eingebe, wird das System verstehen, dass es Olga ist.

Wir zeigen, dass das System bereits so funktioniert, und dies ist eine gute Rechtfertigung. Wir sagen nicht "Ich schwöre bei meiner Mutter, sie arbeitet so", wir beweisen es bei Olga.

2.3. Problem oder # Lebensschmerz

Erzählen Sie uns von einem echten Benutzerproblem.

Weil wir Tester sind. Unsere Aufgabe ist es, zu zerquetschen und zu brechen, "Krieg und Frieden" in ein kurzes Feld einzugeben, einen Eintrag in zwei Browser-Registerkarten und einen anderen zu bearbeiten. Und selbst wenn etwas bei uns nicht funktioniert, bedeutet dies nicht, dass der Benutzer dasselbe tut.

Und manchmal werden Fehler nicht einfach behoben, weil "Ja, das macht niemand!" Und das ist normal. Warum Energie und Ressourcen für ein Problem verschwenden, das niemals auftritt?

Dies gilt insbesondere für Probleme mit der Benutzerfreundlichkeit. Wie wir uns erinnern, ist das, was für einen IT-Spezialisten bequem ist, für einen einfachen Benutzer unpraktisch. Umgekehrt! Und es stellt sich heraus, dass wenn wir nur schreiben "Nun, das ist unangenehm ..." - dies ist eine schlechte Rechtfertigung, man nie weiß, was unangenehm ist, alles passt zum Rest. Wenn wir jedoch Feedback von Benutzern sammeln und deren Briefe anhängen, in denen sie sich bei uns beschweren, deutet dies sofort darauf hin, dass ein solches Problem tatsächlich besteht. Und das erhöht bereits seine Priorität.

Das Problem eines echten Kunden ist immer besser als nur eine Art negativer Test eines Testers.



Dies bedeutet nicht, dass Tester niemals auf Probleme korrigiert werden. Wenn Sie ein Problem haben, beschweren Sie sich auch! Vielleicht kann der Entwickler Ihnen in nur 5 Minuten helfen, er kennt die Situation einfach nicht.

Wenn ich eine neue Funktion teste, decke ich sie mit Autotests ab. Das Test-Framework gibt es schon lange, wir sind daran gewöhnt. Die Tests sind einander ähnlich, also kopieren und einfügen - schließlich ändern wir normalerweise einen Parameter und lassen den Rest unverändert. Dies ist das Prinzip von „1 Test = 1 Test“, sodass ein Abfall des Tests sofort die Ursache anzeigt.

Und jetzt muss ich Parameter von Autotest zu Autotest kopieren. Und ich muss sie vom ersten bis zum zweiten, dritten, vierten, fünften, zehnten Test ausgraben ... Und in diesem Copy-Paste muss ich nur 1 Wert in einer Zeile ändern, und wenn ich das nicht tue, wird alles mit einem Schrecklichen auseinanderfallen ein Fehler.

Natürlich irre ich mich beim Kopieren und Einfügen zumindest irgendwo ... Als Ergebnis habe ich 30 Tests geschrieben, sie gleichzeitig ausgeführt und alles ist mit NPE abgefallen. Ich sitze, kratzte mir am Kopf und denke: "Verdammt, wo irre ich mich?"

Ich habe den ganzen Tag geklärt, nach einem Fehler gesucht, Autotests durchgeführt ... Ich versuche, einen Fehler oder einen Ort zu finden, an dem ich es vermasselt habe. Infolgedessen finde ich und beschwere mich dann bei der nächsten Rallye:

"Ich habe diese Autotests gestern den ganzen Tag geschrieben, weil ich im fünften Test einen Fehler gemacht und dann lange versucht habe zu verstehen, was der Grund für den Sturz war." Oh, dieses Kopieren und Einfügen!

Und dann sagt der Entwickler:
"Ja, sie würde zu mir kommen; ich würde in einer halben Stunde alles für Sie umgestalten und dieses Problem beheben."

Und so war es möglich? !!!

Bitte hab keine Angst! Vielleicht leiden Sie und der Entwickler weiß nicht einmal davon. Und vielleicht kann er Ihr Problem hier und jetzt schnell beheben. Und vielleicht nicht beheben, sondern eine Problemumgehung vorschlagen.

Wenn es sich bei dem Problem um ein einmaliges Problem handelt oder die Behebung zu lange dauert, wird die Optimierungsaufgabe natürlich mit der nächsten oder einer weiteren Version fortgesetzt. Es lohnt sich jedoch, zumindest zu diskutieren, wie dies verbessert werden kann, und eine Aufgabe zu stellen. Denn wenn es keine Aufgabe gibt, wird niemand etwas tun.

Es gibt verschiedene Fälle von Problemen:

- Kundenproblem;
- das Problem des realen Benutzers;
- Testerproblem;
- ein Problem im Team;

Einige haben mehr Priorität, andere weniger. Und doch, wenn wir den wirklichen Fall und das wirkliche Problem beschreiben, dann hat eine solche Aufgabe mehr Chancen zur Korrektur als "offensichtlich, damit jeder besser wird".

Ja, Sie müssen verstehen, dass selbst wenn wir beschreiben, wie schlimm es für echte Benutzer ist, dies nicht garantiert, dass wir den Fehler beheben, aber dies ist das Leben. In jedem Fall wird, wenn wir das Problem zumindest beschrieben haben, zumindest klar, warum wir diese Aufgabe gestellt haben. Selbst wenn wir in einem Monat zu ihm zurückkehren, zwei oder drei. Wir werden immer sehen, warum wir dachten, dass Benutzer schlecht und unangenehm damit arbeiten.

3. Wenn die Begründung nicht benötigt wird

Plötzlich richtig? =)

Trotzdem hat das Antimuster „offensichtlich“ Ausnahmen. Wir müssen wirklich KEINE Begründung schreiben, wenn das System:

• aufgelegt;
• fiel mit einem unbehandelten Fehler;

Besonders wenn dies bei der Produktion passiert ist. Wenn es unsere Website gibt, gibt es keinen Grund, dies zu rechtfertigen. Sie müssen den Gong schlagen und zum Entwickler laufen, um "es dringend zu beheben!" Es ist überhaupt ohne Fehler möglich. Und Sie können mit einem kurzen "Fehler 500 auf der Haupt", das ist genug.

Saugen Sie das Grundprinzip nicht aus dem Finger, denn "es ist immer notwendig". Zu schreiben "das System sollte nicht fallen" ist Text aus Gründen des Textes.

Aber! Sie müssen auf jeden Fall das erwartete Ergebnis schreiben. Auch wenn es Ihnen offensichtlich erscheint, schreiben Sie es auf, es wird Sie nicht auslöschen.

Schritte
Öffnen Sie die Website example.com

Ergebnis
Fehler 500

Erwartetes Ergebnis
Die Hauptseite wurde geöffnet

Hier scheint alles einfach zu sein - das Haupt öffnet sich nicht, sollte es aber. Es gibt jedoch kompliziertere Beispiele.

Zum Beispiel hat der Entwickler eine Formel aus TK erstellt und irgendwo tritt eine Division durch Null auf. Wenn Sie nur "Es sollte keine Fehler geben, der Bericht wird geladen" schreiben, wird der Entwickler weiterhin mit der Frage "Wie sollte er dann geöffnet werden?" Zu Ihnen kommen. Es gibt eine Division durch Null! “

Sie müssen darüber nachdenken und schreiben: „Ich gehe davon aus, dass ein Bericht mit solchen und solchen Werten gemäß der Formel geöffnet wird.“ Während Sie überlegen, was dort sein sollte, können Sie die Verbindung selbst im TOR finden. Und dann erkundigen Sie sich beim Analysten, wie es richtig geht.



Selbst wenn es keine Rechtfertigung gibt, gibt es zumindest das erwartete Ergebnis. Und denken Sie daran, dass dies eine Ausnahme von der Regel ist. Das System sollte nicht fallen und einfrieren. Solche Fehler sind jedoch selten, und in anderen Fällen sollte dies gerechtfertigt sein.

4. Zusammenfassung

Wir haben 3 Antimuster besprochen. Drei Phasen der Wut, Verleugnung und Rechtfertigung von Fehlern:

1. Offensichtlich - Es ist uns klar, dass wir es nicht rechtfertigen. Und dann bekommen wir "Oh, ich habe vergessen, warum ich wollte" ... Das ist nur für dich offensichtlich, nur hier und nur jetzt. Nach sechs Monaten werden Sie selbst vergessen, warum. Erklären Sie, wie dumm, welche Beweise es gibt.
2. Ich schwöre bei meiner Mutter, das ist richtig! - Warum schwören? Aus irgendeinem Grund denkst du, dass es so richtig ist, also sag mir warum. Geben Sie beispielsweise einen Link zu den Anforderungen an.
3. Hasen waren beleidigt - "Oh, du hast der Hauptseite keine Katze hinzugefügt? Nun, das ist es! Ich war beleidigt ... und weg! Und Sie! Den Kunden verloren !! ” Aber was für Sie unpraktisch ist, kann für andere bequem sein. Entfernen Sie also Emotionen und geben Sie Fakten.

Stattdessen sollten sie die richtige Begründung verwenden:

1. Pruflink - TK, Internet, Kundenbrief , in dem er diese Funktionalität angefordert hat ...
2. Einheitlichkeit - Wenn das System immer so und an einem Ort anders funktioniert, lohnt es sich, es zu reparieren!
3. Problem - Beschreiben Sie das Problem, das für Sie oder den Benutzer auftritt (wenn Sie mit Kunden kommunizieren). Das eigentliche Problem ist immer besser als nur ein negativer Test.

Schreiben Sie unbedingt, warum wir entschieden haben, dass dies wirklich ein Fehler ist, und warum wir möchten, dass er genau so behoben wird, wie wir ihn hier geschrieben haben. Wir stellen uns Fragen aus der Serie „5 warum“

- Warum halte ich das für offensichtlich?
- Warum finde ich das so richtig?
- Warum sind die Benutzer meiner Meinung nach verärgert?

Wir stellen Links zu Anforderungen im Internet bereit, weisen auf Einheitlichkeit hin oder sprechen über das eigentliche Problem des Benutzers.

Und wenn Sie nach einem Jahr kompetent ausgeführte Aufgaben erneut lesen, sagen Sie mir immer noch: „Danke!“ ツ