Tester manualny ---> tester automatyczny

0

Witam wszystkich

Potrzebuję pomocy odnośnie mojej dalszej kariery zawodowej. Jestem testerem oprogramowania od 4 lat i chciałbym w końcu zrobić krok w przód i przejść na automatyzację bo wiadomo, większe pieniądze, możliwość pracy zdalnej itd itd. Chodzi o to, że nie bardzo wiem jak się za to zabrać i potrzebuję Waszej pomocy. Możecie mi doradzić jaką ścieżkę obrać? Czy powinienem najpierw uczyć się narzędzi do automatyzacji, czy może język programowania? Jeżeli tak to jaki będzie najlepszy dla testera? Zaznaczam, że nie chce być programistą, a jedynie posiadać wiedzę na poziomie pisania skryptów do automatyzacji. Jestem zdeterminowany i mocno nastawiony na nauke także proszę o pomoc.

0

Zeby cokolwiek skumac i zeby jakkolwiek sensownie uzyc jakiejkolwiek biblioteki, frameworka itd trzeba znac sam jezyk.

Naucz sie najlepiej: Javy + Pythona ( a przynajmniej jednego na sensownym poziomie )
Jak skumasz o co chodzi z samym jezykiem to wtedy mozesz kombinowac dalej.

Widzialem kod testerow manualnych ktorzy po 5 czy 10 latach kariery zabrali sie za programowanie 'skryptow'. Robilem review tego po czym stalem sie wrogiem publicznym nr 1 w dziale testow. Walka z wiatrakami...
Do wiekszosci tych ludzi nie dociera "nic"....

  • Skrypt ktory mozna napisac zwiezle ciagnie sie ciurkiem 1000 liniii
  • zagniezdzen if-ow i elsow to nawet nie idzie policzyc
  • funkcje to oni widzieli w podrecznikach
  • komentarze gorsze niz u studentow
  • masa zakomentowanego kodu w losowych miejscach
  • i te wieczne dyskusje:
    "W tym kodzie nie wiadomo o co chodzi X,Y,Z jest do poprawki"
    "Ale ja wiem o co chodzi w tym kodzie"
    " Ale ktokolwiek inny do tego spojrzy to nic nie zrozumie"
    "To wtedy przyjdzie do mnie i ja mu wytlumacze"
  • "Ale ja nie jestem programista wiec nie musze tego wiedziec"
  • i wkolo swoja niewiedze i niechec do jej pozyskania tlumacza "Nie mialem czasu zeby to napisac dobrze"
    ...
0

Dlatego zależy mi na tym, żeby wszystko miało rece i nogi. Chce być dobrym testerem automatyzacji i nie robić niczego na odwal. Z tego co zauważyłem to najczęstszym językiem programowania, wymaganym przez pracodawcow jest Java, ale czy do pisania skryptów nie lepszy będzie Java Script? Czy, żeby zrozumieć java script musze najpierw zrozumieć Jave?
Reasumując, rozpocząć naukę w tej kolejności?

  • język programowania
  • nauka narzędzi typu selenium ide, selenium webdriver, soapUI itd itd
0

Nie Java Script nie jest Ci potrzebny do tego zeby pisac w Javie. Java Script nie ma nic wspolnego z pisaniem skryptow.
Skrypty mozesz pisac w bash, Perlu, i Pythonie ( polecam Python).
Daj sobie spokoj z Javascriptem w tym momencie.

Skoncentruj sie na jednym i np: ucz sie Javy. Jak juz ogarniesz conieco Jave to wroc za 2 lata i sie pomysli co dalej...

0

A jak wrócisz za 2 (słownie: dwa) lata z tą magiczną wiedzą, Dolbo przygotuje Ci test. Wyruszysz pokonać smoka. Wtedy będziesz godzien dostać następny strzępek tajemnej wiedzy programowania. Mając lat 50, pokonawszy zastępy mrocznych bestii dostapisz zaszczytu zostania stazystom. Pozdro, nie zniechęcaj się takim straszeniem ;)

0

Jesli kolega nie umie w ogole programowac, to jak Dolbo uwazam, ze troche mu to zajac, zeby to robic na sensownym poziomie. To troche jak z jezykiem obcym - dasz rade nauczyc sie slabo rozmawiac w kilka miesiecy, ale zeby pojechac za granice i tam zyc, to taki poziom jezykowy nie bedzie praktycznie zadnym ulatwieniem.

Jesli OP bedzie sie uczyl w mocnym tempie, to nie beda to dwa lata. Tak samo moze znalezc prace slabo programujac, tylko wlasnie potem ktos bedzie musial sie meczyc ze slabym kodem plus OP sam raczej nie bedzie sie czul komfortowo. Chyba, ze trafi do projektu, gdzie wystarczy ctrl+c, ctrl+v z innych testow. Najlepszy chyba jest balans - w miare dobrze pojac skladnie, umiec sprawnie operowac na dostepnych typach danych, paradygmaty(a przynajmniej oop), dobre praktyki, zrobic kilka projektow do szuflady. Potem sie zabrac za toole do testerki. Zalezy od ilosci poswiecanego czasu i tego jakie beda postepy - moze to zajac 8 miesiecy, a moze i 8 lat.

0

W mojej opinii zeby orientowac sie w programowania w czystym jezyku od zera na przyzwoitym poziomie ( NIE zeby znalezc jakas prace bo to jest mozliwe po paru miesiacach) to trzeba poswiecic temu 2 lata.

Poza tym powiedzmy ze wiem o co pytaja w Akamai i Ocado na stanowiska "Software Engineer in Test" i mysle ze 5 czy 6 miesiecy nauki "po pracy" to zdecydowanie za malo zeby tam sie dostac biorac pod uwage ze zaczyna sie od "0".

0
DolBo napisał(a):

Poza tym powiedzmy ze wiem o co pytaja w Akamai i Ocado na stanowiska "Software Engineer in Test" i mysle ze 5 czy 6 miesiecy nauki "po pracy" to zdecydowanie za malo zeby tam sie dostac biorac pod uwage ze zaczyna sie od "0".

Jakiś przykład mógłbyś podać o co pytają?

0

Mimo iż jestem developerem, zajmowałem się dużo tematyką testów (zarówno manualnych, jak i automatycznych - w tym projektowanie i rozwój środowisk do testów E2E). Jeżeli interesuje Cię automatyzacja, to zakładam że chcesz celować właśnie w automatyzację testów integracyjnych lub E2E, ponieważ testy jednostkowe powinni tworzyć developerzy jako część swej normalnej pracy. Potwierdzam wnioski płynące z tego, co napisał @DolBo - jeśli chcesz być dobrym testerem automatycznym, powinieneś tak naprawdę zainwestować w to, aby poznać na rozsądnym poziomie fach developera - tak, jak ja musiałem poznać fach testera również od strony "manualnej", żeby móc robić to, co robiłem :).

Problem polega na tym, że środowisko testów automatycznych to tak naprawdę normalny projekt programistyczny, nieróżniący się niczym od tworzenia normalnych aplikacji. Te same zasady związane z jakością kodu, designem itd., które obowiązują w programowaniu, obowiązują również przy tworzeniu testów automatycznych (o samym środowisku nie wspominając). Aby je umiejętnie stosować, trzeba niestety mieć jakąś praktykę programistyczną, z kolei ich brak sprawia, że koszty utrzymania rosnącego zestawu testów mogą przewyższyć zyski z automatyzacji. Ponadto, im cięższy rodzaj testów, które trzeba zautomatyzować, tym większe wyzwania stoją przed frameworkiem testowym - chodzi tutaj o dostarczenie takich narzędzi, aby jak najefektywniej wykorzystać zasoby czy jak sprawić by pierwszy lepszy fail nie wysypał całego środowiska. Wprawdzie niekoniecznie sam tester powinien takie narzędzia czy framework tworzyć, ale na pewno będzie musiał umieć z tych narzędzi skorzystać.

Jako przykład mogę podać, jak ja się wkręciłem w temat - gdy zaczynałem, istniało sobie kilkaset testów automatycznych i framework do ich uruchamiania. Testy były pisane w autorskim DSL-u, na który wszyscy narzekali ze względu na rozwlekłość (pojedyncza komenda potrafiła zajmować cały ekran tekstu), brak instrukcji sterowania, a także na jakość kodu (spaghetti) samych komend i ograniczoną liczbę konfiguracji, jakie w praktyce można było testować. Problemem było też odpalanie frameworka - dużo plików konfiguracyjnych, brak dokumentacji itd. Rozkminienie całości tak, aby to jako tako hulało i by wykonanie testów docierało do końca, zajęło mi kilka miesięcy (!). Po tym czasie wprowadziliśmy normalny reżim developerski przy tworzeniu testów - review kodu, standardy kodowania, rozplątywanie makaronu. Po pewnym czasie, gdy już mieliśmy doświadczenie, wiedzieliśmy i wiedzieliśmy, czego potrzebujemy, zbudowaliśmy środowisko od nowa. Od początku zaaplikowaliśmy dobre praktyki do testów, projektując wygodne API do ich tworzenia itd. Efekt był taki, że po kilku latach developerzy sami chętnie siadali, aby pisać sobie testy E2E do tego, co właśnie implementowali, albo używali środowiska do puszczania sobie wybranych testów z biurka podczas developmentu (!). I to jest właśnie cel automatyzacji - potwarzalność, stabilność i zaufanie, że jak test mówi PASS, to znaczy, że faktycznie to ma szansę zadziałać.

Jeśli chodzi o sam język programowania, to to zależy od projektu. W powyższym przypadku była to Java ze względu na kompatybilność z technologiami używanymi w projekcie. Dlatego tym bardziej przyda się praktyka developerska - jeśli wiesz, o co w tym chodzi, względnie łatwo douczysz się odpowiedniego języka, gdyby zaszła taka potrzeba.

0

Ja bym Od razu poszedł w development. W ciągu ostatnich 2 lat do środowiska testerów napłynęło tylu debili, że teraz każdy jak słyszy, że piszesz testy, to zakłada, że jesteś jednym z nich. Niemały w tym udział ma największa grupa facebookowa na ten temat, gdzie administrator promuje niewiedzę i głupotę, promując wszędzie gdzie się da swój poradnik o zostawaniu testerem. Dodatkowo, ponieważ miernoty próbują ukryć swoją słabość, to uczą się zadawać bezsensowne pytania - ale ważne, żeby było ich dużo, wtedy PM myśli, że niby ogarniają temat. Ja przeszedłem do testowania z administracji sieciami i jestem w gronie może 10% testerów, które ma jakąś wiedzę techniczną, reszta to klikacze, przez pryzmat których potem postrzegają Ciebie. Jest to wkurzające, jak na przykład testujesz oprogramowanie inteligentnych budnyków i piszesz automat robiący zdjęcia a potem podpinasz rozpoznawanie obrazów, żeby wiedzieć, czy zachowanie jest poprawne, a od znajomych ze studiów potem słyszysz, że testy muszą być nudne, skoro co druga pani z HR to teraz chce robić. Osobiście szlifuję Pythona i uciekam w stronę analizy danych jak będzie okazja.

1 użytkowników online, w tym zalogowanych: 0, gości: 1