W lipcu 2017 r. postanowiłam rozpocząć przygodę z testowaniem oprogramowania. Jestem zwolenniczką podejścia TestOps i uwielbiam ciągle uczyć się nowych rzeczy. W wolnej chwili czytam książki albo spaceruję z psem.
Taki mały kod piątkowy.
Teraz czas na celebrowanie kolejnego piątku w zaciszu domowym.
Chociaż dzisiaj może nie być cicho. Umówiłam się ze znajomymi na drinka. Mam nadzieję, że WhatsApp pociągnie kilkuosobową wideokonferencję 😀
Ps. Ostatnio zrobiłam tę polentę. Całkiem smaczna wyszła. Miłego i zdrowego weekendu!
Czas pandemii. Czas długiego przesiadywania w domu. Czas pracy w domu. W ostatnim czasie dowiedziałam się, że mam do kilka opcji:
Jednak żadna z tych opcji jakoś mi nie podpasowała.
W jednym z ostatnich wpisów pisałam, że czas się wziąć do dalszej nauki. Szczęśliwym trafem pracuję w bardzo fajnej firmie, która bardzo dba o rozwój pracowników. Jeśli chcesz dowiedzieć się więcej, polecam artykuł o upskillach na blogu PGS. I tuż przed ogólnymi wskazaniami do pracy w domu rozpoczęłam upskilla z C#. Zastanawiając się wiele razy, który język programowania wybrać miałam na uwadze: pracuję w dwóch projektach C# i mam męża programistę, który właśnie w tym języku pisze. Ze względu na to, że bardzo kocham swojego męża, java raczej nie wchodziła w grę 😀
W trakcie nauki trafiłam na dwa świetne kursy. Pierwszy to „What Is Programming?” Polecam wszystkim, którzy mają cokolwiek wspólnego z wytwarzaniem oprogramowania. Simon doskonale wyjaśnia podstawowe aspekty programowania bez wgłębiania się w tematykę konkretnego języka. Nieważne więc czy marzysz o C#, C++, Python, Javie czy JavaScript czy jeszcze innym cudzie – ten kurs jest dla Ciebie! Niecałe 3 godziny, które zdecydowanie będą bardziej fascynujące niż niejeden serial na Netflixie 🙂
Drugi z kolei kurs to Understanding C#. Super wyjaśnione podstawy języka C#. Polecam korzystanie z dwóch monitorów – ja na jednym oglądałam, a na drugim od razu stawiałam pierwsze kroki w Visual Studio.
Co dalej? W tej chwili robię dużo zadań, żeby utrwalić poznane zagadnienia i rozwijać programistyczny zmysł 🙂
A teraz czas na przerwę od komputera – idę zrobić polentę 😀 Ile to już razy patrzyłam na nią w książce kucharskiej i myślałam ‚kiedyś zrobię’. Dzisiaj w końcu nadeszło to kiedyś.
A jak Wam idzie koronawirusowa izolacja społeczna?
Bądźcie zdrowi i zostańcie w domu. Chyba że, tak jak ja, macie psa. Wyjdźcie na spacer z psem i potem już zostańcie w domu 🙂
Niedawno dostaliśmy buga z UAT. Po północy występuje błąd podczas przesyłania requestu. Okazało się, że frontend i backend mają inny format daty i gdy jeden system twierdzi, że jest 00:01 to drugi nadal rozumie to jaki 23:01. Podczas prac deweloperskich szukałam odpowiedniego podejścia do testów. Przecież moje zrównoważone lenistwo nie pozwala na dopuszczenie myśli o siedzeniu po północy i robieniu testów…
Podejście pierwsze:
Po wielu konsultacjach (tu okazuje się, że oprócz internetów warto mieć bardziej doświadczonych ludzi w firmie, do których można zwrócić się o szybką poradę) miałam możliwość przestawienia czasu na maszynach Azurowych, do tego przestawiłam czas na swoim komputerze. Nadszedł czas na testy! Niestety, okazało się, że zewnętrzne systemy, z którymi się komunikujemy, w takich warunkach wysypują się. Po głębszej analizie okazało się, że tak tego nie ogarniemy…
Podejście drugie:
Moje zrównoważone lenistwo zostało zachwiane i przez dwa dni z rzędu robiłam testy po północy. Okazało się, że poprawki nie okazały się wystarczające i czekają mnie kolejne takie testy. To zrodziło kolejne przemyślenia na temat optymalizacji takich testów. To poprowadziło do…
Podejście trzecie:
Napisać test automatyczny, który odpali się po północy. Rano przyjdę wyspana i szczęśliwa do pracy i będę wiedzieć, czy bug został naprawiony czy jeszcze nie. Jest tylko jeden mały problem. Nie potrafię tego zrobić. I tak nocne testowanie doprowadziło mnie do wniosku: mimo że testowanie manualne sprawdza się w wielu projektach (m.in. w tych, w których miałam okazję pracować), jednak czasami trafi się na problem, przy którym napisanie testu automatycznego bardzo ułatwi pracę i życie 🙂 Czas się w takim razie wziąć do dalszej nauki.
Ostatni czas nauki zainspirował mnie do podróży w czasie. Pamiętam swój pierwszy graficzny program – piksele, które można było zaznaczać na czarno albo biało, a były tak duże, że były baaardzo widoczne 😀 nie pamiętam jaki to był system ani jaki program, ale pamiętam ile radości mogło to dać kilkuletniemu dziecku szybkie ‚mazanie i rysowanie’ kwadratów 😀
Przeglądając Wikipedię znalazłam, że rok 1999 to m.in.:
Z kolei czytając niedawno „JavaScript Programowania obiektowe” Stoyana Stefanowa natrafiłam na ciekawą wzmiankę dotyczącą roku 1999:
rozpoczęła się Pierwsza Wojna Przeglądarkowa!
Każda wojna rodzi ofiary. Zobaczmy co mogło paść ofiarą Pierwszej Wojny Przeglądarkowej.
Walka zaczęła się jednak wcześniej. Już w roku 1995 było dwóch gigantów i wielka walka o udziały w rynku. Z jednej strony Netscape z najbardziej popularną przeglądarką, z drugiej strony Microsoft z Internet Explorer 1.0 i ogromnymi finansowymi możliwościami. Obie firmy starały się jak mogły, aby pozyskać klientów. Są to również czasy, w których język JavaScript zyskał najgorszą reputację. Język, który pozwalałam stwarzać przeokropne animacje, migające napisy, wibrujące okienka itd. ostatecznie został uznany za straszny kicz przez poważnych programistów ustandaryzowanych języków. Kto ma więcej migających okienek ten lepszy? – Nie koniecznie 😀
Ostatecznie trzy główne czynniki przesądziły o losie wojny:
Pierwsza Wojna Przeglądarkowa skończyła, gdy Microsoft nie miał już godnych uwagi przeciwników. Internet Explorer 6.0 został zwycięską przeglądarką. Przez pięć kolejnych lat nie było kolejnego wydania przeglądarki, co wydaje się w tamtym czasie nie do pomyślenia. Niektóre źródła twierdzą, że dzięki temu usystematyzowały się standardy JavaScript a inni producenci mogli w spokoju doganiać możliwości IE. Jak większość z nas wie, udało im się to. Czytając o historii tej walki nie wiem czy to zwycięski Internet Explorer nie jest największą ofiarą tej Wojny – wystarczy zobaczyć statystyki. Czy Microsoft usiadł na laurach na pięć lat? Jeśli tak, to po analizie statystyk naszą lekcją po Pierwszej Wojnie Przeglądarkowej niech będzie – nigdy nie spoczywajmy na laurach żyjąc w świecie IT.
Zwinność w wytwarzaniu oprogramowania jest bardzo na czasie. Czy słusznie? Moim zdaniem zdecydowanie tak!
Według Manifestu Agile mamy cztery zasady:
ludzie i współpraca > procesy i narzędzia
działające oprogramowanie > obszerną dokumentację
współpraca z klientem > formalne ustalenia
reagowanie na zmiany > podążanie za planem
Zawsze jak widzę te cztery punkty to i tak zlewają mi się w jeden. Wyobraźmy sobie, że klient zmienił zdanie i chce wprowadzić zmianę. Mamy teraz dwa warianty:
Druga opcja wydaje się bardziej przyjazna dla wszystkich, nieprawdaż?
W swojej niedługiej karierze miałam okazję poznać Waterfall i Agile. Jakie różnice były przeze mnie najbardziej zauważalne? Nie różnice w dokumentacji, nie różnice w procesach (chociaż to też było). To byli przede wszystkim ludzie. Od kiedy pracuję w metodykach zwinnych widzę ludzi, którzy chcą rozmawiać, chcą współpracować, do których mogę codziennie podejść i podyskutować o problemach. To są ludzie, do których można dotrzeć nie tylko poprzez oficjalne maile. Tworzymy oprogramowanie jako zgrany zespół i to jest super!
Od dziś, jako certyfikowany zwinny tester oprogramowania, polecam wszystkim podejście „cały zespół” – nic się nie traci, można tylko zyskać 🙂
Co do samej certyfikacji ISTQB Agile Tester Extension mam wiele różnych przemyśleń, ale to na inny raz.
Czas przedświąteczny to czas spędzony w otchłaniach Internetu na poszukiwaniu odpowiedniego prezentu. Dawno, dawno temu musieliśmy w tym celu ruszyć się z domu (teraz oczywiście również istnieje taka opcja) i chodząc od sklepu do sklepu mogliśmy porównywać produkty i ich ceny. Troszkę mniej dawno temu pojawiły się sklepy internetowe i okazało się, że te same produkty można kupić nie wychodząc z domu. Ale jak przejrzeć dziesiątki sklepów, porównać ceny interesującego nas produktu, ceny dostawy, rodzaje przesyłki. Krótko mówiąc, było to również czasochłonne, o tyle pewnie milsze od podróży do sklepu, że można było to robić pod ciepłym kocykiem w domu. A już całkiem niedawno temu pojawiły się serwisy typu ceneo, skąpiec itp. Niech nas wyobraźnia całkiem poniesie i wyszukajmy ulubiony prezent każdego człowieka – świąteczne skarpetki. Dzieje się małe świąteczne czary mary i widzimy listę skarpetek, które możemy sortować, filtrować i sprawdzać najlepsze metody zakupu upragnionych skarpetek!
Wyobraźmy sobie, że mamy już wszystkie te nasze kochane skarpetki (i to w najlepszych cenach!). Dowiedzieliśmy się gdzie sprzedają dobre i tanie choinki, a teraz postanowiliśmy ubierać choinkę i chcemy posłuchać przy tym największych świątecznych hitów. Odpalamy YouTube albo Spotify i wpisujemy to, na co mamy ochotę. Po niezwykle krótkim czasie, można by powiedzieć w magiczny sposób, dostajemy to co chcieliśmy i w rytmie Last Christmas wieszamy łańcuchy i bombki.
A co robimy po ubraniu choinki? Jesteśmy tak wyczerpani i wygłodniali, że jedyne co nam pozostaje to otworzyć aplikację pyszne, wyszukać otwarte restauracje, wybrać kuchnię, na którą akurat mamy ochotę, zamówić upragniony posiłek, zapłacić online i czekać cierpliwie na dostawę.
W świątecznym czasie API kojarzy mi się ze Świętym Mikołajem i elfami – najlepszymi pomocnikami świata. Wyobrażam sobie wszystkie API jako właśnie takie elfy, które dostały od nas zapytanie i biegają po całym Internecie w poszukiwaniu odpowiedzi. Czy to będzie najwygodniejsze skarpetki, najfajniejsza świąteczna piosenka, najlepiej oceniana pizza w mieście – API znajdzie wszystko!
Czy możemy wyobrazić sobie święta bez API? Chyba już nie!
Na ostatnim w tym roku wydarzeniu RzeQA mieliśmy dwóch prelegentów. Emil Bakalarz opowiadał nam o tym jak czasami musimy stać się dzielnym strażakiem Samem. Emilia Lendzion-Barszcz poruszyła temat testowania API.
W trakcie opowieści Emila o płonącym projekcie przypomniałam sobie ponownie o książce Po pierwsze: Złam Wszelkie zasady (pewnie niejednokrotnie będę wracać do tej książki – zdecydowanie polecam zapoznanie się z tą pozycją). Autorzy wspominają o czterech oczekiwaniach klientów, które muszą być spełnione aby można osiągnąć sukces podczas współpracy. Te cztery punkty wydają się spójne z tym co usłyszeliśmy od Emila.
Najważniejsze – zachowajmy spokój i rozmawiajmy!
Jak wspomniałam wyżej Emilia Lendzion-Barszcz opowiedziała nam o testowaniu API (Application Programming Interface). Bardzo spodobało mi się to, jak Emilia opowiadała o swoim pierwszym zetknięciu z SoapUI. Coś w stylu siadaj i rób 😀 – ja miałam jedynie taką przewagę, że miałam blade pojęcie o XML. A jak to było u Was? To chyba też jest dobra lekcja dla wielu z nas na przyszłość – jeśli każecie testować niedoświadczonej osobie w SoapUI, poświęćcie wtedy kilka minut na wyjaśnienie co tak naprawdę robimy i o co w tym wszystkim chodzi. Wydaje mi się, że wiele razy bezsensownie zmieniałam payloady i klikałam zielony trójkącik, aby dostać upragniony pozytywny wynik 😀 Może o samym API napiszę innym razem coś więcej.
Dziękuję prelegentom za ciekawe opowieści z testerskiego świata.
W czerwcu pisałam o tym, że byłam na konferencji Quality Excites. Napisałam wówczas „Więc już myślę o swojej liście rzeczy, które chcę osiągnąć i wprowadzam w życie zdecydowane DO IT NOW.”.
Polecam wszystkim wystąpienie Roba, który zmotywował mnie tamtego dnia do tego, aby coś zmienić.
Między innymi dlatego dzisiaj wykorzystuję przysługujący mi w pracy urlop i od piątku idę do nowej pracy 🙂
Wspaniałą wizję firmy, do której idę, przedstawia CEO Wojciech Gurgul. Mam nadzieję, że za te 3 lata faktycznie będę po prostu świetna, a moja wiedza i umiejętności będą wnosić jakość.
Wojtek Gurgul o przyszłości PGS – link do nagrania
Aż by się w tym momencie chciało powiedzieć: quality excites 😀
To jest doskonały przykład z życia wzięty dlaczego warto jeździć na konferencje. W końcu, jak mawia Dirk Gently „everything is connected”.
Wracam do urlopu. Stay tuned – 9 listopada kolejna RzeQA!
W ostatnią sobotę w Gliwicach odbyła się konferencja Quality Excites. Na szczęście organizatorzy zadbali o miejsce blisko zjazdu z autostrady i poranna kawę, więc od pierwszych wykładów byłam w pełnej gotowości na nową dawkę wiedzy.
Organizatorzy zadbali również o to, abyśmy nie nudzili się również między wykładami. Próbowaliśmy zapobiec apokalipsie bugozombie i manualnie oznaczaliśmy się na mapie – fajna alternatywa do meldowania się online 🙂
Była to moja druga konferencja testerska od kiedy zostałam testerem, więc może nie mam dużego odniesienia, ale moim zdaniem zdecydowanie warto było ruszyć się z łóżka przed piata raną. Z samego rana przypomniałam sobie, że agendę czytałam jakiś tydzień temu i totalnie nie pamiętam, na które wykłady się zdecydowałam – mały początek apokalipsy. I to organizatorzy też chyba przewidzieli – stworzyli aplikację, dzięki której przypomniałam sobie szybko co sobie zaplanowałam i ułożyłam w ładny plan konferencji.
Pierwsza prelekcja była wspólna dla wszystkich uczestników. Rob Lambert opowiedział o kimś, kim zdecydowanie nie chcę zostać za kilkanaście lat – marudnym, narzekającym na wszystko testerem. Więc już myślę o swojej liście rzeczy, które chcę osiągnąć i wprowadzam w życie zdecydowane DO IT NOW.
Daniel Dec opowiedział o tym, co może powodować straty i jak tego wszystkiego unikać.
Mateusz Pieszczak pokazał, jak kraść miliony i to, że niestety użyteczność nie zawsze idzie z bezpieczeństwem.
Aleksandra Kornecka uzmysłowiła mi, że intuicyjność obsługi urządzeń mobilnych skądś się bierze.
Na panelu dyskusyjnym Michała Buczko stworzyliśmy mind-mapę i poznałam kilka ścieżek rozwoju kariery testera, o których do tej pory nie myślałam.
Emilię miałam okazję posłuchać drugi raz i ponownie się nie zawiodłam. Emilia po raz kolejny udowodniła, że warto mieć cierpliwość do testów wydajnościowych.
Przemek Sech mówił o różnie rozumianej jakości i o tym, o czym czasami można zapomnieć – wszyscy mamy wspólny cel, którym jest służenie naszemu klientowi.
Tomek Dubikowski opowiedział o problemach wydajnościowych (nie tylko tych w Biedronce) i dlaczego JMeter może zejść na drugie miejsce.
Adam Stasiak pokazał różnice w testowaniu Androida i IOSa oraz przekonał mnie, że zmiany trzeba przytulic jak króliczka 😀
Na koniec wystąpił Paul Gerrard. Opowiedział o możliwej przyszłości testownia, o tym, że waterfall nie jest najlepszym podejściem do wytwarzania oprogramowania i że Agile to pewnie nie koniec dobrych zmian.
Pozostałych wykładów nie wysłuchałam – niestety nie mam jeszcze zdolności do bilokacji. Jednak kamerę zauważyłam, więc mam nadzieję, że pozostałe wykłady zobaczę w niedalekiej przyszłości.
W całej konferencji ostatecznie widzę tylko dwa minusy:
– musiałam w sobotę rano wstać,
– źle się zorganizowałam i nie zostałam na after party.
Mam nadzieję, że do zobaczenia za rok!
