Przykładowy obraz standardów pracy testera w Software House

Tak jak sugeruje tytuł, poniższy tekst dotyczy spisu obowiązków, dobrych praktyk i organizacji pracy testera, ale w jednej konkretnej firmie typu Software House. Każda inna firma tego typu, ale również “produktowa”, będzie miała ten proces, czy praktyki różne, bliższe własnym potrzebom czy rytmowi. Pomyślałam, że może to być przydatna ściąga dla początkujących testerów, bo stanowi pewien zbiór moich doświadczeń w takiej właśnie firmie. Dzielę się, weźcie z tego, co tylko chcecie :).

Software House

Moje doświadczenie jako testera sięga dopiero roku i jest związane jak na razie tylko z jedną firmą, właśnie Software Housem. Stąd też poniższe wskazówki odnoszą się wyłącznie do niego. Co wyróżnia ten konkretny ale i być może inne Software Housy od firm, które mają swój własny produkt? Przede wszystkim Software House walczy o klientów, podając często niższe ceny i krótkie terminy realizacji, by stać się konkurencyjnym na rynku. Musi więc zapewnić sobie mocny marketing i wielu Project Managerów, by każdy zdobyty klient został odpowiednio zaopiekowany. Podam kilka plusów i minusów z mojego własnego doświadczenia:

Plusy pracy w Software House

• gdy firma ma klientów, tester ma sporo pracy, która w dodatku jest różnorodna, bo i projektów jest dużo,
• można odpocząć lub nabrać dystansu od projektu, wchodząc chwilowo w inny,
• można nauczyć się działać pod presją czasu, która skłania go do szybkiej inicjatywy i dbałości o sprawną komunikację w zespole,
• zdobywa się dużo doświadczenia w projektach o różnej wiedzy domenowej.

Minusy pracy w Software House

• często panuje chaos i kłopoty z organizacją czasu zespołu,
• zdarza się nie wyrobić z projektem na wyznaczony termin,
• krótki czas na testy może obniżyć jakość produktu,
• klienci, którzy nie zawsze rozumieją własny produkt/pomysł lub nie ma z nimi dobrego porozumienia.

Obowiązki testera pracującego w Software House

Testerzy dbają o jakość dostarczanych produktów w następujący sposób.

1.  Zaznajamiając się z wymaganiami klienta poprzez:

• Dokumentację projektu (wykluczanie nieścisłości, dopytywanie o funkconalności, by nie popełnić błędów już na tym etapie).
• Stories (historyjkami użytkownika), czyli dołączonymi do projektu wymaganiami biznesowymi, ułożonymi w krótki opis wymaganej funkcjonalności.
• Bezpośredni kontakt z Project Managerem, który odpowiada za projekt i bezpośredni kontakt z klientem.
• Bezpośredni kontakt z klientem (opcjonalnie, w porozumieniu z Project Managerem).

2. Przeprowadzając testy eksploracyjne, czyli sprawdzając w pierwszej kolejności najważniejsze funkcjonalności, jeśli jest na to przeznaczone niewiele czasu.

3. Przeprowadzając testy funkcjonalne, czyli sprawdzając funkcjonalności oficjalnie oddane przez programistów do testowania.

4. Przeprowadzając testy regresyjne poprzez:

• Pisanie i uruchamianie testów automatycznych o zgodnych z wymaganiami asercjach (np. Smoke Testów i Sanity Testów).
• Aktualizację Test Case’ów w danym projekcie (o ile są w danym projekcie).
• Wykonywanie Stories (o ile są w danym projekcie).
• Ponowne sprawdzenie wymagań dokumentacji projektu pod kątem ewentualnych aktualizacji (o ile dokumentacja jest w danym projekcie).

5. Zgłaszając błędy w programie typu bugtracker, zaznaczając wszelkie istotne dla zgłoszenia informacje i labelki.

6. Wykonując retesty poprawionych zgłoszeń, które w zależności od wyniku, akceptują lub zwracają do poprawy.

7. Przestrzegając i kontrolując przebieg zgłoszeń poprzez:

• Sprawdzanie zgłoszeń określonych labelką przeznaczoną dla testerów (każda firma ma swoje flow nadawania labelek).
• Komunikację potrzeby aktualizacji systemu.
• Komunikację potrzeby pilnej naprawy zgłoszeń określonych labelką “CRITICAL”.

8. Tworząc przypadki testowe (o ile zostało to wcześniej ustalone z zespołem i jest na to czas).

9. Ustalając z zespołem lub PM projektu sposób raportowania swojej pracy (o ile jest taka potrzeba).

10. Przeprowadzając testy na najpopularniejszych przeglądarkach lub takich, które są zawarte w umowie z klientem (dotyczy to również wersji przeglądarek, czasami się zdarza, że firma wspiera kilka wersji wstecz). Przeglądarki np. Chrome, FireFox, Safari, Opera, MS Edge, Internet Explorer.

Zgłaszanie błędów

Tester w firmie jest odpowiedzialny za zgłaszanie błędów, może również sugerować ulepszenia. Poniżej opisano typy zgłoszeń:

1. W pierwszej kolejności, należy zgłaszać wszelkie błędy, które uniemożliwiają korzystanie z aplikacji (błędy krytyczne).
2. Priorytetem są również wszelkie zgłoszenia dotyczące niezgodności z dokumentacją/stories. Przykład: dokumentacja zakłada, że użytkownik nie może edytować swoich danych, ale obecnie aplikacja to umożliwia.
3. Błędy stylistyczne, ortograficzne, literówki, błędy związane z wyglądem strony – najczęściej o niskim priorytecie, natomiast zdarzają się klienci, dla których literówka jest błędem krytycznym, należy wówczas uwzględnić jego potrzeby.
4. Propozycje ulepszeń pod kątem UX, logiki, intuicyjności poruszania się po aplikacji – Pomysły czasem są dosprzedawane klientowi, jeśli widzi w nich sens i pożytek dla siebie. W zależności od decyzji klienta, Project Manager może zamknąć zgłoszenie lub zmienić labelkę. Nie wszystkie pomysły trafiają do klienta, decyduje o tym Project Manager.

Jakie informacje powinno zawierać zgłoszenie?

Każde zgłoszenie MUSI zawierać:

1. Dokładną ścieżkę reprodukcji błędu, która będzie zrozumiała dla osób technicznych i nietechnicznych. N​iektóre kroki mogą wydawać się pozornie nieistotne, ale mogą okazać się krytyczne dla wystąpienia defektu, na przykład przechodzenie z jednej zakładki do drugiej.
2. Dane testowe i dostępowe (konto, dane logowania, ewentualnie typ/rola konta), jakimi tester posłużył się, by wywołać błąd.
3. Środowisko testowe (np. DEV, RC, PROD), każda firma ma swoje standardy odnośnie do środowisk, na których tester może działać. Czasem bywa tak, że DEV jest placem zabaw dla programistów, RC dla testerów, a PROD dla klienta. Czasem dodaje się tzw. Stage, który jest kopią produkcji – daje on bardziej rzetelne wyniki testów.

Dodatkowo programiści rozdzielają repozytoria na frontend i backend, co oznacza, że błędy powinny być zgłaszane zgodnie z ich przyczyną na odpowiednie repozytorium. Nie zawsze oczywistym jest czy błąd spowodowany jest przez frontend lub backend, w związku z tym dobrze, żeby zgłoszenia były konsultowane z programistami.

By odpowiednio rozróżnić zgłoszenie, należy posłużyć się narzędziami developerskimi przeglądarki (zwłaszcza Response oraz Headers: Payload, Request URL, Request Method, Status Code). 

Interesujące dla zgłoszeń frontendowych jest między innymi (choć jest to również zależne od rodzaju zgłoszenia):

1. przeglądarka i jej wersja,
2. system operacyjny,
3. rozdzielczość ekranu,
4. Headers: Payload (w postaci pełnego Json’a.), Request URL, Request Method, Status Code,
5. Console.

Interesujące dla zgłoszeń backendowych jest między innymi (choć jest to również zależne od rodzaju zgłoszenia):

1. Response,
2. Headers: Payload (w postaci pełnego Json’a.), Request URL, Request Method, Status Code, Authorization.

Interesujące dla zgłoszeń aplikacji mobilnych jest między innymi (choć jest to również zależne od rodzaju zgłoszenia):

1. wersja aplikacji mobilnej,
2. urządzenie, na którym testowano,
3. dane dostępowe i adres panelu (spięcie aplikacji mobilnej i panelu) do odtworzenia błędu.

Niezmiernie istotne jest, by tester po każdej aktualizacji testował produkt:

• korzystając z przeglądarki w trybie incognito,
• dbając o to, by wyczyścić cache przeglądarki, jeśli nie korzysta z trybu incognito.

Dobre praktyki zgłaszania błędów

Kilka dobrych praktyk:

Tytuł zgłoszenia

Z jednej strony krótki i zwięzły, ale nie może być też zbyt ogólny. Programista powinien od razu po tytule wiedzieć z jakim typem błędu ma do czynienia. Dla przykładu nazwa defektu “problem z mailem” nie mówi za wiele. Brakuje odniesienia do tego gdzie znajduje się ten błąd i na czym polega, dlatego zgłoszenie​ powinno zawierać skróconą ścieżkę reprodukcji oraz możliwie trafny krótki opis, po którym każdy w zespole będzie mógł łatwo odnaleźć zgłoszenie,

Duplikaty

Zdarzają się nie tylko testerom (zarówno tester duplikuje czasem sam siebie lub innego testera), ale i PM oraz programistom. Często wynikają z nieodpowiedniego nazewnictwa lub po prostu długiej przerwy w pracy nad projektem. Zanim więc dojdzie do zgłoszenia błędu, należy sprawdzić (np. po słowach kluczowych lub kawałku ścieżki reprodukcji), czy identyczny błąd nie widnieje już na liście. Zapobiega to powstawaniu duplikatów.

Testy plików

O ile testujemy dodawanie plików, należy podać informacje na temat typu załadowanego pliku z jego rozszerzeniem (na przykład tekstowy .doc) oraz rozmiaru. Jeśli to możliwe, warto dodać załącznik tego pliku do zgłoszenia.

Załączniki i programy graficzne

Czasem trudno dojść do reprodukcji błędu po samym opisie, nawet jeśli jest bardzo szczegółowy. Niektóre rzeczy trzeba po prostu zobaczyć, dlatego warto dodawać do zgłoszeń screeny i/lub filmy, które obrazują defekt. Program graficzny służy z kolei do zaznaczenia gdzie dokładnie błąd występuje. Dla przykładu dodanie ogromnego screena całego ekranu bez zaznaczenia o co nam chodzi, może sprawić, że osoba przyjmująca traci czas doszukując się nieprawidłowości. Może się przecież zdarzyć, że ich nie zauważy tak jak my. Dlatego dobrą praktyką jest rysowanie strzałek, używanie wyrazistych kolorów, dodawanie krótkich opisów zaznaczeń.

Rezultaty

By programista dokładnie wiedział jakie są oczekiwania, nie wystarczy opisać błędu, należy również podać rezultat rzeczywisty i zestawić go z rezultatem oczekiwanym. Na przykład: rezultat rzeczywisty: powrót za pomocą przeglądarki sprawia, że filtry się czyszczą, rezultat oczekiwany: powrót za pomocą przeglądarki niczego nie zmienia, pozostają filtry, które ustawiłam zanim przeszłam do listy wyników wyszukiwania.

Jedno zgłoszenie = Jeden błąd

Dobrą praktyką jest zgłaszanie jednego problemu w jednym zgłoszeniu, inaczej przy ewentualnych zwrotach do poprawy, tworzy się duża ilość powiadomień i komentarzy, które trzeba przebrnąć, by zrozumieć całość, na przykład gdy jedna kwestia jest poprawiona, a trzy inne trzeba jeszcze poprawić. Jest to uciążliwe zwłaszcza po długiej przerwie lub zmianie testera. Warto o tym pamiętać, opisując skomplikowany błąd, ponieważ czasem kusi, by wspomnieć przy okazji o innych, wynikających z niego błędach. W takich przypadkach zawsze można opcjonalnie odnieść się w drugim zgłoszeniu do pierwszego, podając jego link i dodając komentarz “na podstawie issue [link do zgłoszenia]” albo “powiązane z [link do zgłoszenia]”.

Criticale

Wszelkie błędy krytyczne, zwłaszcza na produkcji wymagają dodatkowego poinformowania PM/zespołu.

Komentarze

Warto dbać o przepływ informacji, dlatego, gdy programista skomentuje zgłoszenie, szybka odpowiedź może okazać się krytyczna do jego rozwiązania.

Wynik retestu

Gdy sprawdzamy zgłoszenie oznaczone labelką odpowiednią dla testerów (przeważnie “to test”), dobrą praktyką będzie dodanie krótkiego komentarza z wynikiem retestu z zaznaczeniem środowiska i aktualnego stanu/potrzeby, na przykład: “retest RC, filtrowanie po statusie działa poprawnie, sprawdzono każdy status, accept” albo “retest rc, bez zmian, to fix”.

Organizacja pracy testera

W każdym zespole projektowym jest tester, który ma za zadanie testować przydzielone do zespołu projekty. Jednak by uniknąć tzw. paradoksu pestycydów, gdy tylko jest na to czas, testerzy wymieniają się projektami w zakresie swojego zespołu QA, by uzyskać nową perspektywę i odkryć nowe nieprawidłowości. Zespoły projektowe samoorganizują się, co oznacza, że każdy jego członek samodzielnie wyznacza sobie zadania, a jedynie ich priorytety powinny być uzgadniane wspólnie. Dobrze, by tester sam wykazał się inicjatywą i dopytywał zespół o zadania, w których może pomóc. Odpowiednia komunikacja oraz zrozumiałe polecenia to klucz do powodzenia projektów. W zależności od rodzaju prowadzenia projektu, tester powinien uczestniczyć w Daily oraz innych spotkaniach zespołowych dotyczących projektowania i stanu gotowości produktu, by na bieżąco orientować się w przebiegu prac.

Podsumowanie

Mam nadzieję, że ten artykuł okaże się choć odrobinę przydatny. Co do wyboru Software House a firma, która ma swój produkt, myślę, że trzeba wziąć pod uwagę głównie swój własny charakter/temperament. Dla przykładu, jeśli mocno razi Cię pośpiech i związane z tym zagrożenia jakości, spróbuj swoich sił w firmie produktowej i zobacz, czy spokojniejsza, bardziej uporządkowana (jak mniemam, rozpytywałam i niebawem się przekonam) praca sprawi, że poczujesz większy spokój o dobrze wykonaną robotę. Jeśli jednak lubisz życie na krawędzi, codziennie nowe wyzwania i jazdę bez trzymanki, zdecydowanie złóż aplikację do Software Housu.