Czy programiści powinni umieć testować? Jak doświadczenie programistyczne pomaga w byciu lepszym QA? Pytamy o to programistów i testerów z Brainhub – firmy, która wdrożyła zasadę, iż każdy programista zajmuje się również testowaniem. Czy to się sprawdza?
W devdebacie udział wzięli:
- Tomasz Grażyński. Quality Assurance w Brainhub, 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 Brainhub. 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 domiują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 w Brainhub. Od ponad 7 lat jest zawodowo związany z jakością systemu – 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.
W Brainhub panuje zasada, iż każdy programista zajmuje się także testowaniem. Jak oceniacie takie rozwiązanie, co ono dla Was oznacza?
Hubert: Osobiście takie rozwiązanie oceniam jako dobre. Uważam, iż 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, o ile mamy do czynienia z testerami czynnie piszącymi testy automatyczne może się okazać, iż to oni zaopiekują się resztą testów, ale to nie znaczy, iż nie powinniśmy już zwracać na nie uwagi, bo może będziemy mogli przynieść wartość dla testerów.
Miłosz: 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: Z moich obserwacji wynika, iż takie podejście przyspiesza proces dostarczania wartości biznesowej do klienta. Dzięki temu, iż 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ć, iż 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, iż to nie my, ale inni interesariusze przygotowali proces testowania i wchodzimy na “gotowe”. Co oczywiście nie znaczy, iż 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 ulepszenia 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, iż 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 o ile 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ć manualnie 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, iż proces testowania zaczyna się już na etapie zbieranie wymagań. Dzięki temu, iż 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ść, iż 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ę, iż są jasne i testowalne. jeżeli tego zabraknie, później wychodzą niejasności i napięcia. Bardzo ważna jest świadomość, iż 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.
Macie może porównanie Waszej firmy do tego, jak się testuje w innych firmach? Widzicie jakieś różnice?
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, iż 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, iż 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, iż 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, iż testerzy tam mieli płacone prawdopodobnie od znalezionego problemu (buga) i żeby zarobić, choćby 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żeli dobrze argumentujemy zmiany, to są one wprowadzane i choćby 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ć, iż mamy idealną aplikację.
