– Wie man den Prozess anwendet, um Organisation und einfach zum Bug Bash cremona zu bringen
Wichtig: Dies ist eine Schritt-für-Schritt-Anleitung zum Organisieren einer Bug-Bash. Weitere Informationen zu den Vorteilen des Einsatzes bei QuintoAndar finden Sie im Artikel „Wie Bug Bashing häufig und konsequent die Denkweise des Teams in Richtung Qualität verändert und die Verbindung bei QuintoAndar aufgebaut hat“.
Einführung
Bug Bash ist eine Testmethode, die ursprünglich von Ron Patton in seinem Buch Software Testing im Jahr 2001 definiert wurde. Dieser Testansatz war bei verschiedenen Trupps in QuintoAndar hilfreich, und als Ergebnis haben wir einen Prozess zur Optimierung seiner Anwendung entwickelt.
Fehler was?!
Ich habe den Begriff Bug bash zum ersten Mal in meinem Recruiting-Interview bei QuintoAndar gehört und es klang gut. Später suchte ich online nach weiteren Informationen, nur um herauszufinden, dass dies eine ziemlich verbreitete Praxis war, die von vielen Unternehmen mit einem gemeinsam verwendet wurde: einer agilen Umgebung. Bug Bash ist eine Testmethode, die ursprünglich von Ron Patton, 2001, definiert wurde. In seinem Buch „Software Testing“ beschreibt er Bug Bash als ein Verfahren, bei dem alle am Produktentwicklungszyklus beteiligten Personen ihre regulären täglichen Aufgaben beiseite legen und „auf das Produkt pochen“. Also, jeder, der irgendwie ein Mitspracherecht beim Produkt hatte — von der Definition bis zum Design; von der Entwicklung bis zum Marketing – sollte im selben Raum sein und die Funktion auf so viele Arten wie möglich testen, bevor er sie veröffentlicht.
Es bringt das Team — von den Stakeholdern bis zur Entwicklung — näher zusammen, um so viele Testszenarien wie möglich abzudecken und somit die Wahrscheinlichkeit eines fehlerhaften Releases zu reduzieren. Als wir erkannten, dass dies eine praktikable und wertvolle Alternative zu unserem schnellen, intensiven Arbeitstempo sein könnte, begannen wir, das Konzept langsam in den Kader einzuführen, wobei wir den Ansatz ständig verbesserten und an die Bedürfnisse des Features anpassten.
Himmel, bist du das?
Klingt wie ein Traum, aber wenn Sie jemals eine Bug-Bash geleitet haben, wissen Sie wahrscheinlich, wie chaotisch es sein kann, so viele verschiedene Profile in einem Raum zu sammeln: Einige Leute bezweifeln, ob es sich um einen Fehler handelt oder nicht, andere fragen, wo sie die Ergebnisse melden sollen, andere haben Probleme beim Zugriff auf das System, alle diskutieren, wie sie Fehlerbehebungen beim Testen verfolgen und priorisieren können und so weiter. Ohne eine minimale Vorbereitung stehen die Chancen gut, dass wichtige Details zwischen Fragen und Post-Its verloren gehen, die Leute frustriert werden, weil sie nicht zugehört werden, und letztendlich, was die produktivste Zeit sein sollte, Fehler zu finden, kann sich als Zeitverschwendung für das gesamte Team herausstellen.
Neben der inhärenten Komplexität der Koordination einer Bug-Bash hatten wir auch die Herausforderung, das Konzept auf ein Produkt anzuwenden, das eine komplette Geschäftslösung bietet: von der Immobiliensuche bis zur Mietverwaltung. Das bedeutet Back-End- und Front-End-Ergebnisse während der gesamten Benutzererfahrung. Daher war es hier bei QuintoAndar unerlässlich, einen flexiblen und anpassungsfähigen Prozess zu haben, der für beide Szenarien geeignet ist.
Wir wussten, dass eine große Herausforderung vor uns lag — und immer noch liegt: lernen Sie, wie Sie die Bug Bash effektiv in verschiedenen Kontexten anwenden können. Wir brauchten einen Propeller. Das heißt, ein reibungsloser Prozess mit wesentlichen und robusten Tools für die Zentralisierung, die anpassungsfähig genug waren, um für die Validierung verschiedener Arten von Lieferungen verwendet zu werden.
Da wir uns über die oben genannten Erkenntnisse wunderten, haben wir einen Prozess entwickelt, der sich darauf konzentriert, wichtige Testpunkte mit Schlüsselelementen der Fehlerberichterstattung zu kombinieren, so einfach wie möglich, ohne die Effizienz zu beeinträchtigen.
Wie bereits erwähnt, beinhalten die Grundlagen für eine gute Bug-Bash eine Vorbereitungsphase, in der die Qualitätssicherungsperson die Bedingungen für das Testen festlegt und den temporären Testern Werkzeuge zur Verfügung stellt, die ihre Testfähigkeiten verbessern. Es gibt drei Hauptschritte für eine gute Einrichtung:
Schritt 1: Erstellen Sie eine Tabelle, um alle Ergebnisse zu zentralisieren
Das Wichtigste zuerst: Wir brauchen alle auf derselben Seite. Buchstäblich! Beim Versuch, Probleme abzubilden, ist es von grundlegender Bedeutung, alles in einem einzigen Dokument zu melden. Dies könnte eine gemeinsame Notiz bedeuten, ein Textdokument, ein riesiger Karton. Wir beschlossen, eine Tabelle zu verwenden, in der wir auch eine visuelle Anleitung geben konnten, was getestet wurde. Diese Wahl war eine Zusammenarbeit mit dem Produktdesigner des Teams, der die Vorteile für das Design selbst im Artikel „Product Design & Bug bash: So validieren Sie Schnittstellen und sichern die Qualität Ihrer Lieferung von Ende zu Ende“.
Eine Tabellenkalkulation ermöglicht auch die einfache Automatisierung des Prozesses, um reibungsloser und funktionaler zu sein. In einer Bug Bash-Tabelle haben wir drei Registerkarten: Teilnehmer, Bug Bash, Automatischer Bericht.
Da die Endbenutzeranwendungen von QuintoAndar größtenteils webbasiert sind, müssen die Tests verschiedene mobile und Desktop-Geräte umfassen. Manchmal ist das Problem gerätebezogen und macht seine Offenlegung unverzichtbar. Also haben wir den Tab „Teilnehmer“ erstellt, in dem jeder Tester oder Teilnehmer der Bug Bash Informationen wie Name, simulierter Benutzer, Browser, Gerätemarke und Gerätetyp eingibt. Dies sind die grundlegenden Informationen, die wir benötigen, um das Problem zu untersuchen oder zu beheben. Sobald diese Informationen vollständig sind, können wir weitermachen.
Auf der zweiten Registerkarte „Bug bash“ kombinieren wir die Test- und Fehlerberichterstattungselemente. Auf ein Bild des zu testenden Kontextes in der ersten Spalte folgen drei Spalten, in denen der Tester den Namen des Testers, eine detaillierte Beschreibung des gefundenen Problems sowie gegebenenfalls ein Bild davon eingibt. Auf diese Weise wissen wir, wenn Zweifel an dem Bericht bestehen, wer sich danach erkundigen muss, und sparen Zeit. Dies ist besonders wertvoll bei der Sicherung von Front-End-Lieferungen, da wir das Endprodukt anhand des entworfenen Layouts validieren können. Wenn wir Back-End-Lieferungen validieren, wird das Front-End-Image normalerweise durch einen Workflow ersetzt, der erklärt, was im Back-End passiert. Auf diese Weise halten wir die Leute über den Kontext auf dem Laufenden, obwohl dies nicht sichtbar testbar ist. Die Leute werden das Produkt testen und alle Probleme, Verbesserungen und Zweifel auf dieser Registerkarte melden. Wenn die Testzeit abgelaufen ist, geht das Team die gemeldeten Probleme durch und überprüft und diskutiert, was sinnvoll ist, um in die Fixierungsphase einbezogen zu werden.
Aufgrund dieser Phase der Bewertung und Priorisierung des Schweregrads ist sich das gesamte Team aller gefundenen Probleme bewusst und wählt diejenigen aus, die sich auf diesen Entwicklungszyklus beziehen, für die Berichterstattung aus. Dies wird die Berichtsphase optimieren und Follow-up-Meetings vermeiden, um die Probleme zu priorisieren.
Die dritte und letzte Registerkarte in der Tabelle mit dem Namen „Automatischer Bericht“ ist der Schlüssel, um mit der Geschwindigkeit unserer Prozesse Schritt zu halten. Es enthält ein Skript, das alle Informationen aus den letzten beiden Registerkarten aufnimmt und automatisch einen Problembericht in unserem Jira-Board erstellt. Dies bedeutet, dass keine Informationen in der Phase des Berichtsprozesses verloren gehen. Dies verhindert viel Nacharbeiten und macht den gesamten Prozess viel effizienter. Das Skript ist anpassbar, sodass weitere zu meldende Felder hinzugefügt werden können.
Schritt 2: Erstellen Sie eine Kontextpräsentation
Um effektiv zu sein, sollte der Umfang des zu testenden Produkts für alle am Testprozess Beteiligten sehr genau definiert sein. Der Anwendungsbereich sollte auf die Funktion(en) beschränkt sein, die in diesem bestimmten Zeitfenster oder Entwicklungszyklus hinzugefügt wurden. Je klarer die Leute über den Umfang dieser bestimmten Testzeremonie sind, desto weniger können Sie beantworten, ob es sich um einen Fehler oder ein Legacy-Problem handelt. Es ist besonders wichtig, diese Präsentation zu haben, falls Stakeholder oder andere Außenstehende an den Tests teilnehmen, da sie möglicherweise nicht die Klarheit haben, die Menschen in der Entwicklung selbst haben.
Schritt 3: Buchen Sie ein Zimmer und senden Sie die Einladung Tage im Voraus
Ordnen Sie ein Zimmer für eine große Gruppe von Personen an, während Sie sich gleichzeitig um den Kalender der Personen kümmern, ist nicht immer so einfach. Es kann lange dauern, bis jeder Kalender passt oder ein ausreichend großer Raum zur Verfügung steht. Teilen Sie auf der Einladung die Kontextpräsentation zusammen mit der Bug-Bash-Tabelle und stellen Sie sicher, dass Sie allen Teilnehmern die erforderliche Berechtigung erteilt haben. Ein weiterer sehr wichtiger Aspekt von Bug Bashes ist die Zeit. Stellen Sie sicher, dass Sie mindestens 1h 30m ( eineinhalb Stunden) Zeit haben, um in diese Zeremonie zu investieren. Es mag viel erscheinen, aber es ist nicht so, wenn so viele verschiedene Personen das Produkt verwenden und interagieren, um einen besseren Ansatz für die Benutzererfahrung zu erhalten.
