ROZWÓJ W DOMOWYM ZACISZU

Baner z napisem 'A może by tak C#?'. W tle cząsteczki koronawirusa.

Czas pandemii. Czas długiego przesiadywania w domu. Czas pracy w domu. W ostatnim czasie dowiedziałam się, że mam do kilka opcji:

  • ciąża,
  • alkoholizm,
  • + 10 kg,
  • rozwód,
  • psychiatryk.

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 🙂

 

KIEDY TESTER NIE ŚPI, POMYSŁY SIĘ RODZĄ

Duża żarówka na tle nocnego rozgwieżdżonego nieba.

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.

PIERWSZA WOJNA PRZEGLĄDARKOWA

Logo Microsoft i Nestscape obok siebie.

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

  • telewizja Polsat nadała premierowe wydanie programu Disco Polo Live,
  • utworzono Park Narodowy „Bory Tucholskie”,
  • Włochy objęły prezydencję w Radzie Unii Europejskiej,
  • komputer Deep Blue wygrał pierwszą partię w szachowym pojedynku  mistrzem świata Garrim Kasparowem,
  • Adam Małysz wygrał w Oslo swój pierwszy konkurs Pucharu Świata w skokach narciarskich

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:

  1. Ogromne możliwości finansowe Microsoftu pozwoliły na stworzenie bezpłatnej (dla wszystkich!) przeglądarki internetowej.
  2. Microsoft miał znaczący udział w dostarczaniu systemów operacyjnych, w których domyślną przeglądarką był IE.
  3. Firma Netscape została przejęta przez inną firmę.

Rysunek chłopaka przerywającego wstęgę mety. Za nim dwie ciemne postaci biegnące wolniej.

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.

 

AGILE CZYLI ZWINNY

Zespół składający się z 4 żab.

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:

  1. Upieramy się, że się nie da, bo wcześniej wszystko było ustalone a dokumentacja mówi a i b, no i oczywiście kto to wszystko miałby zrobić?
  2. Po rozmowie z klientem robimy burzę mózgów w zespole (lub robimy ją razem z klientem), ustalamy co, kiedy i jak trzeba zmienić i bierzemy się do pracy 🙂

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.

 

ŚWIĘTA BEZ API

Sanie z reniferami. Na saniach jedzie napis API.

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!

Elf z koszulka z napisem API.

 

 

PALĄCE SIĘ PROJEKTY I O CO CHODZI Z TYM API – PODSUMOWANIE RZEQA #9

Budda na płomieniach. Podpis keep calm and carry on.

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.

  • dokładność
    Jeden z pierwszych punktów, jaki zapisałam sobie podczas prelekcji Emila to dokładnie opisać ‚posypanie’. Cokolwiek robimy, starajmy się robić to dokładnie. Czy jest sens robić platformę e-learningową gdy klient chce sklep, w którym będzie sprzedawał produkty? Walidujmy to co robimy, dopytujmy się klienta, dokładnie opisujmy nasze niepewności i problemy, z którymi się spotykamy podczas projektu. Nie ma znaczenia jak będziemy miłym i fajnym zespołem jeśli nie zapewnimy dokładności.
  • dostępność
    Jeśli się zaczyna palić musimy być dostępni. Słyszałam o wielu projektach, które zaczynały płonąć na produkcji, jednak wiele godzin poświęconych na ratowanie projektu oraz doskonała współpraca spowodowały, że mimo poczucia porażki ze strony zespołu klient był zadowolony i wniebowzięty, ponieważ ostatecznie otrzymał działający, upragniony produkt. Zdecydowanie podczas pożaru warto poświęcić trochę czasu na ratunek dla dobra przyszłej współpracy.
  • partnerstwo
    Musimy płynnie reagować na potrzeby klienta. Wysłuchanie jego potrzeb wraz z szybką reakcją pokazuje, że nam zależy i że razem dążymy do urzeczywistnienia marzeń naszych klientów.
  • porada
    Jeśli klient zmienia setny raz zdanie to nadal musimy zachować spokój. Może warto się zastanowić dlaczego tak jest? W końcu to my mamy być specjalistami od wykonania produktu. Może odpowiednio zaargumentowaną poradą będziemy w stanie skierować klienta na odpowiednią ścieżkę i przygasić buchające emocje.

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.

DOBRE ZMIANY

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!

 

KILKA SŁÓW O QUALITY EXCITES

Basia Kozioł na ściance konferencji z napisami Quality Excites i Future Processing.

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 🙂

Mapa polski z pineskami ile osób z jakiej części polski dotarło na konferencją. Zoom na Rzeszów z dwoma pineskami.

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!