Tester systemów IT - pytanie/~ogłoszenie

Na wstępie zaznaczę jeszcze raz, że nie jest to ogłoszenie o możliwości podjęcia wymienionej w temacie pracy! A o co chodzi?

Otóż znalazłem w necie ogłoszenie o naborze na stanowisko testera systemów IT właśnie i zastanawiam się co to za praca, czy pozwala poszerzać swoją wiedzę czy to tylko bierne wykonywanie testów (przez bierne rozumiem coś, co po kilku dniach można robić z zamkniętymi oczami i wyłączonym mózgiem:P)? Może ktoś ma doświadczenie na takim stanowisku, albo u kogoś w firmie jest dział zajmujący się właśnie testowaniem oprogramowania i zechce podzielić się swoją wiedzą? Zarobki też oczywiście mnie interesują :)

Zakres obowiązków jest taki:

• tworzenie i rozwój planów testów
• tworzenie przypadków testowych, analiza wyników testów
• wykonywanie testów, badanie poprawności w stosunku do wymagań
  funkcjonalnych
• asystowanie w procesie wdrażania zmian do eksploatacji
• zarządzanie cyklem życia błędu w testowanych aplikacjach
• koordynacja i monitoring pracy testerów
• przygotowywanie raportów z wynikami testowania
• współpraca z administratorami systemów przy rozwoju środowiska
  testowego
• udział w pracach rozwojowych realizowanych w ramach zadań działu

Nie chcę kolejnej pracy, która ładnie wygląda tylko na ogłoszeniu, a w rzeczywistości nie wymaga żadnych zdolności, z którą średniorozgarnięta osoba po podstawówce dałaby sobie radę.
Może jeszcze kilka słów o mnie: w tym roku skończyłem matmę, w czasie studiów należałem do koła naukowego informatyków, gdzie bawiliśmy się trochę w różnych językach programowania. Zaraz po studiach chciałem rozpocząć podyplomówkę z programowania (wiadomo, że zawsze lepiej jak ma się jakiś papierek poświadczający umiejętności), ale nie otworzyli kierunku :-/ Programowanie to jest to, co chciałbym robić, ale na razie jeszcze nie czuję się na siłach i zastanawiam się czy ta praca będzie pomocna w osiągnięciu zamierzonych celów.

Programowanie to jest to, co chciałbym robić, ale na razie jeszcze nie czuję się na siłach i zastanawiam się czy ta praca będzie pomocna w osiągnięciu zamierzonych celów.
Będzie przydatna ale tylko w tym względzie, że będziesz pracować w sektorze IT i/lub zdobędziesz wiedzę na temat inżynierii oprogramowania. Najprawdopodobniej będziesz tylko uruchamiał program, wprowadzał dane testowe i sprawdzał czy zwraca prawidłowy wynik. Poza tym będziesz kontaktował się z klientem, uszczegóławiał specyfikację i produkował tony papierów z wynikami testów oraz wnioskami o zmianę w programie, zgłoszeniami błędów dla programistów.

To na ile taka praca pozwoli Ci się rozwinąć zależy głównie od Twojego przyszłego pracodawcy i/lub kierownika. Jeżeli ktoś dostrzeże Twój potencjał i pozwoli Ci robić coś bardziej ambitnego to możliwe, że będziesz robił takie rzeczy jak:

• pisanie raportów (możesz przy tym nauczyć się SQL i zdobyć trochę wiedzy z zakresu obsługi baz danych)
• migracja danych (możesz przy tym nieco rozwinąć umiejętności z zakresu programowania oraz baz danych)

Niestety z tego przytoczonego przez Ciebie ogłoszenia wynika, że raczej nie będziesz miał zbyt ambitnych obowiązków i prawdopodobnie będziesz tylko produkował papiery i zaznajomisz się z tym jak wygląda proces tworzenia oprogramowania (inżynieria oprogramowania).

Osobiście radzę Ci poszukać ogłoszeń gdzie firmy szukają początkujących programistów, studentów chętnych do przyuczenia. Niestety nie oferują przy tym zbyt wielkiej kasy (oczywiście nie zgadzaj się na praktyki albo pracę za darmo, pensja musi być normalna) ale przynajmniej dają możliwość zdobycia doświadczenia.

Wiesz... generalnie testy to nie klikanie bezmyslnie gdzie popadnie i stwierdzenie, ze program sie wykrzacza.

Trudno powiedziec jak to wyglada w tym wypadku, ale z mojego doswiadczenia jako programisty testowanie zwykle opiera sie o:

• przygotowanie srodowiska testowego: np. maszyna wirtualna z xp z sp2, bez sp, z .netem, bez .netu, z przegladarkami, itp. Generalnie srodowisko, ktore pozwala sprawdzic wszystkie sytuacje, gdzie moze wystapic blad, np. brak odpowiednich latek systemu przy instalacji, itp. Srodowiskiem moze byc tez inny program, w ktorym odpalamy nasz i automatyzujemy wywolanie konkretnych funkcji.
• przetestowanie doglebnie czy program robi to co powinien - to o tyle latwe co pracochlonne, bo trzeba sprawdzic kazda mozliwa funkcje
• przetestowanie sytuacji ekstremalnych - brak miejsca na dysku, brak uprawnien do zasobow, generalnie przewidzenie sytuacji typu: 'u mnie dziala, a u kolegi sie wysypuje'
• najwazniejsze - jezeli 'zespol programistyczny' to nie Ty - przekazanie dokladnych informacji zespolowi co wywala, w jakiej sytuacji, w jakich warunkach, co wypisuje, kiedy, itp. Po to sie robi testy, zeby programista pozniej mogl napisac poprawke.

Tyle z mojego doswiadczenia pisania unit testow wlasnego oprogramowania, moze wypowie sie jakis typowy tester.

Opis powyzej wyglada w miare sensownie, choc oczywiscie rozne piekne ogloszenia widzialem i nie opis swiadczy o samej pracy ;)

Testy... zajęcie dla cwaniaków, którzy poza dużą wiedzą z zakresu technologii którą testują, muszą mieć bardzo dużo weny twórczej i pomysłów. Dobre przygotowanie testów jest dość trudne i trzeba naprawdę myśleć. Testy to kontrola jakości. Słabi przygotowane testy spowodują, że produkt końcowy będzie marny.

Powiem Ci, ze nuda wieje taka praca. Nie warto IMO.

AdamPL napisał(a)

Osobiście radzę Ci poszukać ogłoszeń gdzie firmy szukają początkujących programistów, studentów chętnych do przyuczenia. Niestety nie oferują przy tym zbyt wielkiej kasy...

I to jest właśnie to, że szukam pracy poza miejscem swojego zamieszkania, muszę mieć za co się utrzymać, więc to odpada.

Dzięki za opinie! Jeszcze nad tym pomyślę, poza tym pójście na rozmowę kwalifikacyjną nie zobowiązuje do podjęcia pracy (jeżeli mi to zaproponują ;-) ), a przynajmniej dowiem się na czym to dokładnie polega.

johny_bravo napisał(a)

...moze wypowie sie jakis typowy tester.

Cały czas na to liczę.

Praca testera moze byc dwojaka:

• albo rzeczywiscie bardzo nudna ;(
• albo o wiele, wiele ciekawsza niz praca programisty. Do tego wymagajaca duzej wiedzy z wielu roznych dzialek.

Wszystko to zalezy od projektu.

Osobiscie pracowalem kiedys zarowno jako programista i jako tester i moge powiedziec tyle ze zdecydowanie wole byc testerem ;) Praca o wiele ciekawsza i bardziej urozmaicona. Mi w duzej mierze kojarzy sie z czyms w rodzaju hackingu ;) Uwierz mi trzeba miec naprawde glowe na karku zeby byc dobrym testerem. Z drugiej strony rownie dobrze mozesz trafic do do projektu w ktorym sie zanudzisz na smierc i niczego nie nauczysz.....

Nie wiem czy to prawda na 100% ale slyszalem ze podobno w MS zeby zostac testerem trzeba byc przez iles tam lat wczesniej programista najpierw.

tester napisał(a)

Nie wiem czy to prawda na 100% ale slyszalem ze podobno w MS zeby zostac testerem trzeba byc przez iles tam lat wczesniej programista najpierw.

No to wiadomo, ze sie przydaje, bo w koncu duzo latwiej przewidziec jakie bledy programisci mogli popelnic. Z drugiej strony czasem przydatne jest podejscie pani z biura, ktora nie wie gdzie kliknac...

Pracowalem kiedys jako tester. Wytrzymalem pare dni :]
Generalnie moja robota polegala na tym, aby sprawdzic, czy program jest idiotoodporny. Jezeli w formularzu masz miejsce na jakis tekst, probujesz wpisac liczbe i sprawdzasz, czy sie program nie wysypie.

Generalnie to byla 1 faza testow. Dalej mialo byc juz glebsze testowanie, wlacznie z zapytaniami SQL do Oracla. Ale nie dotrwalem ;)

Ja się zgadzam z johnym, żaden tester nie wypróbuje programu lepiej jak sto pań z biur, które klikają gdzie popadnie.

@mephir: i tak i nie. Pani z biura nie wpadnie na przyklad na pomysl sql injection. Z kolei programista nie wpadnie na pomysl instalowania programu na wylaczonym kompie :P Dlatego tester powinien byc kreatywny i imitowac rozne rodzaje indywiduum siedzacego przed monitorem :) W polowie przypadkow i tak chodzi o typowe bledy braku dostepu do zasobow, gdzie program powinien zachowac sie elegancko, a nie poleciec wyjatkiem na leb na szyje.

johny_bravo napisał(a)

@mephir: i tak i nie. Pani z biura nie wpadnie na przyklad na pomysl sql injection.

: ) Pani z biura robi tylko smietanka injection i nie do formularza na stronce tylko do kawy : )

A co do testerów. Robiłem przez jakiś czas w sporej firmie, gdzie było kilku testerów. Niby panowało przekonanie, że to onie ponoszą największą odpowiedzialność. Niby jak się coś wywali, to wina testera ze tego nie przewidział a nie programisty. W praktyce wydawało mi się jednak zupełnie odwrotnie.

Generalnie też jestem zdania że to nudne zajęcie. Ale zawsze się człowiek czegoś nauczy (każda praca czegoś uczy). Można zawsze coś kogoś podpytać (bo gdzie testerzy tam i programiści) a po pół roku wybrać inną pracę.

Jeszcze co do tej odpowiedzialności, właściwie to jest pewna stresogenna tendencja w zawodzie testera, mianowicie, często oni mają w łapach aplikację poraz ostatni przed wypuszczeniem do klienta, i często od terminu zakończenia testów zależy kiedy aplikacja do klienta wyjdzie. A jak wiadomo, w wielu firmach jest z terminami jak jest, toteż często pytania przełożonych "KIEDY ?!" trafiają właśnie do testerów : )

Ja miałem praktyki jako tester w MS. Nudna robota. Pisanie scenariuszy testowych. Potem klikanie wg. nich. Nie polecam.

DzieX napisał(a)

Ja miałem praktyki jako tester w MS. Nudna robota. Pisanie scenariuszy testowych. Potem klikanie wg. nich. Nie polecam.

Pracuje jako tester juz ladny kawal czasu - pracowalem w tym charakterze w Polsce i poza jej granicami.

Jako tester mozesz pisac niewiele mniej niz programista - glownie w jezykach skryptowych lub z uzyciem specjalnych narzedzi.

Czy ktos w Was slyszal o testach automatycznych? Umozliwiaja one jak nazwa wskazuje automatyczne testowanie aplikacji symulujac dzialanie uzytkownika. Testy manualne ktore trwalyby kilkanascie dni da sie przeprowadzic w kilka godzin - bez wiekszego lub zadnego udzialu z Twojej strony jako testera. Jako tester w roznych firmach mialem juz okazje pisac w co najmniej kilku jezykach programowania + uzywac wielu innych ciekawych narzedzi (darmowych i komercyjnych) + pracowac na wielu roznych systemach operacyjnych.

Czy zastanwialiscie sie kiedys jak bedzie dzialac Wasz aplikacja kiedy bedzie jej uzywac 10000 uzytkownikow w tej samej chwili? O tym takze mozna sie przekonac samemu piszac odpowiedn skrypt.

Dlugo by wymieniac. To tylko mala czastka tego co mozna robic.

Jesli zorganizujesz sobie prace w odpowiedni sposob i zautomatyzujesz testy - praca moze byc ciekawa. Ale to juz zalezy w duzej mierze od tego jak sobie zorganizujesz prace.

Podejrzewam ze nie widziales w MS nawet ulamka tego co robi sie w testach z powodu bycia tam tylko na praktykach.

Hehe, wiem o testach obciążeniowych. Widziałem narzędzia do automatyzacji procesów. Wiem też jak skończył się projekt ITCore... Szczerze, coraz mniej kręci mnie pisanie czegokolwiek, w szczególności skryptów w "ichnich" językach. Na szczęście nie muszę już szukać pracy.

DzieX napisał(a)

Hehe, wiem o testach obciążeniowych. Widziałem narzędzia do automatyzacji procesów. Wiem też jak skończył się projekt ITCore... Szczerze, coraz mniej kręci mnie pisanie czegokolwiek, w szczególności skryptów w "ichnich" językach. Na szczęście nie muszę już szukać pracy.

Hej, w zupelnosci Cie rozumiem - ja tez mimo wszystko lubie sobie popisac tez cos jako developer prywatnie sam dla siebie ;), jednakze oficialnie wole pracowac jako tester.

pozdrawiam

DzieX napisał(a)

Hehe, wiem o testach obciążeniowych. Widziałem narzędzia do automatyzacji procesów. Wiem też jak skończył się projekt ITCore... Szczerze, coraz mniej kręci mnie pisanie czegokolwiek, w szczególności skryptów w "ichnich" językach. Na szczęście nie muszę już szukać pracy.

"Ichnie" języki skryptowe to VBS jak się domyślam? W VBS to chyba tylko u nich jacyś maniacy piszą, takie to okropne (a na serio - ja nie lubię osobiście, ale wiem jakie daje możliwości skryptowanie w VBS i pod Windows jest jedną z kilku genialnych metod automatyzacji).

W przypadku pracy w firmie stosującej metodologię XP (extreme programming) /Test-driven development (są takie w Polsce? bo na świecie to słyszałem) programiści sobie piszą metody/funkcje, a testerzy im to sprawdzają przez unit testy (gdzie często tester i programista to ta sama osoba ;-))

PS. Z fajniejszych narzędzi testowych to na przykład powiem, ze dla Windows Mobile jest program, który symuluje losowe niesamowicie szybkie kliknięcia (stuknięcia) rysikiem po ekranie, by sprawdzić czy program się nie zawiesi jak mu się za dużo poklika po interfejsie ;-)

PPS. O ITCore to nie warto wspominać ;-)

W przypadku pracy w firmie stosującej metodologię XP (extreme programming) /Test-driven development (są takie w Polsce? bo na świecie to słyszałem)

Tak - ja pracuje w takiej firmie ;-) Praca ogólnie polega na wytwarzaniu oprogramowania, ale przed napisaniem właściwego kodu aplikacji tworzy się testy jednostkowe (unit test .NET NUnit + Mock). Na podstawie podanej funkcjonalności pisze się funkcje / klasy itd. (nie tylko .NET - również ASP.NET client-side czyli JavaScript). Oczywiście nie zawsze tak jest - ale wtedy, gdy kod będzie wykorzystywany wielokrotnie i modyfikowany przez wielu programistów (SVN(kontrola wersji + gałęzie) połączony z CC.NET (kontrola integracji) + build machine (kontrola poprawności kodu)) .

Po wykonaniu commit / merge build machine kompiluje cały projekt - pokazuje błędy, ostrzeżenia, ale co najlepsze - wykonuje testy jednostkowe (Assert()), pokazuje status (pass / fail). Dzięki temu realnie da się utrzymać funkcjonalność dużego projektu gdzie pliki są modyfikowane przez 50-ciu programistów. Gdyby funkcjonalność się zmieniła - zmienia się testy. A wszystko po to, żeby ktoś przez przypadek nie popsuł niczego.

Standardowo wygląda to tak:

task --> unit test + development --> done --> verified

gdzie kolor zielony to programista, a kolor czerwony - tester.

Testerzy jednak rzeczywiście nie mają ciekawego zajęcia. Robią oczywiście testy automatyczne (głównie Ruby scripts, automatyczne " klikacze " + wykrywanie błędów w kodzie i w HTMLu, automatyzacje procesów instalacji / deployów itd.). Niestety nie obywa się bez głupiego klikania (tzw. monkey test).

@Ktos
No nie koniecznie mi chodziło o VB tylko o języki które są tworzone na potrzeby tych narzędzi, nie koniecznie MSowych.

Ktos napisał(a)

W przypadku pracy w firmie stosującej metodologię XP (extreme programming) /Test-driven development (są takie w Polsce? bo na świecie to słyszałem) programiści sobie piszą metody/funkcje, a testerzy im to sprawdzają przez unit testy (gdzie często tester i programista to ta sama osoba ;-))

Są i to całkiem dużo. Nie tylko filie zachodnich korporacji, ale też nasze rodzime firmy. Z własnej działki powiem, że obecnie zamówienia publiczne na dedykowany soft są realizowane w lekko zmodyfikowanej metodyce TDD. Modyfikacje wynikają zazwyczaj ze specyfiki pracy firma - jednostka administracji publicznej. Administracja określa funkcjonalności i interfejs oraz struktury danych w xsl, następnie firma tworzy interfejs po czym zaczyna implementację, a administracja tworzenie testów.

Co do języków skryptowych to dość dużo zależy od tego co dokładnie chcemy testować. VBS to chyba tylko mały fragment. Dość dużo testów robi się np. JUnitem (jednostkowe, ale nie tylko), czy też JMeterem (Obciążeniowe), względnie narzędziami dedykowanymi dla danej technologii. Wile pisze się też w bashu, groovy, perlu

johny_bravo napisał:
@mephir: i tak i nie. Pani z biura nie wpadnie na przyklad na pomysl sql injection.

: ) Pani z biura robi tylko smietanka injection i nie do formularza na stronce tylko do kawy : )

Oj byście się zdziwili co potrafią takie panie zrobić z oprogramowaniem, ale jest tu dużo racji. Z jednej strony tester musi być taką panią Jadzią/Krysią/Wandą z drugiej musi też wcielić się w rolę narwanego "masta chakier" z gimnazjum. Dużo też zależy od doświadczenia i praktyki oraz "repozytorium" przypadków testowych.

Zetknąłem się też ze stwierdzeniem, że dobry tester jest znacznie więcej warty niż programista. Wynika to z faktu, że testy "wymagają talentu w psuciu".

Witam
Od grudnia pracuje jako tester. Bardzo ciekawa praca dla ludzi kreatywnych. Absolutnie jestem przeciwny temu, ze jest to nudne zajecie. Moze byc takie dla ludzi malo kreatywnych.
Posiadam w sumie małe doświadczenie. Poki co pisze plany testow, wymyslam zawiłe przypadki testowe, napsalem ostatnio test akceptacyjny do testowanej aplikacji. Teraz bede automatyzowal testy. Zawsze staram sie rozwijac. Polecam dla ludzi cierpliwych oraz skrupulatnych.
Pozdrawiam

OmenTester napisał(a)

Polecam dla ludzi cierpliwych oraz skrupulatnych.

Wydaje mi się, że przede wszystkim upierdliwych do bólu :-P

Wydaje mi się, że przede wszystkim upierdliwych do bólu :-P

a upierdliwość, to podstawa :) często właśnie przez tą ceche, tester może być znienawidzony przez informatyka. U mnie w firmie, póki co, jest ok :)

Pozdro