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:).

Mamo pracuj w IT

Prezentacje w Krzywym Kominie

28. listopada brałam udział w spotkaniu organizowanym w ramach projektu #MamoPracujwIT. Inicjatywa wspierania się kobiet poszukujących nowej drogi zawodowej w branży informatycznej trwa. Zaczynam nawet rozpoznawać twarze niektórych działaczek.

Głównym partnerem wydarzenia w Krzywym Kominie była Nokia. Znów miałam okazję usłyszeć dlaczego warto próbować swoich sił w tej firmie. Przykład centrum Nokii pokazuje, że branża IT jest szczególnie przyjazna rodzicom. Możliwość pracy zdalnej oraz elastyczne godziny wykonywania obowiązków są bardzo atrakcyjnymi argumentami, gdy dzieci są małe lub często chorują. Ponadto, aspekty wymienione powyżej stają się niezwykle cenne, gdy trzeba logistycznie zaplanować, kto i kiedy ma odprowadzać, a później odebrać dzieci z instytucji edukacyjnych, żeby nie stać godzinami w korkach.

Dodatkowo bardzo przemawiał do mnie przytoczony przez przedstawicielkę Nokii argument pracy koncepcyjnej, czyli nastawionej na wykorzystywanie swoich szarych komórek. Będąc księgową codziennie robiłam właściwie to samo i czasami miałam wrażenie, że moje szare komórki obumierają podczas pracy nad fakturami. Praca koncepcyjna jawi mi się więc jako atrakcyjne przeciwieństwo moich dotychczasowych wyzwań zawodowych.

Spotkanie w Krzywym Kominie było też dobrą okazją, żeby uzmysłowić sobie, ile jeszcze innych ciekawych rzeczy dzieje się dla kobiet zainteresowanych IT we Wrocławiu. Sylwia Robak z wrocławskiej społeczności Women in Technology wymieniła między innymi grupy PyLadies, WrocLove Geek Girls Carrots, UX Wrocław i WrotQA. Warto o nich poczytać, zapisać się do nich na Facebooku i brać udział w organizowanych przez nie wydarzeniach. Do grupy Women in Technology i Geek Girls Carrots dołączyłam na Facebooku, dzięki czemu dowiaduję się na bieżąco o ciekawych spotkaniach i warsztatach.

Ostatnią prezentacją była promocja strony internetowej Kodilla.com. Jest to szkoła programowania online inspirowana Codecademy, z tym, że Kodilla oferuje kursy po polsku. Można na tej stronie zrobić bezpłatny test sprawdzający predyspozycje do wykonywania zawodu programisty. Dostępne są też dwa darmowe kursy: wprowadzenie do HTML i podstawy CSS. Jeden ze slajdów w prezentacji Kodilli pokazywał rozbieżność między liczbą studentów informatyki (270 tys.) a zapotrzebowaniem na programistów (1 mln) do roku 2020. Oznacza to, że branża IT będzie chciała zatrudniać nie tylko absolwentów uczelni wyższych, ale również samouków internetowych. Pięcioletnie studia informatyczne nie są więc absolutną koniecznością, żeby znaleźć pracę w tym sektorze. Daje to szansę na przebranżowienie osobom takim, jak ja.

Inspirujące mamy

W drugiej części spotkania cztery mamy z branży IT opowiadały o swojej drodze do obecnej pracy i o tym, jak się im w niej podoba. Wysłuchałam więc czterech ciekawych historii:  Kasi - pracownicy Nokii (znanej mi już z wykładów Girls 4 Girls) , Stefanii - testerki z Objectivity, Karoliny - dawniej pani architekt, teraz pracownicy IBM oraz Igi - specjalistki w dziedzinie User Experience. Najbardziej mi bliska ze względu na podobieństwo do mojej własnej sytuacji była opowieść Kasi. Z tą drobną różnicą, że Kasia ma dziecko w wieku szkolnym, więc mogła poświęcać czas, w którym jej dziecko miało lekcje na swoją naukę testowania i zagadnień telekomunikacyjnych. Po panelu można było chwilę porozmawiać z dziewczynami osobiście. Wykorzystałam tę okazję na podpytanie Stefanii o to, w jakich wrocławskich firmach można rozpocząć poszukiwanie pracy, żeby zdobyć pierwsze doświadczenia zawodowe.


Spotkanie Mamo Pracuj w IT zostało zaplanowane na dwie godziny. Skończyło się po około dwóch i pół, a i tak nie zdążyłam porozmawiać jeszcze z dziewczynami z Nokii. Szczególnie zaintrygowała mnie mama trójki dzieci z widowni, która w tygodniu przed wydarzeniem w Krzywym Kominie dostała pracę w Nokii. Wspomniała, że właśnie przeżyła pierwszy od dawna weekend bez nauki, razem z dziećmi, bo w każdy poprzedni mąż wywoził gdzieś pociechy, a ona zostawała w domu, żeby się uczyć. To jedyna podpowiedź w kwestii zorganizowania czasu na naukę przy małych dzieciach w domu. Rzeczywiście, raz udało mi się wysłać moją rodzinę na weekend do dziadków i wtedy najwięcej udało mi się pouczyć. Niestety nie da się tego sposobu wprowadzać w życie co weekend. U mnie nie da się częściej niż raz na miesiąc. Wydaje mi się więc, że w mojej sytuacji przekwalifikowanie zajmie po prostu więcej czasu niż u Kasi z Nokii i tej wspomnianej mamy trójki dzieciaków.

Ostatecznie, całe wydarzenie pt. Mamo Pracuj w IT utwierdziło mnie w przekonaniu, że warto próbować dalej się przebranżawiać, bo jest w świecie IT jeszcze sporo miejsca dla kobiet.

Pierwsze próby praktyczne

Pierwszy dzień - rodzaje testów

Jestem już po drugim zjeździe w WSB. Mimo, że nie poczyniłam wielkich postępów w nauce od zeszłego miesiąca, to czułam się na zajęciach pewniej. Znów poznałam sporo teorii dotyczącej tym razem podziału testów według ich funkcjonalności. Nie było w tym nic skomplikowanego. Natomiast część zajęć miała wreszcie wymiar praktyczny.

Po wysłuchaniu wykładu w około siedmioosobowych grupach mieliśmy za zadanie wymyślić przypadki testowe dla strony internetowej wizzair. Pracowaliśmy razem na dokumencie googlowskim, więc każdy mógł śledzić, co nowego dopisują inni. Magia techniki - coś się pojawia na moim ekranie w momencie, kiedy ktoś inny pisze to na swoim komputerze.

Wyzwaniem stało się nie tyle wymyślenie przypadków testowych, co próba zorganizowania pracy z zupełnie nieznanymi ludźmi. Większość z nas widziała się przecież w sobotę drugi raz w życiu, a tu mieliśmy za zadanie na podstawie kilku podpowiedzi i przykładów przygotować plan działania i podzielić się jakoś pracą w grupie.

Nie lubię takiego chaosu, jaki zapanował po wydaniu polecenia, że mamy napisać przypadki testowe. Starałam się więc nad nim zapanować przyjmując rolę organizatora, spisując kategorie funkcjonalności, które chcemy przetestować. Wydawało mi się, że wiele osób nie do końca wie, co ma robić i jak się za to zabrać. Ale trzeba było coś wyprodukować i to szybko, więc coś tam nam wyszło. W idealnym świecie poświęciłabym więcej czasu na zawiązanie jakichś relacji w naszym zespole i gruntowniejsze przedyskutowanie planu naszej pracy.

Samo nauczenie się sporządzania scenariuszy testowych wydaje mi się teraz tylko kwestią dalszej praktyki. Na przykład, żeby przetestować przypadek użycia strony wizzair do rejestracji użytkownika, można stworzyć sytuację o tytule "rejestracja użytkownika z użyciem poprawnych danych". Wypisujemy wtedy wszystkie kroki, które należałoby przejść w celu efektywnego zarejestrowania użytkownika na stronie wizzair. W analogiczny sposób można stworzyć scenariusze dla sytuacji wyjątkowych, jak np. niepoprawne dane dla formularza rejestracji i napisać, co powinno się wydarzyć w takim wypadku.

Ważne, żeby poszczególne kroki w każdym przypadku testowym były jak najbardziej szczegółowe. Zamiast pisać "Wpisz niepoprawne dane", zdecydowanie lepiej będzie napisać "Wpisz w pole <Imię> ciąg cyfr <1234>" Podobnie można by przetestować inne scenariusze dla takich przypadków użycia strony jak logowanie, wyszukiwanie lotów, wyszukiwanie hoteli, rezerwacja samochodu, czy zamawianie newslettera.

Ten rodzaj testowania, bez zagłębiania się w sferę kodu kryjącego się za tym, co widzimy np. w przeglądarce internetowej, nazywa się testowaniem czarnoskrzynkowym. Nie jest w nim potrzebna znajomość programowania, więc może ją wykonywać każdy informatyczny laik. Nie jest to trudne, dam sobie z tym na pewno radę.

Drugi dzień - przygotowywanie środowiska programistycznego i pierwsze próby Pythona

Na moim kierunku studiów mam kolegę w grupie bardziej zaawansowanej, który zajęcia z programowania miał w sobotę, a rodzaje testów poznawał w niedzielę - odwrotnie niż ja. Podczas przerwy obiadowej w sobotnich zajęciach wyglądał na bardzo zmarnowanego. Sam też przyznał, że czuje się przytłoczony tempem pracy i ilością wiedzy do przyswojenia. Nieco mnie to zestresowało, bo mogło być przepowiednią tego, co mnie czeka w niedzielę. Jednak tempo mojej grupy jest zdecydowanie bardziej komfortowe. Czułam, że nadążam z instalowaniem całego potrzebnego oprogramowania (Linux, Virtual Box). Poznałam kilka podstawowych komend potrzebnych do tworzenia, przeglądania i modyfikowania plików na konsoli Linuxa. Po przygotowaniu środowiska do pracy z Pythonem miałam też okazję sama wypróbować tworzenie zmiennych i poćwiczyć na nich instrukcje takie, jak sprawdzanie długości listy lub ciągu znaków, dodawanie elementów do list, działanie pętli i instrukcji warunkowych. Same podstawowe rzeczy. Ponieważ bardzo podobne zadania robiłam podczas kursu online w Codecademy (w którym wykorzystywałam symulację konsoli w przeglądarce), nie miałam większych problemów z tą częścią zajęć. Po dniu praktycznych ćwiczeń na wirtualnej maszynie byłam z siebie zadowolona.

Im więcej dowiaduję się o testowaniu, tym łatwiejsze mi się wydaje. Mimo, że mam wykształcenie humanistyczne, nie czuję się całkiem zagubiona w tym odłamie technicznego świata. Oswajam Pythona i oswajam się z myślą, że dam sobie radę z testowaniem.