Cześć ochujales?,

sto dwudzieste wydanie rozpoczynamy z przytupem!

Temat przewodni: co robić i jak żyć, gdy jesteśmy jedynymi QA w projekcie, a każdy wokół naciska na wszystko co wyczytał na reddicie, medium, linkedinie i w ofertach u konkurencji? 

Będzie też sporo naprawdę ciekawych artykułów, m.in. o bugu w GTA: San Andreas, zarządzaniu niewydajnymi pracownikami czy o scamie na githubie. 

Jeżeli mail jest ucięty, kliknij na dole w "pokaż całą wiadomość". Dotyczy głównie Gmaila.

Przypominajkowo, jest już szkolenie, które zwiększy Twoje szanse na wygraną w procesie rekrutacji. Zwiększy Twoje szanse na utrzymanie stabilności finansowej.

Jeżeli jesteś na okresie wypowiedzenia, szukasz nowej pracy i chcesz powalczyć z "nietypową" sytuacją na rynku - to szkolenie może być dla Ciebie. 

Może, ponieważ nie jest ono dla każdego. Jest to materiał eksperymentalny. Jest prawda, są przekleństwa i jest dużo bezpośredniości. I już kilka osób się tym uraziło. Choć ostrzegałem. Ale jeszcze więcej osób pokochało ten styl. 

Konkretnie. I do celu. Pod warunkiem, że pójdziesz za procesem. A nie będziesz przeklikiwać kolejne lekcje bez ćwiczeń. 

Bycie jedynym specjalistą od jakości (Quality Assurance) w projekcie to wyzwanie, które wymaga nie tylko technicznej wiedzy, ale też dobrej organizacji pracy, priorytetyzacji oraz umiejętności komunikacji. W tej sytuacji rola QA wykracza daleko poza “klikanie test case’ów”. 

Przyjrzyjmy się najpierw potencjalnym problemom.

Czyli jak żyć?

• Stosuj matryce ryzyka - przeanalizuj, które scenariusze, funkcje, ścieżki użytkownika są kluczowe i najbardziej podatne na usterki. Nie tylko te techniczne, ale przede wszystkim biznesowe. Zaplanuj działania QA głównie tam. Pomiń mniej istotne obszary. Czasami trzeba podjąć odpowiednie ryzyko. Albo "zawsze".
• Wspólnie określ minimalny poziom pokrycia testami (Minimum Viable Test Coverage) - uzgodnij z zespołami, co OBOWIĄZKOWO testujecie (krytyczne funkcje, integracje, płatności, logowanie etc.), a co jest “mile widziane”. Wkręć do tych rozmów KONIECZNIE Project Managera oraz Klienta.

• Code Review pod kątem testowalności i jakości kodu - zachęcaj devów do pisania testów jednostkowych i integracyjnych. Skup się na pracy zespołowej nad jakością. Dobre code review to również coś, co pomoże Ci zapanować nad chaosem niejakości. Warto również cyklicznie audytować czy wykonywane code review oraz testy są jakościowe i spełniają swoje założenia - spiszcie te założenia, by móc na czym opierać rozmowy i badania.
• Ustal standardy DOR/DoD - bez przejścia testów (jednostkowych), kod nie idzie dalej. Po prostu. Bez wyjątków. Jeden wyjątek to kula, która zaraz zmieni się w lawinę. Uwierz mi. Wiem to z doświadczenia. Konkretnie porozmawiaj o tym z zespołem.

• Wybór kluczowych scenariuszy do automatyzacji - Skup się na najważniejszych, najczęściej powtarzanych testach end-to-end (np. “happy path”) zamiast próbować zautomatyzować wszystko naraz. Pod warunkiem, że w ogóle znajdzie się przestrzeń na automatyzację. Jeśli nie - trudno. 
• Automatyzuj lokalnie, wdrażaj stopniowo - zaczynaj od prostych skryptów, integruj z CI/CD.
• Dokumentuj nowe testy, by zbudować bazę wiedzy dla nowej osoby - skup się jednak na bardzo wysokopoziomowych informacjach. Zamiast "kliknij przycisk "dalej" umieszczony w prawym dolny rogu" wpisz "kliknij przycisk". Po prostu. KAŻDY szczegół to dodatkowe GODZINY w przyszłości, by to utrzymać. 

• Raportuj regularnie ograniczenia - Informuj Product Ownera/Managera o limitach związanych z brakiem automatyzacji, ryzyku regresji, brakiem czasu, nierealnych deadline'ach itd. Informuj o WSZYSTKIM. Spisuj te problemy. Gdy pojawi się ich więcej, będzie można to pokazać na spotkaniu i przemyśleć co dalej. Pamiętaj, że biznes lubi wyniki, badania, tabelki, dokumenty, raporty. 
• Zaangażuj się w planowanie sprintów - podkreślaj realną ilość pracy QA przy określonym przydziale zadań. Dodaj czas QA do estymacji każdego zadania. Jeżeli programista wycenia coś na dwie godziny, a Ty na godzinę testów, wyestymujcie to na trzy godziny. W estymacji uwzględnijcie wszystko: programowanie, testy, aktualizację dokumentacji, stworzenie raportu, konfigurację środowiska produkcyjnego. Czasami wystarczy dodać subtaska. Ale zawsze to wszystko musi być transparentne. 

• Wdrażaj narzędzia pomagające w testowaniu, np. manualne checklisty, “session-based testing”, lekkie narzędzia do raportowania bugów. Czasami zwykła tabelka na Confluence jest lepsza niż kombajnowy plugin do Jiry, który wymaga od nas tańców przy świetle księżyca. Więcej o tym pisałem w e-booku.
• Dbaj o wiedzę w zespole - dziel się dobrymi praktykami QA, podpowiadaj devom jak pisać lepsze testowalne funkcje, uświadamiaj klienta. A często nawet PMa czy PO.