Czy Tester Automatyzujący To Już PROGRAMISTA?
HTML-код
- Опубликовано: 5 мар 2023
- Blog Macieja: testerembyc.pl/
Kanał YT Macieja: / @testerembyc
Kursy i szkolenia:
👉 AkademiaQA.pl - kursy i szkolenia dla testerów
👉 TestowanieBackendu.pl - Naucz się testować REST API
👉 JavaDlaTestera.pl - Naucz się Javy i zacznij automatyzować testy
👉 SzkolaCucumbera.pl - Cucumber w testach REST API
Newsletter Testowa Środa
👉 TestowaSroda.pl - Ciekawe Linki Ze Świata Testów
Rekrutacja testera:
👉 RekrutacjaTestera.pl - Lista ponad 200 pytań rekrutacyjnych dla testerów
Social media:
👉 FB - akademiaqa.pl/facebook
👉 Instagram - akademiaqa.pl/instagram
👉 LinkeIn - akademiaqa.pl/linkedin 
Развлечения
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!
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ą.
Super odcinek :) Kiedyś myślałem nad tym właśnie tematem, a tu wszystko wyjaśnione :)
Podobało się.
Kiedy następny odcinek na wspomniany temat, tzn rekrutacje?
Niebawem :)
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ą.
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.
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.
Co do historii kiedy programiści tworzyli nieutrzymywalny przez testerów kod frameworki testów wspólnego,imnamy pod koniec odcinka.
Co do całej reszty zgadzam się z Tobą niemal w 100% natomiast przyczepię się do tego, że mówisz o ciut innym zagadnieniu, tzn. co powinien umieć tester automatyzujący, my natomiast zastanawiamy się czy tester automatyzujący (w domyśle każdy) jest programistą czy nie.
Jest jeszcze jedna rzecz, o której nikt z nas tutaj nie wspomina wprost, czyli utrzymywalność testów, bo "napisać" kod testów, a "Napisać" kod testów to są 2 różne rzeczy. W projektach, w których testerzy tworzą testy automatyczne dla 1 projektu, jakość kodu (wzorce, itp.) nie jest aż tak bardzo potrzebna. W projektach, w który testuje się kilka zbliżonych aplikacji (często o wspólnym kodzie tzw. core), gdzie testy są reużywalne, jakość kodu, wzorce itp. są niemal wymagane, bo bez nich szybkość tworzenia testów zaczyna spadać wykładniczo z każdym dodanym testem i produktem. To co powiedziałeś i o czym wspominamy, tester dostarcza inną wartość biznesowi i używa innych narzędzi.
PS. Kiedy kolejny odcinek u Ciebie? ;)
@@testerembyc Temat szeroki więc na dogrywkę z dodatkową perspektywą jak najbardziej zapraszam w dogodnym dla Was terminie :)
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