Czy testerzy są potrzebni?

U mnie w pracy nie są, bo i tak przepuszczają błędy, które klient znajduje w minutę.

Ale czy to znaczy że nie są potrzebni?

SĄ POTRZEBNI, TYLKO nie rozumiem DLACZEGO w wielu firmach ludzie uważają, że tester nie musi znać kontekstu biznesowego odnośnie robionego taska :)

Gdyby programiści robili swoją robotę dobrze to testerzy by nie byli potrzebni. Ale programiści swojej roboty dobrze nie robią. Testerzy swoją drogą też nie.

Descendant napisał(a):

to i tak chyba każdy sprawdza/przeklika czy jego kod śmiga.

własne błędy trudno znaleźć najlepiej się znajduje błędy kogoś innego, inna sprawa to czy do testowania nadaje się każdy

tak chyba każdy sprawdza/przeklika czy jego kod śmiga.

@Descendant: zgadnij jak się nazywa automatyzacja tej praktyki

@slsy: To zajmuje 5 minut max dla developera a nie 8h

@Descendant: a jak do przeklinania masz 1000 przypadków a zmiana to zwykłe podbicie bibliotek przez co nie wiesz co może się popsuć? A co jak to nie ty jesteś autorem kodu i nie wiesz co przeklikać? W dobie mikroserwisów testy są jeszcze bardziej potrzebne niż kiedyś, bo jest więcej ruchomych części, więc musisz być pewny, że pojedyncza zębatka działa jak należy w oderwaniu od całej maszyny.

Testerzy są potrzebni, manualni, automatyzujący, jak najbardziej. Tylko teraz jest tendencja, że np. taki Java Developer zgadza się robić za testera także, więc firmy tną koszty nie zatrudniając testerów, a przerzucając odpowiedzialność testowania na programistów.

To, że firmy nie zatrudniają testerów wynika z cięcia kosztów głównie, a nie że nie są potrzebni. Tak samo jest z biznes analitykami. Są potrzebni biznes analitycy w zespołach, tylko dobry biznes analityk kosztuje tyle co programista, więc tnie się koszty, a odpowiedzialność przerzuca się na kogoś innego, zazwyczaj na programistów, czasem na PM'ów. To tak w dużym uproszczeniu.

W korporacjach ogólnie większość stanowisk jest po to, żeby ludzie tylko mieli pracę - bez dostarczania większej wartości. Niemniej testerzy się przydają. Gdy by programista miał dokumentować wszystkie przypadki testowe, tworzyć tysiące scenariuszy itp. to development ciągnął by się w nieskończoność.

Wszystko, co da się zautomatyzować, powinno się automatyzować. W teorii takie testera manualnego powinien zastąpić skrypt, co nie zawsze się da wykonać w rozsadnym czasie i budżecie.

W „nowoczesnym” podejsciu to zespol developerski (literalnie: programiści) jest odpowiedzialny za jakosc dostarczanych rozwiazan od etapu designu (a czesto rowniez zbierania i negocjonowania wymagan) do wdrozenia i utrzymania na prod. Przy takim podejsciu tester szybko staje sie bottleneckiem, chyba, że jego odpowiedzialnoscia jest automatyzacja testow.

To ktoś jeszcze trzyma testerów manualnych? U mnie testerzy zajmują się pisaniem testów e2e.

Przecież piszemy testy jednostkowe, a jak nie to i tak chyba każdy sprawdza/przeklika czy jego kod śmiga.

To bardzo naiwne podejscie. Raz, że twoje zmiany mogą wywalić jakiś zupełnie niezwiazany kawałek kodu, wiec to przeklikanie to słaby plan, bo jako developer możesz w ogóle nie wiedzieć o ficzerze który właśnie popsułeś. Dwa, ze akurat testy jednostkowe guzik dają w kontekście sprawdzania czy system działa, bo są skupione na sprawdzaniu czy jakiś mały kawałek kodu działa tak jak programista myśli ze działa. Jeśli już, to potrzeba przynajmniej testów integracyjnych, ale nawet te niekoniecznie pomogą, bo coś się może sypać dopiero po spięciu ze sobą wszystkich komponentów i bez testów e2e sie nie obejdzie.

Oczywiście wszystko zależy od szczegółów miejsca pracy i samego oprogramowania. Ale ogólnie testerzy (zarówno e2e jak i manualni) jak najbardziej są potrzebni, szczególnie w przypadku aplikacji ze złożonym UI. Główny powód jest bardzo prosty- my, programiści jesteśmy ograniczeni pewnym tokiem myślenia, ramami w których operujemy. Ciężko nam się przełączyć i zacząć myśleć tak jak użytkownik a nie ktoś kto zna wewnętrzne szczegóły, nawet jeśli się bardzo staramy. Dla tego potrzebny jest ktoś z inną perspektywą.

Jakieś prześmiewcze komentarze w kierunku testerów świadczy tylko o autorach takich żartów, i jakimś żałosnym "elitaryzmie".

W mojej opinii jak firma nie ma kasy lub robi się startup to spokojnie można się bez testerów obyć. Widziałem całkiem duże projekty które były dowożone tylko przez programistów (ale byli to dobrzy programiści na etacie a nie "aby szybciej kontraktorzy" czy pracownicy z innego "tego o którym nie mówimy" sub-kontynentu).

Niemniej każda firma zaczyna w pewnym momencie stawiać na jakość i wtedy to słynne QA się pojawia. QA może wykryć to czego programista nie wykryje np. data po norwesku nie mieści się w polu lub musimy zwiększyć długość pola na imię bo hiszpańskie mogą nie wchodzić (przykłady z D). QA wykryje literówki i niezrozumiałe opisy pól czy API. QA zadba o to żeby interface był spójny i jako tako używalny. QA (dobre) wytknie nieoptymalne zachowania programu np. formularz bez ustawionych wartości domyślnych. W końcu QA może przejąć część roboty związanej z pisaniem testów automatycznych.

Dla manualnych testerów nie ma już miejsca w IT. Przekwalifikujcie się na automatycznych lub szukajcie innego zajęcia na emeryturę. Smutne ale prawdziwe. Przyszłość to mix 80% automatów i 20% kreatywnego ręcznego testowania.

@0xmarcin: pytanie dlaczego takiego podejścia nie można pociagnac dalej poza startup. Nie chcialbym placic QA za znajdowanie literowek, takie bledy mozna naprawic w 15 minut wliczajac wdrozenie.

Testerzy manualni itp ogolnie bede zawsze potrzebni ale w coraz mniejszym zakresie i raczej tylko w pewnych niszach / sektorach np;

• gdy jest sporo HW/elektroniki ktora np. wymaga konfiguracji spinania sprzetu do testow w labie roznej masci np. w HW, swiatlowody, anteny, tlumki tp itd
• gdy automatyzacja bardzo specyficznych elementow jest zbyt droga i kosztowna i utrzymanie takiej automatyzacji nie ma sensu na dluzsza mete bo np. testuje sie jakis prototyp
• w sektorach wymagajacych domenowej wiedzy np: telco (znajomosc 3GPP, architektury sieci itp itd), sieci komputerowe (ogolnie dostawy wszelkiej masci sprzetu i oprogramowania na nie), branza medyczna, branza embedded, branza automotive itp itd
• wszelkie miejsca gdzie oprogramowanie u klienta wystepuje w bardzo specyficznych srodowisku klienckim i automatyczne odtworzenie testu nie ma sensu - taka praca testera to czesto ostatnia linia supportu lub profesional service. Nie wiem czy dobrze wyjasnilem o co mi chodzi wiec podam przyklad: Producent np. load balancera sieciowego umozliwia klientom upgrade danego urzadzenia problem w tym ze takie urzadzenia moze np. miec bardzo rozbudowana konfiguracje i mase dowiazan do innych urzadzen. Wobec czego taki tester buduje srodowisko jak najbardziej zblizone do kienckiiego i manualnie wykonuje taki upgrade weryfikujac rozne rzeczy.
• field testy glownie telco
• w niektorych miejscach testy: security, performance testy

Nie wiem, czy są potrzebni. W miejscu, w którym aktualnie pracuję nie ma ani jednego testera i prawdopodobnie nigdy nie będzie.

Jest bardzo dużo testów automatycznych na różnych poziomach (jednostkowych, integracyjnych, e2e), które piszą programiści.

Może w innych obszarach są potrzebni, ale uważam, że powinno się dążyć do maksymalnej automatyzacji wszelkich nudnych i powtarzalnych czynności takich jak testowanie.

Pracowałem tam gdzie nie bylo i według mnie masakra.

Są potrzebni ponieważ, Programista robi, żeby działało a Tester by to zespsuć, to zupełnie inny mindset.
Poza tym testerzy często później bardzo dobrze znają appke, domene i potrafią wpłynąć na sensowne usprawnienia.

Co do głównego pytania, to oczywiście, że testerzy są potrzebni. Wyobraźcie sobie, że macie firmę produktową, gdzie dany produkt jest dla np. 1000 klientów, czasami większość z nich ma różne modyfikacje np. w zarządzaniu tworzeniem koszyka, promocji i nie tylko. Wiele przypadków testowych tylko dla jednego. Automatyzacja? Tylko wspólnych elementów, bo pod jednego klienta się kompletnie nie opłaca. Jeżeli jeszcze firma żyje dłużej niż 2 lata a np. 15-20, to produkt może być mniejszym/większym koszmarkiem. Przepisać? No bez jaj :D Wiadomo można refaktorować poszczególne elementy, ale żeby obrobić całość, to nie zajmie rok...

Czasami zmiana jednej funkcjonalności może wpływać na inne i wtedy trzeba bardziej gruntowne testy przeprowadzić, sprawdzić czy gdzieś nie ma jakiegoś dziwnego błędu. Tester musi znać kontekst biznesowy oraz techniczny zmiany, musi wiedzieć co ma przetestować oraz na co ta zmiana miała wpływ.

Ostatnio był temat, gdzie OP się żalił, że jest one-man-army :D No i tak się pracuje w firmach bez testerów, analityków, wdrożeniowców, gdzie jako programista nie piszesz tylko kodu ale załatwiasz jeszcze wszystko inne.

uważam że tak, aczkolwiek wierzę że jest wiele produktów gdzie testy są napisane tylko przez programistów i to im działa.

dużo zależy od typu softu/produktu np. co jeżeli całościowe testy by latały 2dni? może jednak lepiej mieć od tego dedykowany zespół, a to co można wyłapać unitami, to programiści?

ciekawy thread o TikToku

1. Labor cost difference between & leading to:

• engineers in don't write unit tests(!) they rely on QA to manually test each code commit
• product teams r more hands on + rely on manpower (ops teams) to drive growth, opposed to passive + data-driven Western tech

https://twitter.com/LucasOuYang/status/1493408431323049985

U mnie sa 3 testerzy manualni i tak tacy są potrzebni

Descendant napisał(a):

Czy waszym zdaniem testerzy są potrzebni? Ostatnio jak miałem okazje współpracować z dwoma, to jeden praktycznie nie miał co robić calymi dniami, w drugiej pracy tak samo - koleś testował jak jeden div się wyswietla na webie przez 2 dni i nikt nic z tym nie robił.

U nas raczej mają tyle roboty że się nie wyrabiają, częściej zadania wiszą bo testerzy nie zdążyli ich porządnie przeklikać i przeautomacić, niż dlatego że implementacja się przeciągnęła.

Przecież piszemy testy jednostkowe,

Yyy...

a jak nie to i tak chyba każdy sprawdza/przeklika czy jego kod śmiga.

G...o tam przeklika :) Oczywiście nie powinien oddawać do testów czegoś co najprostszego scenariusza nie przechodzi, ale tester jest od tego by klikał jeden button przez kilka godzin, szybko i wolno, myszką, palcem, z klawiatury i automatem, przy różnej konfiguracji i różnych okolicznościach. Tak by jak najwięcej błędów wyłapać w fazie testów, a nie na zasadzie że programista twierdzi "u mnie działa".

Z doswiadczenia jako Dev uważam ze testerzy sa potrzebni, do dzisiaj pamiętam jak jeden Senior Java Developer oddawal modul platnosci do przelewów, otestowane wszystko, testy integracyjne, code review przechodzi, a potem nagle na UAT'ach po paru dniach tester manualny od klienta zwraca funkcjonalność.

Magick. Gość musial pol tygodnia potem to debugować, nie bede pisal jakie rzeczy tam wychodziły po drodze, ale to sa właśnie te detale ktore świadczą o tym i przekonują mnie ze testerzy sa potrzebni.

Zaznaczę tutaj także aspekt psychologiczny, że potem manager go miał na świeczniku i pingował co chwilę kiedy bedzie poprawka. Także testerzy potrafią tez w pewnym sensie budowac spokój i zaufanie do produktu w zespole.

Ale, przecież zapomniałem....tera trza być "Agile", po co mi tester jak będę zwinny i jako Dev też będę testować xD

Z perspektywy QA - przy projektach o mniejszym poziomie "skomplikowania" od strony użytkownika, z pewnością idzie się obejść bez testerów. Natomiast z doświadczenia - nie widzę tego braku testerów przy projektach typu wdrażanie w banku całej nowej platformy kredytowej, czy całego softu do zarządzania szkodami w firmie ubezpieczeniowej, gdzie samych przejść poprzez różne warunki potrafi być tysiące.

• Testujecie?
• Testujemy!!!
• Świetnie to dlaczego od ponad 2 lat nie da się normalnie w IngBank dla firm ustawić daty na liście przelewów?
• ...a wyczyścił Pan cache przeglądarki?

O mBank nawet nie będę pisał bo to jest jeden wielki ""bug" i kompromitacja zespołu od szczurów w piwnicy po prezesa.

Sa przydatni pod warunkiem, że są w miare kumaci, mają minimum chęci i ambicji i potrafią rzeczywiście coś wychwicić. Czyli rozumieją logikę, potrafią stworzyc sami jakieś test case, przetestowac rozne corner case. Natomiast tacy, którzy nie potrafia nic i jedyne co robią to powtórzenie tych samych testów, które robię podczas developmentu, są tylko utrapieniem i traci się tylko czas na tłumaczenie im co i jak ma przetestować żeby tylko "odklepać taska".
Miewałem w projektach takich i takich.
Istnieja jeszcze tacy, ktorzy coś tam wiedza i kumają ale na siłę szukają dziury w całym (nie wiem po co, chca zabłysnac przed przelozonym?) na przyklad upierajac sie ze jezeli w specyfikacji napisano 2+2x2 to powinienem zaimplementowac to jako (2+2)*2 (przyklad oczywiscie fake ale pokazuje o co chodzi) i potem z takim kolesiem musisz sie kłocić i mu tłumaczyć, potwierdzać to jeszcze z innymi a i tak okaze sie ze koleś nie ma racji (takich tez przerabiam wlasnie teraz, a dodatkowo gdy są to osoby pewnej narodowości na H to ciśnienie skacze)

Co do testowania - zależy CO się robi.

W przypadku CRUD'ów czy jakichś obliczeń - wiele testów można zautomatyzować.
Ale np. w webówce - nikt nie zastąpi ręcznego przeklikania się przez stronę, zobaczenia jak się ona zachowuje na na różnych przeglądarkach, rozdzielczościach, systemach itp.

Takich sytuacji jest zresztą więcej - np. ostatnio siedziałem trochę nad zadaniem z branży embedded (duże słowo, brzmi groźnie - a chodziło o ESP32, jakiś ILI9486, kilka LED'ów i przycisków). I tutaj nie ma innej opcji niż ręczne przeklikanie się. Mam wrażenie, że prawie drugie tyle co na kodowanie to poświęciłem na odpalanie tego ustrojstwa, sprawdzanie czy wszystko się wyświetla i animuje zgodnie z oczekiwaniami itp.

@cerrato:

a jakiś ESP32 simulator/emulator?

@1a2b3c4d5e: są takie rzeczy, ale za bardzo nie wiem, jak by to miało działać i symulować ESP z podłączonym ekranem, do tego jeszcze obsługiwanym przez jakąś zewnętrzną bibliotekę.

A co do tego, co pisał @AsterFV - ok, zapewne pewne rzeczy da się w ten sposób zautomatyzować, tylko pytanie czy czasem (zwłaszcza przy prostszych i bardziej budżetowych projektach) nie jest to przysłowiowa armata na muchę?

@cerrato: Przy prostych i budżetowych - tak. Ale w zasadzie ogranicza się to tylko do naszych projektów do szuflady (odpowiednik strony wizytówki w webie). Większość komercyjnych projektów wymaga tego typu testowania, od elektronicznego zamka na drzwiach, aparatu słuchowego, urządzeniach w podstacjach energetycznych po urządzeniach w samochodach. Nawet jeżeli dany przemysł nie jest objęty surowymi regulacjami to odpowiednie testowanie to podstawa bo w wielu przypadkach nie da się po prostu wydać hotfixa na prodzie - trzeba zakładać, że wypuszczona wersja jest wersja ostateczna. A to wymaga odpowiednio wysokiego poziomu zaufania do produktu. Takie testowanie jest i tak tańsze niż konieczność wycofywania produktu z rynku że względu na krytyczny błąd.