Ich habe ein Bewerbungsformular auf einer Website, um mich für etwas zu bewerben. Es wurde gründlich getestet und hat bestanden. Mein Kunde hat jedoch festgestellt, dass das Formular bricht, wenn Sie ein Emoji in eines der Felder eingeben, das eine Adresssuche durchführt.
Und meine Antwort ist "gut, ja." Es ist eine unvernünftige Aktion. Kein Benutzer würde das tatsächlich tun, und ich finde es albern, dass der Kunde deswegen zu mir kommt. Ich meine, was erwarten sie, wenn sie unrealistische Dinge mit dem Formular machen, die ein gewöhnlicher Benutzer nicht tun würde?
Wie gehe ich damit um/um? Sage ich dem Kunden, dass er sich lächerlich macht, oder mache ich ihm Spaß und korrigiere ihn?
Dies ist nicht das erste Mal, dass sie dies tun. Sie werden alle möglichen Möglichkeiten finden, die Website zu beschädigen, wie z. B. diesen Wert eingeben, dann löschen und dieses ungültige Zeichen eingeben, dann eine Zahl eingeben, dann löschen und wiederholen, das Rote Meer trennen und mein Haus 6 Zoll nach links verschieben und Sie erhalten eine Fehlermeldung. Und ich habe einfach Lust, mir die Haare auszureißen. Was erwarten sie?
Wer ist hier der Unvernünftige?
Aus Sicherheitsgründen sollte man Eingaben niemals vertrauen. Was soll ich sagen, dass es das nächste Mal kein Emoji ist, sondern eine Art Text-Exploit wie ein Milliarden-Lach-Angriff ?
Am Ende des Tages, wenn es sich um eine öffentlich zugängliche Site handelt, werden Sie Skript-Kiddies haben, die ihre Tools darauf richten, die alle Arten von Daten an sie senden. Wenn die Seite abbricht, ist es Ihr BUG, er sollte behoben werden und könnte bedeuten, dass ein inhärentes Risiko besteht (wird er XSS wie alert('hello') akzeptieren und ausführen)?
Die Eingabe sollte auf dem Client UND dem Server validiert werden. Verarbeiten Sie nur Daten, die Sie erwarten.
Schauen Sie sich Troy Hunts sehr nützlichen Owasp Top 10-Leitfaden an, den Sie kostenlos herunterladen können Owasp Top 10-Entwicklerleitfaden
Es kann eine echte Herausforderung sein, zwischen einem Fehler und einer neuen Anforderung zu unterscheiden.
Eine Möglichkeit, dies deutlicher zu machen, besteht darin, einen Testbericht zu erstellen, der sowohl die durchgeführten Tests als auch den Umfang der Tests enthält. Wenn der Kunde den Umfang akzeptiert, werden alle zukünftigen Arbeiten außerhalb des Umfangs kostenpflichtig.
Der Testbericht könnte zum Beispiel so lauten:
Das Adressfeld wurde auf Feldlänge getestet. Es wird keine andere Textvalidierung durchgeführt.
Wenn dies vom Kunden genehmigt wird und er dann ein Problem mit Emojis meldet, die das Feld unterbrechen, wird dies als Änderungsanforderung betrachtet.
Sie haben nicht erwähnt, dass dies Teil eines Client-Beta-Testprozesses war, also gehe ich davon aus, dass dies nicht der Fall ist.
Stattdessen gehe ich davon aus, dass dieses Problem aufgetreten ist, als ein tatsächlicher Client die Anwendung tatsächlich verwendet hat und ein Verhalten gezeigt hat, das der Client nicht erwartet hat .
In meinen Augen ist das ein Bug . Jedoch!
Sage ich dem Kunden, dass er sich lächerlich macht, oder mache ich ihm Spaß und korrigiere ihn?
Sie zeigen da ein bemerkenswert polarisiertes Denken. Sagen Sie niemals einem Kunden, dass er lächerlich ist! Selbst wenn Sie einen Kunden feuern möchten, wäre Ihnen besser gedient, wenn Sie dies auf eine Weise tun, die ihm keinen Anlass gibt, Ihrem Unternehmen erheblichen bösen Willen zu hegen, was möglicherweise dazu führt, dass er sich dann alle Mühe gibt, Sie zu ärgern Schaden (z. B. das öffentliche Posten Ihrer Misshandlung).
Und selbst wenn es sich um einen Fehler handelt, spricht nichts dafür, alles fallen zu lassen und es jetzt zu beheben . Haben Sie darüber nachgedacht, mit Folgendem zu antworten?
"Vielen Dank für Ihr Feedback! Wir haben Ihren Fehlerbericht erhalten und in unser System eingegeben. Sobald er priorisiert wurde, beginnen wir mit der Bearbeitung."
Geben Sie dem Fehler dann eine angemessene (sprich: niedrige) Priorität und beheben Sie ihn, wenn Sie irgendwann Zeit haben (möglicherweise nie, aber das Durchgehen von Fehlerberichten mit geringem Risiko und geringer Belohnung scheint mir eine gültige Verwendung von Slack zu sein Ihr Kilometerstand kann variieren).
Stellen Sie sicher, dass Sie ihnen danken , denn sie tun Ihnen einen Gefallen . Ich würde gerne so engagierte und hilfsbereite Kunden wie diesen haben. Er/sie führt kostenlose eingehende Tests zur Qualitätssicherung durch . Wahrscheinlich einfach, weil er/sie Ihr Produkt mag und möchte, dass es so gut wie möglich ist (oder möglicherweise einfach, weil er/sie gerne die Probleme anderer Leute findet, aber so oder so, das Ergebnis ist das gleiche).
Der Kern Ihres Problems scheint darauf hinauszulaufen:
Es wurde gründlich getestet und hat bestanden. Mein Kunde hat jedoch festgestellt, dass das Formular bricht, wenn Sie ein Emoji in eines der Felder eingeben, das eine Adresssuche durchführt.
Aus Sicht des Projektmanagements lassen sich aus den beiden oben zitierten Sätzen folgende Take-aways ableiten:
Die Definition of Done des Projekts wurde nicht formal definiert.
Wenn Sie und der Kunde unterschiedliche Definitionen von „gründlich getestet“ haben, auf die Sie sich im Vorfeld nicht geeinigt haben, dann haben Sie ein Problem. Es kann ein Kommunikationsproblem, ein Planungsproblem oder ein vertragliches Problem sein, aber in allen Fällen ist es ein Problem auf Projektebene und muss konstruktiv angegangen werden.
Sie sagen, die Form "bricht", aber definieren nicht das Ausmaß der Auswirkung.
Ihr Kunde führt umfangreiche QA-Tests durch (wie es jemand im Projekt tun sollte) und findet Probleme. "Die Form bricht" ist jedoch ziemlich unspezifisch. Wenn es unsaubere Daten in eine Datenbank legt, die Anwendung zum Beenden bringt oder auf andere Weise etwas anderes tut, als einen behebbaren Fehler auszulösen, dann handelt es sich um einen Fehler. Wenn Ihre Anwendung kaputt gehen kann, wenn jemandes Katze über die Tastatur läuft, ist es unwahrscheinlich, dass sie ihren Zweck erfüllt.
Aber auch hier geht es um die Definition eines Qualitätsniveaus. Sie haben es als "das Formular funktioniert, wenn Benutzer dem glücklichen Weg folgen" definiert. Der Kunde hat es wahrscheinlich als „das System ist robust gegenüber unsauberen Eingaben“ definiert. Das Projekt hat jedoch kein vereinbartes Qualitätsniveau erreicht, auf das sich sowohl die Entwickler als auch der Kunde einigen. Repariere das!
Das Projekt integriert QA oder Akzeptanztests nicht in den Entwicklungszyklus.
Ein Teil Ihrer Frustration besteht darin, dass Sie im Nachhinein Feedback zum Arbeitsinkrement erhalten. Wenn QA und UAT jedoch wirklich in den Entwicklungszyklus integriert würden, gäbe es für niemanden Überraschungen. Sowohl die Entwickler als auch die Tester wüssten im Voraus, welche Tests bestanden werden müssten und ob jeder Arbeitsschritt diese Ziele erfüllte oder nicht.
Der Übergang zu einer Test-First-Denkweise ist schwierig, aber alles andere bedeutet, dass Ihr Projekt zum Scheitern verurteilt ist. Hier kann Projektmanagementerfahrung, einschließlich Prozessmanagement und kommunikationsorientierter Führung, wirklich helfen.
Sie und der Kunde arbeiten nicht zusammen .
Einer der vier Grundwerte des Agilen Manifests ist die Zusammenarbeit mit dem Kunden bei Vertragsverhandlungen . Selbst wenn Sie keine agile Methodik verfolgen (was sicherlich einige Ihrer Probleme erklären würde), ist der Punkt, dass es im Allgemeinen effektiver ist, Seite an Seite mit Ihrem Kunden zu arbeiten, anstatt sich auf Übergaben und Round-Trip-Feedback zu verlassen und vermeidet genau die Art von Kommunikation und Erwartungsproblemen, die Sie erleben.
Arbeiten Sie an der Schaffung von Zusammenarbeit durch eine klar definierte Definition of Done, die Implementierung einer testgetriebenen Entwicklung und die Einbeziehung von Client-Testern und UAT-Spezialisten in jeden Entwicklungszyklus. Die Zusammenarbeit ist fast immer effektiver bei der Lösung der Herausforderungen, denen Sie begegnen, insbesondere im Vergleich zu Vertragsstreitigkeiten oder Rechtsanwälten.
Bart van Ingen-Schenau
Robert K. Bell