Mentionsy
Czy to już KONIEC Po Szklanie i Na Testowanie? - 076 - Podcast QA
Czy to już koniec Po Szklanie i Na Testowanie? Zapraszamy na odcinek podcastu, gdzie Kuba wraz z Pawłem zrobią przegląd aktualnych hot tematów (AI, Playwright, Automatyzacja) i poruszą jeden z najważniejszych do tej pory na kanale. Rozkład jazdy: - Co słychać | Nintendo Switch | Gaming09:34 - Narzędzia AI stworzone z myślą o QA27:51 - Czy P********t jest taką rewolucją? - Czy zespół bez testerów jest możliwy? - Czy to naprawdę koniec? Co się stało, że się zes**ło?
Szukaj w treści odcinka
Sporo się rzeczy dzieje, takich powiedzmy nie do końca branżowych, tak bym to nazwał, nie związanych do końca z pracą, gdzieś z tym naszym światem IT QA.
Pytanie, jak ty, patrząc na to wszystko z boku, oceniasz tę rewolucję AI, ale z perspektywy QA?
Testowałem kilka różnych narzędzi, które czysto teoretycznie były dedykowane QA-om i tym procesom QA-owym, ale tak jak sam powiedziałeś, zauważyłeś, to coś, co też my delikatnie próbowaliśmy zrobić, jest to takie bardziej wspomaganie takiego procesu od spodu.
W sensie narzekam, ale narzekam na każdą rzecz w IT mniej bądź bardziej, dlatego jestem w QA.
Jeżeli mamy zespół, który pisze backend w dotnecie i mamy jakieś ograniczone zasoby w QA, jeżeli chodzi o testowanie API, no to nie uciekajmy do innej technologii, tylko spróbujmy
Wyobrażasz sobie płynnie i dobrze działający zespół bez dedykowanego QA w nim?
Podstawowym argumentem, albo warunkiem, żeby tego QA nie było, to to, że ten zespół deweloperski, czy cokolwiek by w nim pracował, czy deweloperzy, biznes-analitycy, PM-owie itd., to jakby pewny poziom świadomości tych ludzi musi już być na jakimś tam konkretnym poziomie.
I właśnie wtedy, żeby tego QA nie było, to ci ludzie mimo wszystko muszą wiedzieć, że ta jakość musi się w tych elementach pojawiać, że muszą być jakieś tam testy, że czy to oni będą sobie nawzajem testować, czy ktokolwiek, jakkolwiek będzie patrzył na ten finalny produkt, albo już nawet w momencie implementacji, tak jak pamiętam takie fajne przypadki, na samym początku mojej pracy, jak podchodziłem gdzieś tam do kolegów z zespołu i oni coś tam dewelopowali, to mieli coś takiego, że widzieli, że jest błąd w ich kodzie.
Jak QA nie znajdzie, to pies go drapał, mi się nie chce męczyć nad tym, żeby go fiksnąć.
Więc jak masz taki mental, no to jednak QA jest must have.
To nie musi być dedykowany QA.
Natomiast jeżeli mamy naprawdę jakieś duże projekty, gdzie goni nas ten czas, gdzie czas pracy programisty jest więcej warty, i to tak znacznie więcej warty, niż czas pracy testera QA, no to wtedy ten QA raczej uważam, że powinien się pojawiać, że powinien część tych obowiązków weryfikacji przeprowadzać, pilnować tego w ogóle porządku, bo to często też jest na naszych barkach, że my nie tylko klikamy i sprawdzamy, zgłaszamy defekty, ale też pilnujemy, żeby był porządek we wszystkim dookoła.
Dodałbym tylko to, że moje podejście zmieniło się też o tyle, że teraz jakbym budował zespół od zera, to bardzo dużym wyznacznikiem tego, ile takich QA-ów bym dorzucił do zespołu.
Bo im prostszy projekt, tym bardziej sobie wyobrażam, że książkowo jakbyśmy wszędzie mieli takich QA, jak sobie wyobrażamy, że QA powinien być, to wszędzie bym ich wpychał.
My sobie mówimy, o dobra, tutaj mamy zespół QA-ów i tak dalej, a bardzo często ta praca wygląda tak, że robimy to, co programiści nam napiszą w tasku.
To łatwiej mi po prostu przyjąć to, że w takim zespole by QA jako takiego dedykowanego nie było.
Im więcej danych i więcej ścieżek, które mogą wystąpić w trakcie tym większy nacisk na te zespoły QA bym położył.
Coordynatorów, że tak powiem, tych doglądaczy, tych prawdziwych QA'ów, a po prostu postawił na bardzo dużo testerów, którzy de facto siedzą i klikają te wszystkie możliwe scenariusze.
No tylko znowu, czy my do eksploracji, czy my do takich zadań potrzebujemy QA-ów takich, wiesz, z krwi i kości, jak to mówimy?
Tu fajną rzecz poruszyłeś w kwestii tego poziomu, czy to musi być QA z takiej skryfikości, czy to może być zwykła osoba, która ma jakąś kreatywność i potrafi klikać.
Powiedzmy, jest ogarnięty nasz klient i nie przewidujemy takich czynności, nie klikamy, nie walimy głową w klawiaturę, a okazuje się, że jednak czasem warto, czy jednak warto jest tam poszukać tych opcji i wtedy to poklikać, no i wtedy taki QA bardziej się przydaje w tym zespole bezpośrednio developerskim, no bo programista, no tak jak sam już zauważyłeś, on te podstawowe ścieżki gdzieś tam do pewnego poziomu rozgałężeń pewnie by poklikał, ale walić głową w klawiaturę to mu się raczej nie chce.
Zgadza się, ale to właśnie teraz pytanie, czy osoba, którą opisałeś, to właśnie jest QA, czy jednak ten taki tester oldschoolowy?
Nie do końca chyba ma przestrzeń na to, żeby być tym właśnie modnym w ostatnich latach QA-em, nie?
Poszło mocne parcie na to, że jesteś QA-em, to musisz tam w procesach uczestniczyć, budować to od początku i tak dalej i tak dalej.
My technicznie jako QA poszliśmy bardzo do przodu.
Ostatnie odcinki
-
Czy to już KONIEC Po Szklanie i Na Testowanie? ...
24.09.2025 06:20
-
Dawid Pacia - jak QA zmieniało się przez lata, ...
18.08.2025 06:39
-
TADA x PSINT: Dlaczego przełożyliśmy konferencj...
16.07.2025 08:18
-
Czy AI pozwoli nam stworzyć aplikację i testy b...
03.03.2025 08:04
-
Czy AI pozwoli nam stworzyć aplikację i testy b...
03.03.2025 07:45
-
Czy AI pozwoli nam stworzyć aplikację i testy b...
03.03.2025 07:31
-
Po Szklanie Charity Special - ARNIKA HRYSZKO - ...
24.02.2025 07:30
-
Wzorce programowania obiektowego w testach auto...
17.02.2025 07:30
-
Aktualności ze świata QA - 070 - Podcast QA
10.02.2025 07:30
-
Czy tester powinien znać technologie, w której ...
15.01.2025 08:00