RELACJA Z RzeQA #10

Dwa notatniki testera. Na jednej stronie napis TestOps w sercu.

Ostatnie spotkanie RzeQA udowodniło po raz kolejny dlaczego warto spotykać się z innymi z branży, a tym razem nawet spoza branży.

Jako pierwsza wystąpiła Zosia Gołębiewska. Tytuł jej prezentacji pokazał dokładnie to, co może stać się podczas procesu rekrutacji: „Jak się zrekrutować, żeby nie zwariować”. Miałam już przyjemność współpracować z Zosią i wszystkie jej porady wzięłam sobie do serca przygotowując się do rozmów o pracę. Jeśli miałabym wymienić te najważniejsze (według mnie) to by były:

  • zawsze się przygotuj,
  • chwal się ale nie kłam,
  • nie oczerniaj byłego pracodawcy, skup się na tym dlaczego chcesz zmienić pracę,
  • nie bój się agencji rekrutacyjnych.

Idąc na rozmowę zawsze warto pamiętać o przeglądnięciu pytań np. z grupy Testowanie Oprogramowania 🙂 lub 111 pytań na rozmowę rekrutacyjną przygotowanych przez Artura Zwolińskiego.

Następnie Sławek Radzymiński przedstawił sylwetkę nowoczesnego testera. Dzięki tej prezentacji dowiedziałam się o istnieniu TestOpsa – roli, do której mam zamiar dążyć 🙂 Polecam do poczytania blog Sławka. Znajdziecie tam m.in. kim jest TestOps i dlaczego warto zagłębić się w tę rolę.

Na tym spotkaniu przedstawiony został również Notatnik Testera – który, jak widać, już posiadam (zdjęcie powyżej) i polecam każdemu testerowi. Nie dość, że jest mnóstwo miejsca na robienie notatek, to w środku można znaleźć inspiracje od znanych osób ze świata testowania oprogramowania. Dochód ze sprzedaży idzie na cele charytatywne, więc szczególnie polecam!

Notatnik testera - informacje o pomocy dla Krzysia.

 

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!

 

RELACJA Z RzeQA #4

Dwa laptopy ustawione naprzeciwko siebie. Z laptopów wychodzą ręce. Jedna podaje drugiej pęk kluczy.

Kolejne spotkanie RzeQA #4 okazało się bardzo pouczające. Mimo niesprzyjającej pogody udało mi się dotrzeć na miejsce i jeszcze przed rozpoczęciem zjeść pyszny sernik.

W pewnym momencie na stoliku pojawiły się napoje energetyczne SJSI – pierwszą moją myślą było, że to jakaś nowość w podnoszeniu jakości testerów. Mi na razie wystarczy certyfikat ISTQB 😉

Tym razem było o dobrych praktykach, które powinny pojawić się podczas badania wydajności systemów. Jak się oczywiście okazało nie ma jednego unikalnego klucza do sukcesu. Pracując przy projektach IT dobrze widać, że aby osiągnąć dany milestone konieczny jest cały pęk kluczy.

  • BIZNES
  • IT
  • DZIAŁ ZAKUPÓW
  • DZIAŁ BEZPIECZEŃSTWA
  • ORGANIZACJE NADZORUJĄCE

To są elementy całości, które udało mi się zapamiętać ze spotkania. Wyczerpująco opowiedział o nich Piotr Ślęzak – człowiek z ogromnym doświadczeniem i tak miły, że zechciał się tym doświadczeniem podzielić z nami 🙂

Rozmowa z biznesem da nam odpowiednie wymagania i ryzyka biznesowe. Dobra komunikacja z IT powinna zaowocować doskonałą znajomością architektury i posiadaniem idealnego środowiska testowego. Odpowiednie przygotowanie do rozmowy z działem zakupów spowoduje, że dostaniemy dokładnie takie narzędzie jakie chcemy i wtedy kiedy chcemy. Przejście przez dział bezpieczeństwa może również okazać się kluczowe. Jak przetestować system, do którego nie mamy dostępu? Osiągnięcie sukcesu zależy od całego zespołu i każda jednostka ma na potencjalny sukces ogromny wpływ. Teemwork jest ważny i warto o tym pamiętać.

Po spotkaniu RzeQA #4 po raz kolejny jestem zdumiona tym ile ludzie wiedzą i ile jeszcze nauki przede mną aby zostać ekspertem w naszej dziedzinie. Chodzenie na meetupy jest równie ważne jak rozwój poprzez doświadczenie, czytanie książek itp..

Na szczęście spadło dużo śniegu i po spotkaniu mogłam wyciągnąć pierwszy raz narty i przewietrzyć umysł na lekko mroźnym powietrzu 🙂 Dużo nowej wiedzy i trochę endorfin to doskonale spędzony urodzinowo-imieninowy dzień 😀

RELACJA Z WEBINARU, RZEQA MEETUP #2 i TEST CAMP

Zdjęcie komputera, kubka z napisem 'wypijmy za błdęy' i kręcący się bączek.

Dlaczego warto oglądać webinary? Bo zawsze się czegoś ciekawego dowiesz i są za darmo . Tym razem tematem był C# dla żółtodziobów. Wydaje mi się, że łatwiej by mi było, gdybym wiedziała ciut więcej o automatyzacji (ciut więcej niż to, że jest). Najważniejszy wniosek dla mnie: uczyć się małymi krokami, dawać sobie na początek małe cele do zrealizowanie, żeby się nie zniechęcić. Dlaczego nie zacznę na razie myśleć więcej o automatyzacji napiszę opowiadając o konferencji TestCamp. Webinar organizowany przez testuj.pl a opowiadał Krystian Brożek.

Kolejnym wydarzeniem, w którym wzięłam udział było spotkanie RzeQA Meetup #2. Pierwsza opowiadała Natalia Krawczyk-Grzegorzewicz o BDD. Ze względu na to, że dopiero zaznajamiam się z ogórkowymi tematami (jak i z wieloma innymi w testowaniu) wszystko wydawało się ciekawe i rozjaśniło mi sporo wątpliwości, które dotychczas się pojawiły. Następnie Karolina Zmitrowicz opowiedziała o znaczeniu jakości wymagań w procesie testowania. Po takich opowieściach aż się chce zostać perfekcyjnym analitykiem 😀

Teraz najwięcej do opowiadania czyli kilka słów o konferencji TestCamp. Przede wszystkim dzięki wielkie testuj.pl! Dobra organizacja i co najważniejsze – nielimitowany dostęp do kawy. Dzięki Wam mam również w czym pić kawę podczas pisania tego postu (patrz na zdjęcie powyżej) a bączek będzie mi łatwo podpowiadał czy po tej kawie zasnęłam czy jednak nie (patrz film Incepcja) 🙂

Ze względu na to, że nasłuchałam się tylu ciekawych dla mnie rzeczy tylko kilka słów o każdej prelekcji:

  1. Emilia Lendzion-Barszcz (JavaGirl.pl) – Hej! Zróbmy sobie testy wydajnościowe!
    Faktycznie zrobiliśmy sobie test wydajnościowy. Fajnie było zobaczyć takie rzeczy na żywo. W bardzo fajny sposób podane informacje na co zwracać uwagę przy tego rodzaju testach, jak ważny jest użytkownik końcowy, skala aplikacji i potencjalny sprzęt. W trakcie bardzo przydatna informacja na temat Onetu 🙂
  2. Paweł Banaszczyk – Pracuje jako tester – i co dalej.
    Na tej prelekcji było w dość przyjazny sposób wyjaśnione w jakie kierunki testowania można iść. Do tego wiadomo już kto jest kim w zespole oraz jak podchodzić do sprawy awansu 🙂
  3. Karolina Zmitrowicz – Rozwój testera – nie tylko ISTQB.
    Tym razem usłyszałam o tym, że warto się certyfikować (potwierdzamy swoją wiedzę). Warto czytać książki (to od zawsze w sumie wiedziałam). Standardy są ważne. Do tego w końcu wiem jak przeczytać IEEE 😀
  4. Piotr Kuljon – Ewolucja od testera manualnego do władcy automatów.
    Piotr opowiedział mnóstwo ciekawych rzeczy o automatyzacji testów m.in. o obszarach i narzędziach. Jakoś nie zrobiłam zbyt wielu notatek w czasie prelekcji, więc najbardziej zapamiętał mi się robot Hans 😀 (ps. też takiego chyba sobie sprawie).
  5. Katarzyna Morawska Kierownik testów – a gdyby tak dać innym potestować?
    Po tej prelekcji nikt nie powinien mieć wątpliwości jak powinien wyglądać dobry kierownik testów!
  6. Karolina Pawłowska – Co zabrać ze sobą na podróż po systemie?
    Po niesamowitej podróży z Karoliną wszyscy znają wady i zalety testowania eksploracyjnego oraz kiedy warto przejść ścieżką krytyczną. Nikt już nie powinien się zastanawiać po co rekruterzy pytają o testy szklanki, krzesła, wanny czy, na pierwszy rzut oka, innej bezsensownej rzeczy.
  7. Andrzej Doliński – Jak rola trenera wpływa na rozwój QA inżyniera?
    Super opowiedziane o tym dlaczego od samego początku warto być aktywnym członkiem zespołu i udzielać się m.in. na warsztatach, prelekcjach (nawet w małej grupie).
  8. Jakub Rosiński – Testowanie “techniczne” – czym jest, czy jest się czego bać?
    Ostateczne wyjaśnienie co oznacza testowanie „techniczne”? Raczej nie, jednak większość przypadków została omówiona i ostatecznie musimy pamiętać, żeby „nie dać się zwariować” 🙂 Tu padło bardzo mądre zdanie: najpierw nauczcie się dobrze testować, później automatyzujcie. Coś w tym jest.

Ogólnie jestem bardzo zadowolona, że się wybrałam. Ciężko czasami przesiedzieć 12 h w pociągu (podróż tam i z powrotem), żeby wybrać się na jednodniową konferencję. Teraz wiem już, że czasami warto. Dzięki wielkie RzeQA za zorganizowanie konkursu, dzięki któremu wylądowałam na TestCampie 🙂

Z tego co wiem mają być udostępnione nagrania z konferencji, więc jeśli komuś nie udało się pojechać życzę miłego seansu 🙂

KONFERENCJE, WARSZTATY, SPOTKANIA CZYLI CZAS NA ROZWÓJ!

Ikonka buga powtórzona wielokrotnie. Dzięki uprzejmości testerzy.pl

Wypoczęta po urlopie biorę się do dalszej pracy. Przejechane ponad 500 km na rowerze dało mi niewyczerpana dawkę endorfin i mam wielkie siły i chęci do działania. Oczywiście w międzyczasie dostałam dobre i złe wieści.

Z tych złych to niestety nie udało mi się dostać na warsztaty Rails Girls z Rubiego. Zapowiadało się fajnie, może innym razem.

Z dobrych wieści udało mi się wygrać wejściówkę na konferencję TestCamp we Wrocławiu z czego się ogromnie cieszę. Relacja z konferencji w przyszłym tygodniu 🙂

A jeszcze w tym tygodniu spotkanie RzeQA.

Poza tym na dzień dzisiejszy ograniczam czytanie teorii. Czas na zaznajamianie się z praktyką. W wielu miejscach pojawia się hasło Mr. Buggy (http://mrbuggy.pl). Oto moje początkowa refleksja – kobieto zwolnij. Chciałam jak najszybciej zainstalować i zobaczyć co to takiego, że nawet mi przez głowę nie przeszło czytanie informacji o instalowaniu środowiska. Włączyłam, jakieś błędy, ale podejrzanie za dużo, podejrzanie zbyt oczywiste. To zabrałam się za czytanie dokumentacji. Zainstalowałam całe środowisko (krok po kroku zgodnie z instrukcją) i Mr. Buggy przestał reagować na uruchamianie! Co za smutek i pech.

Odinstalowałam wszystko. Nadszedł czas na ponowne zrobienie wszystkiego od początku, tym razem tak jak należy.

Jest nieźle. Instalator rusza i pyta się czy na pewno chcę zezwolić aplikacji na zmiany, po kliknięciu ‘tak’ nic się dalej nie dzieje.

Ze względu na to, że skończyły mi się pomysły postanowiłam podzielić się swoim problemem z grupą na Facebooku „Testowanie oprogramowania” (jak dobrze należeć do jakiejś mądrej społeczności!). Okazało się, że możliwą przyczyną jest użycie spacji w nazwie foldera i faktycznie – na początku wrzuciłam plik *.exe do ogólnego foldera (i to był ten pierwszy raz gdy uruchomiłam Mr Buggy i działał), a że lubię mieć porządek przeniosłam później ten plik to foldera o nazwie „Mr Buggy”.

Ze strony technicznej: z tego co zrozumiałam w kodzie musi brakować cudzysłowu, który spowodowałby rozpoznanie pełnej nazwy foldera, w którym znajduje się plik *.exe.

Skoro Mr Buggy się uruchomił i zapoznałam się ze specyfikacją czas na polowanie na bugi!