Wpis z mikrobloga

Nie proszę nie zwalniajcie testerów nie oni są potrzebni. Panie Januszu nieeeee, stracicie jakość!

Ciekawy trend się tworzy, pierwszy raz widzę tego typu artykuł. Sam siedzę w tej branży i ciekaw jestem czy faktycznie firmy pójdą w oszczędności w postaci zwolnień testerów. Na pewno czesc ich da się zredukować, czesc zautomatyzować i cyk zamiast 4 manuali jeden automatyk który w „międzyczasie” będzie klikał tez manualne scenariusze.

Co sądzicie o tym?

Źródło: https://testerzy.pl/baza-wiedzy/artykuly/przemysl-decyzje-o-zwolnieniu-testerow

#programista15k #pracait #testowanieoprogramowania
bb89 - Nie proszę nie zwalniajcie testerów nie oni są potrzebni. Panie Januszu nieeee...

źródło: Zdjęcie z biblioteki

Pobierz
  • 23
@bb89 trochę ma to sens, bo żeby zautomatyzować cokolwiek to trzeba to najpierw przeklikać. Jest na pewno trend szukania QA-orkiestry, czyli osoby która zrobi wszystko co potrzebne w projekcie: od testowania manualnego be/fe, poprzez a11y, performance be/fe aż po testy automatyczne. Po sobie widzę, że jest to bardzo cenione w projektach, gdzie jest z reguły jeden QA. Firma potem bez problemu może taką osobę "sprzedać" do innego projektu.
@bb89: generalnie przynajmniej w scrum nie powinno być podziału na developerów, testerów, analityków devopsów itd tylko wszyscy powinni brać odpowiedzialność i własność za to co robią. Inaczej masz taką sytuację że sprint zamienia się w waterfall gdzie kuce godzinę przed review "kończą" i wypychają kod mimo iż nie jest przetestowany przez testerów i uznają że sprint jest zrealizowany. Generalnie teraz tyle osób się pcha, że zamiast zatrudniać testera lepiej jest zatrudnić
@MosPass to też niestety prawda - nie ma wiele firm gdzie "doceniają" takich ludzi, ale nie znaczy że takich w ogóle nie ma.
Patrząc na stawki i oferty pracy widzę, że eldorado się skończyło póki co.
@bb89: Przez ponad rok pracowałem w firmie, gdzie właśnie był 1 QA per zespół i zajmował się wszystkim - testował manualnie, potem to automatyzował, automatyzował też historyczne ficzery, do tego inne działalności związane np. z releasami czy ogólnie pojętym QA. I tak jak w zespołach, gdzie było mało ludzi i mało pracy to jeszcze jakoś się to sprawdzało, tak w tym z większą ilością to dochodziło do tego, że niektóre taski
@bb89: jako automat, moja ulubiona sytuacja to jak manual pisze scenariusze i klika nowe ficzery, ja wchodze pach pach zautomatyzowane.
Rzeczywistosc wyglada tak ze samemu trzeba wszystko robic jako automat, moze bez security i performance ale tez zdarzaja sie sytuacje ze do tego tez jestes spychany.
Ale tez z drugiej strony jak masz projekt z test menagerem, test architektem jest kliku automatow i kilku manuali do jednej czesci projektu to zazwyczaj
@bb89: Manual już od jakiegoś czasu jest redukowany na rzecz automatycznego.
Realnym problemem tutaj jest to, że wszelkie zmiany w grupie testerów są widoczne na projekcie z opóźnionym zapłonem. Czasami jest to nawet rozwleczone w czasie. Dlatego Januszom ciężko zauważyć to jak testerzy są potrzebni...
Na pewno czesc ich da się zredukować, czesc zautomatyzować i cyk zamiast 4 manuali jeden automatyk który w „międzyczasie” będzie klikał tez manualne scenariusze.


@bb89: Automatyzacja to jedno, a manualny test to drugie. Do tego dochodzi QA i BA, które mniej lub bardziej krzyżują się z kompetencjami Testerów. IMHO przy produktach gdzie jest legacy code, wiele różnych technologii zależnych od siebie i dużo nieudokumentowanych rzeczy tester manualny pracy nie straci.
Trzeba też pamiętać, że tester manualny testerowi manualnemu nierówny - gdzieniegdzie ktoś taki tylko leci po scenariuszach testowych przygotowywanych przez innych, a gdzie indziej robi praktycznie wszystko oprócz automatyzacji (np. przygotowywanie jakichś dokumentacji, prowadzenie demo, jakieś szkolenia, jakieś pilne wrzutki). Przez wiele lat pracowałem w różnych konfiguracjach i najlepsze doświadczenia mam z obecnej pracy, gdzie w zespole jest 1 tester od automatyzacji plus 1 od pozostałych czynności.
via Wykop
  • 2
@Jaslanin: To jest myslenie dyrektorow i prezesow. Po co mi tester w cenie developera jak mam darmowych stazystow. A czesto zdarzaja sie projekty mega skomplikowane gdzie samo zbuildowanie apki wymaga przejscie przez wiele systemow itp nie mowiac o integracjach i innych problemach jak chociazby wiedza gdzie szukac pomocy jak gdzies sie zaciales. Mam obecnie taki projekt gdzie wywalili 3 testerow przede mna bo sobie nie radzili i architekci czy kto tam
via Wykop
  • 1
@buntowniczaczupakabra: to jest powod dla ktorego nie robie dla polskich firm, przyjdzie pan programista po bootcampie z 2-3 letnim expem i poco on ma sprawdzac jak sa testerzy XD Swietna logika. U mnie z doswiadczenia dziala to odwrotnie - zrobie dobrze bo inaczej tester sie dowali i bedzie mi trul ile i co mam poprawiac
via Wykop
  • 2
@Pmpa: nie zgodze sie, jako szeroko pojety tester bardzo duzo pracuje z klientem chociazby zeby znalezc kroki do powtorzenia bugow ktore wedlug klienta "czasem ale nie zawsze" sie pojawiaja albo byc pierwsza linia kontaktu zeby nie zawracal glowy programistom albo zeby zrobic jakies buildy wewnetrzne zeby cos sobie przetestowal
najlepsze doświadczenia mam z obecnej pracy, gdzie w zespole jest 1 tester od automatyzacji plus 1 od pozostałych czynności.


@buntowniczaczupakabra: Duży macie ten zespół? Obaj testerzy mają pełne obłożenie pracą? Dużo nowych ficzerów? Pytam z ciekawości bo u mnie jeden tester na zespół i ogarnia zarówno manuale jak i automaty.
via Wykop
  • 2
@#!$%@?: owszem zgodze sie, ale powiem Ci jak to wyglada z mojej strony. Ja zglaszam bugi, daje jasno do zrozumienia ze to jest ultra #!$%@? a klient stwierdza ze dla niego ok, albo nie ma czasu (pieniedzy) zeby to poprawiac. Bardzo czesto slaby jakosciowo produkt to efekt decyzji ponad testerami lub po prostu brak testerow