Koniec pierwszego etapu

Zakończył się okres próbny w mojej pierwszej pracy w IT. Przygotowałam sobie podsumowanie, spostrzeżenia, pomysły, które przedstawiłam swojemu przełożonemu na spotkaniu na koniec okresu próbnego. Są na tyle neutralne i, mam nadzieję, obiektywne, że mogę się nimi podzielić.

Pierwsze dwa tygodnie pracy jako tester były wprowadzeniem do projektu, w którym miałam pracować. Wiedza, którą mi wtedy przekazywano była dobrze usystematyzowana i przedstawiona. Pojęcia i zagadnienia stopniowo stawały się bardziej skomplikowane, ale pomagało to, że po każdym większym fragmencie teorii byłam proszona o przedstawienie własnej interpretacji tego, co zrozumiałam. Był to czas, kiedy wszelkie niejasności mogły zostać rozwiane, a źle pojęte części wyjaśnione jeszcze raz. Dostawałam małe zadania do zrobienia na podstawie przedstawionego materiału, te zadania były sprawdzane i korygowane przez osobę wdrażającą. Bardzo pomocne było też to, że mogłam uczyć się i wykonywać zadania z drugą osoba, zatrudnioną w tym samym czasie co ja. Fajnie się wspieraliśmy i pomagaliśmy sobie.

Trzeci tydzień pracy musiałam spędzić z chorym dzieckiem w domu, a w czwartym wróciłam do firmy akurat, kiedy zespół miał przeprowadzić test run na jednym z urządzeń. Miałam krótkie, bardzo lakoniczne wprowadzenie do tego, co będzie wykonywane w test runie, ale bez przedstawienia szczegółów jego procedury. W założeniu, miałam dobrą okazję, żeby poznać od wewnątrz tego typu zadanie obserwując doświadczonych członków zespołu. W rzeczywistości dowiedziałam się o test runie niewiele, gdyż osoby przygotowujące środowisko testowe nie opowiadały o tym, co robią.
Po tym doświadczeniu zgłosiłam swojemu przełożonemu pierwsze obawy dotyczące dopasowania do zespołu. Podzieliłam się też z nim trudnościami w pozyskiwaniu wiedzy i dobrych praktyk od zespołu. Niestety, mimo, że miałam w teorii nie krępować się i pytać kogokolwiek z zespołu i prosić o pomoc, czułam, że wszystkim przeszkadzam i wytrącam ich z biegu ich własnych zadań. Może gdybym na tym etapie zamiast do wszystkich mogła zgłaszać się do jednej przypisanej osoby, która miałaby wyznaczone w systemie kontowania czasu pracy zadanie mentoringu, ten etap wdrożenia byłby dla mnie bardziej efektywny.

Drugi miesiąc pracy polegał na wybieraniu kolejnych funkcjonalności do testowania i tworzeniu do nich automatycznych testów w ramach stworzonego we frameworku pytest zestawu metod. Nie musiałam wymyślać na nowo koła, tylko składać klocki z różnych dostępnych już rozwiązań. Znowu zabrakło jednak mentora, który pokazałby mi, gdzie najefektywniej szukać najlepszych dla sprawdzenia przypisanej mi funkcjonalności pomysłów. Dużo czasu zajmowało mi szukanie w wielu zestawach testów, czegoś, co mogłoby zadziałać w moich założeniach testowania. Informacją zwrotną do mojego pierwszego zestawu testów był przegląd - code review. Wszelkie błędy i niejasności w utworzonym przeze mnie skrypcie opisane zostały w komentarzach pod linijkami kodu, które owe niedociągnięcia zawierały. Zabrakło mi przejścia przez pierwsze review ramię w ramię z osobą przeglądającą moje rozwiązania. Wydaje mi się, że bardziej efektywne byłoby poświęcenie mi dwóch godzin na informację zwrotną  przy moim biurku o tym, co zrobiłam źle lub co można by zrobić lepiej, niż czytanie suchych komentarzy i osobne proszenie o wyjaśnienie części z nich.


Po tych dwóch miesiącach pracy najbardziej zapadły mi w pamięć komentarze typu "Lepiej by było, żebyś sama do tego doszła", "I tak miałaś bardzo dużo wprowadzenia, my tyle za naszych początków nie dostaliśmy", "Sprawdź w logach dlaczego test nie przeszedł", czy "To ty jesteś testerem i powinnaś wiedzieć, jak najlepiej przeprowadzić to sprawdzenie". Były dni, kiedy bywało lepiej i byli ludzie, którzy prawie zawsze chętnie mi pomagali, ale miałam wrażenie, że zajmuję im za dużo czasu, podczas gdy oni i tak mają bardzo dużo zadań do wykonania. Skupienie na wykonywaniu swoich zadań było bardzo duże i zrozumiałe, zabrakło jednak procesu wspierającego nowego pracownika.

W trzecim miesiącu pracy zgłosiłam się na ochotnika do wzięcia udziału w kolejnym test runie. Liczyłam na to, że tym razem, jako osoba pierwszy raz w nim uczestnicząca, a nie tylko obserwująca, będę mogła się nauczyć na czym ten proces polega. Niestety, znowu raczej odniosłam wrażenie, że oczekiwane ode mnie jest wiedzieć, jak wykonać test run, ponieważ na stronach portalu zespołowego była instrukcja, jak go przeprowadzić. Dla mnie ta instrukcja wyglądała jednak jak niejasny i mający wiele dodatkowych niezapisanych reguł plan. Tłumaczenie, że ktoś najlepiej uczy się poprzez przejście przez takie trudne zadania sam nie było dla mnie bardzo budujące. Żeby skutecznie wykonać tak skomplikowane zadanie samemu, trzeba mieć jakieś zaplecze techniczne i doświadczenie z podobnych procesów, którego mi brakowało. Nie wystarczy dać komuś słownik języka angielskiego, żeby móc oczekiwać, że napisze poprawnie książkę po angielsku. Jako były nauczyciel wolę uczyć na przykładzie i sama też wolę przez dobry przykład być uczona. Nie można przecież będąc instruktorem pływania kazać osobie nie umiejącej pływać wskoczyć do basenu i poprosić, żeby zawołała, kiedy będzie się topić. Nie można też mieć jej za złe, że woła, że się topi od razu po wskoczeniu do głębokiej wody.

Doświadczenia tego trzeciego miesiąca ugruntowały mnie w przekonaniu, że nie mogę przedłużać umowy.  Mimo, że menadżer, który mnie przepytywał na rozmowie o pracę i zatrudnił, wiedział, że nie mam żadnego doświadczenia w testowaniu, miałam prawie codziennie wrażenie, że nie pasuję do zespołu i nie mam szans na dorównanie mu poziomem wiedzy technicznej i doświadczenia. Wydaje mi się, że zespołowi tez byłoby łatwiej, gdyby zamiast mnie zatrudniony został ktoś z większym doświadczeniem.

Nauczyłam się dużo przez trzy miesiące. Zobaczyłam, jak działa pycharm, bitbucket, JIRA, pytest. Nauczyłam się, czym jest parametryzacja w testach, jak można przeprowadzić asercję, jak wprowadzać do zestawu testów metody statyczne. Oprócz tego przekonałam się, jak pracuje się w scrumie, jak uczestniczy się w daily meeting, jak planuje się i estymuje zadania. No i przekonałam się, że nawet najtrudniejsze zagadnienia techniczne jestem w stanie do jakiegoś poziomu zrozumieć. Może nie w całości, ale na tyle, żeby sprawdzić wiele z podstawowych założeń ich działania.

Zabrakło programu mentoringu oraz procesu, który by go wspierał od strony organizacyjno-formalnej.  Z przykrością podjęłam decyzję, że bez tego procesu nie będę w stanie dorównać członkom mojego zespołu i być dla niego wsparciem, więc zrezygnowałam z dalszej współpracy z moim pierwszym pracodawcą w świecie IT. Warto więc przekwalifikowując się mieć na uwadze, że w pierwszym miejscu pracy może nie udać się pracować tak, jak się marzyło wkraczając do branży IT.  Ważne, żeby potrafić dostrzec to, czego udało się nauczyć i szukać dla siebie miejsca, w którym możemy wzrastać.

Dwa tygodnie po zakończeniu pierwszego etatu na stanowisku testera spędziłam w domu douczając się. Powtórzyłam sobie wiedzę z "Zawód Tester" Radosława Smiglina, zapisałam się na tutorial testowania na guru99.com i zarejestrowałam się do portalu zrzeszającego zdalnych testerów z całego świata uTest.com. Uzupełniłam CV i rozsyłałam je do nowych firm. W przyszłym tygodniu najprawdopodobniej zacznę swoją przygodę z testowaniem od początku w nowym miejscu. Nauczona doświadczeniem z poprzedniej pracy, podchodzę do tego z większą dozą dystansu i ostrożności, ale może nauczę się czegoś od podstaw, bo tym razem zacznę od testów raczej manualnych. Mam nadzieję, że to będzie dla mnie skokiem na mniej głęboką wodę i poradzę sobie lepiej. A jeśli nie, to są jeszcze kolejne miejsca i możliwości.

Pierwsze koty za płoty

Dobre miejsce

Zaczęłam pracować! W IT! Doceniam uroki flexi-time'u, czyli mogę przyjechać do biura około 7:00, żeby po pracy spokojnie odebrać dzieciaki ze szkoły i przedszkola. Albo zaprowadzić je tam rano, żeby dotrzeć do pracy przed 9:00. Raz w tygodniu przywożą nam świeże owoce, mam nieograniczony dostęp do wody mineralnej, dobrej kawy i wielu rodzajów herbat (nawet sypanych;). Firma dofinansowuje mi też obiady w dwóch lokalnych barach.

Trudne początki

A sama praca jest trudna. Trudna merytorycznie, bo mimo, że wiem, jak wygląda Python, to mój zespół używa do testów framework'u pytest, którego dopiero teraz się uczę. Pracuję z oprogramowaniem osadzonym (embedded), dokładniej z komunikacją między oprogramowaniem pralek/suszarek do bielizny a aplikacją umożliwiającą sterowanie tymi urządzeniami zdalnie. Dużym wyzwaniem jest dla mnie zrozumienie na jakiej zasadzie pralka i tablet komunikują się z routerem wifi i ze sobą nawzajem. Staram się ogarnąć, jakie informacje przekazują sobie te urządzenia, jakim protokołem, co jest przechowywane na serwerze, a co na urządzeniach. Jako podstawę powinnam pojąć, jak to się dzieje, że sprzęt agd paruje się z aplikacją i rozpoznają się one, gdy chce się wywołać jakiś program i opcję prania lub suszenia będąc poza domem.

Życiowe zrządzenia losu

A jeszcze przede mną nauczenie się pytestowych pluginów, fixtur i hooków. Dżizas;). Doświadczam zdecydowanie lawiny trudnych informacji w krótkim czasie. A na dodatek, Fistaszek pierwszy tydzień września spędził w domu na chorobowym z Tatą, a pod koniec drugiego złapał nowego wirusa, więc wypadła moja kolej na zajęcie się chorym dzieckiem w domu. Boję się pomyśleć, jak zatrudniony razem ze mną w tym samym czasie kolega wyprzedzi mnie w poziomie poznania naszego środowiska pracy podczas mojej nieobecności. Z pewnością jestem wymagającym pracownikiem, bo bardzo często proszę o pomoc i przeprowadzanie mnie krok po kroku przez podstawowe zagadnienia, no i już w trzecim tygodniu pracy jestem na zwolnieniu. Ale pocieszam się, że w tej branży i w tej firmie wszyscy mają jakieś życie poza pracą, mają rodziny i wiele są w stanie zrozumieć. No i że w końcu będę miała do zaoferowania coś od siebie za ten trud włożony we wdrażanie mnie do projektu i będę w stanie zrewanżować się moim wkładem w pracę zespołu.

Uwaga, laik przy pracy

Tak się akurat zdarzyło, że jestem jedyną dziewczyną w zespole na ten czas (dwie pozostałe są na urlopach, z czego jedna już jest na okresie wypowiedzenia). Jestem też najmniej doświadczona i wyedukowana technicznie. Brakuje mi trochę bratniej duszy, która potrafiłaby zrozumieć, co to znaczy być laikiem technicznym. Dla chłopaków z zespołu protokoły komunikowania się urządzeń, różne rodzaje pamięci rozmaitych modułów sprzętu i pytestowe fixtury to chleb powszedni, więc rozumiem, że może być im trudno to w ogóle wytłumaczyć osobom spoza branży. To pewnie trochę, jakby człowiek miał wytłumaczyć komuś, jak działa krzesło. Kiedy na co dzień czegoś używamy, nie zastanawiamy się jak to działa, więc jak o tym opowiadać przybyszowi z innej planety:). Trochę czuję się takim ufoludkiem na razie. Oby tylko mieli dla mnie jeszcze trochę cierpliwości. Oby tylko przejść przez ten pierwszy trudny miesiąc. Potem będzie łatwiej. Na pewno...:)

Podsumowanie studiów podyplomowych

Przyszedł czas na podsumowanie roku akademickiego na WSB. Za mną 10 zjazdów (na 11-stym być nie mogłam) na podyplomowych studiach o kierunku Tester oprogramowania dla aplikacji mobilnych i serwerowych. W październiku rozpoczynałam naukę z dużą tremą. Kończę z poczuciem, że dobrze sobie poradziłam z tym najbardziej oddalonym od moich edukacyjnych początków wyzwaniem naukowym w mojej karierze.

Przyjemne początki

Pierwszy semestr studiów opierał się głównie o przygotowanie do egzaminu ISTQB Poziom Podstawowy z jednej strony oraz zapoznanie z Pythonem i środowiskiem Linux z drugiej. Można by nazwać ten okres wprowadzeniem do testowania dla zupełnych laików. Miałam poczucie, że dużo się uczę i że nadążam za prowadzącymi. Szczególnie interesowało mnie nauczenie się tworzenia przypadków testowych, czyli podstawowej techniki pracy testera oprogramowania. Warsztaty dotyczące tego tematu nie zajęły niestety całego dnia zajęć, a jedynie jego część i brakowało mi w nich indywidualnej informacji zwrotnej. Pamiętam, że opisywałam w moim grudniowym wpisie, jak chaotyczna atmosfera panowała na tych zajęciach. Głównie dlatego, że mieliśmy po krótkim wprowadzaniu pracować w grupach około siedmioosobowych.

Z perspektywy czasu, widziałabym to raczej tak:

• kilka przypadków testowych chciałabym stworzyć wspólnie z całą grupą, aby skorzystać z wiedzy i kreatywności innych,
• kilka przypadków chciałabym przygotować w parach, żeby mieć już większy wkład w ich tworzenie, ale nadal współpracą wzbogacić ich jakość,
• kilka przypadków samodzielnie bardzo chciałabym też zrobić sama z możliwością uzyskania feedbacku od prowadzącego, aby skorzystać z jego wiedzy i doświadczenia.

A może by tak ...

Mimo, że ogólnie dobrze sobie radziłam i wiele wartościowych tematów udało mi się przyswoić, było też sporo sytuacji, w których czułam się zagubiona i skonsternowana. Nie byłam pewna, jak wiedza z jednego przedmiotu przekłada się i łączy z wiedzą z innego. Wydaje mi się, że pomogłoby stworzenie dedykowanych tym studiom aplikacji lub strony internetowej do praktycznego testowania, które przewijałyby się przez różne przedmioty. Dałyby słuchaczom poczucie spójności i pomogłyby całościowo spojrzeć na zbiór różnych zajęć dydaktycznych. Wyobrażam sobie, że moglibyśmy najpierw pisać przypadki testowe dla jakiejś strony/aplikacji, potem ta sama strona/aplikacja służyłaby nam do testowania zautomatyzowanego, a na końcu zostałaby wykorzystana w procesie continuous integration lub testów na urządzeniach mobilnych. Podczas zjazdów zobaczyliśmy wiele różnych realnych przykładów stron czy aplikacji i super byłoby wzbogacić zestaw tych przykładów o coś, co spajałoby i systematyzowało całą przedstawianą nam wiedzę.

Level advanced

Drugi semestr stracił nieco z komfortowego tempa poziomu pierwszego i zaczęło się testowanie - level advanced. Ten semestr sprawiał wrażenie jakby był stworzony z myślą o osobach, które już testowały zawodowo i chciałyby nauczyć się automatyzacji testów oraz tworzenia środowisk testowych. Zamysł taki jest dla mnie logicznym kolejnym krokiem w edukacji, jednak widząc skonsternowane twarze współ-studentów oraz odnotowując wyższy poziom frustracji u mnie samej wnoszę, że przyspieszyliśmy za mocno. Może osoby z grupy bardziej zaawansowanej na takie właśnie tempo czekały, jednak w grupie laików było ono niewspółmierne do naszego poziomu. Wykładowcy coraz częściej zwracali się do nas jak do inżynierów z informatycznym doświadczeniem. Natomiast my nadal zapominaliśmy podstawowych komend w Linuxie. Nie przeszkadzałoby mi bardziej łopatologiczne tłumaczenie tego, co robimy szczególnie w ramach zajęć z continuous integration.

Zdarzało się, że wykonywałam na swojej maszynie coś, czego nie rozumiałam, przepisując polecenia z projektora. Dopytywałam dlaczego wykonujemy konkretną czynność w dany sposób - z resztą nie jako jedyna - i kilka razy padało wtedy stwierdzenie, żeby nie przejmować się, że czegoś nie rozumiemy, bo w IT codziennie zdarzają się sytuacje, kiedy czegoś się nie rozumie. O ile zgodzę się, że rzeczywiście w pracy w IT napotyka się na trudności, których rozwiązania często znajdziemy na forach internetowych, to na zajęciach dydaktycznych nie podobało mi się takie podejście. Nie do zaakceptowania było dla mnie tego typu wytłumaczenie w momencie, gdy zupełnie nie rozumiałam podstaw tego, co robimy. Poradziliśmy sobie do pewnego stopnia wspólnie jako grupą: Ci którzy zrozumieli coś lepiej podpowiadali tym, którzy mieli problemy.

Zakładam że wszyscy zdali krótki test kończący i podsumowujący naukę. W tym roku nie udało się zgodnie z wcześniejszymi planami napisać w małych grupach praktycznego projektu razem z którąś ze współpracujących z WSB firm IT. Może uda się to w przyszłości, gdy kierunek ugruntuje swoją pozycję w portfolio uczelni. Myślę, że wielu słuchaczom mogłoby to pomóc w uzyskaniu pierwszej pracy jako tester, dlatego trzymam kciuki za tą inicjatywę.

Czy warto?

Myślę, że studia podyplomowe dały mi dużo. Że pomogły zobaczyć różne obszary i ścieżki pracy testera. Że pokazały wiele technik i narzędzi, które mogą być punktem wyjścia do dalszego zgłębiania tematu. Że dały możliwość poznania wielu łebskich ludzi, zarówno wśród wykładowców, jak i współ-studentów, od których można się uczyć i z którymi przyjemnie się współpracuje. Że przypomniały mi, jak fajnie jest uczyć się nowych trudnych rzeczy. I w końcu, że dodały mi pewności siebie

Doradzam wszystkim, którzy płacą za swoje studia dociekanie, dopytywanie i drążenie tematu, aż do jego zrozumienia. Jest to bowiem częścią umowy biznesowej zawartej z uczelnią - płacimy za to, żeby ktoś nam efektywnie wytłumaczył to, czego chcemy się nauczyć. Sama byłam nauczycielką i wiem, że trudne bywa przedstawienie obcej osobie, czegoś, co wydaje nam się banalnie proste i oczywiste. Nauczyciel powinien wiedzieć, że nie każdy rozumie temat tak jak on i że musi próbować dotrzeć do tych najbardziej opornych na wiedzę na różne sposoby. Trzeba też upewniać się, że studenci rozumieją jakąś sprawiającą im do tej pory kwestię nie poprzez zapytanie "Czy ktoś jeszcze nie rozumie?". Niewielu jest odważnych przyznać się, że nadal nie nadążają, żeby nie stracić twarzy. Ale proponuję poprosić kogoś, kto miał problemy ze zrozumieniem tematu, o przedstawienie reszcie studentów swoimi słowami tego, co zostało wytłumaczone w nowy sposób przez wykładowcę. To celniej pokazuje, czy zostaliśmy jako nauczyciele dobrze zrozumiani.

Etap studiów w moim przebranżawianiu kończy się sukcesem, ponieważ po wysłaniu CV do 15 firm, 4 jakichkolwiek odpowiedziach nie wysyłanych przez automat i po dwóch rozmowach kwalifikacyjnych od września zacznę pracę jako Młodszy Inżynier Testów :). Wydaje mi się więc, że podtytuł bloga "Jak humanistka próbuje zostać testerką oprogramowania" będę wkrótce mogła zamienić na "Humanistka testuje".

Unit test w Pythonie

Przypadek testowy

Część pewnej majowej niedzieli postanowiłam spędzić na pisaniu testów automatycznych w Selenium. Zamysł wydawał się prosty: stworzyć na githubie repozytorium z testami sprawdzającymi stronę mojego własnego bloga. Wymyśliłam, że przetestuję jakąś małą funkcjonalność tej strony, czyli np. czy ikonka Facebooka i Twittera zabierają użytkownika do odpowiednich stron internetowych podłączonych do tychże ikon. W manualnym testowaniu taki przypadek testowy wyglądałby mniej więcej tak:

Tytuł: Nawigacja do linka na Facebook
Środowisko: Windows 10, Przeglądarka Chrome
Warunek wstępny: Użytkownik ma dostęp do internetu i przeglądarkę Chrome

Kroki:

1. Otwórz przeglądarkę Chrome.
2. Wejdź na stronę martamaracje.blogspot.com.
3. Kliknij na ikonę Facebook z prawej strony ekranu pod nagłówkiem "Tutaj jestem".

Rezultat oczekiwany: Otwiera się strona facebook.com/martamaracje/.

Proste? Proste! Co w tym trudnego? Łatwo wykonać te kroki manualnie.

Test automatyczny

Wynalazłam moje notatki z zajęć z testowania automatycznego w Pythonie przy użyciu Selenium oraz zajrzałam do repozytorium na githubie zapewnionym przez naszego WSB-owego wykładowcę tego tematu i skopiowałam zarys formuły do stworzenia testu jednostkowego.
W testach jednostkowych w Pythonie można za pomocą metody setUp spowodować, że Selenium przed wykonaniem konkretnego testu lub zestawu testów otwiera przeglądarkę Chrome - może to być oczywiście dowolna inna przeglądarka.

def setUp(self):
    self.driver=webdriver.Chrome()

Następnie, kolejna funkcja musi zaczynać się od słowa "test" i wykonuje kolejne kroki naszego przypadku testowego. Kilka poleceń dla webdrivera mogłam skopiować z przykładów, które robiłam na zajęciach w WSB, a reszty szukałam w googlu. Większość odpowiedzi na to, jak pokierować webdriverem znalazłam na stackoverflow.com. Po godzinach wymyślania, szukania i sprawdzania, doszłam do czegoś takiego:

def test_when_facebook_link_clicked_then_navigate_to_facebook(self):
    #Arrange
    driver=self.driver
    driver.get("http://martamaracje.blogspot.com")
    expected_url="https://www.facebook.com/martamaracje/"
    social_media_link=driver.find_element_by_css_selector(
           "#fawesomeicons > a[href='" + expected_url + "']")
    initial_tabs=len(driver.window_handles)
        
    #Act
    social_media_link.click()
    sleep(2) #wait for navigation
    opened_tabs=len(driver.window_handles)
    driver.switch_to.window(driver.window_handles[opened_tabs-1])

    #Assert
    self.assertGreater(opened_tabs, initial_tabs)
    self.assertIn(expected_url, driver.current_url)

Nazwa testu opisuje w zwięzły sposób, co ma on sprawdzać (when_facebook_link_clicked_then_navigate_to_facebook). Wiem, że to nie jest zdanie, jak z Szekspira i ma lekko zachwianą gramatykę, ale zawiera kluczowe słowa "when" i "then" ważne w programowaniu np. w składni gherkin. Wszystkie kroki pogrupowane są wg zasady:

• Arrange - przygotuj
• Act - wykonaj
• Assert - sprawdź

W sekcji Arrange webdriver otwiera stronę martamaracje.blogspot.com. Stworzyłam sobie zmienną expected_url, żeby móc jej później użyć dla sprawdzenia twittera, podmieniając jedynie wartość expected_url na mój twiterrowy adres. Zmienna social_media_link będzie miała przypisany element w kodzie html, który webdriver znajdzie na podstawie selektora css zawierającego oczekiwany adres internetowy, przypisany wcześniej do zmiennej expected_url. Ponieważ link do facebooka otwiera się w nowej zakładce, musiałam też stworzyć zmienną initial_tabs, która zliczy ilość zakładek otwartych zanim kliknie się na link.

Po tych warunkach wstępnych zlecam driverowi następujące działania (Act): po pierwsze kliknąć na to, co znalazł i co przypisane zostało do zmiennej social_media_link. Następnie, po 2 sekundach funkcja len zlicza jeszcze raz ilość otwartych zakładek i przypisuje ją do zmiennej opened_tabs. Na koniec driver ma za zadanie przejść do ostatnio otwartej zakładki (to będzie ta otwarta kliknięciem na link facebooka).

I nadchodzi czas na sprawdzenie (Assert), czy otworzyła się poprawna strona z linka. Najpierw, więc test sprawdzi, czy ilość otwartych po kliknięciu zakładek (opened_tabs) jest większa od początkowej ilości zakładek (initial_tabs). To sprawdzenie daje pojęcie, czy coś nowego się otworzyło. Ale jeszcze przydałoby się sprawdzić, czy adres internetowy obecnie otwartej zakładki zgadza się z tym oczekiwanym i przypisanym do zmiennej expected_url. Do tego użyłam funkcji assertIn, która oceni, czy adres https://www.facebook.com/martamaracje/ występuje w url-u, do którego posłałam webdrivera poleceniem driver.switch_to.window().

Uruchomiony na moim komputerze test nawigacji do linków na facebooku i twitterze zadziałał: webdriver sam otwierał przeglądarkę, klikał, gdzie mu wskazałam i sprawdzał wyniki tych działań, wracając do mnie z komentarzem "OK". Całość kodu do tego testu jednostkowego można obejrzeć na github.com/martamaracje/blogtests. Jestem z siebie dumna. To może mały krok dla ludzkości, ale duży skok dla martamaracje:).

Wroclove Code Carrots SQL

Geek Girls

Stereotypowo IT geek w męskim wydaniu kojarzy się z okularnikiem w koszuli w kratę podjadającym pizzę. Dlatego grupa Geek Girls postanowiła nazwać się Carrots, żeby zerwać z tym obrazem wielbicieli technologii. Na warsztatach SQL organizowanych przez Wroclove Geek Girls Carrots i RTS Software Masters można więc było podjeść wiele zdrowych przekąsek (z marchewkami na czele), jak również skorzystać z pomocy pięknych, przyjaźnie nastawionych dziewcząt (i dwóch chłopaków) chętnych do dzielenia się swoja wiedzą z zakresu baz danych.

MySQL

Na prawie sześciogodzinnych warsztatach korzystaliśmy z darmowego serwisu do ćwiczenia baz danych db4free.net. Karotki  przygotowały tam dla nas bazę danych fikcyjnego biura podróży, którego zasoby mogliśmy wykorzystywać do praktycznych ćwiczeń.

Warsztaty składały się z czterech części: każda zaczynała się krótkim wstępem teoretycznym, po którym następowały indywidualne ćwiczenia. Uczestnicy podzieleni byli na 4 grupy, a do każdej z nich przydzielonych było po dwóch mentorów do pomocy przy praktycznych zmaganiach.

Po podstawowym wstępie na temat tego, czym są dane, bazy danych oraz systemy zarządzania bazami danych, poznaliśmy składnię najprostszego zapytania, czyli SELECT. Żeby wyciągnąć z bazy np. nazwiska klientów, trzeba wysłać zapytanie:

 SELECT nazwisko
   FROM klienci

gdzie "nazwisko" będzie nazwą kolumny, a "klienci" nazwą tabeli, z której te dane chcemy pobrać.
Następnym poziomem jest zabawa w filtrowanie wyników wyszukiwania po wysokości rabatu przypisanego klientowi lub literze nazwiska dzięki formule WHERE, np.:

 SELECT *
   FROM klienci
  WHERE rabat > 0

Relacje

Najtrudniejszą częścią warsztatów było dla mnie zrozumienie, jak w zapytaniach zaznacza się relacje między rożnymi tabelami. Jeśli  chcemy zdobyć np. listę klientów, którzy nie zapłacili jeszcze za swoje wakacje, będziemy musieli połączyć najpierw dwie tabele: tę z danymi klientów i tę z danymi rezerwacji:

 SELECT klienci.* , rezerwacje.*
   FROM klienci 
   JOIN rezerwacje ON klienci.id = rezerwacje.klient_id 
  WHERE zaplacone = FALSE

Właśnie to JOIN...ON sprawiło mi najwięcej trudności. Jest to bowiem miejsce w zapytaniu, gdzie musimy zaznaczyć z jaką tabelą należy połączyć tabelę "klienci", aby otrzymać dane o opłaceniu rezerwacji. Informacje o klientach zawiera tabela "klienci", a informacje o rezerwacjach tabela "rezerwacje". Mają coś wspólnego - identyfikator klienta. Relacja ta wyrażona jest za pomocą klucza głównego w tabeli "klienci", czyli "klienci.id" oraz klucza obcego w tabeli "rezerwacje", czyli "rezerwacje.klient_id". Dzięki temu połączeniu możemy uzyskać zarówno dane klientów, jak i informację, czy rezerwacja została opłacona.

Funkcje

Funkcje pozwalają przetworzyć dane tak, aby zwróciły nam nową informację np. średnią (funkcja AVG) lub sumę (funkcja SUM). Dla przykładu, aby policzyć sumę pieniędzy, którą nasze biuro podroży uzbierało już z opłaconych rezerwacji, możemy użyć zapytania:

 SELECT SUM(oferty.cena)
   FROM rezerwacje
  INNER JOIN oferty ON rezerwacje.oferta_id = oferty.id
  WHERE rezerwacje.zaplacone = TRUE

Dane o opłaceniu rezerwacji są w tabeli "rezerwacje", a ceny znajdują się w tabeli "oferty" - stąd relacja JOIN. Natomiast funkcja SUM zlicza wszystkie kwoty po połączeniu danych odnośnie cen i zapłaconych rezerwacji.

Reasumując :)

Mimo luźnej atmosfery widać było, że warsztaty zostały pieczołowicie i profesjonalnie przygotowane. Dało się odczuć, że mentorzy przećwiczyli swoje wystąpienia, a wszystkie przykłady i zadania były spójne. Każdy uczestnik mógł otrzymać doraźną pomoc w swoich dylematach podczas rozwiązywania zadań.

Mili ludzie, smaczne przekąski, dobra kawa i nowe umiejętności podane w przystępny sposób - przepis na udaną sobotę! Było to moje pierwsze spotkanie z Karotkami i jestem pod wrażeniem. Po warsztatach mogliśmy porozmawiać przy wspólnym obiedzie w knajpie przy Rynku. To nieformalne spotkanie uzmysłowiło mi jeszcze dobitniej, jak świetnie jest mieszkać we Wrocławiu, gdzie tyle niesamowitych osób dzieli się swoją wiedzą z samej chęci rozpowszechniania zamiłowania do technologii. Aż chce się dać coś z powrotem od siebie. Może kiedyś dotrę do poziomu znajomości tematu, który pozwoli mi odwdzięczyć się za całą zdobytą za darmo wiedzę i życzliwość, której doświadczyłam poprzez przekazanie tej wiedzy dalej.

Napisz swój pierwszy test w Javie

Women in Technology Rule

Zgłosiłam się na wydarzenie organizowane przez Women in Technology i QA Courses dla testerów manualnych, którzy nie znają języka Java, ani nigdy wcześniej nie pisali testów automatycznych. Mimo, że wprawdzie nie jestem testerem manualnym, na podstawie mojego zgłoszenia zakwalifikowałam się do grona 25 uczestników warsztatów "Napisz swój pierwszy test w Javie".  Bardzo się ucieszyłam z tego małego sukcesu. Konfigurowanie środowiska, żeby sprawnie w tych warsztatach wziąć udział przysporzyły mi nieco kłopotów, ale dopomógł mąż deweloper. Zainstalowałam na swoim  komputerze pod czujnym okiem domowego uber-programisty Java JDK, środowisko programistyczne IntelliJ IDEA i wtyczkę Selenium Builder w Firefoksie, aby w środowy wieczór popędzić moją srebrną Renią na spotkanie z innymi aktywnymi technologicznie dziewczętami. Jak przed każdym tego typu wydarzeniem, byłam zestresowana, że nie nadążę za tempem prowadzących i reszty grupy, ale dzielnie pojawiłam się na miejscu.

QA Courses Rule

Warsztaty prowadziła Irena Szumowskaja z pomocą krążącego po sali, żeby rozwiązywać bieżące problemy Olega Manzhosa. Irena jeszcze przed szkoleniem wymagała, żeby wszyscy uczestnicy poprosili ją na Skypie o dodanie do czatu, dzięki czemu mogliśmy wszelkie linki i kawałki kodu dostawać wprost na nasze konta Skypowe natychmiast, gdy były nam potrzebne w ćwiczeniach. Bardzo przypadło mi do gustu to rozwiązanie usprawniające naszą komunikację i nasze ćwiczenia.

Sama Irena prowadziła warsztaty w komfortowym tempie, spokojnie, cierpliwie i z poczuciem humoru tłumacząc zagadnienia i rozwiązując problemy. Dziewczyna umie uczyć! Warsztaty były dobrze zorganizowane i zaplanowane - jedno ćwiczenie dotyczyło stworzenia testu automatycznie przy pomocy zapisu z nagrywarki Selenium Builder, a drugie odbywało się już ręcznie - prawie od podstaw.

Najpierw robiliśmy test automatyczny z użyciem Selenium Buildera wspólnie. Wtyczka Selenium Builder zapisuje kroki, które wykonuje się na jakiejś stronie internetowej, a następnie te kroki można wyeksportować do "Java/TestNG", czyli zapisać w pliku scenariusz testowy w języku Java. Taki plik można potem otworzyć przy pomocy IntelliJ IDEA, żeby zobaczyć kod i ponownie uruchomić zapisane kroki.

Na podstawie kodu, który utworzył się przy pomocy Selenium Buildera, Irena pokazała nam, jak stworzyć podobny test od podstaw, ręcznie. Nauczyła nas poleceń takich jak:

 // utwórz sterownik
 FirefoxDriver wd = new FirefoxDriver();
 // nawiguj do wskazanego adresu strony
 wd.get("adres.strony.http");
 // znajdź element po identyfikatorze i go kliknij
 wd.findElement(By.id("main-search-text")).click();
 // znajdź element po nazwie
 wd.findElement(By.name("a"));
 // znajdź element po nazwie i wstaw do niego tekst
 wd.findElement(By.name("password")).sendKeys("password");
 // znajdź element z wykorzystaniem XPath
 // - drugie pole tekstowe w formularzu o identyfikatorze 'login'
 // - i go kliknij
 wd.findElement(By.xpath("//form[@id='login']/input[2]")).click();

Zmienna wd to Web Driver przeglądarki Firefox. Jest to urządzenie z pakietu Selenium, które możemy prosić o wykonanie konkretnych poleceń w przeglądarce internetowej, np. znalezienie elementu w kodzie HTML strony, aby następnie wywołać na nim akcje takie, jak kliknięcie, czy uzupełnienie danymi. Irena pokazała nam, jak znajdować elementy oznaczone identyfikatorem (id) i/lub nazwą (name), których chcemy użyć w naszym teście.

Jest to dla mnie nadal doświadczenie z pogranicza magii, kiedy jakieś tajemnicze polecenia napisane w ledwo zrozumiałym języku powodują, że komputer zaczyna żyć własnym życiem, otwierać strony internetowe, uzupełniać pola tekstowe. Warsztaty nie były dla mnie ani za trudne, ani za łatwe. Zakończyły się z poczuciem osiągniętego sukcesu, bo oba zadania udało mi się zrobić i wszystko zadziałało tak, jak było przewidziane.

JetBrains Rule

IntelliJ IDEA to takie środowisko, w którym można tworzyć kod w języku Java. Stworzyła je firma JetBrains, z którą miałam już styczność przy bezpłatnym kursie podstaw Pythona przygotowanym przez Udemy.com.  Tam poznałam środowisko podobne do IntelliJ tyle, że przygotowane specjalnie do pisania w Pythonie - PyCharm. JetBrains wydaje się tworzyć dosyć przystępne narzędzia do ćwiczenia swoich umiejętności tworzenia oprogramowania w różnych językach. W PyCharm można znaleźć konsolę do tworzenia skryptów Pythonowych oraz terminal do wpisywania komend typowych dla Linuxa. Wszystko jest zintegrowane w jednym miejscu i od razu można zobaczyć działanie swojej radosnej twórczości.

Trochę praktyki, trochę zdobytych porad i napisany egzamin

Testy jednostkowe i TDD

Już coraz więcej rozumiem i coraz więcej wiem. Czuję się coraz pewniej w zagadnieniach teoretycznych. Radzę sobie nawet z testami jednostkowymi na studiach podyplomowych, choć są one dla mnie bardzo wymagające intelektualno-logicznie.

Testy jednostkowe, które ćwiczymy na WSB bazują na podejściu zwanym Test Driven Development, czyli "najpierw testuj, potem programuj." Polega ono na tym, że dostajemy dane, które ma obsługiwać napisana przez nas funkcja tak, żeby osiągnąć wyszczególniony rezultat. Na przykład, jeśli podamy funkcji liczbę 1, to ma ona zwracać liczbę 1, a jeśli tej samej funkcji podamy liczbę 2, to ma zwrócić liczbę 4. Trzeba się nagłówkować, jak napisać w Pythonie funkcję, która wykona najpierw to pierwsze zadanie, a później zadziała również dla drugiego przypadku. Podczas zajęć formułę do tworzenia testu jednostkowego dostaliśmy gotową, więc główne zadanie polegało na modyfikowaniu modułu z funkcją tak, żeby test przechodził pozytywnie. Zgodnie z zasadami TDD, najpierw test jednostkowy ma zostać nie zaliczony i na podstawie błędu wprowadza się zmiany w module z funkcją, aż uda się zaliczyć test poprawnie. Było to trudne i jeszcze przede mną wiele ćwiczeń na zadanie domowe, ale dużą satysfakcję daję komunikat, że test został zaliczony pomyślnie.

Praktyczne warsztaty z testowania oprogramowania

12. lutego razem z dwoma koleżankami ze studiów i jednym kolegą bawiliśmy się w testerów na warsztatach prowadzonych przez Karolinę Pawłowską z Ipis Services. Karolina przygotowała dla nas krótką prezentację teoretyczną z typowych zagadnień związanych z testowaniem oprogramowania. Natomiast 80% czasu w tę słoneczną niedzielę próbowaliśmy znajdować usterki w grze komputerowej przygotowanej specjalnie na warsztaty.

Moje emocje związane z praktycznym testowaniem gry na tych ćwiczeniach określiłabym od początkowej konfuzji i zupełnego chaosu do końcowego uporządkowania i większej uważności. Stopniowo uczyliśmy się, jak efektywnie podchodzić do zadań testerskich, które mogą nas spotkać na rozmowach kwalifikacyjnych. Ćwiczenia przeplatały się z coraz bardziej uszczegółowioną teorią. W usystematyzowany sposób poznawaliśmy od praktycznej strony kolejne techniki: od testowania eksploracyjnego przez testowanie w oparciu o klasy równoważności i warunki brzegowe, aż po przypadki testowe generowane ze specyfikacji. W miarę upływu czasu coraz lepiej szło nam spostrzeganie defektów. I co najważniejsze uczyliśmy się nasze odkrycia w miarę sensownie i spójnie notować.

Karolina bardzo wiele opowiadała nam też o tym, co warto uwypuklić w CV (szczególnie, kiedy nie mamy jeszcze żadnego doświadczenia przemawiającego na naszą korzyść) i jak wyglądają rozmowy kwalifikacyjne, które ona sama przeprowadza dosyć często.

Akademia Początkującego Testera

Udało mi się wziąć udział w wydarzeniu organizowanym przez Akademię Początkującego Testera pt. "Rozmowy o testach." Nie było to ogólnikowe spotkanie, na którym poznaje się, czym jest zawód testera i jak się zabrać za przebranżawianie. Wydarzenie określiłabym raczej na poziomie średnio-zaawansowanym. Składało się ono z czterech wykładów dotyczących różnych szczegółów/aspektów pracy testera.

Po pierwsze Joasia mówiła o tym, że jeśli są jakieś cechy charakteru, które utrudniają nam bycie dobrym testerem (np. introwertyzm lub nie dostateczne zwracanie uwagi na szczegóły), to mamy na nie wpływ przez ćwiczenia i wyrabianie nowych nawyków. W skrócie - możemy pracować nad naszymi słabszymi stronami - nie determinują one powodzenia w pracy testera. Asia poleciła nam książkę "Myśl jak Sherlock Holmes" jako źródło ćwiczeń na spostrzegawczość. Postaram się ją przeczytać w wolnej chwili.

Po drugie, Marta przedstawiła kilka narzędzi do zarządzania testami, które warto poznać, żeby ułatwić sobie pracę w testowaniu - od Excela po Microsoft Test Manager. W każdej firmie istnieje inny sposób zarządzania testami, ale wyróżnione przez Martę narzędzia mogą służyć jako przedstawiciele większości z nich.

Następnie Darek podpowiadał, jak można się samodoskonalić, żeby zostać testerem. Podkreślał rolę poświęcenia, wizualizacji, wyznaczania sobie i zapisywania celów. Muszę jego wskazówki koniecznie wcielić w życie, bo moje cele motają mi się w głowie bez większego ładu, co nie pomaga w dążeniu do ich realizacji.

Na koniec, Grzegorz opowiadał o tym, jak skomplikowane jest testowanie urządzeń mobilnych i jak wiele rzeczy trzeba wziąć pod uwagę, żeby przetestować aplikacje mobilne. Mnogość zagadnień, z którymi trzeba się liczyć w takim testowaniu przyprawia o zawrót głowy, ale podobno są usystematyzowane sposoby na poradzenie sobie z tym.

Egzamin ISTQB - poziom podstawowy

7. marca napisałam egzamin ISTQB w siedzibie SJSI we Wrocławiu. Cieszę się, że mam to już za sobą i mogę skupić się na uczeniu innych, bardziej praktycznych rzeczy. Moja wersja egzaminu składała się zarówno z typowych pytań o teorię zawartą w sylabusie, jak i z kilku praktycznych zastosowań tej teorii w przypadkach testowych. Te praktyczne zadania przysporzyły mi najwięcej trudu z racji tego, że za mało mam jeszcze doświadczenia w tworzeniu testów i przypadków testowych. Wyobrażam sobie, że ktoś, kto zdaje egzamin ISTQB po przepracowaniu choć kilku miesięcy jako tester może poradzić sobie z tego typu pytaniami o wiele lepiej. Ale mam nadzieję, że rozwiązałam poprawnie wystarczająco dużo zadań, żeby egzamin zdać. Dowiem się tego w ciągu kilku nadchodzących dni.

W Nowy Rok dalej drogą do testowania

Przerwa świąteczno-noworoczna

Moja przerwa świąteczna na blogu przeciągnęła się na prawie cały styczeń. Nieobecność blogowa nie przekładała się jednak na brak aktywności naukowej. Przez ostatni miesiąc poznałam teoretycznie cały syllabus do egzaminu ISTQB. Uczę się dosyć systematycznie po godzinę dziennie lub co drugi dzień. Niestety, pytania egzaminu są skonstruowane tak, że właściwie najrozsądniej nauczyć się większości pojęć na pamięć. Nie wystarczy bowiem pojąć ogólnie jakiś temat i potrafić o nim opowiedzieć. Trzeba znać niektóre definicje i składowe procesów słowo w słowo, bo inaczej głowa może rozboleć od rozróżniania niuansów między odpowiedziami w teście. Ale uczę się po swojemu, ze zrozumieniem, rozrysowując zależności między różnymi definicjami i procesami oraz robiąc drzewka podziału testów i narzędzi do nich. Od ostatniego wpisu zakupiłam sobie w świątecznej promocji na stronie SJSI voucher na egzamin ISTQB i zapisałam się na termin marcowy. Mam więc jeszcze trochę czasu, żeby wyuczyć się syllabusa.

Girls for Girls z warsztatami z ROBOT framework

Na początku grudnia brałam udział w kolejnym spotkaniu Girls for Girls w Nokii. Tym razem pracownice opowiadały o pracy specyfikatora, o pomiarach radiowych oraz o frameworku Angular. Wykłady były ciekawe, ale dla mnie osobiście nie wyznaczały kierunku do dalszego rozwoju w branży IT. Natomiast w części warsztatowej mogłam obejrzeć narzędzie do przeprowadzania testów automatycznych stworzone w Nokii, mianowicie ROBOT. Razem z 14 innymi uczestniczkami próbowałyśmy stworzyć test, który miałby zalogować się na pocztę gmail i wysłać z niej maila. Miałyśmy okazję zobaczyć, jak może działać takie narzędzie i jak korzysta się z biblioteki Selenium.  Nie było łatwo nadążyć za prowadzącą warsztaty, ale ostatecznie wydaje mi się, że dałabym radę nauczyć się pracy z ROBOTem, gdybym mogła poćwiczyć jeszcze kilkanaście lub kilkadziesiąt godzin. Chociaż nie mogę powiedzieć, że nauczyłam się obsługi ROBOTa, bo było to trudne do osiągnięcia w 2 godziny, to przynajmniej wzbogaciłam swoją wiedzę o naoczne poznanie nowego narzędzia.

Webinary "Jak zostać testerem"

Dzięki społeczności Mamo Pracuj w IT obejrzałam w styczniu dwa webinary przygotowane we współpracy z testuj.pl pod wdzięcznie brzmiącym tytułem "Jak zostać testerem oprogramowania". Kasia i Ewa opowiadały, jak wyglądała ich droga do kariery testerki i na czym polega ich praca obecnie. Dziewczyny mają podobne historie życiowe do mojej. Słuchając jak sobie poradziły z przebranżowieniem i jak są zadowolone ze swojej pracy teraz, można było się zainspirować. Mi na pewno ich pozytywne nastawienie dodało motywacji. Kilka dni temu Kasia prezentowała w skrócie na czym polegają kaskadowe i iteracyjno-przyrostowe podejścia do tworzenia oprogramowania i jaka jest w nich rola testera. W czwartek 26.01.17 czekam na ostatni webinar z tej serii. Tym razem Ewa ma opowiadać o rodzajach błędów i o tym jak się je zgłasza. Prezentacje Kasi i Ewy pomagają mi usystematyzować wiedzę teoretyczną i wzbogacić ją o perspektywę praktyczną prawdziwych testerek.

Miałam wrażenie, że niewiele przez ostatni miesiąc, czy półtorej robiłam w kierunku testowania. Jednak powyższe podsumowanie pomogło mi uzmysłowić sobie, że jestem już o kilka kroków bliżej do zmiany zawodu, że nie stoję w miejscu. A że piszę te słowa kołysząc na kolanach przeziębionego Fistaszka, czuję się rozgrzeszona, że nie zrobiłam więcej. Od końca listopada moje dzieci chorują bowiem mniej więcej co dwa tygodnie - tydzień/półtora przeziębienia, dwa tygodnie przerwy, tydzień przeziębienia lub zapalenia ucha, tydzień relatywnego zdrowia, itd...Kto ma dzieci, ten wie, o co chodzi:).