Cześć Październik... nie mam pojęcia kiedy okres letnio-wakacyjny minął... Ale nie wpadajmy w smutki, przed nami piękna jesień i kilka wartościowych artykułów z branży QA 😉 |
|
|
|
#1: Warto doczytać
Masz ciekawy materiał, którym warto się podzielić z innymi? Podeślij go do mnie, odpowiadając na tę wiadomość. Jeżeli okaże się wartościowy, pojawi się w kolejnym wydaniu newslettera. Dzielmy się wiedzą 🙂
|
|
|
|
#2: Kilka ogólnych porad dla przyszłych/nowych Quality Assurance
- Nie bój się zadawać pytań - zarówno tych organizacyjnych, jak i w samym projekcie. "Słuchajcie, ale co się stanie, jeżeli kliknę w ten przycisk, po czym się wyloguję?" czy "Czy ten licznik pobierany jest z serwera czy z czasu lokalnego użytkownika, co się stanie, gdy zmienię czas systemu?" to tylko kilka pytań, które mogą uświadomić Ci, że ich zadawanie jest bardzo potrzebne, rozwija kreatywność zespołu i pokazuje Twoje zaangażowanie. Staraj się tylko zadawać trafne pytania i ich nie powtarzać ;)
- Naucz się dobrze obsługi narzędzi używanych w firmie. Przed pierwszą pracą wystarczy, że rozpoznasz tylko zarys niektórych narzędzi, takich jak Jira. Wiedz jak zarządzać taskami czy tworzyć nowy, jednak gdy już trafisz do pierwszej pracy, postaraj się dobrze rozeznać w używanych tam narzędziach. To usprawni Twoją pracę.
- Pytaj programistów w jaki sposób rozwiązali zgłoszony przez Ciebie problem - to rozwija Twoje umiejętności techniczne i nawet jeżeli z początku tego nie zrozumiesz, to z czasem przyniesie pożytek. W przyszłości pojawią się podobne defekty i będziesz w stanie od razu zaproponować (ale nie narzucać!) jakieś rozwiązanie, przynajmniej ogólne.
- Proś o warsztaty wewnątrzdziałowe. Nic tak nie rozwija jak wspólna nauka, motywacja i dzielenie się wiedzą. Jeżeli ktoś wymiata w testach API - poproś, aby pokazał Ci (a najlepiej całemu zespołowi) jakieś protipy, sztuczki czy dobre praktyki. Ktoś wymiata w wydajnościówce? Poproś, aby podzielił się wiedzą z obsługi narzędzi. To naprawę rozwija. I nie musisz iść we wszystkie specjalizacje, ale warto znać choćby podstawy każdej z nich.
- Gdy już zapoznasz się z procesami w organizacji i miną pierwsze tygodnie w projekcie, pomyśl o rozwijaniu się w jakiejś specjalizacji. Tu możesz wybrać bezpieczeństwo, wydajność, analizę biznesową, dostępność. I nawet jeżeli w firmie, w której pracujesz, nie ma takich specjalizacji, zacznij czytać, ćwiczyć i uczyć się prywatnie. Taka wiedza prędzej czy później się przyda i zwróci. Pomyśl o tym od strony pracodawcy - czy dałbyś podwyżkę osobie, która od trzech lat jest na tym samym poziomie doświadczenia i nie nauczyła się niczego więcej? Może brutalny przykład, ale chciałem Ci pokazać, że to ma sens - również finansowy, ale otwiera też wiele perspektyw i możliwości.
- Integruj się z zespołem projektowym - rozmawiaj, proponuj spotkania typu "kawki" czy wspólne wyjścia na lunch. Ja wiem, że to jest bardzo trudne w przypadku introwertyków (hej! ;) ), ale nie trzeba od razu proponować wyjścia na popijawę. Ot, lunch, rozmowa, nie tylko na temat projektu. To zmniejszy barierę i zminimalizuje ewentualne konflikty, zwłaszcza wtedy, gdy popełnisz jakieś błędy. Staraj się też nie oceniać innych - jeżeli ktoś nie odpisuje przez 2-3 godziny, zaakceptuj to i spróbuj zrozumieć. Może ma deadline, a może ma jakieś przykrości w życiu - tego nie wiesz, staraj się podchodzić z wyrozumiałością do innych (licząc na to samo w Twoim przypadku, gdy życie da w kość).
- Naucz się dobrze testować manualnie, zanim zaczniesz naukę automatyzacji. Aby dobrze automatyzować, trzeba znać metody i podejście w testowaniu manualnym. No bo jak zautomatyzować coś, czego nie potrafisz zrobić? ;)
- Pamiętaj, że automatyzacja to nie jest święty Graal. Owszem, jest tu bardzo dużo ofert pracy, ale po pierwsze - to nie jest następca testowania manualnego (to po prostu coś innego), a po drugie - istnieje wiele innych dziedzin, gdzie nie automatyzujesz - choćby analiza biznesowa czy testy bezpieczeństwa, które w dużej mierze opierają się na pracy manualnej. Oczywiście w każdej dziedzinie można coś zautomatyzować, dlatego przyszłościowo warto znać podstawy jakiegoś języka programowania - Python, JS czy Java to dobre i popularne wybory, ale możesz też poczytać i wybrać coś innego. Jeżeli jednak idziesz w kierunku testowania manualnego, skup się najpierw na tym, a gdy to opanujesz, rozbuduj swoją wiedzę o kolejne elementy, jak chociażby tę automatyzację.
- Dobrze opisuj zgłaszane defekty. Ja wiem, że czasami wystarczy tytuł i brak opisu (o zgrozo, nadal się z tym spotykam...) i można powiedzieć "ale ja wiem o co chodzi". I to jest prawda. Ale wyobraź sobie, że idziesz na urlop i ktoś Cię zastąpi. Co on ma z tym zrobić? Albo że wlatuje to do backlogu i powróci po sześciu miesiącach - będziesz jeszcze pamiętać o co tam chodziło? Opisuj dobrze kroki do odtworzenia, nie bój się screenów czy nawet krótkich nagrań wideo - to naprawdę pomoże. Nie zapomnij też wspomnieć gdzie zostało to odtworzone. Bug na Firefoxie niekoniecznie będzie dostępny również na Chrome.
|
|
|
|
#3: Symulacja rozmowy rekrutacyjnej
Mniej więcej w okolicach premiery szkolenia, zostanie uruchomiona nowa usługa - symulacja rozmowy rekrutacyjnej. Możesz się dowiedzieć o tym więcej z tej strony.
|
|
|
|
Podobał Ci się dzisiejszy QA Weekly? |
|
|
|
|
|
|
|
|
|
|
Zawiódł mnie |
|
Niespecjalnie |
|
Może być... |
|
Bardzo fajne |
|
Genialne i wartościowe! |
|
|
|
|
|
|
|
|