QA engineer / tester automatyzujący - co dalej? React? Czy DevOps?

Hej, pytanie z cyklu do wróżki. Liczę się z pseudo śmiesznymi cynicznymi odpowiedziami w forumowym stylu, ale jak zwykle pewnie trafi się jakaś ciekawa wypowiedź :D

Mam kilka lat expa jako QA. Zakładam, że do końca roku uderzę o sufit zarobkowy. Znam większość topowych narzędzi do testów, automayzowałem w selenium, cypress, playwright, protractor, robiłem testy wydajnościowe w jmeter. Programuję w pythonie, javie, js/ts, coś tam naklepię w powershellu.

Miałem epizod też jako QA manager, ale pieniądze jako QA Lead a QA senior to praktycznie to samo, w moim kontekście przynajmniej.

Mam do wyboru 2 ścieżki tak naprawdę.

1. frontend dev w react - tutaj sprawa byłaby uproszczona bo już coś tam klepię w react, pracuję w projektach reactowych i tak naprawdę pewnie jak zwolni się miejsce, bo jakiś dev da nogę to sam mógłbym zaproponować swoją kandydaturę na to miejsce (pewnie za mniejszą stawkę na początku niż mam obecnie). Kwestia doszkolenia się z reacta przez 2-3 miesiące i czekania aż zwolni się slot na frontend deva.

2. devops - tutaj musiałbym się nauczyć w cholerę nowych rzeczy z tego co zrobiłem research, dużo więcej niż na react deva i transfer na to stanowisko byłoby dużo trudniejsze (w projekcie w ogóle nie mam kontaktu z tym działem i pewnie nie wchodziłby w grę w transfer poza zespół). Z plusów to kasa dużo wieksza niż na react deva.

Priorytetem jest kasa, możliwości dalszego rozwoju i możliwie szybki transfer.

Na naukę jestem w stanie poświęcić 6-12 najbliższych miesięcy przed transferem.

Co o tym myślicie? Ciekaw jestem waszej opinii, wskazówek.

Ale co miałbyś robić jako "DevOps"? Nie ma jednego zakresu obowiązków dla "DevOpsa" więc napisz jak sobie takie stanowisko wyobrażasz. Programista Java to wiadomo, pisze kod w Javie, a "DevOps"? Każda firma definiuje DevOps po swojemu. W jednej "DevOps" będzie stawiał i automatyzował infrastrukturę w chmurze, on-premises albo tu i tu. W innej będzie klepał YAMLe do Kubernetesa i Dockerfile'e dla aplikacji, w jeszcze innej będzie kleił deployment aplikacji za pomocą CI/CD, Powershella, Basha, Ansible i innych magicznych tooli, a w jeszcze innej będzie robił wszystkiego po trochu.

Nie mówiąc o tym, że praca "DevOpsa" to często babranie się w szambie. Mam kolegę który trafił jako "DevOps" do projektu "uchmurawiania" starych aplikacji jako część strategicznej cyfrowej transformacji przedsiębiorstwa czy jakoś tak na zasadzie Lift&Shift, czyli wpakujmy legacy w kontener i siup na K8S :D

Na kasę nie patrz, bo stawki się wyrównują w perspektywie długoterminowej (widać to chociażby po runku US czy UK).

markone_dev napisał(a):

W jednej "DevOps" będzie stawiał i automatyzował infrastrukturę w chmurze

Można uznać, że to plus automatyzacja procesów ogólnie, utrzymywanie/konfigurowanie środowisk, czy to testowych, czy developerskich, czy w chmurze czy na serwerze; automatyzacja procesów wdrożenia; wdrażanie elementów CI/CD, dowolnych w zależności od zapotrzebowania; budowanie pipelinenów.

A interesuje cię to w ogóle czy patrzysz tylko na kasę? Praca "DevOpsa" wymaga znajomości sieci komputerowych, serwerów, programowania, a od pewnego czasu również chmury. Patrząc po twoim doświadczeniu będziesz zaczynał praktycznie od zera. Wiesz jak działają load balancery? Czym się różni Network Load Balancer od Application Load Balancer i od Classic Load Balancer w AWS? Kiedy stosować który? Jak się je konfiguruje? Jak działają strefy DNS? Co to Private Link? Znasz Terraform? Uruchmiałeś jakąś aplikację w kontenerze od zera i deployowałeś na K8S? Zautomatyzowałeś kiedyś stawianie usługi lub usług za pomocą Ansible/Puppet/Chefa?

Jeśli nie to zaczynasz w DevOps od zera więc lepiej sobie odpuść tą ścieżkę i skup się na tym co już znasz. Nie wiem skąd to przeświadczenie że praca jako "DevOps" jest prosta, łatwa i przyjemna. Zwłaszcza dla kogoś kto nie ma doświadczenia w administrowaniu serwerami i sieciach komputerowych. Dobrzy "DevOpsi" dlatego koszą dobry pieniądz bo są uniwersalni i potrafią ogarnąć zarówno tematy programistyczne, sieciowe jak i administracyjne.

markone_dev napisał(a):

Nie wiem skąd to przeświadczenie że praca jako "DevOps" jest prosta, łatwa i przyjemna.

Zacytuj gdzie tak napisałem.

Odpowiadając na 2 pierwsze pytania/sugestie:

1. Interesuje mnie tak jak wszystko inne czym się zajmuje i czego dotknąłem (nie ma mniej lub bardziej), ale patrzę głównie na kasę.
2. Tak, zaczynałbym od zera i mogę poświęcić 6-12 miesięcy na przygotowanie.

KarnyJerzy napisał(a):

markone_dev napisał(a):

Nie wiem skąd to przeświadczenie że praca jako "DevOps" jest prosta, łatwa i przyjemna.

Zacytuj gdzie tak napisałem.

Napisałem ogólnie bo widzę po postach nie tylko na 4p ale też w innych miejscach, że wiele osób które nie ma szans się dostać na programistę a na testera nie chce iść bo dużo chętnych, myśli że pójdzie w DevOps i będzie zarabiać tyle co programiści. Jeśli odebrałeś to osobiście to przepraszam.

@markone_dev: z ta trudnoscia wokol LB to przesadzasz, wystarczy pomyslec o tym jak o bardziej rozbudowanym rozrzutniku nawozu (tyle ze nie po polu a meidzy aplikacjami). W dodatku po pierwsze mona sobie szybko doczytac czym sie roznia (jak wykilkujesz z UI to sa opisane, jak robisz z TF/API to i tak pasuje zobaczyc co i jak), po drugie gdzie masz powiedziane ze wyladujesz na AWS, GCP tez ma swoje typy LB. Terraforma tez mozna szybko ogarnac (Yaml nie jest przesadnie trudny), jedyny minus ze pomylka moze zaowocowac wywaleniem produkcji w kosmos.

Jak siedzial w testach wydajnosciowych to jest spora szansa, ze musial ogarniac podstawy opsowania. Bo przeciez trzeba zestawic system, monitorowanie, porobic automatyzacje itp.

W kazdym razie ja w karierze skakalem Software Engineer <=> QE ==> Devops/Sre wiec mozna.

@WhiteLightning: Wiadomo, że mogłem wymyśleć trudniejszy przykład niż ELB w AWS, ale nie o to chodzi w wątku. Chciałem pokazać, że praca jako "DevOps" wymaga znajomości zagadnień sieciowych. Zgodzę się z tym, że wszystko można doczytać w dokumentacji i nie jest to rocket science, żeby ogarnąć, ale tutaj dochodzi do tego wątek zrozumienia tego co się robi i jak działa.

Weźmy na przykład coś z programowania np ORM. Ile to się naczytałem na forach i grupach dyskusyjnych narzekania, że ludzie nie rozumieją jak działają ORMy i na pytanie dlaczego tak zrobił (źle) to często jest odpowiedź bo tak było/jest napisane w dokumentacji, albo że nie było tego napisanego w dokumentacji i klasyczna odpowiedź "idź się najpierw naucz jak działa ORM".

Tutaj jest podobnie. Można klepać Terraforma jak małpa bezrozumnie, ale potem jak coś nie działa, albo się wywali i trzeba to naprawić, albo trzeba zrobić jakiś niestandardowy konfig, to jest klops, bo nie ma się podstaw działania urządzeń sieciowych, routingu, protokołu TCP/IP i tak dalej. W ten sposób pracuje przecież wielu programistów, robią coś w ten i ten sposób bo tak napisali w dokumentacji do Springa że tak należy robić i elo. A potem przychodzi niestandardowy case do rozwiązania i zwarcie w mózgu bo trzeba jeszcze rozumieć co się dzieje gdy dodaję kolejną szóstą już adnotację do klasy/metody.

Przeraża mnie, że rozpocząłem ten wątek 5 miesięcy temu, a mam wrażenie jakbym to pisał z tydzień temu :D
Jestem nadal w tym samym miejscu, nadal klepię automaty, sufit zarobków dla QA praktycznie osiągnięty, bo ofert za wyższe stawki zwyczajnie nie ma.
5 miesięcy a ja nadal się kręcę w kółko, bo nie wiem co mam dalej robić.
Frontend odpuszczam póki co, za duża konkurencja na poważne stawki i pewnie musiałbym zejść z oczekiwań na kilka lat, także wraca temat devopsowania.

Zastanawiam się, czy zamiast nie tłuc technologii do zeszytu, czy nie spróbować od razu na juniora devopsa żeby leciały dupogodziny i wiadomo, że najlepiej się uczyć w prawdziwym projekcie.

Jest kilka ofert na rynku, gdzie spokojnie mogę aplikować. Jest tylko jeden problem - finanse. Nie mogę zejść poniżej pewnego poziomu zarobków ze względu na koszty życia.

Z waszego doświadczenia, jaka jest szansa, żeby trzymać się obecnej posady i jako drugi projekt wziąć projekt juniorski na devops? Czy jest szansa, że ta druga firma się na to zgodzi? Wtedy w ogóle mogę się zadowolić jakimś śmiesznym 4-6k na fakturę, bo wiadomo, że nie o pieniądze by tu chodziło tylko o dupogodziny do cv.

chłopaki? @markone_dev: @WhiteLightning

Jak masz na tyle przestrzeni w obecnej firmie żeby wziąć drugi etat to spróbuj co ci szkodzi?

Co do tego czy firma się na to zgodzi to zależy od tego jaką masz umowę (UoP/B2B) i co masz w tej umowie wpisane. Ostatecznie nie musisz nikogo informować że jedziesz na dwa etaty, ale musisz się liczyć z konsekwencjami jak to wyjdzie na jaw i obecna lub nowa firma uzna że poniosła przez to straty i skieruje sprawę do sądu. Inną kwestią jest że musi jeszcze to przed sądem wykazać więc to nie jest takie proste, ale lepiej sobie oszczędzić nerwów.

Ze swojego doświadczenia mogę napisać, że większość firm w których pracowałem zgadzała się na dodatkowy etat po godzinach pod warunkiem, że nie zachodził konflikt interesów.

Aha i jest jeszcze szansa, że jak powiesz w nowej firmie, że masz już jeden etacik to ta druga może się na to nie zgodzić, zwłaszcza jak będziesz wykonywał pracę dla dwóch klientów w tych samych godzinach. Ja zwykle staram się dogadać tak, że pracę dla drugiego klienta wykonuję po godzinach pracy dla pierwszego. Czasem tylko się muszę za dnia wdzwonić na jakieś spotkanie, ale ja robię takie rzeczy jako konsultant a nie etatowiec, więc to trochę inaczej