Czy każdy programista powinien umieć testować? Debata programistów i testerów

W Brainhubie panuje zasada, że każdy programista zajmuje się także testowaniem. Jak oceniacie takie rozwiązanie, co ono dla Was oznacza?

Hubert Stemplewski: Osobiście takie rozwiązanie oceniam jako dobre. Uważam, że każdy programista powinien brać czynny udział w procesie testowania – zaczynając od testów jednostkowych swoich metod i komponentów, poprzez testy integracyjne i e2e (te ostatnie już po ustaleniu z działem zajmującym się QA). W niektórych projektach, jeżeli mamy do czynienia z testerami czynnie piszącymi testy automatyczne może się okazać, że to oni zaopiekują się resztą testów, ale to nie znaczy, że nie powinniśmy już zwracać na nie uwagi, bo może będziemy mogli przynieść wartość dla testerów.

Miłosz Sałata: Dla mnie to oznacza rozszerzenie odpowiedzialności za jakość na cały zespół – wszyscy pracujemy nad wysoką jakością dostarczanego produktu. Przeniesienie ciężaru testowania na cały proces developmentu na pewno w tym pomaga, a także zmniejsza liczbę błędów wykrytych podczas testów QA – po prostu część z nich została znaleziona i poprawiona wcześniej, co dodatkowo przyspiesza pracę zespołu. 

Tomasz Grażyński: Z moich obserwacji wynika, że takie podejście przyspiesza proces dostarczania wartości biznesowej do klienta. Dzięki temu, że już na etapie implementacji programiści sprawdzają swoją pracę i dodatkowo piszą nowe i naprawiają obecne testy, to więcej problemów i defektów jest naprawianych już na tym etapie. Zaimplementowana funkcjonalność rzadko kiedy wraca z etapu testów na poprawki, nie trzeba jej również potem re-testować. Poza tym zmniejsza to dług techniczny w postaci liczby funkcji niepokrytych testami automatycznymi. Dzięki temu możemy uniknąć długotrwałych testów regresji przed wypuszczeniem nowej wersji i od razu wiemy, co nie działa przy implementowaniu nowych funkcjonalności. Warto również wspomnieć, że wczesne wykrywanie defektów zmniejsza koszt i czas ich naprawy.

Jak z Waszej perspektywy wygląda testowanie w zespole? 

Hubert: Jako programista muszę zacząć od jedynej słusznej odpowiedzi: “To zależy”. To zależy od projektu, w którym bierzemy udział. W części projektów może zdarzyć się tak, że to nie my, ale inni interesariusze przygotowali proces testowania i wchodzimy na “gotowe”. Co oczywiście nie znaczy, że nie mamy już wpływu na proces. W Brainhubie cechuje nas podejście do problemów i projektów jako konsultanci, dzięki czemu doradzamy możliwe usprawnienia już od samego początku. 

Przykładowo: w obecnym projekcie, który realizuję w Brainhubie proces był już ustalony, ale kod, który dostaliśmy nie był najlepszej jakości. Pierwsze, co zaproponowaliśmy, to zmiany w kodzie usprawniające działanie aplikacji i oczywiście pokrycie najważniejszych części testami (unit, integration, e2e). Wcześniej proces wyglądał tak, że po dostarczeniu danej funkcjonalności programiści przekazywali testowy build do QA i oni sprawdzali wymagania (0 testów jednostkowych, ani żadnych innych). Po pełnym cyklu testerzy sprawdzali wszystko od początku i jeżeli przeszło weryfikację, to leciało na produkcję. 

Obecnie po naszych zmianach flow jest trochę inne. To, co możemy (jako programiści) pokrywamy testami, przez co zabezpieczamy się już na poziomie pisania kodu (testy za każdym razem są sprawdzane na pipeline), ale również dokumentujemy w ten sposób wymagania. Dopisaliśmy też testy e2e dla najważniejszych funkcjonalności, takich jak np. logowanie, i przekazaliśmy do działu QA, dzięki czemu nie muszą już sprawdzać ręcznie logowania, bo przed releasem wykonujemy te testy na skonfigurowanym przez nas pipelinie. Testerzy mogą za to skupić się na ważniejszych rzeczach i use case’ach w aplikacji.

Tomasz: Podpisuję się pod tym co powiedział Hubert, dodam tylko, że proces testowania zaczyna się już na etapie zbieranie wymagań. Dzięki temu, że staramy się, aby cały zespół był świadomy wymagań i potrzeb biznesowych oraz procesu ich zbierania, to już na tym etapie dyskutujemy z klientem o tym, jakie problemy może stworzyć nowa funkcjonalność, gdzie konfliktuje z istniejącymi funkcjami i jak te problemy rozwiązać, np. poprzez dodatkową walidację. Oczywiście testujemy również nowo zaimplementowaną funkcjonalność, zarówno manualnie, jak też przy użyciu testów automatycznych – po to, aby nie powtarzać tej samej pracy po kilka razy. Ważne jest również poczucie odpowiedzialności za jakość produktu i świadomość zespołu w kwestii zysków z takiego podejścia – pewność, że wprowadzane zmiany nie psują istniejących funkcji, nie ma już żmudnych okresów testowania przed releasem, code-freezów, rzadko dostajemy“zwrotki”, czyli bugi znalezione przez klienta i użytkowników końcowych.

Miłosz: Pracuję w mało brainhubowym projekcie, więc mam trochę inne doświadczenie niż chłopaki. Staramy się zacząć proces testowania od weryfikacji wymagań, upewnieniu się, że są jasne i testowalne. Jeśli tego zabraknie, później wychodzą niejasności i napięcia. Bardzo ważna jest świadomość, że pracujemy nad działającym systemem, który realizuje określone cele, a nie pojedynczymi funkcjonalnościami. Jako zespół QA uczestniczymy w code review, co też daje nam pogląd na zmiany i okazję do rozwoju – warto korzystać z takiej możliwości. Testujemy manualnie nowe funkcjonalności na feature-branchach, a następnie na środowisku testowym. Ze względu na rosnącą liczbę funkcjonalności i zwiększający się zakres regresji dążymy do zwiększenia poziomu automatyzacji testów.

Czy widzicie jakieś różnice w podejściu do testów między Brainhubem, a Waszymi poprzednimi firmami?

Hubert: Jasne, siadajcie, opowiem wam historię :) W jednej z moich poprzednich firm o testach nie było mowy. Niestety, byłem wówczas bardzo mało doświadczonym programistą i nie miałem takiej mocy, żeby sprowadzić testowanie kodu. Jedynym tego typu procesem było testowanie manualne przez dział QA. Fun fact, nasz tester potrafił testować automatycznie, ale projekty były na tyle małe i start-up’owe, że czas był najważniejszym czynnikiem i trzeba było dowozić jak najszybciej, bo każdy dzień testowania mógł spowodować ich zdaniem upadek firmy i koniec finansowania.

W innym przypadku było tak, że projekt był ogromny, ale pisanie testów trzeba było “przemycać”, bo jak ktoś by się dowiedział ze strony klienta, to by się zapytał, czemu marnujemy czas i powiedziałby, że moglibyśmy w tym czasie dowieźć coś jeszcze. Tam jednym z najważniejszych wymagań było: “Trzeba dowieźć to na ASAP”. Dział QA w tamtym projekcie był po stronie klienta, jednocześnie outsourcowany do innej firmy. Najśmieszniejsze było to, że testerzy tam mieli płacone prawdopodobnie od znalezionego problemu (buga) i żeby zarobić, nawet feature requesty wrzucali w jirę jako bugi.

Obecnie w Brainhubie nie miałem podobnych historii. Z reguły klienci podchodzą do nas jak do ekspertów, z którymi można podyskutować o procesie. Jeśli dobrze argumentujemy zmiany, to są one wprowadzane i nawet gdy nie mamy testera w projekcie, jest dla nas przestrzeń na testy. W Brainhubie jest bardzo duży nacisk na testy, a co za tym idzie – jednocześnie na utrzymanie jakości, ale nie za wszelką cenę, bo pokrycie 100% wcale nie musi znaczyć, że mamy idealną aplikację.

Tomasz: Niestety, większość doświadczeń to takie anty-patterny, które pokazują złe drogi, a w dłuższej perspektywie kosztowne konsekwencje takiego podejścia. Tutaj można dużo opowiadać. W moim pierwszym projekcie proces był typowo waterfallowy – przychodziła specka na maila (kilkadziesiąt stron), team developerski zamykał się z nią na kilka miesięcy, w tym czasie team QA spisywał manualne test case’y, team developerski przychodził z branchem, większość przypadków testowych była do przepisania. Następował żmudny proces testowania, naprawiania, retestowania, testów regresji, dogadywania z analitykiem biznesowym szczegółów wymagań, które jakimś cudem już zostały zaimplementowane(!), następnie kilka tygodni mergowania z innym teamem i głównym branchem, a potem po releasie mnóstwo zwrotek – bo w sumie to klientowi chodziło o coś innego. W czasie kilkuletniej pracy udało się wprowadzić jakieś testy automatyczne, bardziej zwinne podejście, natomiast był duży opór po stronie klienta. Zasadniczo sztywne rozdzielenie obowiązków i podział na zespół programistów i QA rodziły nieporozumienia, konflikty i brak odpowiedzialności za to, co dostarczamy.

Firmy, w których pracowałem miały wiele projektów dla różnych klientów i z reguły podejście  było mixem tego, jak zwinna i elastyczna była organizacja i jej kadra zarządzająca (management) oraz tego, jak bardzo zespół chciał robić rzeczy dobrze i jak bardzo był w stanie zgrać się, aby zmienić świat na lepsze. Często dało się wyprowadzać projekt na prostą przez aktywne zmniejszanie długu technicznego, zaangażowanie QA w cały proces tworzenia oprogramowania, począwszy od zbierania wymagań a na procesie release’u i maintanance’u kończąc, jak i przez częsty kontakt z klientem, aby unikać założeń i niedopowiedzeń.

Miłosz: Z opisu Tomka wynika, że pracowaliśmy kiedyś w jednym projekcie, choć spotkaliśmy się dopiero w Brainhubie. Myślę że prawie każdy tester może podzielić się sporą liczbą anty-wzorców, które napotkał podczas swojej pracy – testy na produkcji, absolutny brak czasu przewidzianego na testy, mikrozarządzanie osób bez odpowiedniej wiedzy, i wiele innych. Większość z nich wynika z kombinacji cech organizacji (brak elastyczności, niski priorytet testowania) oraz podejścia klienta (myślenie, że testy to zbędny koszt). Mam wrażenie, że coś się w tej kwestii zmienia i testy stają się niemniej ważną częścią procesu wytwarzania oprogramowania. 

Jak w ogóle trafiliście do Brainhuba? Czym zajmowaliście się wcześniej?

Hubert: U mnie historia trafienia do Brainhuba jest oklepana i nudna. Studia informatyczne, praca jako programista i nabieranie doświadczenia w innych firmach, chęć zmian, chęć przejścia na b2b (co wymusza trochę zmianę pracodawcy) i oto jestem.

Miłosz: Brainhub jest czwartą firmą, w której pracuję. W każdej poprzedniej pracowałem w roli QA i tutaj też nie jest inaczej.

Tomasz: Znajomy z poprzedniej firmy przeszedł do Brainhuba i zaproponował mi, abym też spróbował, bo widział potrzebę QA w nowym projekcie. Skusił mnie też fakt, że Brainhub nie miał wtedy żadnego QA, więc dało mi to duże pole do nauki i rozwoju. Wcześniej byłem również QA, po części manualnym, w późniejszym etapie po części automatyzującym, głównie w dużych projektach, gdzie zrozumienie domeny wymagało trochę czasu. 

Co trzeba umieć, aby zostać testerem oprogramowania? Jakie skille są potrzebne?

Miłosz:  Wydaje mi się, że na początku bardzo istotne są umiejętności/cechy, niezwiązane bezpośrednio z samym testowaniem – spostrzegawczość, asertywność, dociekliwość w drążeniu tematów i bezwzględnie – biegłość w obsłudze komputera. Początkujący tester powinien wiedzieć, jak działają strony / aplikacje / aplikacje mobilne, co to jest dobry UX, generalnie mieć jakieś pojęcie o IT. Umiejętności obsługi systemu kontroli wersji (np. GIT), baz danych (SQL), znajomość działania REST API, wydają mi się dobrym startem. Wiedza z zakresu ISTQB, oraz zwinnych metod wytwarzania oprogramowania też się przyda. 

Tomasz: Podpisuję się pod tym, co powiedział Miłosz i dodam, że ważna jest dokładność, dbałość o szczegóły i chęć zrozumienia problemu i powodów, które go wywołały, tzw. dojście po nitce do kłębka. Następnie warto zainteresować się tym, jak podchodzi się do testów w dużych firmach (Google, Facebook. Polecam to repozytorium: https://github.com/abhivaikar/howtheytest), pomaga zrozumieć korzyści płynące ze zwinnego podejścia i automatyzacji. Bardzo ważna jest świadomość tego, że robimy oprogramowanie po to, aby rozwiązać czyjś problem lub pomóc komuś zarobić duże pieniądze. Na końcu prawie zawsze jest jakiś użytkownik, który albo będzie zadowolony z tego, co dostarczamy, albo nie. Warto więc pracować tak, aby mieć na uwadze zadowolenie tej osoby.

Czy programista powinien umieć testować?

Hubert: Zdecydowane tak, ale nie w takim stopniu, jak fachowy tester. Programista powinien mieć wiedzę, jak się testuje, rozumieć scenariusze i wymagania, powinien pisać testy kodu, znać podstawowe zagadnienia takie jak piramida testów, white/black box testing itp. Ale nie musi mieć wiedzy doświadczonego testera i jego umiejętności.

Miłosz: Myślę że nawet nie umiejętności, a podejście jest istotne. Testerskie podejście na pewno pomaga w weryfikacji dostarczonych wymagań (Dlaczego tak, a nie inaczej? Tutaj chyba czegoś brakuje?). A stąd już bardzo blisko do lepszego produktu.

Tomasz: Programista powinien przede wszystkim wiedzieć, dlaczego się testuje :) Stąd droga do tego, jak to robić jest już otwarta. Tak, jak wspomnieli koledzy – warto znać podstawy, poziomy testów, czym są equivalence partitioning, boundary value analysis, combinatory testing. Znajomość tych prostych technik pozwala pisać lepsze i precyzyjniejsze testy jednostkowe. W idealnym świecie QA nie wyręcza zespołu w testowaniu, a jedynie daje im możliwości i wspomaga zespół w polepszaniu jakości dostarczanych rozwiązań. W myśl powiedzenia: “Daj komuś rybę, a nakarmisz go na jeden dzień. Naucz go łowić ryby, a nakarmisz go na całe życie”. 

W debacie udział wzięli:

• Tomasz Grażyński - Quality Assurance Engineer w Brainhubie, a po polsku – Inżynier Jakości Oprogramowania. Od 10 lat zajmuje się tematami Quality Assurance, ale przez ten czas udało mu się również zdobyć doświadczenie w tematach związanych z organizacją zespołu, analizą biznesową, DevOps, analizą nowych klientów i ich potrzeb oraz programowaniem w .NET i JS. W pracy ceni luźną atmosferę, zdrowe podejście, zespołowe zaangażowanie i przejmowanie odpowiedzialności. Dla odpoczynku wybiera góry i basen, ale nie pogardzi książką i filmem lub serialem.
• Hubert Stemplewski - Full Stack Developer w naszym teamie. Od 5 lat zajmuje się zawodowo programowaniem, głównie frontendowym, ale nie ma sprecyzowanej dziedziny. Technologicznie lubi wyzwania, niezależnie od tego, czy to mobile, backend, czy blockchain, najważniejsze jest dla niego odpowiednie dobranie technologii do problemu. Lubi próbować nowych rzeczy i choć JavaScript to jego dominujący język, nie zamyka się na próbowanie nowych rozwiązań. Interesuje się tematami DevOps (CI/CD) i bezpieczeństwem. W wolnym czasie lubi grę w squasha, piłkę nożną i ćwiczenie na siłowni, ale ponieważ aktywność fizyczna to nie wszystko, nie odmówi też dobrego serialu.
• Miłosz Sałata - Quality Assurance Engineer w Brainhubie. Od ponad 7 lat jest zawodowo związany z jakością oprogramowania – szeroko pojętym testowaniem, automatyzacją testów w Pythonie, a także budowaniem procesów usprawniających pracę zespołu. Skupiony na nauce nowych narzędzi, a także rozwoju w tematyce CI/CD. Zawsze docenia zaangażowanie, kreatywność i holistyczne podejście do projektu. Po pracy zajmuje się fotografią, podnoszeniem ciężarów, wspinaczką i rozbijaniem dronów.

‍