Czy każdy programista powinien umieć testować? Devdebata

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ę, że 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ą 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.

W Brainhub panuje zasada, że 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, ż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: 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, ż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.

Zobacz też

QA Historia testowania oprogramowania. Jak wyglądało wczoraj, a jak wygląda dziś?

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.

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, ż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ę.

Oferty pracy z

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ć/znać, 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.

Zobacz też

Juniors Dzień Testera. Najlepsze materiały edukacyjne dla początkujących testerów

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”.

Jak doświadczenie programistyczne pomaga w byciu lepszym QA?

Miłosz: Otwiera nowe możliwości – automatyzacja testów, testowanie backendu, wejście w tematy CI/CD. Umiejętność programowania pomaga usprawnić pracę – manualne regresje wypaliły niejednego testera, a dzięki automatyzacji to ryzyko zdecydowanie maleje. Mam też wrażenie, że programiści inaczej patrzą na testerów, którzy potrafią coś napisać. Dzielimy podobne problemy i trudności, co przekłada się na rozmycie twardego podziału na testerów/programistów – który w wielu firmach jest nacechowany mocno negatywnie.

Tomasz: Ja zawsze u innych QA doceniam wiedzę i doświadczenie z zakresu, który nie podpada stricte pod testowanie. Uważam, że bardzo przydatne umiejętności dobrego QA to rozumienie kodu i uczestniczenie w code review, umiejętność konfigurowania i zautomatyzowania procesów CI/CD, brak oporów przed wejściem w buty analityka biznesowego i spisanie wymagań na podstawie rozmowy lub mini-warsztatów z klientem. Warto również znać podstawy efektywnego zarządzania zespołem i umieć budować w zespole świadomość tego, czym jest jakość i jak o nią dbać. Zasadniczo dobry QA powinien wypełniać luki w zespole, które powodują, że zespół nie jest w stanie dostarczyć klientowi wysokiej jakości wartości biznesowej w sensownym czasie. O tym, czym jest “wysoka jakość” i “sensowny czas” decyduje już specyfika projektu i świadomość zespołu.

Miłosz: Podpisuję się pod tym, że dobry QA powinien wypełniać luki w zespole. W wielu projektach, w których pracowałem tak właśnie było. Dlatego tak ważne jest rozwijanie się w wielu kierunkach – nie tylko stricte testerskich/programistycznych.

Ostatnio widzimy wzrost zainteresowania tematyką testingu. Jak myślicie, skąd się to wzięło? Czy testowanie będzie popularnym kierunkiem rozwoju w IT w najbliższych latach?

Hubert: Jeżeli mam być szczery, to wydaje mi się że zainteresowanie przez osoby niedoświadczone wynika trochę z mylnego przeświadczenia, że tester (w szczególności manualny) to najłatwiejsza droga na wejście w spopularyzowany rynek IT $$$. Czy będzie popularnym kierunkiem? Wydaje mi się że tak, bo będzie ciężko zmienić te przekonania. A z perspektywy osób, które już siedzą w branży to myślę, że stawia się większy nacisk na jakość, a co za tym idzie – na testowanie. Interesariusze widzą w tym wartość nie tylko jakościową, ale wiedzą, że znalezienie błędu wcześniej redukuje wydatki poniesione na jego wyeliminowanie.

Miłosz: Moim zdaniem testowanie to droga z najniższym progiem wejścia (w sensie wiedzowym) do branży IT, co wiąże się też z prawdopodobnie najliczniejszą konkurencją i dużą ilością CV wysyłanych na juniorskie stanowiska. Uważam, że jak ktoś jest dobry, to niezależnie od obranej drogi (tester, programista, analityk biznesowy, itd.) to szybko wejdzie w branżę.

Cała branża się rozwija, więc myślę, że z testowaniem nie będzie inaczej. Na pewno cieszy rosnąca świadomość klientów dotycząca potrzeby testowania.

Tomasz: Oprócz wspomnianego niższego progu wejścia, mam wrażenie, że rola QA łatwiej pozwala przekształcić się w innym, być może dla danej osoby bardziej atrakcyjnym kierunku, jak Analityk Biznesowy, UX/UI Designer czy też programista. Dodatkowo jeszcze kilka lat temu stawki QA byłī przeważnie niższe od programistycznych, a ostatnimi czasy te różnice się wyrównały.

Zobacz też

DevDebata Jak wygląda rynek testerów, QA w Polsce? Devdebata

Wspomnieliście mi o ciekawych pytaniach na rekrutacjach na testerów. Możecie je przytoczyć – i przy okazji podzielić się trafnymi odpowiedziami?

Miłosz: “Jak przetestowałbyś stół/szklankę/cokolwiek?” – różne rozmowy, podobne pytania, a najprostsza poprawna odpowiedź to – zgodnie z wymaganiami. Zdarzało się, że rekruter nie był zadowolony z takiej odpowiedzi i wtedy trzeba było bardziej kreatywnie podejść do takiego pytania, np. wymyślając cały proces testowy dla danego przedmiotu.

Tomasz: Przywołane pytanie “jak przetestowałbyś ten stół?” jest naprawdę dobre. Jeśli zaczniemy sprawdzać, czy stół jest stołem, to już wpadamy we własną pułapkę, zakładając, że ten stół ma pełnić funkcję stołu. Być może klient chciał krzesło, ale się z nami nie dogadał. Co z tego, że dostanie super stół, jeśli jego potrzebą jest krzesło? Bez zrozumienia kontekstu biznesowego i potrzeb końcowych użytkowników nie jesteśmy wstanie powiedzieć, czy dostarczamy dobre rozwiązanie.

Dobre są pytania, na które nie ma jednoznacznej odpowiedzi – kiedy zacząć testować (jak najwcześniej), kiedy skończyć testować (najlepiej nigdy, nawet na produkcji można testować, jeśli chcemy pierwsi wiedzieć, że coś nie działa), po co testować, czym jest jakość. Tutaj kandydat pokazuje, jak bardzo rozumie sens roli QA. Warto też spytać o to, jak dana osoba widzi swoją rolę w zespole, co zrobi, gdy wejdzie do projektu – to może pokazać, jak szeroka jest perspektywa danego kandydata. Inna użyteczną informacją jest to, jak dana osoba się rozwija, czego się ostatnio nauczyła – dzisiejszy rynek IT docenia dużo bardziej zdolność adaptacji i zmiany kontekstu niż wiedzę per-se, a wynika to z dynamiki jego rozwoju.

Hubert: Jak Tomek napisał o tym, że klient chciał krzesło, a dostał stół, to aż mi się przypomniał ten mem:

A patrząc szerzej – na co zwraca się uwagę przy rekrutacjach na te stanowiska?

Miłosz: Warto wiedzieć o czym się mówi – uczenie się suchej teorii, bez żadnego odniesienia do praktyki jest błędem. Dla mnie zawsze ważnym czynnikiem (niestety jest to dosyć subiektywne), na który zwracałem uwagę podczas rozmów rekrutacyjnych było: Czy dobrze współpracowało by mi się z tym kandydatem? Poza wiedzą/umiejętnościami ważne jest podejście do pracy, ludzi, a także napotykanych problemów.

Tomasz: Na rekrutacjach na QA, oprócz doświadczenia zwracam również uwagę na zaangażowanie danej osoby, na jej determinację w dojściu do sedna problemu, jak i na zdolność wybrnięcia z trudnej sytuacji (np. gdy programista mówi, że nie naprawi tego buga “bo nie”). Ważnym jest też podejście danej osoby do teamu. Jeśli na któreś trudne pytanie pada odpowiedź w stylu “zwrócę się o pomoc do innego członka zespołu” to oznacza, że osoba ta będzie współpracowała z zespołem, zamiast kręcić się w kółko nad nierozwiązanym problemem.

Jak Waszym zdaniem będzie wyglądała przyszłość tej branży?

Hubert: Przyszłość branży… hmmm myślę, że pójdziemy w stronę większej automatyzacji i skupienia się na testach bardziej szczegółowych i przypadków, które ciężko jest obsłużyć automatami. W programowaniu wielkim tegorocznym hitem jest np. Github copilot wykorzystujący AI do generowania kodu na podstawie komentarzy i tego, co napisaliśmy wcześniej. Może będziemy szli też w tę stronę? Kto to wie.

Tomasz: Mam nadzieję, że Hubert ma rację. Fajnie by było, aby w każdym projekcie była automatyzacja testów, uporządkowany proces, duża świadomość biznesowa i zaangażowani ludzie. Między innymi rolą QA jest to, aby projekty tak wyglądały.

Hubert: Tu jeszcze tylko dodam, że QA ma się zająć dostarczaniem oprogramowania wysokiej jakości, a co za tym idzie jego zadaniem nie są tylko testy, tak jak wspomniał Tomek.

A Wy – macie może plany na dalszy rozwój ścieżki kariery?

Hubert: Oczywiście, ale bardziej z perspektywy programisty. Bo to nie jest tak, że po seniorze jest tylko emerytura, zawsze można wejść na większy poziom abstrakcji i kreować rozwiązania na wyższym poziomie. Nigdy nie można powiedzieć, że wie się już wszystko, więc jeszcze długa droga przede mną.

Tomasz: Nie mam obranej żadnej specyficznej linii rozwoju. Na pewno chcę pozostać na bieżąco z technicznymi rozwiązaniami w dziedzinie testowania i automatyzacji testów, ale chcę też pełnić rolę “konsultanta”, który będzie w stanie polepszyć jakość całego procesu dostarczania oprogramowania, jak również jakość pracy wszystkich osób zaangażowanych. Zobaczymy co przyniesie przyszłość.

Miłosz: W tym momencie skupiam się na rozwoju w automatyzacji oraz tematyce CI/CD. A co dalej? Zobaczymy.

Zdjęcie główne pochodzi z unsplash.com.