Czy testerzy powinni automatyzować swoją pracę?

Próbujemy skonfigurować nasz proces testowania. Zastanawiamy się, czy nasi testerzy powinni opracować automatyczne testy regresji, czy też programiści powinni to zrobić.

A co z innymi typami testów automatycznych? Czy testerzy powinni je rozwijać?

Mówię, że testerzy powinni opracować zautomatyzowane testy - mają do kodu podejście „zewnętrzna para oczu” i wykryją (a może to po prostu „może”?) Wykryć błędy, o których nie pomyślałeś, a co dopiero poradzić sobie .

Ponadto ich zrozumienie wymagań funkcjonalnych może być wyższe niż zrozumienie programistów - tak więc leżąc pomiędzy hardkorową znajomością programisty na niskim poziomie, ale nie tak wysokim jak BA.

Jeśli możesz to zautomatyzować, zautomatyzuj to.

Pozostaw testerom swobodę w znajdowaniu rzeczy, których nie możesz zautomatyzować. A kiedy znajdą nowy błąd, jeśli można go zautomatyzować i dodać do automatycznych testów, dodaj go.

Moim zdaniem programiści i testerzy są odpowiedzialni za różnego rodzaju testy.

Deweloper, pisząc logikę, powinien także pisać testy jednostkowe i integracyjne. Pozwoli to twórcy upewnić się, że to, co napisali do tej pory, działa zgodnie z przeznaczeniem. Dodatkowo testy te będą jeszcze dostępne, aby program mógł zostać uruchomiony, gdy wprowadzą przyszłe zmiany. Po zakończeniu logiki deweloper może być pewny, że to, co jest napisane, działa, ponieważ rozumie specyfikacje i może przekazać testerowi.

Od tego momentu tester powinien być odpowiedzialny za pisanie testów systemowych, które upewnią się, że logika biznesowa działa zgodnie z przeznaczeniem.

Biorąc pod uwagę, że deweloperzy są często zbyt przywiązani do kodu, testerzy powinni być w stanie pomóc wyczyścić testy deweloperów, ale nie odwrotnie.

Z mojego doświadczenia wynika, że ​​sposób, w jaki tester konfiguruje i wykonuje przypadek testowy, w rzeczywistości różni się od sposobu, w jaki robi to programista. Testerzy będą zastanawiać się, jak uzyskać jak najwięcej informacji z przypadku testowego, jak szybko wykonywać testy, jak utrzymać testy w utrzymaniu i tak dalej. Co najważniejsze, testerzy zobaczą niuanse pokrycia testowego, za które programiści tęsknią.

Jeśli zasoby programistyczne do testowania są niskie, programiści mogą pomóc - ale tester powinien dokładnie sprawdzić swoją pracę. Deweloperzy powinni pracować nad urządzeniami i narzędziami testowymi przed napisaniem rzeczywistych przypadków testowych, a deweloperzy nigdy nie powinni pisać przypadków testowych dla własnego kodu. Pomoc programistom w testowaniu ma dodatkowe zalety - naraża programistów na inne elementy produktu, a testowanie może pomóc im stać się lepszymi programistami. Jednak, podobnie jak praca młodszego programisty nigdy nie obejdzie się bez przeglądu kodu, praca deweloperów powinna uzyskać ocenę jakości od osoby z większym doświadczeniem w testowaniu.

Zredagowano, aby dodać: Jestem SDET z 5-letnim doświadczeniem. Pracuję z wielkimi twórcami z ponad 10-letnim doświadczeniem, a ostatnio współpracowałem z nimi, aby przejść przez wąskie gardło testowe.

Jedną rzeczą, którą naprawdę chciałbym zobaczyć, są solidne narzędzia automatyzujące dla testerów, które pozwolą im skutecznie rejestrować swoje postępy za pomocą skryptu testowego, a następnie pozwolić na automatyczne uruchomienie tego skryptu w przyszłości. Zwłaszcza jeśli ułatwia to również uruchamianie tego samego skryptu w różnych wersjach systemu operacyjnego, bez konieczności testowania wszystkich testerów ręcznie.

Niestety, z pewnością w przypadku produktu, nad którym pracuję, żadne z dostępnych na rynku narzędzi nie spełnia swojej roli. Ale warto o tym pamiętać i sprawdzać, co jest dostępne na rynku, na wypadek, gdyby było coś, co zadziałałoby na to, co robisz.

Bardzo ważne jest tutaj jedno ważne rozróżnienie: czy testerzy po prostu sprawdzają , czy testują ?

Ten post na blogu autorstwa Michaela Boltona wyjaśnia to lepiej, ale w gruncie rzeczy: czy chcą jedynie potwierdzić zachowanie, czy też szukają problemów z systemem?

Myślę, że warto również rozważyć Kwadranty testujące zwinne (Brian Marick pierwotnie je opisał, ale natknąłem się na nie w książce Lisa Crispin i Janet Gregory „Testy zwinne”: nawet jeśli nie postępujesz zgodnie z metodologią programowania zwinnego, myślę, że rozróżnienie między testami, które krytykują produkt, a testami wspierającymi zespół, jest naprawdę opłacalne przy rozważaniu automatyzacji i próbie opracowania planu dla tego, kto co robi i dlaczego.

Na przykład kontrole jednostek napisane przez programistów działają jak detektory zmian, umożliwiając wczesne wykrywanie regresji, gdy są one regularnie uruchamiane - są to testy wspierające zespół. Zautomatyzowane kontrole regresji na poziomie systemu, dzięki którym można je regularnie i szybko uruchamiać ponownie, wspierają również zespół, wcześnie wychwytując regresję i uzupełniając testy jednostkowe wykonywane przez programistów. To zwalnia czas testerów na wykonanie testów, które krytykują produkt - na przykład testów eksploracyjnych. Lub ewentualnie zastosowanie niektórych automatycznych kontroli w celu przetestowania produktu w warunkach skrajnych.

Inną rzeczą, która bardzo podoba mi się w prezentacji Lisa Crispin, którą połączyłem, jest to, że wskazuje ona, że ​​automatyzacja może być również używana do obsługi testowania ręcznego - tworzenie danych testowych, automatyzacja używana do uzyskania scenariusza do punktu, na którym chcesz się dzisiaj skoncentrować, dla przykład.

Biorąc pod uwagę te dwa artykuły, mamy nadzieję, że pomogą ci przeanalizować, jakie testy chcesz wykonać, ułatwią wybranie, co może być odpowiednie dla automatyzacji, i dowiedzieć się, które części automatyzacji są bardziej odpowiednie dla testerów, a które przez programistów.