>
— Jak zastosować proces, aby ułatwić organizację i uprościć poprawka błędów w cremona
ważne: jest to krok po kroku jak zorganizować Bug bash. Więcej na temat korzyści z jego wykorzystania w QuintoAndar można znaleźć w artykule „jak często i konsekwentnie Bug bashing zmieniał nastawienie zespołu na jakość i budował połączenie w QuintoAndar”.
wprowadzenie
Bug Bash jest metodologią testów, pierwotnie zdefiniowaną przez Rona Pattona w jego książce Software Testing w 2001 roku. Takie podejście do testowania było pomocne w różnych oddziałach w QuintoAndar i w rezultacie stworzyliśmy proces optymalizacji jego aplikacji.
Bug Co?!
Po raz pierwszy usłyszałem termin bug bash na rozmowie rekrutacyjnej w QuintoAndar i brzmiał dobrze. Później szukałem w Internecie więcej informacji, aby dowiedzieć się, że jest to dość rozpowszechniona praktyka, używana przez wiele firm z jedną wspólną cechą: zwinnym środowiskiem. Bug Bash jest metodologią testowania pierwotnie zdefiniowaną przez Rona Pattona, 2001. W swojej książce „testowanie oprogramowania” opisuje Bug bash jako procedurę, w której wszyscy ludzie zaangażowani w cykl rozwoju produktu, odkładają na bok swoje regularne codzienne zadania i”pound on the product”. Tak więc każdy, kto w jakiś sposób miał coś do powiedzenia na temat produktu-od definicji do projektowania; od rozwoju do marketingu — powinien być w tym samym pomieszczeniu, testując tę funkcję na jak najwięcej sposobów przed jej wydaniem.
przybliża zespół — od interesariuszy do rozwoju — do omówienia jak największej liczby scenariuszy testowych, a tym samym zmniejsza szanse na wadliwe wydanie. Zdając sobie sprawę, że może to być realna i cenna alternatywa dla naszego szybkiego, intensywnego tempa pracy, zaczęliśmy powoli wprowadzać koncepcję do zespołu, stale ulepszając i dostosowując podejście do potrzeb funkcji.
Niebo, to Ty?
brzmi jak marzenie, ale jeśli kiedykolwiek poprowadziłeś Bug bash, prawdopodobnie wiesz, jak chaotyczne może być zebranie tak wielu różnych profili w pokoju: niektórzy ludzie budzą wątpliwości, czy jest to błąd, czy nie, inni pytają, gdzie zgłosić wyniki, inni mają problemy z dostępem do systemu, wszyscy dyskutują o tym, jak śledzić i priorytetyzować poprawki błędów podczas testowania i tak dalej. Bez minimalnego przygotowania, szanse są takie, że ważne szczegóły zostaną utracone między pytaniami i post-its, ludzie będą sfrustrowani, że nie są słuchani, a ostatecznie to, co powinno być najbardziej produktywnym czasem znajdowania błędów, może okazać się stratą czasu dla całego zespołu.
oprócz złożoności związanej z koordynacją usuwania błędów, mieliśmy również wyzwanie zastosowania tej koncepcji w produkcie oferującym kompletne rozwiązanie biznesowe: od wyszukiwania nieruchomości po administrację wynajmem. Oznacza to rezultaty back-end I front-end przez cały okres użytkowania. Dlatego tutaj, w QuintoAndar, konieczne było posiadanie elastycznego i elastycznego procesu, który mógłby pasować do obu scenariuszy.
wiedzieliśmy, że jest — i nadal jest-wielkie wyzwanie przed nami: dowiedz się, jak skutecznie zastosować Bug bash w różnych kontekstach. Potrzebowaliśmy śmigła. Oznacza to, płynny proces z niezbędnymi i solidnymi narzędziami do centralizacji, który był wystarczająco elastyczny, aby mógł być stosowany w różnych rodzajach walidacji dostaw.
zastanawiając się nad powyższymi realizacjami, stworzyliśmy proces skupiony na połączeniu kluczowych punktów testowania wraz z kluczowymi elementami raportowania błędów, w jak największym uproszczeniu bez uszczerbku dla jego wydajności.
jak wspomniano, podstawy dobrego Bug bash obejmuje fazę prep, w której osoba zapewniająca jakość, ustala warunki testowania, zapewniając tymczasowym testerom narzędzia, które sprawiają, że ich umiejętności testowania są cenione. Istnieją trzy główne kroki do dobrej konfiguracji:
Krok 1: Utwórz arkusz kalkulacyjny, aby scentralizować wszystkie wyniki
Po pierwsze: potrzebujemy wszystkich na tej samej stronie. Dosłownie! Podczas próby mapowania problemów fundamentalne jest zgłaszanie wszystkiego w jednym dokumencie. To może oznaczać wspólną notatkę, dokument tekstowy, gigantyczny karton. Postanowiliśmy użyć arkusza kalkulacyjnego, w którym moglibyśmy również przedstawić wizualne wskazówki dotyczące tego, co jest testowane. Wybór ten był wynikiem współpracy z projektantem produktu zespołu, który opisuje korzyści dla samego projektu w artykule ” Product Design & Bug bash: how to validate interfaces and quality assure your delivery from end-to-end”.
arkusz kalkulacyjny pozwala również na łatwe zautomatyzowanie procesu, aby był płynniejszy i bardziej funkcjonalny. W arkuszu kalkulacyjnym bug bash mamy trzy zakładki: uczestnicy, Bug bash, Automatyczny raport.
ponieważ aplikacje użytkownika końcowego QuintoAndar są głównie internetowe, testy muszą obejmować różne urządzenia mobilne i stacjonarne. Czasami problem jest związany z urządzeniem, dzięki czemu jego ujawnienie jest niezbędne. Dlatego stworzyliśmy zakładkę „uczestnicy”, w której każdy tester lub uczestnik Bug bash wprowadza informacje takie jak nazwa, symulowany użytkownik, przeglądarka, Marka urządzenia i typ urządzenia. Są to podstawowe informacje, których potrzebujemy, aby zacząć badać — lub naprawiać — problem. Po uzupełnieniu tych informacji możemy kontynuować.
w drugiej zakładce „Bug bash” łączymy elementy testowania i raportowania błędów. Po obrazie kontekstu, który ma być badany w pierwszej kolumnie, następują trzy kolumny, w których tester wprowadza nazwę testera, szczegółowy opis znalezionego problemu, a także jego obraz, jeśli ma to zastosowanie. W ten sposób, jeśli są wątpliwości co do raportu, wiemy, kogo o niego zapytać i zaoszczędzić czas. Jest to szczególnie cenne przy zapewnianiu dostaw front-end, ponieważ możemy zweryfikować produkt końcowy pod kątem zaprojektowanego układu. Jeśli sprawdzamy dostawy back-end, obraz front-end jest zwykle zastępowany przepływem pracy wyjaśniającym, co dzieje się w back-endzie. W ten sposób informujemy ludzi na temat kontekstu, mimo że nie można go wyraźnie przetestować. Ludzie będą testować produkt i zgłaszać wszystkie problemy, ulepszenia i wątpliwości na tej karcie. Po upływie czasu testowania zespół omówi zgłoszone problemy, przeglądając i omawiając, co ma sens, aby zostać włączonym do fazy naprawiania.
ze względu na ten etap oceny ważności i priorytetyzacji, cały zespół będzie świadomy wszystkich znalezionych problemów i wybierze te związane z tym cyklem rozwoju do raportowania. Pozwoli to zoptymalizować fazę raportowania i uniknąć dalszych spotkań w celu ustalenia priorytetów problemów.
trzecia i ostatnia zakładka w arkuszu kalkulacyjnym o nazwie „Automatyczny raport” jest kluczem do nadążania za szybkością naszych procesów. Zawiera skrypt, który pobiera wszystkie informacje z dwóch ostatnich zakładek i automatycznie tworzy raport o problemach na tablicy Jira. Oznacza to, brak informacji utraconych na etapie procesu raportowania. Zapobiega to wielu przeróbkom i sprawia, że cały proces jest bardziej wydajny. Skrypt jest konfigurowalny, dzięki czemu można dodać więcej pól do raportowania.
Krok 2: Utwórz prezentację kontekstową
aby był skuteczny, zakres testowanego produktu powinien być bardzo dobrze zdefiniowany dla wszystkich zaangażowanych w proces testowania. Zakres powinien być ograniczony do cech dodanych w danym oknie czasowym lub cyklu rozwojowym. Im wyraźniej ludzie mówią o zakresie tej konkretnej ceremonii testowej, tym mniej będziesz mógł odpowiedzieć na to, czy jest to błąd, czy problem z dziedzictwem. Jest to szczególnie ważne, aby mieć tę prezentację w przypadku, gdy interesariusze lub outsiderzy oddziału biorą udział w testach, ponieważ mogą nie mieć jasności, jaką mają ludzie wewnątrz samego rozwoju.
Krok 3: zarezerwuj pokój i wyślij zaproszenia
zorganizuj pokój, aby pasował do dużej grupy ludzi, a jednocześnie dbanie o kalendarz nie zawsze jest takie proste. Może to zająć dużo czasu, aby dopasować każdy kalendarz lub mieć wystarczająco duży pokój dostępny, więc bądź na bieżąco. Na zaproszeniu Udostępnij prezentację kontekstową wraz z arkuszem kalkulacyjnym Bug bash i upewnij się, że udzieliłeś wymaganej zgody wszystkim uczestnikom. Innym bardzo ważnym aspektem Bug bashes jest czas. Pamiętaj, aby poświęcić co najmniej 1h 30m (półtora godziny), aby zainwestować w tę ceremonię. Może się to wydawać dużo, ale nie jest tak, gdy jest tak wiele różnych osób korzystających z produktu i interakcji, aby uzyskać lepsze podejście do doświadczenia użytkownika.
