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 współpraca testera z programistą 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 aplikacji. 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? 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 się zalogować.
Równocześnie 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 zgłoszonych 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ść łatwiejszej 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ładowo Oczekiwany rezultat dla „Komunikat o błędzie po kliknięciu zaloguj” to „Użytkownik jest zalogowany do aplikacji, nie otrzymał żadnych komunikatów”.
W tym samym przypadku Obserwowane zachowanie to „Użytkownik otrzymał komunikat 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). 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 się 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, „wytyka” 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ług 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ągnięcia 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.
