Czy testerzy powinni automatyzować swoją pracę?

9

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ć?

Jader Dias
źródło
Po prostu zacznij nazywać ich „programistami w teście”, a dwuznaczność zostanie rozwiązana.
Edward Strange
@Crazy Ale posiadanie 2 zespołów programistów nie jest droższe?
Jader Dias,
5
Droższy niż co? Sprzedajesz źle przetestowany produkt? Wąskie gardło procesu programowania, ponieważ programiści piszą testy zamiast produktu?
Edward Strange

Odpowiedzi:

12

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.

James Love
źródło
Ale czy nie mogliby po prostu poprosić programistów o napisanie tego przypadku testowego?
Jader Dias
1
Z powodów, o których wspomniałem powyżej, programiści wiedzieliby znacznie więcej o wewnętrznej implementacji i podchodzili do oprogramowania inaczej niż z zewnątrz.
James Love
Nie widzę, jak implementacja przypadku testowego może się różnić w zależności od osoby.
Jader Dias
5
@Jader, chcesz, aby różni ludzie pisali testy automatyczne niż napisali oryginalny kod. W przeciwnym razie testy będą tendencyjne do pracy z kodem, który został napisany.
Marcie
3
W ciągu ostatnich kilku tygodni miałem programistę, który pomógł mi napisać urządzenia dla jego kodu. Jest bardzo dobrym twórcą, ale zdecydowanie brakuje mu niuansów związanych z pokryciem jego kodu tylko dlatego, że nie myśli o pokryciu go regularnie. Jeśli deweloperzy pomagają w testowaniu, poproś testera o sprawdzenie ich pracy.
Ethel Evans
11

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.

CaffGeek
źródło
Ale dlaczego powinni i nie tylko programiści?
Jader Dias,
@JaderDias, jak już wspomniano, testerzy nie powinni mieć uprzedzeń odnośnie do kodu, który próbują przetestować
CaffGeek
3

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.

Cena Taylora
źródło
Ciekawi Cię ostatnie zdanie - nie uważasz, że deweloperzy mogą przyczynić się do testów funkcjonalnych? Co jeśli testerzy zarysują strukturę testu i zidentyfikują przypadki testowe, a deweloperzy pomogą tylko we wdrożeniu?
Panna Cellanie
1
Myślę, że wyobrażam sobie testerów, którzy sami są programistami i mogą pisać własne testy. Ich zadaniem byłoby przejrzenie wymagań i porozmawianie z użytkownikiem, aby zidentyfikować przypadki testowe, a następnie je napisać. Dzięki temu programiści logiki mogą być blisko logiki podczas pisania. Pozostawia również testerów wystarczająco daleko od „posiadania” logiki, że mogą próbować ją złamać obiektywnie i bez wyrzutów sumienia.
Taylor Price
2

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.

Ethel Evans
źródło
0

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.

glenatron
źródło
Visual Studio 2010 (Premium lub Ultimate, nie pamiętam, który) ma coś, co rejestruje działania ekranu w celu zautomatyzowania testowania interfejsu użytkownika. Widziałem demo tego autorstwa Andrew Woodwarda MVP podczas pokazu interfejsu użytkownika testowania SharePoint, niewiarygodnie.
James Love
Nagrywanie i odtwarzanie słusznie ma dość złą reputację. Zwykle jest dość delikatny i trudny w utrzymaniu. Tak, jako szybkie i brudne „Muszę to uruchomić na 4 różnych centrach danych, nie chcę go przechowywać do przyszłego użytku”, jest w porządku, ale jest okropne w utrzymaniu, ponieważ kończy się na nim mnóstwo powtórzeń. Jeden mały element zmienia się - i nagle musisz zaktualizować 100 testów. Bolesny. Nie zastępuje też w żaden sposób testu ręcznego, który zwykle jest zaprojektowany z założeniem, że człowiek zauważy wszystkie inne rzeczy, których wyraźnie nie sprawdziłeś.
testerab
To, co byłoby całkiem słodkie, to coś, co może przenieść rzeczy na nieco niższy poziom niż przesunięcie wskaźnika i kliknięcie myszką, dzięki czemu faktycznie rejestrujesz, który przycisk został kliknięty, a nie gdzie nastąpiło kliknięcie. Dzięki temu tego rodzaju testy byłyby bardziej odporne i praktyczne. Kiedy potrzebujesz uruchomić każdy skrypt, na przykład na dziewięciu różnych wersjach systemu Windows, koszmar musi być wykonywany ręcznie na wszystkich z nich.
glenatron
Identyfikacja przycisku według identyfikatora zamiast lokalizacji jest całkowicie możliwa w przypadku niektórych narzędzi. Niestety, nagrywanie i odtwarzanie takich skryptów jest NAPRAWDĘ niestety trudne - nie rozwiązuje to problemu powtórzeń. Nie wydaje mi się, żeby trzeba było ostrożnie projektować automatyzację testów, jeśli naprawdę chcesz trzymać jakieś skrypty lub stworzyć ich kilkanaście. Czy zastanawiałeś się nad użyciem czegoś opartego na słowach kluczowych, takiego jak Robot Framework wraz z Auto-It?
testerab
0

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.

testerab
źródło