Dziś zapraszam na kolejny post z serii Dzień pracy!

Przyjrzymy się jak wygląda rzeczywistość pracy testera oprogramowania w dziale QA (Quality Assurance). Przyjmę też kilka założeń, które realnie wpływają na to jak taki dzień pracy może wyglądać.

Założenia:

• Tester: manualny z elementami automatyzacji na poziomie Junior lub Mid 
• Firma: software house, 50-100 osób
• Zespół: do 10 osób
• Projekt: 6-12 msc, etap implementacji (przed chaosem testów odbiorczych i wdrożenia)
• Model pracy: Praca hybrydowa, 2-3 dni w biurze, reszta zdalnie
• Etat: Pełen etat, godziny standardowe, dopasowane do reszty zespołu
• Inne: Zwinne metodyki wytwarzania oprogramowanie, klient z sektora publicznego

Dlaczego tyle założeń?

No i jak to wygląda?

09:00 – Rozpoczęcie dnia pracy, najlepiej spotkaniem zespołu typu daily (piszę „typu daily”, gdyż nie chcę opisywać sposobu pracy w konkretnej metodyce a tylko zaznaczyć konkretne wydarzenia z danego dnia). Jeśli w biurze – to spotkanie w salce konferencyjnej lub największym pokoju zespołu. Jeśli online to wszyscy widzimy się na zoomie/teamsach. Spotkania wyglądają różne – jeśli prowadzone zgodnie z pewną popularną metodyką projektową  – trwają 15 minut i każdy z członków zespołu wymienia swoje zadania na dany dzień. Jeśli służą omówieniu zadań, wyzwań (czyt. problemów) oraz priorytetów  – potrafią trwać nieco dłużej. Dobrze jest, jeśli w oprogramowaniu pomocniczym typu asana, gitlab czy trello są opisane zadania, przydzielone osoby, określone terminy i priorytety.

Co dalej?

Tester w swoim planie dnia może dostawać różne zadania. Mogą być to zadania zweryfikowania oddawanych funkcjonalności, poprawek, zmian. Wtedy dobrze jest jeśli te zadania pojawiają się w różnego typu systemie pracy grupowej np. gitlab, gdzie na bieżąco spływają realizowane przez dział programistów zadania. W opisie zadania tester powinien mieć założenia dotyczące testowanej funkcjonalności. Mogą być to zadania przygotowania scenariuszy testowych i danych testowych. W zależności od rozbudowania zespołu QA, szczególnie na poziomie mid  –  to tester lub koordynator testerów (w praktyce też często tester…) jest odpowiedzialny również za ułożenie planu testów – testów funkcjonalnych, niefunkcjonalnych, regresji itd. 

Realizacja zadań typu 'przetestuj’ polega na sprawdzeniu zgodności zrealizowanych zmian czy poprawek z założeniami opisanymi przez analityków. W razie stwierdzenia nieprawidłowości zgłasza się uwagi wraz z dokładnym opisem sposobu uzyskania błędu. Takie zgłoszenie trafia z powrotem do działu programistów.  Zadania przygotowania scenariuszy testowych i danych testowych to praca na dokumentach i polega na dokładnym zaprojektowaniu ścieżki przejścia testu wraz z dokładnymi wytycznymi co do wprowadzania danych. Jest to zadania wymagające dokładności oraz pewnej wyobraźni. Trzeba się często postawić na miejscu użytkownika końcowego i wymyśleć, że mimo, że w założeniach pole jest numeryczne z zaokrągleniem do trzech miejsc po przecinku użytkownik będzie chciał koniecznie wpisać osiem. Lub w pole do załączenia załączników typu dokument wstawi 200gb film. Lub zamiast wybrać ze słownika wartość wpisze swoją. Lub w pole Ulica wpisze numery działek bo chce je mieć wyświetlone w adresie. Lub….

Tych 'lub’ może być milion. I od testera zależy na jak wiele pomysłów wpadnie i ile niestandardowych zachowań użytkowników przewidzi. I ile błędów systemu tym samym wychwyci.

I nagle jest 17:00. I jako, że w założeniach mamy etap implementacji projektu to jeszcze wszyscy mają czas. Dla siebie, dla zadań. Można zamknąć komputer.

To jak Ci się rzeczywistość pracy testera w firmie IT podoba?