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

Polski rynek pracy dla testerów i QA jest bardzo duży i dominują w nim testerzy manualni – to wniosek zaproszonych ekspertów do dzisiejszej devdebaty. – Ta sytuacja nie powinna ulec zmianie, ale zmienią się możliwości jakie mają testerzy manualni, t.j. narzędzia do automatyzacji typu “codeless” spowodują, że ich możliwości testowania będą o wiele większe a ich praca bardziej ciekawa – powiedział Paweł Maciążek, CEO TestRevolution & BugBug.io.

Czy branża testerska znalazła się w ślepej uliczce? Czy organizacje zazwyczaj na zbyt późnym etapie przykładają się do testowania swojego produktu? Gdzie w czasach sprintów scrumowych trwających zwykle dwa tygodnie jest miejsce na testowanie? Na te i na wiele innych pytań odpowiedzi znajdziecie w tej devdebacie.

W devdebacie udział wzięli:

• Paweł Maciążek. CEO TestRevolution & BugBug.io. Przedsiębiorca i lider zespołu z dość dużym międzynarodowym doświadczeniem, w ostatnich latach swojej kariery zawodowej odpowiadał za: ekspansję międzynarodową, projekty IT i zarządzanie zespołami, definiowanie odpowiednich strategii marketingowych / sprzedażowych oraz wdrażanie planów działań, sprzedaż produktów i usług, a także złożonych projektów, wdrażanie nadzoru konkurencji i narzędzi do sterowania działaniami, rekrutacja, szkolenia i prowadzenie międzynarodowych zespołów.
• Paweł Bylina. CTO w BugBug.io. Pasjonat technologii związany z rynkiem IT od lat szkolnych, a czysto zawodowo od ponad 13 lat. Przeszedł w trakcie swojej dotychczasowej kariery przez najróżniejsze stanowiska i role w branży, w tym programisty i team lidera, DevOpsa, czy Product Ownera. Bliżej mu jednak do technologii i startupów niż managementu i korporacji, choć doświadczenie zdobywał w obu tych środowiskach. Osobowość przedsiębiorcy. Aktualnie w roli Co-foundera i CTO w startupie tworzącym narzędzie do testów end-to-end BugBug.io.
• Aleksandra Kornecka. Pracuje jako Software Quality Assurance Engineer z ponad 6-letnim doświadczeniem komercyjnym. Jest certyfikowaną testerką oprogramowania ISTQB oraz konsultantką ds. jakości oprogramowania. Docenia nurt DevTestSecOps, dobre procesy w pracy, analizę wymagań i ryzyka, UX, ochronę danych osobowych oraz architekturę informacji. Ola jest osobą aktywną w społeczności testerskiej, realizując się jako prelegent i mentorka.

Czy branża testerska znalazła się w ślepej uliczce? Jak widzicie jej sytuację?

Paweł Maciążek, CEO TestRevolution & BugBug.io:

Branża testerska będzie rozwijała się dynamicznie, być może czeka ją też rewolucja, bo jest sporo wyzwań, które są kluczowe do dalszego rozwoju. Poniżej kilka aktualnych problemów, które wpływają na branżę:

1. Rosnąca złożoność powstających aplikacji wymaga większych nakładów pracy, a zatem wysiłek testowy jest większy.
2. Kompleksowość testów wzrasta wykładniczo wraz z pojawianiem się nowych funkcji a pokrycie testowe rośnie liniowo, ponieważ testy mogą być dodawane tylko pojedynczo. W efekcie produkowane jest coraz więcej kodu, niż testerzy są w stanie przetestować, co prowadzi do coraz większej luki w pokryciu testowym
3. Programiści nie za bardzo lubią pisać testy – badania pokazują, że zaledwie kilka procent zajmuje się QA i projektowaniem testów.

Możliwości rozwiązania tego problemu jest kilka, jeden to zwiększenie ilości testerów automatycznych, ale w tym wypadku często pojawiają się kolejne problemy, natury makroekonomicznej, czyli sytuacja rynku pracy i ilości dostępnych zasobów ludzkich. Oczywiście można zwiększyć nakłady na szkolenie tych kompetencji, ale to też jest tylko rozwiązanie dla części problemów, bo wielu testerów manualnych nie jest w stanie osiągnąć poziomu samodzielnego pisania testów automatycznych.

Druga możliwość rozwiązania tego problemu to właśnie narzędzia dla testerów, które pozwolą im pracować lepiej i szybciej, do tej pory wyglądało to różnie, bo wiele narzędzi nie spełnia pokładanych w nim nadziei. Dostępne narzędzia na rynku działają w sposób nieprzewidywalny przez co nie można na nich polegać. Jest też problem efektywności tych narzędzi: rozwiązania są ociężałe, wolne, trudne w konfiguracji i zniechęcające do użytkowania (archaiczne UI/UX).

Aleksandra Kornecka, Software Quality Assurance Engineer:

Trudno mi oddzielić taki byt, jak „branża testerska” od całości procesu wytwarzania oprogramowania – jesteśmy połączeni w cyklu developmentu, a testowanie było, jest i będzie zawsze elementem takiego cyklu, choć może przybierać różne formy, role i praktyki.

Jeśli chodzi o „branżę testerską” jako ludzi na stanowiskach „tester” czy „QA” to faktycznie obserwuję różne kierunki rozwoju – niektóre firmy zatrudniają osobne działy testerskie i są dumne z posiadania wsparcia zawodowych testerów. Inne lawirują między „mamy testerów” a „nie potrzebujemy testerów, bo jest DevOps”. Jeszcze inne ukrywają testerów pod nazwami innych stanowisk.

W IT jedyną pewną rzeczą jest zmiana oraz fakt, że cenne są zdolności do adaptacji, uczenia się nowych rzeczy, rewidowania istniejących. Stąd trudno mi myśleć, że „branża testerska” jest w jakiejś ślepej uliczce, bo te wartości są cały czas „na topie”. Zmieniają się narzędzia, trendy, ale kluczowe kwestie pozostają niezmienne.

Do tego każda branża potrzebująca oprogramowania (czyli praktycznie każda) ma swoją specyfikę, np. automotive czy medyczna wymagają więcej procedur i certyfikowania, i tam zawsze będzie potrzebna odrębny etap testów oraz testerzy stanowiskowi, najlepiej jeszcze certyfikowani ISTQB.

Przyznam też, że wielu programistów nie lubi specjalizować się w testach albo nie mają zmysłu testerskiego lub cierpliwości do testów różnego poziomu i rodzaju – tutaj zawsze będzie pole do popisu dla zawodowych testerów.

Pewnego rodzaju ślepą uliczką wydają mi się „fabryki testerów”, których ostatnio pojawiło na rynku, a w których wmawia się ludziom, że każdy może być dobrym testerem i zarabiać miliony. Wielu ludzi żądnych zmiany branży lub dobrego wynagrodzenia podąża tym trendem, płacąc kilka tysięcy za szkolenie, które czasami niewiele realnie daje.

Przychylam się do tego, że każdy może zacząć testować, ale nie każdy będzie w tym dobry i poszukiwany na rynku pracy.

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

Paweł Maciążek, CEO TestRevolution & BugBug.io:

Jako rynek pracy jest bardzo duży i dominują w nim testerzy manualni – widać to nawet po ogłoszeniach na waszym portalu. Ta sytuacja nie powinna ulec zmianie, ale zmienią się możliwości jakie mają testerzy manualni, t.j. narzędzia do automatyzacji typu “codeless” spowodują, że ich możliwości testowania będą o wiele większe a ich praca bardziej ciekawa.

Paweł Bylina, CTO w BugBug.io:

To zależy do czego odnosimy to pytanie. Jeśli spojrzeć na to jak 10 lat temu postrzegano pracę QA, a jak teraz, to mamy ogromną przepaść. Na plus oczywiście. Rynek zrozumiał, a może zwyczajnie klienci wymusili podniesienie jakości tworzonego oprogramowania. Za tym poszedł popyt na usługi związane z testowaniem. Mamy tym samym zdecydowanie więcej oferty pracy w tym segmencie niż jeszcze kilka lat temu, rosną również płace. Z moich obserwacji wynika także, że jest dość wyraźny podział na testerów manualnych i inżynierów testów (QA Engineers). O tych drugich na rynku jest spora rywalizacja, bo mało kto kieruje swoją karierę w tę stronę (w nawiązaniu do ankiet StackOverflow).

Na pewno warto zwrócić uwagę w kierunku ruchu “no-code” i nowych narzędzi pojawiających się na rynku, które wspierają inżynierów testów w ich pracy. Dotychczas narzędzia tego rodzaju pozostawiały bardzo dużo do życzenia, ale widać, że “idzie nowe”. Dobre narzędzie potrafi z testera czy inżyniera QA zdjąć mnóstwo powtarzalnej i niepotrzebnej pracy, a w związku z tym uwolnić jego deficytowe zasoby i wykorzystać efektywniej lub po prostu w innych projektach w organizacji.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Obserwuję wzrost zapotrzebowania na doświadczonych testerów i QA. Jest sporo dobrych ofert dla testerów automatyzujących w danej technologii oraz „senior QA”, którzy mają w obowiązkach zarówno mocne kwalifikacje programistyczne, jak i dotyczące tworzenia strategii testów.

Odnoszę wrażenie, że trwa swego rodzaju „moda” na IT, istnieją podmioty szkoleniowe sugerujące, że tester to najprostszy punkt wejścia do IT – w efekcie mieliśmy wysyp stażystów i junior testerów przez co obecnie trudniej jest zaczynającym wejść na rynek niż kilka lat temu. Dla doświadczonych testerów jest sporo pracy. Widzę też tendencje rekrutowania polskich testerów na zagranicę, od kiedy praca zdalna jest bardziej powszechna.

Co sądzicie na temat bootcampów, które sprzedają wizję “od zera do testera”?

Paweł Bylina, CTO w BugBug.io:

Moje zdanie na temat wszelkich bootcampów, od początku powstania firm świadczących takie usługi, jest dość jednoznaczne – sprzedawanie marzeń za ciężkie pieniądze. Praca w branży IT jest wymagająca i jeśli ktoś nie jest w stanie przy aktualnym, bardzo szerokim dostępie do wiedzy w internecie samemu narzucić sobie “reżimu edukacyjnego” i przynajmniej przerobić podstawy z danej tematyki, to z dużym prawdopodobieństwem nie tylko nie dostanie pracy w branży, ale takiego bootcampu zwyczajnie nie ukończy. Jest mnóstwo darmowych materiałów, książek, wideo szkoleń na platformach typu udemy.com i podobnych – sugerowałbym zacząć tutaj i sprawdzić czy to na pewno temat dla mnie zwyczajnie mniejszym kosztem.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Zawsze jestem za tym, by ludzie się rozwijali. Natomiast jestem zdania, że praca w IT jest dość specyficzna i nie każdy się w niej odnajdzie. Co nie znaczy, że nie warto próbować.

Niemniej jednak twierdzenie, że każdy po 2 tygodniach kursu zostanie testerem jest moim zdaniem nadużyciem. A już na pewno w takim czasie po samym tylko kursie nie będzie się dobrym testerem, świadomym co robi i co warto robić w danej implementacji. Doświadczenie w projektach i pracy z ludźmi w prawdziwych projektach jest najważniejsze.

Osoby spoza IT po samych kursach mają jakąś wiedzę, której nie potrafią na początku „przypiąć” do realiów.

Czy Waszym zdaniem firmy zazwyczaj na zbyt późnym etapie przykładają się do testowania swojego produktu?

Paweł Maciążek, CEO TestRevolution & BugBug.io:

Ciężko generalizować, bo w wielu firmach testowanie jest bardzo dobrze prowadzone i programowanie z testowaniem odbywa się jednocześnie, są jednak przypadki i to w bardzo dużych organizacjach (np. banki i połączone z nimi instytucje finansowe lub firmy ubezpieczeniowe), które mają spory problem przy testowaniu. Ostatnia historia z mbanku to chyba najbardziej znany przypadek, ale takich problemów jest dużo więcej.

Paweł Bylina, CTO w BugBug.io:

Trudno jednoznacznie ocenić. Jest mnóstwo firm, które ciągle nie dojrzało do tego żeby zatrudnić osobę do zespołu w roli testera w ogóle. Jest też na pewno sporo takich, które by chciały, ale ich na to zwyczajnie nie stać. Startupy, w których pracowałem do tej pory w początkowej fazie często nie mogły sobie pozwolić na zatrudnienie QA pilnując mocno kosztów. Ostatecznie jednak zawsze jakaś forma testowania jest realizowana, choćby manualna weryfikacja kluczowych procesów.

Problem na pewno nie występuje w średnich i większych organizacjach, w których normą w tych czasach jest uczestnictwo QA w zespołach produktowych. Często to właśnie te osoby są cichymi bohaterami, które ciągną jakość produktu w górę, gdy terminy gonią nie pozwalając “przepychać” aplikacji z błędami. Właściwie na tym polega rola asertywnego i dobrego QA właśnie.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Trochę tendencyjnie zadane pytanie. Moim zdaniem ocena procesu danej firmy powinna być przeprowadzona z uwzględnieniem jej realiów i charakterystyki. Zależy to też od obranej metodyki pracy, wielkości i zróżnicowania zespołu, branży, rodzaju oprogramowania, stopnia w jakim projekty muszą być walidowane i certyfikowane. Najlepszą sytuację mają firmy, które rozumieją, że testy i dbanie o jakość zaczynają się zanim powstanie linijka kodu.

Niezależnie czy i ilu testerów zatrudnia firma, to od jej dojrzałości zależy jak wyglądają procesy wbudowywania jakości w jej strukturach.

Wartościowy QA i tester odnajdzie się w każdej firmie, która rozumie potrzebę weryfikacji swojego produktu oraz której zależy na dobrym technicznie produkcie. W metodyce kaskadowej prowadzenia projektu testowanie jest z definicji na końcu procesu i nie jest to nic złego pod warunkiem, że wszyscy w projekcie rozumieją proces równie dobrze i jest to uzgodnione z interesariuszami jako koszt na końcu projektu, który warto podjąć z różnych powodów.

Oczywiście zdarzają się firmy, które zbyt późno lub na końcu uzmysławiają sobie, że „jednak przydałoby się potestować” albo „jednak ten tester miał rację żeby zrobić A i nie robić B” – dobrze jeśli uczą się na błędach i następnym razem po prostu wcześniej zaadresują potrzeby weryfikacji oraz testowania.

W firmie, w której nie rozumie się po co tester istnieje albo, w której nie pielęgnuje się kultury jakości takie opóźnienia albo niska jakość i ilość testowania będzie odbijała się na jakości końcowej produktu.

Jakie opcje mają firmy w sytuacji, gdy podejmą decyzję o zwiększeniu kosztów na testowanie swojego produktu? Od czego powinny zacząć?

Paweł Maciążek, CEO TestRevolution & BugBug.io:

Jest kilka opcji i zależności od projektu powinny być rozważane odpowiednio wcześniej.

• Opcja nr. 1 to oczywiście zwiększenie ilości osób odpowiedzialnych za testy – to nie zawsze jest szybkie i skuteczne, bo rodzi sporo innych problemów i dodatkowych kosztów.
• Opcja nr. 2 to automatyzacja pracy testerów – tutaj przeważnie pojawiają się problemy techniczne przy wdrażaniu nowych narzędzi i jest ew. problem krzywej nauki takiego narzędzia, dodatkowo trzeba to dobrze zaplanować żeby nie wprowadzić nowych rzeczy w momencie w którym team jest zbyt mocno przeciążony projektami bo to spowoduje dodatkowe opóźnienia.
• Opcja nr. 3 (według mnie najbardziej skuteczna) to zwiększenie liczby osób przy jednoczesnym wprowadzaniu narzędzi do automatyzacji – unikniemy wtedy problemów a zwiększenie możliwości testowych w teamie w idealnym scenariuszu nie będzie rosło liniowo a wykładniczo.

Paweł Bylina, CTO w BugBug.io:

Przede wszystkim od zbadania realnego zapotrzebowania względem produktu, który ma być testowany. Inną sytuację mamy kiedy projekt ma określony czas życia (budowany przez software house i przejmowany przez zespół docelowy), a inną w momencie gdy budujemy rozwiązanie długofalowo utrzymywane i ciągle rozwijane. Naturalnym jest, że gdy budżet rośnie robi nam się przestrzeń na zatrudnienie dodatkowych osób do zespołu. W takiej sytuacji trzeba jednak uwzględnić wiele dodatkowych czynników.

Można skalować kompetencje testerów manualnych, a można zainwestować w inżynierów QA, którzy testy będą programować. Można również wybrać wariant pośredni i wykorzystać szereg narzędzi wspierających procesy tworzenia testów i posiadać kompetencje mieszane w zespole, tj. testerów manualnych i automatyzujących. Projekt na pewno jeśli do tej pory nie posiadał to powinien zbudować również swój proces CI/CD z uwzględnieniem automatycznego raportowania o błędach. Ścieżek jest bardzo wiele i nie ma tej jedynej słusznej.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Trudno tutaj o uniwersalna poradę, bo każda firma, produkt i projekt mają swoją specyfikę.

Jest bardzo wiele możliwości i opcji inwestowania w jakość. Nazwałabym to inwestycją a nie po prostu „kosztem”, bo koszt to coś co się wydaje i jest wydane, zaś inwestycja polega na przyłożeniu się do pracy, która daje długofalowe efekty – tak jest z jakością – kiedy unikamy długu technicznego, robimy rozwiązania wspierające rozwój produktu, myślimy perspektywicznie, pilnujemy zadowolenia użytkowników – wtedy zbieramy owoce naszej inwestycji w jakość.

Pamiętajmy, że jakość nie oznacza testowania jako czynności, ani ilości popełnianych czy znajdowanych błędów. Jakość budowana jest przez dosłownie cały zespół. Inwestować w jakość można począwszy od zatrudniania dobrych specjalistów (programiści, testerzy, analitycy, UX badacze, PM / PO), którzy są świadomi jak mogą ze swojej strony wspierać jakość produktu.

Można zespół wyposażać w narzędzia usprawniające pracę – proces, programowanie, testowanie, zarządzanie projektem i wymaganiami, komunikacją. Od dobrych praktyk zbierania potrzeb użytkowników i badań UX, czy formułowania wymagań, dokumentacji, analizy statycznej i bezpieczeństwa kodu, poprzez wersjonowanie, dobre praktyki code review, sprawną automatyzację testów, sensowne testy manualne, aż po pożyteczny pipeline wydawczy i narzędzia ciągłej integracji oraz sprawny monitoring produkcji i alerting.

Można inwestować w szkolenia zespołu, które pozwolą im znajdować optymalne sposoby działania, narzędzia, korzystać optymalnie z narzędzi i dobrych praktyk związanych z daną technologią, branżą, rozwiązaniem.

Rodzaj i proporcje tych inwestycji zależą od potrzeb danej firmy i super jest mieć w organizacji osoby, które mądrze doradzą w jakie działania warto inwestować.

Z czego Waszym zdaniem wynika niechęć programistów do przebranżowienia się w kierunku projektowania testów?

Paweł Maciążek, CEO TestRevolution & BugBug.io:

Wiadomo, że programista musi się ciągle uczyć – tego zawodu nie da się wykuć raz na zawsze i już dalej na tym bazować, QA jest dość specyficzną ścieżką kariery. Dla wielu programistów wydaje się nudna a dodatkowy motywator to zarobki – w QA są dobre, ale w innych specjalizacjach mogą być lepsze.

Paweł Bylina, CTO w BugBug.io:

Moje osobiste odczucia wskazują na dwa powody. Po pierwsze – wynagrodzenie. Średnia pensja programisty jest na rynku wyżej wyceniania niż QA. Różnica ta w ostatnich latach systematycznie się zaciera, ale ciągle występuje. Trudno zatem dziwić się, że mało jest chętnych na zejście z wynagrodzenia przy przejściu na zbliżone kompetencjami stanowisko.

Druga sprawa sama specyfika stanowiska. Praca programisty moim zdaniem ma w sobie więcej procesu twórczego niż praca testera. Ten drugi mimo wszystko ma pewnego rodzaju odtwórczą pracę. Działa na już gotowych procesach i choćby je nawet automatyzował to i tak z punktu widzenia całości programuje się po prostu kolejne ścieżki użytkownika czy testy integracyjne API. Wyobrażam sobie, że nie dla wszystkich jest to interesujące. Na pewno można też na tych stanowiskach się spełniać próbując nowych narzędzi, rozwijając się pod kątem testów wydajnościowych czy nawet specjalisty security, ale każda z tych ról ma inną specyfikę i często wymaga od ludzi zupełnie innych kompetencji.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Istnieją firmy, gdzie osobne stanowisko zajmuje się projektowaniem testów, lecz najczęściej jest to jeden z obowiązków testera lub QA. Są też firmy, w których to programiści projektują testy na poziomie integracyjnym a nawet UI. Nie zauważyłam żadnej jawnej niechęci do samego testowania. Często za to procesy i dług techniczny skutecznie frustruje i utrudnia pisanie sensownych testów i tutaj w pełni rozumiem niechęć programistów i kogokolwiek do interakcji z takim kodem.

Jeśli pytanie dotyczy przebranżowienia się programisty na testera to mogę powiedzieć, że znam takie przypadki, choć o wiele mniej niż przypadków przebranżowienia w drugą stronę.

Wyróżniłabym tu dwie rzeczy:

• osobiste predyspozycje,
• osobiste preferencje.

Te dwie składowe niosą ze sobą w różnych proporcjach różne czynniki – może być więc ktoś motywowany przez wyższe nadal najczęściej zarobki programisty, może ktoś uwielbia pracę z kodem i chce tworzyć produkt a nie tylko go otestowywać.

Są też osoby, które uwielbiają projektować, wspierać procesy i pracować bardziej z ludźmi niż z kodem. Umiejętności i zdolności oczywiście też mają wpływ na decyzję i kierunek przebranżowienia, ale niekoniecznie główny.

Poza tym czym innym jest przebranżowienie z jednej roli w IT na inną rolę w IT, nawet stereotypowo „odległą” (np. PM na programistę albo na odwrót), a czym innym z innej branży na IT w ogóle.

Od kilku lat wszystko i wszyscy starają się być “agile”. Gdzie w czasach sprintów scrumowych trwających zwykle dwa tygodnie jest miejsce na testowanie?

Paweł Bylina, CTO w BugBug.io:

Przy zdrowym podejściu w zespole scrumowym zadania wyceniane są razem przez programistów i testerów. W takim przypadku czas na testowanie jest niejako wpisany w zadanie, a więc jest uwzględniony w ramach sprintów. To jednak potrafi być często niestety tylko teorią, a nie praktyką. Jeśli idzie nacisk “z góry” na tempo prac, to zdarza się, że testy zaczynają być spychane poza sprint i są realizowane post factum powodując nawroty zadań i poprawki do funkcjonalności, które zostały już zrobione w poprzednich iteracjach.

Na pewno prościej jest, gdy w ramach projektu zautomatyzujemy chociaż testy regresji, a testujemy tylko nowe zadania. Praktyka jest jednak bardzo różna i zależy od zarówno Product Ownera, samego zespołu budującego oprogramowanie czy wymogów jakościowych produktu ogólnie.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Agile podobnie jak wszelkie inne metodyki powinno być świadomym wyborem stylu pracy i procesu. W gestii organizacji jest też pomóc zrozumieć pracownikom jak sprawnie działać w takim stylu jeśli jest narzucony. W poprawnie zaplanowanym procesie i sprincie jest miejsce na wszystkie etapy normalnego cyklu wytwarzania oprogramowania, tyle że w mikroskali (inkrement po 2 tygodniach, a nie po miesiącu czy roku jak to bywa w metodyce kaskadowej). A zatem jest też czas i miejsce na testowanie.

Powinniśmy określić, co rozumiemy pod „testowaniem”, gdyż to może oznaczać ogromne zróżnicowanie praktyk, czynności i narzędzi wykonywanych przez różne role w projekcie.

Stereotypowy tryb „dobrego agile” mógłby wyglądać tak:

zespół zbiera wymagania dotyczące produktu od użytkowników, testowane są prototypy i makiety produktu z próbką badanych, potem zespół analizuje zebrane wymagania biznesowe i techniczne i wyszukuje potencjalne trudności i obszary mogące być szczególnie podatnymi na błędy. Można testować dokumentację, w tym czasie programiści zaczynają implementację i piszą testy jednostkowe do powstającego kodu. Wspomaga ich analiza statyczna kodu przy pull requestach, potem jest weryfikacja manualna, tworzone są scenariusze testów, automatyzowane są kluczowe ścieżki użytkownika implementacji, dopisywanie są testy integracyjne kluczowych ścieżek, zdefiniowane i zaimplementowane są metryki sukcesu i zdrowia aplikacji oraz dashboardy, założony jest monitoring kodu oraz alerting po wydaniu.

Nie ma przepisu idealnego, rzadko udaje się ująć wszystkie te elementy w powtarzalny proces, ale warto skupić się na obszarach kluczowych dla danego produktu czy projektu.

Jeśli chodzi o testowanie w sprincie:

analizowana jest logika i use cases według wymagań biznesowych i technicznych, tworzone są przypadki testowe, w tym czasie programiści rozpoczynają implementację, mogąc się konsultować na bieżąco z testerami, analitykami, produktowcami. Programiści otestowują swój kod jednostkowo niejako podczas implementacji kodu produktu, testerzy testują eksploracyjnie bieżącą implementację, testerzy automatyzujący rozpoczynają pisanie testów automatycznych.

W przypadku większych wydań na koniec implementacji (np. na koniec sprintu, ale niekoniecznie, może być też cały sprint osobny na to, albo początek sprintu) cały zespół za przywództwem testerów wykonuje testy regresyjne manualnie albo ze wspomaganiem narzędzi.

Jak waszym zdaniem będzie wyglądała przyszłość tej branży? Czy wysłużone Selenium umrze? AI “pożre rynek”?

Paweł Maciążek, CEO TestRevolution & BugBug.io:

AI to na razie w wielu przypadkach tzw. “buzz word” – słowo odmieniane przez wszystkie przypadki, w wielu startupach po prostu dodawane do wszystkich możliwych produktów, które tak naprawdę z sztuczną inteligencją nie mają nic wspólnego. W przypadku branży testowej nie ma jeszcze takich narzędzi, ale w przyszłości na pewno się pojawią – sami mamy w planach stworzyć taki system. Na razie to faza koncepcji, ale przypuszczam, że w przyszłości to będzie możliwe. W przypadku Selenium możliwości rozwoju są raczej ograniczone, mimo to myślę, że w najbliższej przyszłości nie umrze, ale po prostu będzie miało coraz mniejszy udział w rynku.

Paweł Bylina, CTO w BugBug.io:

Branża na pewno mocno się rozwija i nabiera z roku na rok tempa. Rynek globalnie wskazuje na wyraźną tendencję rosnącą segmentu testowania ogólnie. To jednak napędzane jest po prostu rozwijającym się segmentem IT i wszelką automatyzacją dookoła, jak i wzrostem jakości tworzonego oprogramowania. Odnosząc się jednak do wspomnianego Selenium to moim zdaniem w mniejszym lub większym stopniu pozostanie z nami na zawsze. Jest jakby nie patrzeć częścią standardu W3C. Istnieją także naprawdę duże firmy takie jak BrowserStack czy Sauce Labs, które bazują na Selenium, mają się dobrze i nie zapowiada się by coś w tym obszarze miało się szybko zmienić.

Oczywiście jest konkurencja open source w postaci cypress czy puppeteer, ale moim zdaniem to dopełnienie rynku i zdrowa konkurencja, której przez wiele lat nie było. Sytuację można też ocenić po dostępnych ofertach pracy – ciągle sporo z nich wymaga znajomości selenium webdriver. Oczywiście rynek nie stoi w miejscu i pojawiają się narzędzia kolejnych generacji dla testerów, ale nie oszukujmy się, AI to nie jest i długo nie będzie. Całe to hasło sztucznej inteligencji jest ostatnimi czasy tak wyświechtane, że aż nudne do bólu. AI nie istnieje, co najwyżej mamy procesy Machine Learningowe, które potrafią pewne czynności na bazie określonych zbiorów danych automatyzować. I w takim kierunku oceniam, że segment będzie się rozwijał. Czyli w mojej opinii narzędzia, które będą powtarzalne czynności automatyzowały, ale nie zastąpią QA czy testera tylko będą dla niego wsparciem. Słowem, pracy nie zabraknie jeszcze długo chociaż juniorzy będą mieli z wejściem na rynek coraz ciężej.

Aleksandra Kornecka, Software Quality Assurance Engineer:

Jeśli chodzi o „branżę testerską” to jest ona spójna z branżą IT w ogóle. Tak jak wspominałam wcześniej – narzędzia i role się zmieniają, ale testowanie jako takie zawsze z nami będzie.

Automatyzacja, AI – to też są moim zdaniem narzędzia, środki do celu jakim jest usprawnienie testowania i zautoamtyzowanie powtarzalnych ścieżek czy często występujących błędów w zależności od typu oprogramowania. Obecnie słowo „AI” oraz „ML” są modnymi słowami, którymi często nazywa się dawno już używane algorytmy.

Myślę, że każdemu profesjonaliście zależy by ułatwić sobie życie oraz zwiększyć efektywność działań więc cieszę się, że jakieś działania w kierunku wsparcia procesów testowych sztuczną inteligencją się dzieją. Co do jej możliwości to na paręnaście kolejnych lat nie przewiduję by zastąpiła ludzi w dobrych testach eksploracyjnych, a to jest największa wartość testów tzw. manualnych. Nie chodzi tu przecież o „przeklikanie się” jak małpka albo automat, tylko poszukiwanie, co jeszcze może pójść nie tak, a co może wydarzyć się na produkcji.

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