dla każdego solowego testera polecam prowadzenie regularnej działalności testowej bug bash/mob. Jest to czynność, którą można wykonać pod koniec cyklu sprintu / feature dev. Zapraszasz zespół, zbierasz przekąski / napoje i przeprowadzasz testy przez około godzinę.
Konfiguracja
możesz upewnić się, że masz dobre pokrycie urządzenia/przeglądarki, upewniając się, że wszyscy są skonfigurowani z danymi/urządzeniami przed ręką. Możesz także przygotować dokumenty pomocy, które pomogą ludziom zacząć pracę. Lubię mieć mindmapę na temat pomysłów pokrycia przygotowaną przed ręką, aby ludzie mieli wizualny wskaźnik tego, co testują. Mogę również utworzyć kilka kont testowych przed ręką i rozpowszechniać je do zespołu.
lekkie zgłaszanie błędów
powinieneś zachęcać do zgłaszania błędów o małej wadze;
- może ludzie piszą błędy na karteczkach
- dodaj błędy do udostępnionego arkusza kalkulacyjnego
- lub wywołaj błędy Jira bezpośrednio ze Slacka za pomocą skrótu /jirio Utwórz błąd
należy skupić się na znajdowaniu błędów, a nie na ich zgłaszaniu. Zawsze możesz wyjaśnić problemy dalej po Bug bash, jeśli potrzebujesz więcej informacji.
co przetestować w bug bash
mam 3-stopniowy heurystyk decydujący o tym, co przetestować (myśl; przewodnik lub zasada kciuka):
- co się ostatnio zmieniło? Zmiana wprowadza nowe ryzyko. jakie funkcje zostały zbudowane? Jaki kod został zrefakturowany? Jakie biblioteki zostały zaktualizowane? Skoncentruj zespół, aby najpierw przetestować te obszary
- test regresji. Miej listę kontrolną co najwyżej tuzina scenariuszy podstawowej funkcjonalności (może wokół rejestracji, płatności i głównych rzeczy, które ludzie robią z Twoim produktem). Poproś ludzi, aby rozważyli te przypadki podczas robienia 1), może poproś ludzi, aby umieścili tam nazwę obok sprawy, gdy ją testują, abyś mógł zorientować się, co należy/możemy zrobić w przypadku
- ? Czasami może to mieć sens, aby zrobić test pen bug bash sesji lub testowania wydajności bash lub cross Browser Test bash, ale to nie musi się zdarzyć za każdym razem
Test w produkcji
, jeśli możesz; test w produkcji. Nie ma takiego środowiska.
ale jeśli nie możesz przetestować w produkcji, upewnij się, że środowisko testowe jest stabilne, Twoje dane są skonfigurowane i dałeś zespołowi prośbę „Nie dotykaj, z wyjątkiem testowania Bug bash”.
po Bug Bash
pamiętaj, aby podziękować ludziom za ich czas, policzyć błędy i dać uznanie swojemu najlepszemu łowcy błędów. Testowanie / jakość to w końcu odpowiedzialność zespołu. Wyślij e-mail z podziękowaniem z wynikami i nagrodami. Wręczyłem to trofeum nosorożca w żywicy na bazie trofeum naszemu łowcy robaków numer jeden.:
