W dziedzinie tworzenia systemu zawsze istniała niezaprzeczalna zależność między programistami a inżynierami QA. Relacja ta nierzadko balansuje pomiędzy płynną współpracą a ukrytym antagonizmem, ale jednocześnie odgrywa kluczową rolę w każdym projekcie.
Dziś przekażę Wam kilka praktycznych wskazówek, które pozwolą umiejętnie ułożyć strategię QA, co w konsekwencji może pozytywnie wpłynąć na interakcje wewnątrz Waszych zespołów.
Wspólne wyzwania programistów i zespołów QA
Jak brzmi jedno z najczęściej zadawanych pytań podczas budowania zespołu projektowego? „Czy naprawdę potrzebujemy inżynierów QA?”
Moim zdaniem możliwe jest tworzenie produktów wysokiej jakości bez dedykowanego zespołu QA. Niemniej zależy to od kilku czynników. Oto one:
- charakter produktu,
- branża, dla której przygotowujemy produkt,
- obecność dobrze ugruntowanych procesów wewnętrznych.
Jeśli produkt jest niewielki, dobrze znany wśród programistów lub tworzony w znajomym im obszarze (tj. aplikacje bankowe, platformy e-commerce), to z powodzeniem możemy działać bez QA. Są jednak takie sektory, jak na przykład zarządzanie łańcuchem dostaw, które potrzebują bardziej szczegółowego podejścia. Ciężko mi sobie wyobrazić pracę nad ogromnym systemem do zarządzania magazynem (WMS), grą, czy skomplikowanym FinTechem bez wsparcia QA. Przeanalizujmy zatem głębiej, dlaczego inżynierowie QA przez cały czas odgrywają najważniejsze role w zespołach programistycznych.
Po pierwsze, podobnie jak osoby wykonujące pracę twórczą, programiści mogą mieć pewne uprzedzenia do efektów swojej kreatywności. Często są wrażliwi na ostateczne rezultaty i patrzą na nie tylko z własnej perspektywy. Jednak tworząc produkt, należy dostosować swoje działania tak, aby wpasowały się one w globalne interesy zarówno samego produktu, jak i klienta. Specjaliści QA patrzą na pracę bardziej obiektywnie, dzięki czemu zespół może wypracować odpowiednie podejście do zadań.
Po drugie, QA dostarcza rozwiązań, które są opłacalne pod względem kosztów. Przeprowadzenie testów przy udziale inżynierów QA często wiąże się ze znacznie niższymi kosztami niż poleganie wyłącznie na programistach.
Po trzecie, programiści często skupiają się na technicznym rozwiązywaniu problemów, przez co mogą (nawet nieświadomie) odsuwać user experience i główne cele produktu na dalszy plan. W takich przypadkach team QA pomaga im spojrzeć na sprawę bardziej ogólnie.
Rola strategii QA w procesie rozwoju oprogramowania
Przyjrzyjmy się powodom, dla których warto wdrożyć efektywną strategię QA oraz jej wpływowi na pracę nad oprogramowaniem.
W mojej pracy często definiuję strategię QA jako mapę, która pomaga nam zarówno zaplanować całą trasę do celu, jak i przystanki, dzięki którym bezpiecznie i z sukcesem do niego dotrzemy. Co ciekawe, moim zdaniem strategia nie musi (ale oczywiście może!) być formalnym dokumentem. jeżeli nasz zespół potrafi dobrze ze sobą współpracować i rozumie oczekiwania wszystkich stron, to wystarczy, iż spotka się ze sobą, spisze najważniejsze punkty strategiczne, poszczególne role na projekcie i omówi szczegółowo plan działania. Niezbędnym jej elementem będą też składowe niezbędne do skutecznego testowania, gdyż głównym celem strategii QA jest w końcu zapewnienie produktu wolnego od błędów.
Jak więc ta strategia wpływa na programistów i ich role?
Jak już wspomniałem, programiści zwykle skupiają się na technicznych aspektach, więc obecność strategii QA oznacza dodatkową przejrzystość w procesie. W końcu ma ona na celu odpowiadać też na nietechniczne pytania, takie jak na przykład „Dlaczego testujemy ten aspekt?”. Dzięki dobrze zdefiniowanej strategii zespół może szczegółowo wyjaśnić swoje działania, zapewniając, iż wszyscy działają według tego samego planu.
Wyobraź sobie inżynierów QA jako inspektorów do spraw jakości. Analogię możemy znaleźć chociażby w budownictwie – na budowach również mamy inżynierów, którzy nadzorują kwestie bezpieczeństwa i jakości materiałów używanych do pracy, ale nie muszą się martwić detalami dotyczącymi każdej cegły czy konstrukcji dachu. Zamiast tego skupiają się na ostatecznym rezultacie, którym jest gotowy dom i satysfakcja klienta. Podobnie strategia QA dostosowuje się do unikalnych niuansów konkretnego produktu.
Prawie każda strategia jest tworzona oddzielnie dla wszystkich projektu. Dlaczego prawie? Bo czasem, korzystając z powtarzalności pewnych schematów, możemy sobie pozwolić na zaadaptowanie istniejących już strategii pod potrzeby danego klienta. Dobrym przykładem są tu sklepy internetowe, gdyż w ich przypadku trzeba skupić się na ułatwianiu użytkownikom korzystania z nich i przestrzeganiu norm branżowych. Z kolei aplikacje bankowe obsługują transakcje finansowe, weryfikację tożsamości i wrażliwe dane, dlatego priorytetem jest bezpieczeństwo i intuicyjna obsługa.
Do kategorii powtarzalnych projektów należą też systemu dla przedsiębiorstw, chociaż w przeciwieństwie do aplikacji i stron, są to bardzo złożone systemy. Są one zwykle budowane przez wiele małych zespołów, z których każdy jest odpowiedzialny za jego konkretną część. Właśnie dlatego strategia QA dla zespołu musi być dostosowana do ogólnej strategii QA całego produktu.
Kluczowe składowe i zasady każdej strategii
Przejdźmy do szczegółów:
Cele: Po pierwsze, musisz określić cele jakości dla swojego produktu. Co oznacza „jakość” w jego kontekście? Na przykład, brak krytycznych błędów w produkcji i zapewnienie, iż wszystkie istotne scenariusze biznesowe działają poprawnie.
Aby określić, co oznacza jakość, musisz zrozumieć swój produkt, jego główne cele biznesowe i oczekiwania dotyczące ich osiągnięcia.
Zakres testów: Powinieneś określić obszary do testów i ich metodykę. Mogą to być testy manualne, testy automatyczne, testy jednostkowe, testy wydajnościowe i testy zabezpieczeń. Innymi słowy, co będziemy testować i jak.
Środowisko testowe: Weź pod uwagę środowisko testowe, czyli sprzęt, oprogramowanie i infrastrukturę sieciową wymaganą do przeprowadzania testów. Na przykład, jakie przeglądarki i systemy operacyjne będzie obsługiwać produkt? Podobnie, jeżeli tworzysz aplikację mobilną lub grę, musisz zrozumieć szybkość wymiany danych wymaganą do osiągnięcia optymalnej wydajności.
Narzędzia: Określ narzędzia, które zostaną wykorzystane do testowania. Możesz wpisać na listę systemy zarządzania testami, systemy zarządzania projektami (takie jak Jira), narzędzia do testowania API (takie jak Postman lub Swagger), narzędzia do testowania wydajności (takie jak JMeter) itp.
Planowanie testowania: Ta część strategii określa, co będzie testowane, jak, na których etapach, kto będzie odpowiedzialny za testy i harmonogram. jeżeli planujesz użyć narzędzi do automatyzacji testów, powinieneś również zawrzeć do w strategii oraz stworzyć osobny plan działania do tego punktu. Automatyzacja nie zawsze ma sens z biznesowego punktu widzenia, ale może się przydać w długich lub powtarzalnych projektach.
Wykonanie Testów: Obejmuje standardy, metrykę, dokumentację oraz zgodność z regulacjami i normami, których produkt musi przestrzegać, takimi jak na przykład RODO.
Czy programiści mogą skorzystać z automatyzacji testów QA?
Tak, mogą. Automatyzacja staje się przydatna, gdy zdajemy sobie sprawę, iż musimy wielokrotnie testować niektóre funkcje. Czyli zasadniczo to, co inżynierowie QA i tak by robili.
Zaletą automatyzacji jest też niewątpliwie to, iż developerzy mogą gwałtownie zrozumieć, czy i co jest nie tak z ich kodem. Wyobraź sobie programistę pracującego nad funkcją produktu. jeżeli ta funkcja jest już napisana, przetestowana i zautomatyzowana, programista może scalić swój kod z najnowszą wersją produktu, uruchomić testy automatyczne i sprawdzić, czy nie ma problemów. I to wszystko bez udziału zespołu QA.
Automatyzacja jest skuteczna, gdy produkt jest stosunkowo statyczny i nie wymaga dynamicznych zmian w trakcie rozwoju. Warto jednak pamiętać, iż ma też kilka istotnych wad. Po pierwsze, jest dość kosztowna w rozwoju i utrzymaniu. Po drugie, nie da się zautomatyzować wszystkich procesów. Na przykład w grach, istotnym aspektem jest user experience. To, czy gra inspiruje graczy do kontynuowania gry, nie może być testowane przez maszyny. Tam, gdzie w grę wchodzą estetyka i ludzkie zmysły, automatyzacja jest niewystarczająca.
Efektywna komunikacja: Zamykanie luki między programistami a testerami QA
Na początek chciałbym wyjaśnić, co rozumiem przez „efektywność”. Z mojego punktu widzenia, efektywność w komunikacji polega na uzyskaniu odpowiedzi na wszystkie pytania przy jak najmniejszej liczbie interakcji werbalnych.
Jeśli chodzi o efektywną komunikację między programistami a testerami QA, każda specjalizacja ma swoje obowiązki. Te obowiązki się nakładają, ale nie są identyczne. Ich zadania różnią się, ale każdy musi wypełnić swoją rolę. Znacząca część pracy testerów polega na zadawaniu adekwatnych pytań, które wcześniej wymagają dogłębnej analizy. Jako profesjonalny tester powinieneś zawsze przystępować do rozmów dobrze przygotowany. Zadawaj konkretne pytania, wymagaj konkretnych odpowiedzi i idź do przodu.
Co ciekawe, inżynierowie QA zwykle lepiej rozumieją produkt niż programiści, dlatego nie bój się inicjować rozmów z nimi. W końcu korzyść, jaką testerzy dają developerom, polega na dopracowaniu wzajemnych wymagań i wyjaśnianiu zmian funkcjonalnych.
Pracowałem kiedyś 3-4 lata nad grą komputerową. Jako zespół QA, znaliśmy tę grę na wylot. Po jej premierze, programiści byli zszokowani, jak dobrą grę wspólnie stworzyliśmy. Moim zdaniem, brakowało im kompleksowego zrozumienia finalnego produktu.
Wspomniałem już o tym, iż inżynierowie QA mogą pomóc lepiej zrozumieć obecny stan produktu lub konkretnej funkcjonalności, ponieważ zwykle mają głębszą wiedzę o produkcie. Właśnie dlatego warto z nimi rozmawiać – testerzy „filtrują” pracę nad projektem, lepiej identyfikując wymagania w procesie rozwoju.
Strategie poprawy efektywności komunikacji
Szacunek: najważniejsze jest szanowanie pracy i obowiązków innych osób.
Cenienie czasu: Testerzy powinni zdawać sobie sprawę, iż zanim przystąpią do rozmów, powinni sami najpierw zbadać i zebrać szczegółowe informacje na temat pracy zespołu. Najlepiej jest podchodzić z konkretnymi pytaniami i potencjalnymi rozwiązaniami. Na przykład, możesz powiedzieć: „Mam problem. Rozumiem go tak. Próbowałem go rozwiązać w ten sposób, ale napotkałem te problemy”. Ten szablon jest idealny do komunikacji.
Ustalanie limitów: Ustal limity czasu poszukiwania odpowiedzi. jeżeli nie znajdziesz odpowiedzi w ciągu 2-3 godzin, prawdopodobieństwo, iż znajdziesz ją w kolejnych 8 godzinach, jest mniejsze. Może czas podejść do tematu nieco inaczej?
Rodzaje problemów: Zrozum różne rodzaje problemów. Są błędy związane z nową funkcjonalnością oraz bug reporty. W przypadku bug reportów, tester musi je napisać zrozumiale, tak, jakby tłumaczył to swojej babci. jeżeli ktoś po zapoznaniu się z nimi przez cały czas potrzebuje wyjaśnień, to niestety wskazuje to na to, iż komunikacja nie jest całkowicie skuteczna.
Harmonijna współpraca: Chociaż może się wydawać, iż testerzy i programiści są antagonistami, tak naprawdę nimi nie są. Pomyśl o tym jak o Don Kichocie i Sancho Pansie. Don Kichot nie byłby wspaniałym rycerzem, gdyby nie miał kogoś, kto zaopatruje go w zbroję i broń. Byłoby fantastycznie, gdyby członkowie zespołu zrozumieli, iż pracują w kierunku wspólnego celu, a nie za każdym razem zastanawiali się, dlaczego QA zwróciło zadanie z uwagami. Jakość produktu jest wspólnym celem programistów, inżynierów QA i całego zespołu.
Wnioski
Wracając do początku artykułu, „Czy naprawdę potrzebujemy inżynierów QA?” Odpowiedź brzmi: Tak. Kluczem do efektywnej współpracy między QA a programistami jest proaktywna strategia, która znacząco wpływa na proces rozwoju. Zapewnia ona wspólne zrozumienie wymagań, zakresu zadań i sposobów testowania przez wszystkich członków zespołu, co prowadzi do pozytywnych rezultatów.
W moim zespole najważniejsze są otwarte kanały komunikacji między programistami a specjalistami QA. Gdy otrzymujemy nowe zadanie, często zdarza się, iż programiści i QA angażują się w dyskusje. Dialog sprawia, iż programista dostosowuje swoją pracę do szczegółowych wymagań opracowanych przez specjalistę QA. Co więcej, specjalista QA może zaoferować cenne wskazówki dotyczące tego, na czym warto skupić się podczas testowania, ułatwiając pracę programiście.
Chociaż dyskusje te mogą początkowo wydawać się czasochłonne, długoterminowe korzyści znacznie przeważają nad krótkotrwałymi niedogodnościami. Wczesne ustalenie strategii testowania działa jako środek zapobiegawczy, pomagając zidentyfikować i rozwiązać potencjalne problemy, zanim produkt dotrze do użytkowników końcowych. To proaktywne podejście jest opłacalne i minimalizuje zakłócenia, które mogłyby pojawić się po wydaniu produktu.
Zdjęcie główne artykułu pochodzi z envato.com.
