QA Developer - zarobki

Hej. Czy warto wybrać się na stanowisko QA Developer (wiekszość pracy jako programista testów automatycznych, ale też trochę testowania manualnego), jeśli w przyszłości chce się być developerem ? Dostałem taką propozycję współpracy w dużej firmie, w dużym mieście w Polsce i to jak na razie jedyna oferta. Jak się kształtują widełki na takich stanowiskach dla osoby bez doświadczenia oraz w późniejszym okresie, dużo niższe od Developerów ? Powiedzmy, że popracuje z 2 lata, a potem gdy chciałbym pracować jako developer to będę traktowany jako osoba bez doświadczenia ? Jak to wygląda ?

Z góry dziękuje za odpowiedź :)

1. Ale umiesz programować i nadajesz sie na Deva? To startuj na pozycje Developera. Jak nie umiesz a chcesz się uczyć, pracując przy okazji "w branży" to idź na QA. Nie mówie tu absolutnie że QA to coś gorszego, odnoszę się tylko do kwestii że chcesz docelowo być developerem.
2. Widełki niższe. Nie mam jakiegoś super rozeznania ale ~30% niższe.
3. To zależy co będziesz dokładnie robił w pracy. Bo jak będziesz pisał system automatyzujący testowanie, to będziesz miał 2 lata doświadczenia jako programista. A jak będziesz klikał albo nagrywał coś przez selenium i potem odgrywał i wystawiał tickety z bugami, to będziesz miał 0 doświadczenia jako programista.

1. Umiem "coś" programować ale odpadałem na rekrutacjach na juniora, choć niewiele brakowało. Mógłbym iść na jakiś staż za parę groszy(dostawałem się) ale jako QA dostałbym już umowę za przyzwoitę pieniądze jak na osobę bez doświadczenia(ok 3300 - 3500 brutto na start).
2. Tam chodzi właśnie o automatyzację testów manulanych - Java/skryptowe języki, jednak manualki troszke może być ale stopniowo coraz mniej.

Warto brać ?

1. No dobra, ale pytanie czy faktycznie potrzebujesz teraz tej kasy? ;)
2. To są 2 różne sprawy. Czym innym jest stukanie skryptu który będzie cośtam mieszał i sprawdzał czy aplikacja poprawnie coś odsyła, a czym innym jest pisanie jakiegoś frameworka testowego. O ile to drugie jak najbardziej da ci sporo w kontekście bycia programistą o tyle to pierwsze nie za bardzo.

Shalom napisał(a):

1. No dobra, ale pytanie czy faktycznie potrzebujesz teraz tej kasy? ;)
2. To są 2 różne sprawy. Czym innym jest stukanie skryptu który będzie cośtam mieszał i sprawdzał czy aplikacja poprawnie coś odsyła, a czym innym jest pisanie jakiegoś frameworka testowego. O ile to drugie jak najbardziej da ci sporo w kontekście bycia programistą o tyle to pierwsze nie za bardzo.

1. Tak, potrzebuje niestety.. :)
2. Czyli mówisz, że praca jako programista testów automatycznych ma niewiele wspólnego z prawdziwym programowaniem ? Niby też uczy myślenia programistycznego w jakiś sposób, przynajmniej tak mi się wydawało.

1. No to po co w ogóle ta dyskusja? :P
2. Nie uczy wcale myślenia programistycznego. Wręcz przeciwnie. Testerzy zajmują się zupełnie innymi rzeczami i mają totalnie odmienne podejście. Programiści generalnie myślą o tym jak coś "zbudować" a testerzy o tym jak to "popsuć" ;] Poza tym nijak też nie nauczysz się takich rzeczy jak programowanie w zespole, cykl życia projektu etc.

Shalom napisał(a):

1. No to po co w ogóle ta dyskusja? :P
2. Nie uczy wcale myślenia programistycznego. Wręcz przeciwnie. Testerzy zajmują się zupełnie innymi rzeczami i mają totalnie odmienne podejście. Programiści generalnie myślą o tym jak coś "zbudować" a testerzy o tym jak to "popsuć" ;] Poza tym nijak też nie nauczysz się takich rzeczy jak programowanie w zespole, cykl życia projektu etc.

1. Liczyłem, że ktoś mnie przekona :P
2. Miałem już tą posadę brać ale mnie trochę zmartwiłeś.. Cóż jakąś decyzję będę musiał podjąć.

Niukom napisał(a):

3. Czyli mówisz, że praca jako programista testów automatycznych ma niewiele wspólnego z prawdziwym programowaniem ? Niby też uczy myślenia programistycznego w jakiś sposób, przynajmniej tak mi się wydawało.

To od Ciebie zależy, czy Twój kod ma coś wspólnego z programowaniem. Widziałem trochę kodu pisanego przez testerów, nie był on najwyższych lotów (był proceduralny, żadnych własnych klas, najczęściej używana metoda to kopiuj-wklej), ale jeśli Ty będziesz chciał pisać ładny kod, to chyba nikt Ci tego nie zabroni.

Shalom napisał(a):

Poza tym nijak też nie nauczysz się takich rzeczy jak programowanie w zespole, cykl życia projektu etc.

A co programiści wiedzą o cyklu życia projektu? :D Chyba tylko jak naklepać trochę kodu i nie przejmować się tym, co z nim będzie później.
Ogólnie, jeśli programiści i testerzy mają tego samego PM i chodzą na te same standupy, to można wiele rzeczy przynajmniej poobserwować.

Shalom napisał(a):

3. Nie uczy wcale myślenia programistycznego. Wręcz przeciwnie. Testerzy zajmują się zupełnie innymi rzeczami i mają totalnie odmienne podejście. Programiści generalnie myślą o tym jak coś "zbudować" a testerzy o tym jak to "popsuć" ;] Poza tym nijak też nie nauczysz się takich rzeczy jak programowanie w zespole, cykl życia projektu etc.

Chryste jaka bzdura... zeby popsuc to trzeba zbudowac test pierw a to programowanie jak kazde inne. No chyba ze ktos testuje przy pomocy Selenium IDE to znaczy ze totalnie nie warta czasu praca bo to moze robic kazdy. Natomias jesli piszesz kod pod czyste Selenium to i pierwsze primo ultimo musisz znac jakis framework do testow danego jezyka, drugie primo ultimo musisz znac Selenium czy nawet jednostkowe jak dotkniesz.. Trzecie primo ultimo bycie dobrym testerem to znaczy tyle co bycie dobrym programista, bo jesli potrafisz dobrze przetestowac metode to znaczy ze bedziesz wiedzial tez jak dobrze ja napisac. Natomiast w druga stronie to nie zawsze i nie czesto spotykana sytuacja. Przecietny programista to czesto robi taka kiszke w kodzie ze nie wiadomo gdzie przod a gdzie tyl... Na dodatek jest przewaznie wielce zbulwersowany ze jego kod nie dziala po wnikliwych testach.

Moge dac kilka przykladow :D zmienne o nazwach:

Object tutajNicniepowinnobyc_empyt;
int counterFunkcji;
void InputDlatransferu();

po prostu pracujac z takim kodem to rece opadaja

Ogolnie fajnie zaczac od testow bo potem jestes swiadom co mozna w twoim programie ze tak powiem zjebac. Bedziesz lepiej przewidywal a co najwazniejsze bedziesz miec swiadomosc ze dobry i czytelny kod to kod ktorego wynik latwo zweryfikowac testem. Czytelne zmienne, jasno mowiace o pelnionej roli. Ogolnie TDD + Clear Code samo do ciebie przyjdzie. No dobra nie samo.. tylko w tedy gdy zrozumiesz ze ten kod bedzie przez kogos moze kiedyc weryfikowany

@up Dokładnie tak myślę, zwłaszcza, że tam podobno z tego co rozmawiałem z ludźmi dużą wagę przywiązuje się do jakości kodu.
Clean code + code review każdego automata to standard.

@Zimny orzeł :D :D :D To ciekawe czemu ci wszycy testerzy jakich miałem okazję poznać pracują jako QA a nie jako Devowie, skoro twierdzisz że muszą być przynajmniej tak samo dobrzy. Szczególnie kiedy dostają 60-70% kasy na jaką mogą liczyć programiści.
No ale po kolei:

zeby popsuc to trzeba zbudowac test pierw a to programowanie jak kazde inne

Od kiedy? Zbudowanie testu opiera się na opisaniu przypadku testowego i z programowaniem nie ma nic wspólnego.

No chyba ze ktos testuje przy pomocy Selenium IDE to znaczy ze totalnie nie warta czasu praca bo to moze robic kazdy

Przeważająca większość testerów do klikacze którzy nawet nagrywać za pomocą Selenium nie potrafią...

Natomias jesli piszesz kod pod czyste Selenium to i pierwsze primo ultimo musisz znac jakis framework do testow danego jezyka, drugie primo ultimo musisz znac Selenium

Jasne, ale tu już przestajemy mówić o testerach. Bo tester to ktoś kto testuje oprogramowanie. A ktoś kto pisze framework testowy oparty o selenium to jest zwykły programista. Miałem kiedys okazję pisać coś takiego - pozwalało to testerom w kilku linijkach xmla konfigurować automat do testowania dość złożonej aplikacji. Tylko że ani ja, ani nikt z mojego zespołu nie byliśmy testerami i nigdy niczego nie testowalismy. Pisaliśmy oprogramowanie z którego testerzy korzystali.
Testerzy zajmowali sie tym czym sie zwykle zajmują:

• przygotowaniem przypadków testowych,
• konfiguracją środowiska,
• odpaleniem testów,
• analizą wyników,
• wystawieniem ticketów z opisem znalezionych defetów,
• zamykaniem ticketów które zostały naprawione

Jedyny punkt który może uwzględniać programowanie to konfiguracja środowiska (ale tu od pewnego czasu stosuje się już gotowe rozwiązania oparte o maszyny wirtualne, puppeta i dockera) oraz odpalanie testów. Tylko że biorąc pod uwagę obowiązki testera zwyczajnie nie będzie czasu na coś więcej niż napisanie jakiegoś prostego skryptu / małego programu automatyzującego. Bo do napisania czegoś większego potrzeba miesięcy pracy całego zespołu.

bo jesli potrafisz dobrze przetestowac metode to znaczy ze bedziesz wiedzial tez jak dobrze ja napisac

To jest prawda, szczególnie biorąc pod uwagę ideę TDD. Ale nie ma nic wspólnego z tematem bo testerzy zasadniczo nie piszą unit testów. Przynajmniej nie w żadnej firmie którą znam. Unit testy piszą programiści piszący dany kod.
Na poziomie wyższym niż kod, tzn na poziomie systemu, to że ktoś umie coś przetestować absolutnie nie oznacza, że umiałby napisać daną funkcjonalność. Bo zupełnie czym innym jest wykrycie, że jak podam ujemną wartść to się program wysypuje, a czym innym jest napisanie kodu który przesuwa marsjańskiego łazika o podaną odległość.

Przecietny programista to czesto robi taka kiszke w kodzie ze nie wiadomo gdzie przod a gdzie tyl

Widocznie pracujesz w takich firmach ;]

Poza tym bardzo dziwne wydaje mi się to co piszesz, bo wynika z tego że zajmujesz sie pisaniem unit testów / testów na poziomie kodu źródłowego, a to raczej bardzo dziwna praktyka żeby zajmowali sie tym QA. Może też z tego wynika słaby poziom waszych koderów? Bo unit testy raczej słabo sprawdzają się w kontekście szukania błędów w aplikacji, ale za to bardzo dobrze sprawdzają się w utrzymywaniu jakości kodu. Jak test trudno napisać to znaczy że kod jest słaby. Ale jak ktoś nie pisze testów do swojego kodu to może sobie z tego nie zdawać sprawy...

Zimny Orzeł napisał(a):

Trzecie primo ultimo bycie dobrym testerem to znaczy tyle co bycie dobrym programista, bo jesli potrafisz dobrze przetestowac metode to znaczy ze bedziesz wiedzial tez jak dobrze ja napisac.

Tester to ktoś, kto używa aplikacji w sposób pozwalający odkryć błędy. Tester nie wie co to jest metoda. Tester widzi całą aplikację, nie jej elementy. Tester w ogólności w ogóle nie musi znać żadnego języka programowania. A zatem tester nie może być programistą.

Tester to też ktoś, kto automatyzuje ten proces przy użyciu narzędzi udających używanie aplikacji przez użytkownika. Tacy ludzie może mogliby być programistami, gdyby się nauczyli tych wszystkich technologii, frameworków i wzorców, o których nie mają pojęcia, bo są testerami, a nie programistami.

Na dodatek jest przewaznie wielce zbulwersowany ze jego kod nie dziala po wnikliwych testach.

Kod o ile się kompiluje/parsuje nie może nie działać. Nie działać może funkcja aplikacji jako całość. I od wykrywania takich błędów są właśnie testerzy, a nie programiści. Programiści powinni testować na poziomie jednostkowym, a nie całościowym.

Chodzi pewnie o firmę Sabre, gdzie sam obecnie pracuję. Dam Ci więc rade: jeśli chcesz być devem nie pchaj się w QA. Znam temat testów automatycznych, bo musiałem coś w nich grzebnąć, pisanie takich testów (z użyciem gotowego frameworku na bazie Selenium) jest schematyczne i odtwórcze, podobnie jak przy użyciu SoapUI, nie nauczy Cię programowania, rozwiązywania problemów. Poświęć miesiąc na podwyższenie skilla (choćby zrozum się i naucz tego co w książce do SCJP porządnie), teraz są tak niskie wymagania na juniora wszędzie - scjp spokojnie starcza, przerób wzorce projektowe, coś o algorytmach. Ja nie znam QA, którym się udało przekwalifikować na dev. Jak już wejdziesz w QA ciężko będzie potem to zmienić.

Jeśli piszesz automaty, mające działać, w ogarniętej firmie, to piszesz je w grupie, z użyciem gita/svna, z użyciem wzorców projektowych itp. QA developer to właśnie developer frameworków testowych, jak sama nazwa wskazuje, czyli od deva webowego różni się tym, że zna inne narzędzia(też jest tego od groma, od wspomnianego już webdrivera, poprzez jakieś appiumy, po pisanie własnych frameworków w "x"Unitach). Przynajmniej tak powinno to wyglądać w normalnych firmach. A co do kasy, to znam 2 rodzaje firm, takie, które mają dobrych test developerów/testerów i płacą im tyle samo co devom webowym, oraz takie co płacą 30-50% mniej i przez wiele lat nie są wstanie ogarnąć poprawnie otestowanego CI ;)