Przerwa

Tęsknię za pracą. Mam przymusową przerwę w karierze zawodowej, ponieważ od lutego poważnie choruję.

W pracy udało mi się od strony organizacyjnej osiągnąć mały sukces: przygotowałam i poukładałam większość dokumentów związanych z testami pierwszej części projektu, do którego zostałam przypisana na wyłączność z kolegą z zespołu.

Podobało mi się samo przygotowywanie scenariuszy testowych - może dlatego, że mieliśmy w ogóle dokument, na którym mogliśmy bazować. Zdarza się, że testowanie projektów musi być nieco bardziej eksploracyjne ze względu na brak dokumentacji typu instrukcja obsługi jakiejś aplikacji lub platformy. Tym razem jednak "manual" był, a wszelkie niejasności można było rozwiać kontaktując się bezpośrednio z klientem. Po przygotowaniu scenariuszy musiałam zostać z synem na chorobowym, więc samych testów nie mogłam wykonywać. Za to po powrocie do pracy miałam okazję przejrzeć, usystematyzować i połączyć kilka naszych wewnętrznych dokumentów tak, by odwoływały się one do siebie w jasny sposób, czyli odniesienia typu numer scenariusza testowego miały swoje odzwierciedlenie w raporcie znalezionych bugów. Zajęło mi to sporo czasu, bo akurat kolega, który testował nasze scenariusze wyjechał  na urlop i nie miałam możliwości skontaktowania się z nim. Jednak bardzo byłam zadowolona z rezultatów mojej pracy i z dumą mogłam je udostępnić klientowi. Dzięki usystematyzowaniu naszych dokumentów mogłam też sprawnie przenosić nasze zgłoszenia bugów na platformę JIRA klienta. Brałam też udział w dyskusji, jak najbardziej efektywnie powinien wyglądać formularz zgłoszenia buga w JIRZE w naszym projekcie.

Po zakończeniu pracy nad pierwszą fazą projektu, dostałam pozytywne wiadomości zwrotne zarówno od klienta, jak i od własnego zespołu, więc bardzo się cieszyłam na dalszą współpracę. Niestety, w tym samym czasie okazało się, że mój układ limfatyczny jest bardzo poważnie zajęty przez nowotwór zwany chłoniakiem Hodgkina i muszę przejść 6-8 cykli chemioterapii.  Dlatego też nie mogłam wziąć udziału w zapowiadanym w poprzednim poście webinarze dla #MamoPracujwIT

Skupiam się teraz na regeneracji i odpoczywaniu, a do pracy wrócę, gdy wyzdrowieję. Moja choroba jest bowiem wyleczalna w 90% przypadków, więc mam nadzieję, że właśnie w tej większości się znajdę. Zaczęłam trzeci cykl leczenia, więc jestem już może w połowie drogi do pełni zdrowia.

Nowa praca - nowa ja

Niespodziewany grudzień

Od 14. grudnia zaczęłam pracę w nowym miejscu. Nie spodziewałam się, że tak szybko znajdę kolejne zatrudnienie. Mam sporo szczęścia. Wysłałam CV na kilka ofert i po rekrutacyjnej rozmowie telefonicznej z jedną z firm, jeszcze tego samego dnia dostałam propozycję współpracy i pytanie, czy mogę zacząć od następnego tygodnia. Nowa firma pracuje na innej zasadzie biznesowej niż poprzednia - zajmuje się  outsourcingiem, czyli usługami testowania dla klientów zewnętrznych, więc zamiast pracy przy jednym projekcie, ma się okazje pracować nad wieloma różnymi. Ta różnorodność mi się podoba. Prawie codziennie mam do czynienia z czymś nowym, nową aplikacją mobilną, nową funkcjonalnością internetową, nowym narzędziem desktopowym.


Atmosfera pracy 

W nowym miejscu testuje się głównie manualnie. W związku z tym wielu moich współpracowników świetnie radzi sobie ze swoimi zadaniami, mimo że nie ma dużego zaplecza technicznego. Dzięki temu czuję, że lepiej tu pasuję. Ludzie są przyjaźni; pytają, jak mi idzie, jak mi się podoba, zagadują na różne pozabranżowe tematy. Przydzielono mi mentora, który wynajdował mi już od pierwszego dnia zadania związane z projektem, nad którym sam pracuje. Pokazywał, jak mam zadania wykonać, pochwalił, kiedy dobrze mi poszło. Znalazłam buga i mogłam go zaraportować pod jego okiem. Mała rzecz, a cieszy. Nie czuję się gorsza na starcie, więc łatwiej mi uwierzyć, że gdy już poznam więcej narzędzi testerskich i popracuję nad kilkoma projektami, będę mogła wnieść realną dodatnią wartość w funkcjonowanie całego zespołu testerskiego.


Pierwszego dnia po pracy załapałam się na spotkanie przedświąteczno-wigilijne, które mimo, że nikogo jeszcze nie znałam było całkiem miłe. Osoby, które siedziały koło mnie przy stole normalnie ze mną rozmawiały i były ciekawe skąd się wzięłam i co wcześniej robiłam oraz czym się zajmuję poza pracą. Takie relacje z ludźmi są dla mnie niezmiernie ważne. Jakość życia w domu po pracy też się przez to poprawiła, jak twierdzi mąż. Rzeczywiście, poprzednie trzy miesiące trudu w poprzedniej pracy odbijały się niekorzystnie na moje nastawienie do całego świata, również tego domowego.  Teraz jednak jest lepiej, a jak mówi ludowe przysłowie "happy wife - happy life." I to dla wszystkich domowników:).

Oczekiwanie na własny projekt 

Tu gdzie teraz jestem zasadą pracy na co dzień jest zajmowanie się przez ok. 80% czasu przydzielonym projektem długoterminowym, a przez pozostałe 20% doraźną pomocą w krótkoterminowych, małych zleceniach. Przez pierwsze tygodnie załapałam się na sprawdzanie funkcjonalności sklepu internetowego w przeglądarce internetowej oraz funkcji płatności jednym kliknięciem w aplikacji na telefon. Oprócz tego pomagałam mojemu mentorowi przy jego aplikacji mobilnej.

Na początku stycznia zostałam przydzielona do projektu, który może stać się długoterminowy. Razem z bardziej doświadczonym kolegą pojechaliśmy do firmy w Poznaniu, żeby zapoznać się z zespołem i z narzędziem, które będziemy testować. Byłam stremowana wizytą u klienta, bo nie czułam się na siłach, żeby odpowiedzieć na wiele pytań. Na szczęście, mój współpracownik dużo opowiadał, ja mogłam zadawać dodatkowe pytania i słuchać. Po powrocie do Wrocławia, kilka dni musieliśmy poczekać na zorganizowanie wszystkich potrzebnych nam dostępów i środowiska. Po dostarczeniu przez klienta instrukcji obsługi i wersji narzędzia, na której mogłam je trochę poekspolorować, napisałam scenariusze do przetestowania ok. 25 przypadków użycia jednej z funkcjonalności.


Przymusowa przerwa w działaniu

Same testy w moim projekcie będę mogła kontynuować dopiero po tygodniu opieki nad Fistaszkiem. Wypadła moja kolej zajmowania się chorym dzieckiem, bo zaraz po przerwie świątecznej poprzedni wirus kurował mąż. Takie to życie rodzica. Czuję się odpowiedzialna za ten projekt, szczególnie, że poznałam osobiście ludzi, dla których będziemy pracować. Trochę mi głupio, że zostawiłam na tydzień swojego współpracownika bez pomocy. Pocieszam się, że chociaż te kilka scenariuszy udało mi się przygotować przed chorobowym.  Mam nadzieję, że po powrocie z L4 będę mogła się zrehabilitować.


Bonus medialny

Dostałam w nowej firmie propozycję opowiedzenia o pracy testerki mamom z projektu #MamoPracujwIT. Webinar planowany jest na koniec lutego. Nie jestem jeszcze co prawda na pewno ekspertką, bo ciągle jeszcze mam za mało doświadczenia, żeby uczyć kogokolwiek innego. Jednak o ogólnych testerskich zagadnieniach oraz o swojej dotychczasowej drodze do testowania mogę coś przygotować. Może doda to którejś mamie otuchy do próbowania swoich sił w IT. Jednocześnie będzie to dla mnie symbolicznie zatoczenie koła w moim przebranżawianiu. Rok temu oglądałam podobny webinar dla #MamoPracujwIT w swoim domu, w trakcie nauki na WSB. W tym roku znajdę się po drugiej stronie i jest to dla mnie miarą mojego sukcesu w zmianie kariery zawodowej.

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.