Jak to jest z pracą testera?

Mam wrażenie, że programiści patrzą na pracę testera trochę z góry. Ciekawy jestem, jak to jest z tymi testerami? Widzę, że mają bardzo dobre zarobki. Pojęcia nie mam, ale zdaje się, że próg wejścia jest znacznie niższy niż dla developerów. Dlaczego zatem wielu ludzi woli być programistami? Pomińmy takie kwestie jak pasja. Na pasję jest czas w domu, a praca to tworzenie dóbr i zarabianie pieniędzy ;)

Oczywiście że pasja. A że jeszcze za to płacą, i to dobrze, to przyjemny zbieg okoliczności

Update:
Jakby nie pasja to zostałbym Bardzo Dzielnym Scrum Masterem. Odpowiedzialność żadna, a kasa lepsza

radomir napisał(a):

Mam wrażenie, że programiści patrzą na pracę testera trochę z góry.

Programiści na 99% społeczeństwa patrzą z góry :D

To zalezy jaki tester. Tester od automatów to jeszcze spoko, ale manualny to tragedia, po prostu nie dla mnie - 20 razy wchodzenie na te same formularze, to po prostu jest żmudne. Ja najbardziej lubię taski gdzie moge sprawdzić samym automatem i być pewnym że działa, bez tzw. "klikania" :)

Testerzy są potrzebni w projektach takich jak słynne marsjańskie łaziki :), ale to odsetek.

Według mnie w typowych projektach biznesowych najlepiej jest, gdy pracę testera wykonuje developer. To jedyne uczciwe podejście. Nie potrzeba:

• testerów manualnych - nie zmuszamy nikogo do powtarzalnego klikania, co łatwo może zrobić maszyna,
• testerów automatycznych - nie zmuszamy nikogo do pisania testów do nieswojego kodu.

Największy sens ma tzw. testowanie eksploracyjne, czyli używanie aplikacji i wyszukiwanie nowych typów błędów, które następnie są zgłaszane do developerów. Nie jest to jednak krok konieczny, ponieważ mając dobry monitoring eksplorację i tak zrobi produkcja, a pętla będzie krótsza.

Podsumowując, testowanie i wdrażanie powinno być integralną częścią pracy programisty. Tam gdzie jest dużo testerów prawdopodobnie proces wytwarzania softu kuleje.

@nie100sowny:

Według mnie w typowych projektach biznesowych najlepiej jest, gdy pracę testera wykonuje developer. To jedyne uczciwe podejście. Nie potrzeba:

Ja uważam, że jeżeli testuje ten, kto nie pisał kodu, to znajdzie więcej bugów i rzeczy, które "powinny być", a nie są.

Bo dev przeklepie głównie happy path, sprawdzi czy dokumentacja jest 1:1, a nie od strony usera :P

edit. Osoba pisząca kod myśli w inny sposób niż faktyczny User. Przecież nie myślisz w taki sam sposób co nauczycielka historii, która korzysta jedynie z youtube i facebooka. -

wdrażanie softu programiści też?

chcesz jeździć po klientach i stawiać im bazy, backupy robić itd?

to się nie kalkuluje, bo programista zarabia inną stawkę niż wdrożeniowiec (obstawiam, że znacznie większą ma jakiś seniór)

WeiXiao napisał(a):

chcesz jeździć po klientach i stawiać im bazy, backupy robić itd?

Budzimy! XXI wiek. Chmury, Docker i IaaS już powstały. :P

nie100sowny napisał(a):

Według mnie w typowych projektach biznesowych najlepiej jest, gdy pracę testera wykonuje developer. To jedyne uczciwe podejście. Nie potrzeba:

• testerów manualnych - nie zmuszamy nikogo do powtarzalnego klikania, co łatwo może zrobić maszyna,
• testerów automatycznych - nie zmuszamy nikogo do pisania testów do nieswojego kodu.

Chyba nie ma gorszej osoby do testowania niż własnie developer, to chyba najgorsza rzecz jaką można zrobić w projekcie:

1. Podświadomie i psychologicznie zawsze w jakimś stopniu jego testy to happy path
2. Bagatelizowanie drobnych błędów - to się szybko naprawi
3. Większość developerów nie lubi testować - zwykle jest to na zasadzie byle szybciej i robimy kolejny cieakwy task
   4.Cena za godzinę pracy developer/testera

Gdyby do moich obowiazków w pracy zaliczało się testowanie w sensie manualnym to długo bym tam nie został.

Pół żartem pół serio, to jest też kwestia powołania:

• testerzy potrzebują powołania do psucia, potrzebują czerpać z tego przyjemność, z tworzenia nowych problemów
• programiści potrzebują powołania do tworzenia, potrzebują czerpać przyjemność z budowania nowych rzeczy, z rozwiązywania problemów

zupełnie jak jasna i ciemna, strona mocy: Choose your side Luke :D

Chyba nie ma gorszej osoby do testowania niż własnie developer

Zależy, jak się temat rozegra. Wiadomo, że jak ktoś testuje swój produkt, to raczej za wiele nie znajdzie, głównie z powodów, które wymienił @W2K:

• będzie bagatelizował drobne usterki
• nie będzie się umiał wczuć w skórę przeciętnego usera, bo przecież sam wszystko wie doskonale, zna oczekiwaną kolejność klikania i sposób obsługi programu
• jest przekonany, że napisał wszystko dobrze, więc po co tracić czas na jakieś sprawdzenia, skoro lepiej w tym czasie będzie działać.

Dlatego trzeba zrobić konkurs - Piotrek szuka dziury w aplikacji Tomka, a Tomek testuje efekt pracy Adama.
Kto znajdzie najwięcej dziur dostaje premię. Zobaczyłbyś nagle, z jaką radością zostanie wytknięty każdy, nawet najmniejszy błąd :D

Ja tylko moge powiedziec ze jako QA nieraz zarabialem wiecej niz developerzy na moim poziomie w drabince stanowisk. Mam porownanie po obu stronach i troche inaczej sie podchodzi jako dev troche inaczej jako QA, czesto jak robilem taski gdzie bylo trzeba dziwna logike zaimplementowac, to POMIMO ze mam sporo doswiadczenia w roznych rodzajach testow i staralem sie pokrywac rowniez sciezki gdzie moga byc problemem to zdarzalo sie ze bledy uciekaly. Poza tym automatami nie pokryjesz testow niefunkcjonalnych, eksploracyjnych itp.

Czasami tez pracuje sie z legacy w dziwnych technologiach gdzie nie ma finansowego uzasadnienia do przepisywania/refactoringu/pokrycia testami. Juz nie mowiac o problematycznosci oblozenia testami np. transformat XSLT czy systemu regulowego.

nie100sowny napisał(a):

Według mnie w typowych projektach biznesowych najlepiej jest, gdy pracę testera wykonuje developer. To jedyne uczciwe podejście. Nie potrzeba:

• testerów manualnych - nie zmuszamy nikogo do powtarzalnego klikania, co łatwo może zrobić maszyna,
• testerów automatycznych - nie zmuszamy nikogo do pisania testów do nieswojego kodu.

No może, ale to tylko pokazuje jak smutne jest życie crudowych programistów w januszsoftach.

Praca testera nie polega na powtarzalnym klikaniu w interfejsie użytkownika. Praca testera polega na zweryfikowaniu, czy software działa.

Zautomatyzować, to sobie można regresję, ale nie weryfikację, czy nowy ficzer działa. Bo trzeba sprawdzić wymagania funkcjonalne, pozafunkcjonalne, zgodność z dokumentacją, sam fakt istnienia dokumentacji, czy obsłużone są wszystkie możliwe ścieżki, czy podstawowe security działa, i czy ficzer w ogóle jest dostępny i ma sens dla użytkownika.

Ja jako backendowiec mogę sobie co najwyżej napisać trywialne testy do endpointów, które wystawiam i to wszystko. Nie jestem w stanie przeprowadzić całego rzeczywistego flow, w którym użytkownik np. musi się uwierzytelnić i zatwierdzić operację w banku apką mobilną, którego nawet nie mam i nigdy nie widziałem na oczy. Nie mam też wystarczającej wiedzy biznesowej, żeby wiedzieć np. które kombinacje produktów łączą się z jakimi promocjami, i co jest sens testować. Oczywiście mógłbym to zrobić - ale po co, skoro od tego są testerzy, i robią to lepiej.

Mam wrażenie, że programiści patrzą na pracę testera trochę z góry.

Raczej nie ale przyznam że testerzy to jednak są lekko zakompleksieni na punktcie developerów. Ostatnio w firmie zaproponowałem na spotkaniu by testerzy nie jedli przy tym samym stole co developerzy w kuchni. O jezu jaką gównoburzę i histerię o to rozkręcili to było po prostu żenujące...

Praca testera jest ciekawa jeżeli jest ciekawa.

Należy unikać miejsc w których tylko tester jest odpowiedzialny za:

1. Przklikanie happy pathów każdego nowej funkcjonalności.
2. Przeklikanie regresji.
3. Pisanie trywialnych testów API/e2e itp, generalnie każdego rodzaju testów, ktore deweloper może dołączyć jako część np. swojego pull requesta.

Ciekawe obowiązki testera to na przykład:

1. Wyszukiwanie interesujących edge caseów nowej funkcjonalnośći, również podatności lub inne niefunkcjonalne rodzaje testów.
2. Development narzędzi do testowanie nietrywialnych problemów domenowych. Np
   a) narządzia do automatycznego testowania czy film na youtube nie zawiera pornografii.
   b) narzędzia które automatycznie zbuduje i przeprowadzi testy aplkacji mobilnej, coś w stylu https://www.test.ai/
   c) narządzia do automatycznego wyszukiwania i naprawiania prostych błędów, coś w stylu https://engineering.fb.com/developer-tools/finding-and-fixing-software-bugs-automatically-with-sapfix-and-sapienz/
   d) rozwój frameworka do property based testing, coś w stylu https://en.wikipedia.org/wiki/QuickCheck
   e) projektowania narzędzi opartych na nowych interesująych protokołach do automatyzacji UI aplikacji, coś w stylu https://github.com/GoogleChrome/puppeteer
   itd itd itd

Pozwole sobie przytoczyć wyjątkowo brutalnego cytata, który zachęca do unikania roli testera/qa/sdet-a/ drugiej kategorii:

#neversdet these positions need to be die out and the only way to do it is stop accepting them. Both SDE and SDET have the same bar and same pay but one leads to an amazing career and the other leads to testing things other people write while in their amazing careers.

Uwielbiam pracę testera. Tak, zdarzali mi się programiści traktujący mnie z góry ale myślę, że akurat to byli tacy co wszystkich traktują z góry i moje bycie testerem nie miało związku z traktowaniem. Zaczynałem jako programista i z czasem się tak składało, iż brałem na siebie coraz więcej i więcej testowych zadań aż naturalnie przeszedłem w testerkę :).

Ale tester testerowi nie równy tak samo jak programiści. Wielu często narzeka na nudny i durny projekt, na dużą ilość powtarzalnych czynności czy różne problemy w projekcie. Posiedzę chwilę i nagle okazuje się, że mogę np. zautomatyzować różne taski, rozwiązać tamte problemy itp. Tą część uwielbiam najbardziej kiedy udaje się zestawić sensowne środowisko testerskie przy skomplikowanych przypadkach. Chociaż nie pracowałem jeszcze przy typowych CRUDach więc nie wiem jak to tam wygląda. Zestawienie testów w embedded (np. testy automatyczne z gitlab pipeline procesorka leżącego na Twoim biurku) czy big data było dla mnie ciekawym wyzwaniem. Lubię też pracę testera dlatego, że często mamy - choć powierzchowny - wgląd w wiele części projektu i integrację modułów. Często jak pytam programistę o coś odsyła mnie do drugiej osoby bo mają często specjalizację np. jeden ciągle zajmuje się tylko jednym sterownikiem czy micro serwisem.

Na płacę nie narzekam. Zacząłem skromnie a obecnie zarabiam porównywalne kwoty co programiści.

Kiedyś wpadłem na to wideo i udało mi się odszukać w historii: (Tester, taki gorszy programista?)

Tester który u nas pracuje (ok 5 lat expa, automaty) podczas pierwszego tygodnia pracy zapytał mnie jak się usuwa branch na GITcie xD