Ja osobiście staram się bardzo ostrożnie i z otwartym umysłem podchodzić do definiowania kogokolwiek. Bo potem ktoś może do mnie podejść i powiedzieć, że ch*j ze mnie a nie Polak, jeśli nie wiem kto przewodził powstaniu krakowskiemu w 1846 r. albo jak z domu nazywała się żona Józefa Piłsudzkiego. Na pewno do swojej definicji programisty bym włączył każdego, kto otrzymuje w sposób bezpośredni lub pośredni wynagrodzenie za tworzenie kodu w jakimś języku programowania - więc w tym przypadku pewnie większość testerów automatyzujących. Poza tym nie mogę się zgodzić, że wszyscy programiści są jakimiś super mega przekotami. Chyba rzecz w tym, że swoje przygody z IT zaczęliście dość dawno i teraz w większości przypadków pewnie kontakt macie z jakimiś techleadami / architektami. Obecnie całe IT jest mocno oblegane i wiele osób próbuje się przebranżowić na programistów. Dlatego nie zawsze są to osoby typowo po studiach informatycznych, itp. Poza tym sprawdzanie programisty testów automatycznych w zadaniach realizowanych przez inny typ programisty jest niesprawiedliwe. Poproście programistę backend o wyśrodkowanie kilku elementów na frontendzie albo programistę frontent o napisanie prostego API zawierającego kilka ścieżek i middleware’ów. Ciekawe jak wypadną.

Ciekawy odcinek, fajna forma dyskusji :) Dobrze usłyszeć opinie z różnych stron, każdy ma inne doświadczenia. Trzymam kciuki za rozwój kanału, pozdrawiam!

Super odcinek :) Kiedyś myślałem nad tym właśnie tematem, a tu wszystko wyjaśnione :)

No cóż. Ja przeszedłem ścieżkę „w drugą stronę” (a po prostu wyszło, że wolę znajdować błędy niż je pisać😂). Z tej perspektywy powiem - trzeba się uczyć, bo niestety o ile sam nie czuję się żadnym wymiataczem to większość testerów jedynie myśli, ze coś umie :). Inna kwestia, ze tester automatyzujący to JEST programistą - zazwyczaj słabszym, o zupełnie innym polu działania i z innymi narzędziami, ale programistą.

Podobało się. Kiedy następny odcinek na wspomniany temat, tzn rekrutacje?

Czy w następnym odcinku moglibyście wypowiedzieć się na następujący temat, mianowicie jaka część osób zajmujących się testowaniem manualnym czy automatycznym z waszego otoczenia, aktualnego czy poprzednich miejsc pracy ma wykształcenie typowo informatyczne? Osobiście uważam że poniekąd to o czym rozmawialiście w tym odcinku jest z tym powiązane. Na pewno obecnie wymagania na rynku pracy dla testerów są zupełnie innej niz powiedzmy 5 lat temu. Z moich obserwacji wynika że wśród testerów jest mało osób z informatycznym wykształceniem, tym samym te osoby często są samoukami, z manualnych testerów zaczęli rozwijać się w kierunku automatyzacji. Myśle, że mało kto, kto kończy informatyke decyduje się na bycie testerem, szczególnie manualne testy. Powszechnie wiadomo że testerzy w dużej cześci to nie są osoby, które od wczesnego etapu edukacji planowali taka drogę zawodową. W większości brakuje im, mnie również, po prostu tego wykształcenia, wiedzy i koniec końców tester automatyzujący to nie programista.

A i jeszcze jedno😅 Te dwie osoby, stanowisko pracy które zajmują nie powinno być określane tym samym słowem, sformułowaniem ze względu na to że tylko ta jedna grupa tworzy kod, który firma sprzedaje. I po drugie, co już pisałem programiści względem testerów automatyzujących są lepiej wykształceni. Gdzieś na grupie fb kiedyś była jakaś ankieta na ten temat. Właśnie ze względu na te 2 argumenty uwazam że nie powinno jednych i drugich nazywać się programistami, czy ogólnie tym samym określeniem, sformułowaniem.

Panowie nastepnym razem nie wchodzcie sobie w zdanie w co drugim zdaniu :D pytanie : czy tester autom. bez studiów informatycznych może stać się java junior developer ? patrząc po ofertach ciężko znaleźć oferty bez wymaganego wykrzystałcenia

Dwóch testerów, więc się nie powstrzymam, muszę się przyczepić: wziąć na tapet, nie na tapetę! ;) Bardzo fajny odcinek. Według mnie warto pamiętać o zasadzie KISS, keep it simple (super/stupid). Dokładnie z tej przyczyny, o której mówicie - piszemy testy i nasze cele są nieco inne, niż aplikacje wystawione na świat zewnętrzny. Oczywiście musimy dbać o to, by kod nie był spghetti, ale przesadne używanie skomplikowanych wzorców „bo tak, bo umiem” jest totalnie bez sensu. Przy odrobinie szczęścia ktoś oprócz twórcy takiego frameworka będzie umiał się w nim poruszać, a jednak dobrze, żeby to zespół QA dobrze się w nim czuł. Miałem taką historię, framework przygotowany przez programistę, który chyba wziął sobie za punkt honoru stworzenie skomplikowanej aplikacji, a nie frameworka. Efekt? Przepisanie testów praktycznie od zera, bo praktycznie nikt nie umiał tego efektywnie używać. Wspomnieliście o bardzo istotnej kwestii. Sam u siebie w organizacji naciskam, żeby każdy automatyk używał SonarLinta, to daje bardzo dużo fajnych tipów, zwłaszcza dla początkujących, a jednocześnie zapewnia pewien porządek w kodzie. Jakby w ogóle do SonarQube’a podpiąć projekt to już w ogóle klasa - pomocne chociażby w wykrywaniu dużych bloków duplikacji kodu. Polecam każdemu. Co do znajomości zaawansowanych zagadnień programistycznych przez QA, to tak. Jestem fanem podejścia, by QA znał jak najwięcej wzorców, zasad programowania, narzędzi wspomagających programowanie, żeby lepiej ten kod rozumieć. Ale niekoniecznie jestem za tym, żeby to wszystko wprowadzać w automatyzacji testów. Trzeba dobierać odpowiednie strategie i narzędzia do konkretnych celów. Dlatego jeśli współpracujemy z developerami np. przy Pull Requestaxh fajnie jest z nimi najpierw porozmawiać i przedstawić właściwy cel testów, tak, by ich uwagi faktycznie były możliwie jak najbardziej pomocne (zamiast wywołujące WTF, ale po co mi to?). Czekam na kolejny odcinek.