W tym wpisie postaram się opisać co robię by moja (testera) współpraca z programistą układała się dobrze i bez problemów. Zespół, którego jestem członkiem pracuje w Scrumie, a to znaczy że stanowią go programiści, analitycy i testerzy. W jednym z moich artykułów opisałem już jak wygląda dobra współpraca analityka i testera. Teraz chcę Ci przybliżyć co zrobić by układała się ona równie dobrze z programistami.

Co zrobić by nasza współpraca była bardzo efektywna?

Uważam, że najlepszą rzeczą jaką możemy zrobić by było dobrze jest szanować wzajemnie swój czas pracy. To znaczy że jako tester powinienem dołożyć wszelkich starań by zgłoszenie nie stwarzało problemu przy weryfikacji przez programistę. I w drugą stronę programista wrzucając kod do testu powinien go sam wcześniej sprawdzić. I nie chodzi mi o testowanie za mnie, ale sprawdzenie czy podstawowe ścieżki działają, czy nie ma wyjątków czy z aplikacją da się pracować po wprowadzeniu zmian.

Po pierwsze - dołóż wszelkich starań by błąd zgłoszony do systemu nie wymagał wyjaśnień

Myślę, że najczęściej popełnianym przez testerów błędem jest niepoprawne lub niedokładne zgłaszanie błędów. Poniżej przeczytać możesz co według mnie powinno zawierać dobre zgłoszenie błędu.

Tytuł błędu

Zwykle jest to pole tekstowe mieszczące około 100 znaków. Z tego powodu treść zawarta w tytule zgłoszenia powinna w sposób jasny i czytelny nakreślić problem jaki jest w apliakcji. Tytuł ma być krótki, zwięzły i na temat.

Przykładowo: “Komunikat o błędzie po kliknięciu zaloguj”

Priorytet / ważność błędu

Tak jak wspomniałem wcześniej dobra współpraca testera z programistą będzie wtedy, gdy będziemy wzajemnie szanować swój czas pracy. Błędy zgłoszone do systemu trafiają na listę błędów. Ta lista wyświetla zazwyczaj tytuł błędu oraz priorytet. Programista na podstawie przede wszystkim tych dwóch wartości określa kolejność poprawy błędów. Dlatego dobierając priorytet błędu biorę pod uwagę czy błąd uniemożliwia lub utrudnia możliwość korzystania z funkcjonalności? Ale także czy istnieje obejście problemu? Czy trudno będzie wywołać defekt innemu użytkownikowi? I wreszcie czy problem uniemożliwia korzystanie z aplikacji? Dzięki temu unikniesz frustracji programisty, który na koniec dnia pracy ma poprawić błąd o średnim priorytecie, który blokuje funkcjonalność aplikacji.

Przykładowo “Komunikat o błędzie po kliknięciu zaloguj” będzie miał priorytet krytyczny jeśli po otrzymaniu komunikatu użytkownik nie może zalogować się wogóle. 

Ale też ten sam błąd “Komunikat o błędzie po kliknięciu zaloguj” będzie miał priorytet niski jeśli komunikat się wyświetla ale użytkownik zostaje zalogowany.

Przypisanie do konkretnego programisty

To pole w którym podaje się imię i nazwisko programisty, który powinien błąd poprawić. Zwykle nad aplikacją pracuje kilku, kilkunastu programistów. Żaden z nich nie ogarnia aplikacji w całości. Przeważnie każdy jest odpowiedzialny za swój obszar. Lista błędów zgloszonych do aplikacji bywa długa. Jeśli zatem zależy Ci na tym by zgłoszenie zostało zauważone i poprawione w skończonym czasie, powinieneś pamiętać by przypisywać błąd do konkretnego programisty.

Środowisko testowe

Przeważnie podczas wytwarzania oprogramowania mam do czynienia z kilkoma wersjami aplikacji np. wersją produkcyjną / rozwojową. Dlatego, też zgłaszając błąd podaję, na którym środowisku wystąpił błąd, tak aby programista miał możliwość łatwejszej identyfikacji, gdzie wystąpił problem.

Ścieżka odtworzenia defektu

Dla mnie osobiście jest to najważniejszy element całego zgłoszenia. Poprawnie opisane kroki odtworzenia defektu, powinny bez problemu naprowadzić programistę na usterkę w oprogramowaniu. Testerze pamiętaj, aby konkretnie krok po kroku opisać jak wywołać błąd. Ponieważ nie tylko programista potrzebuje tych informacji, ale również i Ty będziesz ich potrzebował retestując zgłoszenie. Retest może być wykonywany czasami nawet po miesiącu. Dlatego dobrze jest opisując defekt myśleć o tym, że kiedyś on do Ciebie wróci.

Oczekiwany rezultat

Jest to nie wymagany element zgłoszenia, natomiast bardzo pomocny o ile jest poparty fragmentem dokumentacji lub innego źródła analizy biznesowej produktu. W tym polu wyjaśniamy jak powinna zachować się aplikacja gdyby błędu nie było.

Ważne by tego pola nie mylić z polem “Obserwowane zachowanie”, w którym opisujemy co zadziałało nie tak jak powinno. Od kolegi programisty dostałem informację, że ponieważ te pola są mylone, często błędy są nieczytelne i trudno odróżnić czy chodzi nam o oczekiwany rezultat czy też o rezultat wywołania defektu.

Przykłądowo Oczekiwany rezultat dla “Komunikat o błędzie po kliknięciu zaloguj” to “Użytkownik jest zalogowany do aplikacji, nie orzymał żadnych komunikatów.

Ale w tym samym przypadku Obserwowane zachowanie to “Użytkownik otrzymał kumunikat o błędzie i nie został zalogowany do aplikacji”.

Załączniki

To pliki, które powinieneś załączyć do zgłoszenia jeśli zależy ci na dobrej współpracy z programistami. Pliki te to zrzuty ekrany, filmy na których widać co dzieje się na ekranie monitora zanim i w trakcie wystąpienia błędu, linki i przede wszystkim logi aplikacji. Pliki te ułatwiają programiście odtworzenie błędu. W przypadku logów powinniśmy je dostarczać w postaci linków, gdy używamy do tego odpowiednich aplikacji (np. Loggy) lub wycinków z plików (najlepiej zapisanych w formacie .txt lub wrzuconych w Jira {code}. Moim skromnym zdaniem my testerzy powinniśmy sobie wyrobić nawyk dołączania logów do zgłoszenia, pomoże to programistom szybciej naprawić defekt, a to sprawi, że będziemy przez nich bardziej docenieni.

Po drugie - nastaw się na współpracę a nie rywalizację

Dobra komunikacja jest kluczem do tego by współpraca układała sie bezproblemowo. Dlatego też tester nigdy nie powinien informować o usterce w aplikacji w sposób nieuprzejmy. Czasami zapominamy o tym, że wszyscy pracujemy razem. Tester ciesząc się ze znalezionego błędu “wytykają” go deweloperowi. Programista w ramach “odwetu” naśmiewa się z testera gdy ten zgłosi błąd niesłusznie.  Żarty żartami one też są potrzebne, ale też miejmy na uwadze uczucia innych ludzi, którzy niekoniecznie muszą się dobrze czuć, kiedy żartujemy z ich pracy. Pamiętajmy o tym, że jako cały zespół dążymy do tego samego celu jakim jest dostarczenie jak najlepszego oprogramowania.

Po trzecie - Dobrze prowadzony support z klientem

Kolejną rzeczą, o jaką powinniśmy dbać to dobrze prowadzony support, mam tu na myśli weryfikację, a następnie zgłaszanie defektów na podstawie zgłoszeń od klienta. Klient w tym przypadku nie zawsze ma rację, dlatego zgłoszenie otrzymane od klienta nie koniecznie musi być błędem. Do tego również trzeba pamiętać, że osoba po stronie klienta nie koniecznie została przeszkolona z zakresu zgłaszania defektów, co może skutkować bardzo nieczytelnymi zgłoszeniami. Każdy członek zespołu będzie nam wdzięczny za profesjonalne podejście do wsparcia klienta w zakresie testów.

Po czwarte - Samorozwój oraz odwaga do nauki nowych narzędzi.
Ostatnio zapytałem znajomych programistów co wedłuch nich sprawiłoby, że my jako testerzy bylibyśmy bardziej przez nich docenieni. Dostałem odpowiedź, że największym problemem jeśli chodzi o współpracę z nami jest nasz strach w stosunku do „nowości”. Nie powinniśmy się wstydzić przyznać gdy nie znamy niektórych narzędzi. Zamiast tego należy pytać i poprosić o pomoc programistę, który najbardziej się zna na narzędziu, które używamy. Jeżeli zdarzy się sytuacja, w której żaden programista nie będzie w stanie nam pomóc to zawsze zostaje nam google lub grupa na Facebooku „Testowanie Oprogramowania”.
Po piąte - zanim zgłosisz błąd postaraj się go zrozumieć

W naszej pracy nie chodzi o to by zgłosić jak najwięcej błędów, ponieważ ilość nie świadczy o jakości. Dobre zgłoszenie jest przemyślane. To znaczy, że poza znalezieniem i zgłoszeniem defektu sprawdzono również jego powtarzalność oraz to w jakich dokładnie warunkach występuje. Jeżeli tester próbował zrozumieć błąd, dokonał wielu prób, a mimo to nie znalazł schematu na jego powtórzenie, to również jest to ważna informacja dla dewelopera. Błędy zgłoszone na “szybko” często mają bardzo pobieżny opis mówiący tylko np. jaki ekran włączono i jaki przycisk naciśnięto. Dobrze opisany błąd to taki, po którego przeczytaniu deweloperowi od razu łatwiej jest go poprawić. 

Czy zatem praca z programistami zawsze układa się idealnie?

Oczywiście, że nie! Każdy człowiek jest inny. Podczas swojej kariery trafimy na różnych ludzi. Będą wśród nich tacy, którzy nie widzą błędów nawet tych oczywistych w aplikacji. Jak i tacy, którzy będą dokładali nam testerom pracy poprzez wrzucanie zmian w aplikacji bez „odpalenia” jej… Jakie by nie były problemy, powinniśmy być w stanie sobie z nimi poradzić. Zwykle prosty dialog/ rozmowa rozwiąże problem. Współpraca testera z programistą oparta jest o komunikację, bez niej nasze wzajemne niedociągniecia przerodzą się w konflikt. A ten zepsuje atmosferę w zespole. Jeśli nie działa rozmowa i zwrócenie uwagi na sytuacje, które mogą nam przeszkadzać w pracy, powinniśmy eskalować problem u Scrum mastera lub też na spotkaniu „Retrospekcji”. Przy innych metodologiach wytwarzania oprogramowania niż Scrum powinniśmy udać się do przełożonego czy do test menagera.

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz