W najnowszym odcinku Bezpieczny Kot Podcast gościmy Piotra Tuńskiego, doświadczonego QA lead’a, który dzieli się swoimi przemyśleniami na temat ewolucji roli testera w branży IT. Dyskusja koncentruje się na trzech głównych wątkach:

1. Innowacyjne podejścia w testowaniu: Piotr wprowadza koncepcję „Shift Right” – testowania na produkcji, omawiając jej potencjał i wyzwania w kontekście zapewniania jakości oprogramowania.
2. Transformacja roli testera do QA: Piotr omawia, jak tradycyjna rola testera ewoluuje w kierunku szerszego zakresu odpowiedzialności QA, podkreślając znaczenie umiejętności miękkich i biznesowych.
3. Znaczenie automatyzacji i bezpieczeństwa w QA: Piotr podkreśla rosnące zapotrzebowanie na umiejętności w zakresie automatyzacji testów oraz znajomość aspektów bezpieczeństwa jako kluczowe elementy współczesnego QA.

Więcej o Piotrze znajdziecie na jego stronie internetowej oraz na jego LinkedIn.

Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.

Transkrypcja

Krzysztof: Witamy, witamy bardzo serdecznie. Jak będziecie tego odsłuchiwać, to będzie 9 września, czyli dzień testera oprogramowania. Jest z nami nasz gość, Piotr Tuński, jest też Andrzej. Witam was serdecznie.

Andrzej: Siemaneczko.

Krzysztof: Piotrze miło nam Ciebie gościć w naszym podcaście Bezpieczny Kot Podcast. No i od razu jakbyś mógł w telegraficznym skrócie przedstawić się naszym słuchaczom i powiedzieć czym się na co dzień zajmujesz.

Piotr: Jasne no to w telegraficznym skrócie jestem QA-em, obecnie QA leadem. jakby tutaj umiejętności miękkie przeważyły w tym kierunku, ale w dużym, bardzo telegraficznym skrócie, niecałe 6 lat doświadczenia, 4 firmy, 6 projektów, zazwyczaj byłem, że tak powiem testerem, później ewolucja w kierunku QA, a jak to w ogóle zrozumiałem, kim jest QA, i finalnie że tak powiem, awans jakby w jednej firmie, przebijanie się przez szczeble, no i finalnie jakby QA Lead obecnie w Santanderze, w nordyckim, żeby też nie mylić z polskim, bo mamy różne, że tak powiem, filie na całym świecie. Także no to jest mocna odnoga.

Andrzej: Ja będę miał od razu pierwsze pytanie, bo mi to się lampka już zapaliła. I zawsze o to pytam, jak tylko druga strona punktuje. Powiedz mi, jak ty widzisz różnicę pomiędzy testerem a QA-em, bo zaznaczyłeś, że najpierw byłeś testerem, a potem byłeś QA-em, czyli zakładam, że QA jest czymś szerszym w Twoim spojrzeniu.

Piotr: Jasne. Tutaj zdecydowanie na pewno możemy od razu przyczepić się słowa szerszy, bo QA zdecydowanie jest szerszym od noga, ale zaczynając od testera, Jakie moje definicje testera są? na pewno jest sporo, natomiast jeśli mielibyśmy streścić taką osobę, to jest osoba, która zajmuje się bardzo wąską częścią sprawdzenia oprogramowania, ale tylko w wyznaczonym obszarze, czyli na przykład mamy jakieś checklisty, listy kontrolne, coś, co już jest zdefiniowane albo też będzie zdefiniowane przez testera, po czym się po prostu poruszamy. Jakby tutaj jest przez nas weryfikacja, walidacja produktów w taki sposób, żeby dowieść coś, co było jakby wymagane i też zgodne z oczekwaniami klient. No i jakby tutaj ta praca testera można powiedzieć, że się zakończa. Natomiast QA, no to tutaj możemy pójść troszkę bardziej, ponieważ wygraczamy poza samo testowanie produktów takim powiedzmy, nie wiem, testowanie featurera danego jakiegoś elementu oprogramowania. Poza taki obszar na zasadzie, okej, to jest jakby związane z zapewnieniem jakiejś jakości w danym wąskim obszarze, natomiast możemy pochylić się w wielu innych aspektach, jak na przykład bezpieczeństwo, czyli coś, co jest wam dobrze znane. Możemy pójść w kierunku na przykład modnej obecnie dostępności. Mówię modnej, ponieważ wymogi prawne tutaj do 2025 roku połowy narzucają mocno, ale o tym na pewno będziemy mogli jeszcze troszkę porozmawiać dalej. Mamy jeszcze aspekty związane ogólnie z samą funkcjonalnością aplikacji, czyli mamy elementy jakby niefunkcjonalne, czyli które nie będą dokładnie opisane, że coś ma działać w punkcie A lub Z, ale na przykład mamy w tym wszystkim zawartą wydajność, czyli możemy testować wydajność. Więc tych aspektów jako QA Możemy uczepić się jednej gałęzi w pewnym momencie i zostać w niej ekspertem. Możemy też starać się złapać, że tak powiem, wszystkie srogi za ogon, o ile się tak mówi. Ale generalnie tak, próbujemy złapać większy obszar. No i mówię, jedni się potrafią specjalizować w czymś, po prostu chcą się w czymś specjalizować. Inni przeskakują jakby po różnych gałęziach, więc QA jako taki jest naprawdę bardzo szerokim pojęciem.

Andrzej: To jeszcze mam. follow up question. Jeszcze po dłubie, jeszcze nie dam Ci odejść. To w takim wypadku powiedz mi jak swojego doświadczenia z obserwacji rynku, czy to swoich koleżanek, kolegów, czy trochę szerzej jak po prostu obserwujesz to co się dzieje na rynku? Jak oceniasz faktyczną ilość przechodzenia ludzi tą ścieżką? Czyli tutaj pytam dokładnie o to, że jeśli ktoś na przykład zostaje testerem, to jeśli mamy, nie wiem, 10 czy 100 takich osób, to ile z nich? z Twojego doświadczenia, tu nie chodzi mi o twarde liczby, ale z Twojego wyczucia idzie dalej i to znowu jakąkolwiek odnogę, ale już idzie dalej, idzie w tym kierunku szerzenia, oferowania trochę szerszego wachlarzu umiejętności, usług, po prostu skillsetu.

Piotr: Jasne, no to tutaj, że tak powiem, Instytut Danych No żeby nie mówić brzydko, ale tak, z mojego doświadczenia, jasne, jeżeli chodzi o tutaj moje podejście i to jak widzę jak zespoły gdzieś tam działają, mógłbym powiedzieć, że co piąta osoba gdzieś tam powiedzmy wykracza poza testowanie, ponieważ no jakby chce dziabnąć czegoś więcej, nie chce być tylko taką osobą, która powiedzmy przeklikuje, nawet sama automatyzacja testów to też jest swoim jakby odnogą jakby quality assurance. W automatyzacji testów są ludzie, którzy po prostu chcą wyjść dalej. Nie dostaniemy na przykład scenariusza testowego, który zautomatyzujemy i tylko będzie scenariusz testowy, automatyzacja, scenariusz, automatyzacja. Tylko chcemy wyjść dalej. W zasadzie, co możemy zrobić, żeby to usprawnić? Ścieżki jakieś krytyczne może pokryjmy. Może jakby zadbajmy o to, żeby obniżyć koszty dla klienta w sposób, w jaki to zautomatyzujemy. Jakie w ogóle są wymagania od strony klienta, jeżeli chodzi o dochodowość, nie? Jakby w tym wszystkim. Co jakby być w tym biznesie, ale od takiej strony nie, że na zasadzie to są moje obowiązki, ja będę je wykonywał, bo ktoś mi każe, tylko być świadomym i się zastanowić, że okej, skoro już tu jestem, zróbmy coś pożytecznego, nie? To tak bym w tym kierunku uderzał. Dlatego mówię, że takich osób na mojej ścieżce, zazwyczaj jak dołączam zespołów, to widzę kilka osób, które przejawiają tę tendencję, natomiast Duża część osób po prostu wykonuje powierzone swoje obowiązki, co też nie jest oczywiście złe w tym wszystkim. To nie jest tak, że tutaj negatywnie uderzam, tylko właśnie osoby, które gdzieś tam aspirują dalej, zazwyczaj kończą po prostu jako QA. No i później jak już zaczną się specjalizować w czymś, no to mogą np. pójść w stronę bezpieczeństwa i być bezpiecznikiem, nie? Możliwości jest wiele, nie, w tym wszystkim. Też znam przypadki osób, które zaczynały od testera, przeszły przez QA, albo np. z testera od razu przeskoczyli na dewelopera. Także to jest też kwestia podejścia, jak wchodzą ludzie do IT. I też trzeba szukać tych sposobów, szczególnie dzisiaj, nie.

Andrzej: Tak, szczególnie dzisiaj. Łatwo i szczerze.

Krzysztof: Właśnie, a mówiąc o tym, że łatwo nie jest, to Piotr, twoim zdaniem jak obecnie wygląda rynek dla testerów, dla inżynierów jakości? Ile tej pracy jest i co potencjalni kandydaci mogą robić, jak inwestować swoją karierę, jak właśnie tester czy inżynier do spraw jakości oprogramowania, aby być konkurencyjnym na rynku? No bo rynek jest w tym momencie dziki, jest mocno nasycony i konkurencja jest naprawdę duża i trzeba pokazać sobą, przynajmniej w moim mniemaniu, coś więcej niż tylko wykonywanie dobrze swoich obowiązków.

Piotr: Jasne, no to tutaj z mojej strony, bo też śledzę jakby rynek, nie ze względu, żebym szukał jakby innej pracy, ale też przede wszystkim warto wiedzieć, w którym miejscu jest jakby się na rynku. Też oczywiście zachęcam dla sportu powodzenia na rozmowy rekrutacyjne, chociaż obecnie będzie to zapewne trudniejsze. Natomiast jeżeli chodzi o wejście na rynek przez samego testera, jeżeli chodzi o samą jakość, jeżeli mówilibyśmy o takich testach manualnych, Bez doświadczenia jako junior, szczerze, mógłbym wysłownąć tezę, że jeżeli nie mieszkasz w centralizowanych takich miastach typu Warszawa, Gdańsk, Katowice, Kraków, no jakby duże ośrodki. jeżeli chodzi o Big Techy, no to może być bardzo ciężko, bo przede wszystkim na pewno hybryda mocno i praca stacjonarna mocno, więc załapanie zdalnej pracy jako pierwszej. No jeżeli udało Ci się, to naprawdę jesteś jednym z nielicznych, nie? Tutaj jest jakby ten pierwszy temat, czyli relokalizacja do większych miast. to na pewno pierwszy benefit. Natomiast jeżeli chodzi o sam skillset, no to tutaj mocno bym szedł w kierunku automatyzacji testów, jako takich ogólnie. Wszelkiego rodzaju automatyzacja jest po prostu must have według mnie w dzisiejszych czasach, żeby po prostu nie tyle co wejść, ale wyprzedzić konkurencję, móc pokazać coś więcej w CV. Problemem jest też to, że dużo firm niekoniecznie będzie korzystać z tej automatyzacji, ale to jest osobny wątek. Że tak powiem, lepiej być full stack testerem, czyli manual i automat, tak bym to ujął, niż być tylko po prostu testerem manualnym, bo będzie ciężej. Natomiast jeżeli ktoś chce mimo wszystko być testerem manualnym, no to nic jakby nie stoi na przeszkodzie, żeby wejść automatyzacją i później odchodzić w tą nogę, że tak powiem, testów manualnych, nie? Natomiast jeszcze tylko, Andrzej, jedna rzecz. Drugi element, który dochodzi, no to bezpieczeństwo. I tutaj wiele ofert zauważam, że się pojawia na pentesterów, generalnie związanych z bezpieczeństwem. Znajomość dodatkowych elementów bezpieczeństwa jest też nice to have’em, jakby zaczęło się po prostu pojawiać. Także to jest na pewno jakiś taki tick, który możemy zastosować w tym, żeby wysunąć się przed konkurencję.

Andrzej: Ja mam tutaj od razu pytanie, bo użyłeś takiego keyworda, który ja powiem szczerze, że usłyszałem jakoś niedawno, niedawno, bo tam kilka miesięcy temu, może koło sześciu. Fullstack tester. I powiedz mi, czy ja dobrze rozumiem, że fullstack tester to jest osoba, która testuje, tak jak ty wspomniałeś, ma te umiejętności testowania manualnego, ma te umiejętności testowania automatycznego. ale też idzie w kierunku rozszerzania umiejętności, a jakieś dodatkowe nazwijmy to specjalizacje. Czyli przykładowo to może być bezpieczeństwo, ale też może być na przykład dostępność, accessibility. Czyli dobrze rozumiem ten koncept.

Piotr: Tak, znaczy generalnie z założenia wychodzimy z połączenia testów manualnych i automatycznych, dlatego mówię full stack, bo posiadamy te możliwości. Nie musimy używać tych skillów automatycznych, ale mimo wszystko skoro je mamy, no to pracodawca najprawdopodobniej chętniej weźmie nas niż osobę, która nie ma tego, że tak powiem, w ofercie. No bo siłą rzeczy, lepiej mieć dodatkowy zestaw narzędzi w swoim zespole. I dodatkowo poszerzamy o kolejne umiejętności. Czyli właśnie możemy np. testy automatyczne wspomóc o bezpieczeństwo, testy automatyczne możemy wspomóc o dostępność. Jakby to wszystko się fajnie nam zaczyna zazębiać. No i też dodatkowy element w testach automatycznych jako takich. Mamy plus taki, że możemy tą swoją wiedzę w jakiś sposób zaprezentować. Pokazać, że poruszamy się po jakichś sektorach. Czyli moje testy w jakimś obszarze sprawdzają bezpieczeństwo. Jakieś tam podstawowe powiedzmy walidacje, w danych polach się nie pojawiały jakieś dziwne symptomy, krzaki i tak dalej. Nie możemy poszerzać się w obszarze dostępności, czyli czy teksty, które pokazujemy na stronie są na przykład łatwo odczytywane przez syntezatory mowy i tak dalej i tak dalej. Możemy to wszystko poszerzać, ale mówię full stack. według mnie to po prostu manual plus automat i dodatkowe umiejętności.

Andrzej: Okej, okej. Kupuję, kupuję to wytłumaczenie.

Krzysztof: To co mówisz Piotr jest niezwykle istotne, bo ja też widzę takie przesunięcie w stronę tego, że jednak kontrahenci firmy chcą agregować coraz więcej umiejętności w obrębie jednej osoby i nawet przerzucenie na testerów części obowiązków związanych czy to właśnie wydajnością takim bardzo podstawowym powiedzmy zakresie, czy właśnie bezpieczeństwem, czy dostępnością jest mile widziane, w sensie wychodzi to ze strony klientów jako takie mile widziane oczekiwanie względem osób, które będą to robić. A powiedz mi, jak w Twoim mniemaniu zmienił się krajobraz tego, co robicie w testerce po wybuchu tego boomu na duże modele językowe i generatywną sztuczną inteligencję?

Piotr: Jeżeli chodzi o sztuczną inteligencję, szczerze powiedziawszy, patrząc na to, z jakimi elementami się mierzymy najbardziej, w sensie my jako my, będę mówił tak jakby przez społeczność QA, bo jeżeli chodzi o mój personalny projekt, nie sądzę, żeby akurat modele AI jakkolwiek mocno naruszyły, że tak powiem, sferę bankowości ze względu na spore ilości regulacyjne związane z prywatnością danych i tak dalej i tak dalej. Natomiast jeżeli chodzi o QA jako takie, Szczerze powiedziawszy takie personalne doświadczenie to zaobserwowanie bardzo dużej ilości incydentów, które się pojawiają ogólnie na świecie w różnych projektach, związanych z bezpieczeństwem głównie. Mam wrażenie, że przez to, że jak bardzo szybko chcemy tworzyć oprogramowanie, gdzieś te aspekty związane z jakością i z bezpieczeństwem, zeszły na margines. I tutaj powiem zdanie, które ostatnio zasłyszałem, związane z bezpieczeństwem, ale też nie przekalkuluję na jakość, że bezpieczeństwo jest sexy w momencie, w którym coś się zadzieje. Tak samo jest z jakością. Ona jest sexy w momencie, w którym coś się wywróci. Czyli wtedy patrzymy nagle, że ola Boga, kurczę, jak to się stało, nie? Jakby im większy fuck up, nie? Tym większe jest spojrzenie osób z góry, menadżmentu, inwestorów i tak dalej, że nie możemy tylko pchać, budując, nie wiem, dom z cegieł bez sprawdzenia, kto to robi, jak to robi, czy to ma atesty jakiekolwiek i tak dalej. Taka, takie porównanie, nie? Więc tutaj odbijam to, że jeżeli chodzi o modele językowe, no to bezpieczeństwo wydaje mi się, że jest takim elementem, który od razu widać na pierwszy rzut oka, nie? Jakby gdzieś to wszystko jest bardzo na marginesie, nie? Z mojej strony. I to nie wiem, czy to też jest związane z moją bańką medialną, że zacząłem śledzić więcej związanych tematów z bezpieczeństwem, z jakby z elementami, które gdzieś tam, incydentami, które pojawiają się na świecie, bo też jest mniej takich elementów związanych z jakością, no bo kogo obchodzi, że nie wiem, klient nie mógł przejść danego elementu, bo przycisk się nie pojawił, nie? Gdzie to byśmy zakwalifikowali stricte jako jakoś tak, no bo jakby hookerscy.

Andrzej: I ja bym tutaj poszedł o krok dalej i powiedział, że oczywiście to bezpieczeństwo też możemy traktować właśnie jako część jakości. I ja doskonale zdaję sobie sprawę, że ty to wiesz. Krzysiek też to wie. Natomiast bardzo spodobało mi się to zdanie, które właśnie powiedziałeś, że bezpieczeństwo czy jakość jest sexy w momencie, kiedy mamy jakiś problem. I ten problem jest widoczny, możemy jasno wskazać, że jest to problem, a wtedy, kiedy po prostu wszystko działa, to nikt nie będzie o tym myślał.

Piotr: Dokładnie. A dlaczego mam za to zapłacić skoro działa?

Andrzej: Dokładnie tak. I tutaj jest ten problem, że bezpieczeństwo, ale ogólna jakość to są właściwości systemu, które się objawiają. Z angielskiego jest to emergent property. To nie jest coś, co możesz po prostu dodać do systemu czy aplikacji. To jest coś, co otrzymujesz w momencie, kiedy dbasz o ogólną jakość projektu, czyli odpowiednio odrażasz architekturę, dbasz o proces projektu, dbasz o implementację. To jest coś, co dostajesz jako bonus, a nie coś, co możesz po prostu sobie potem dokoktować. I ja odnośnie tego dodam ostatnią myśl. Bardzo mi się podoba, jak o tym wszystkim mówisz, tak jak wcześniej wspomniałeś o tym, że trzeba się przenieść do jakiegoś większego ośrodka bytowego, jeśli chcemy znaleźć pracę, albo teraz, jak mówisz o tej właściwości i bezpieczeństwa, czy jakości, że nie da się tego dodać, czemu mam za to zapłacić, skoro tego nie widzę. Bo ja widziałem, że ty masz background edukacyjny w ekonomii.

Piotr: Tak, akurat moja ścieżka jest dosyć nietypowa jeżeli chodzi o ogólnie samo wejście w IT, bo u mnie to była ekonomia, całe życie. mówiłem będę księgowym, głównym księgowym autorem. Jak mantra, nie? Jakby tutaj byłem przekonany, nie? Czwarty, piąty rok studiów, widzę znajomi idą w IT, programiści. No i tutaj przyznam szczerze, jeden czynnik główny to były zarobki, nie? Jakby znajomi szli po podwyżkę i mówię, nie ma bata, żeby to się udało. I się udawało, nie? Jakby tutaj te elementy, mówię, okej, czyli tutaj jest duże pole na rozwój. No i idziemy, idziemy w kierunku. będę programistą. Nie udało się, zostałem testerem. No i wsiąkłem na tyle, że cała ścieżka już poszła dalej. Z automatu się tym wszystkim zainteresowałem, bo jednak inżynieria wytwarzania i oprogramowania całej SDLC jest po prostu dużym kombajnem, którego się nie widzi korzystając z aplikacji na co dzień.

Andrzej: Tak, a jest mega, mega interesujące i podoba mi się to Twoje trzeźwe spojrzenie, ale też widzę, że jesteś po prostu dość otwarty, mówiąc o tym, że no tak, poszedłem do IT, bo tam były pieniądze. Ja zauważam często, gęsto, że ludzie gdzieś tam się trochę kryją z tym argumentem. Najpierw próbują wysuwać ten argument pasji, czy mi się to podoba, zamiast po prostu jasno powiedzieć, jeśli tak jest, że idę tam, bo tam są pieniądze, ja chcę po prostu dobrze zarabiać. to nie oznacza, że to jest najważniejsze w moim życiu, ale po prostu oznacza, że wybieram tą ścieżkę kariery, bo według mnie ma ona sens, no właśnie ekonomiczny, ekonomiczny sens. Podoba mi się, podoba mi się, że o tym otwarcie mówisz.

Piotr: Znaczy no wydaje mi się, że to jest też taka kwestia, jakby też nie mówimy otwarcie o zarobkach, widełki swoją drogą też z ofert pracowych znikają powoli, więc tutaj akurat smutek duży, ale no być może trend się kiedyś odwróci. Natomiast jeżeli wchodzi na, wchodzenie na rynek, no też trzeba rozróżnić, że Niektórzy gonią za pieniędzmi, ale później brakuje tej dodatkowej werwy na to, że no jakby wypalają się w zawodzie. Mimo wszystko udało im się poświęcić duży zasób czasu, nauczyć się pokazać sobie, dałem radę, ale później jednak mimo wszystko, no to nie jest to, nie? Więc to też trzeba tak odbijać, że no pieniądze wiadomo, tak jak mówisz, to nie wszystko. Ale no też daje nam taki motor, że mam pieniądze na rozwój, mogę się kształcić, mogę kupować kursy, mogę jakby inwestować w swój samorozwój, jeżeli nawet pracodawca nie chce inwestować we mnie. To mam te pieniądze, żeby po boku to zrobić, że tak powiem.

Andrzej: A tutaj jeszcze na marginesie dodam, że, bo wspomniałeś, że miałaś nietypową ścieżkę. Mamy taką, w cyberbezpieczeństwie mamy taką dziewczynę, kobietę ze Stanów Zjednoczonych, która jest mega ogarnięta, mega ogarnięta i ona też ma background czysto ekonomiczny. Skończyła ekonomię, potem pracowała w dużych bankach. A końcą końców wylądowała Cyber Security. i mówię oczywiście o nikim innym niż o Kelly Shortridge, która ma bardzo ciekawe pomysły, fajnie prowadzi taki thought leadership i ma bardzo trzeźwe spojrzenie na cyberbezpieczeństwo, a ta trzeźwość spojrzenia bierze się, ja już po czasie z pewnego doświadczenia mogę powiedzieć, że bierze się z backgroundu ekonomicznego. Mówię tutaj o doświadczeniu, bo w pewnym momencie parę lat temu sam zacząłem nadrabiać swoją wiedzę ekonomiczną i wtedy wiele rzeczy mi się gdzieś tam zaczęło, po prostu dostrzegam to. I tak, wiedza ekonomiczna jest mega, mega przydatna. Jak działają te wszystkie mechanizmy? Mega przydatna.

Piotr: To jest na pewno, projektowo też wydaje mi się, że zmienia troszkę perspektywę na to, jak patrzymy na dane, że tak powiem, błędy, podatności, które są kluczowe z punktu biznesowego, gdzie byśmy widzieli, jakbyśmy byli właścicielem tego biznesu, to gdzie byśmy chcieli zainwestować swoje pieniądze, nie? Gdzie widzimy tą taką proporcję cena, jakość, żeby to było najwyżej, jakby słupek, wskaźnik, żeby był po prostu jak najbardziej efektywny. Więc no wydaje mi się, że taka ogólnie pojęcie na zasadzie, że dlaczego robię to, co robię plus jeszcze te z tyłu głowy biznes, no na pewno pomaga.

Krzysztof: Tak, no ten field biznesowy jest niezwykle istotny, szczególnie w bezpieczeństwie, które tak jak tutaj wspomnieliśmy wcześniej jest nad nogą jakości. Myślę, że bez tego w bezpieczeństwie no kariera raczej w pewnym momencie po prostu zaczyna umierać, bo nikt Nikt Cię nie chce słuchać, jeżeli chcesz grać z największymi to musisz rozmawiać tak jak oni, a żeby rozmawiać tak jak oni to jednak nie obędzie się bez tej biznesowej komponenty. A odbijając w inną stronę, przechodząc troszeczkę dalej, jeżeli mówimy o procesie wytwórczym Piotrze, Jakie jest Twoje podejście do takich paradygmatów jak shift left versus takie klasyczne bramki bezpieczeństwa gdzieś na końcu deployu?

Piotr: Znaczy generalnie tak, ja ostatnio się spotkałem w marcu na konferencji z Shift Right, które mnie też mocno użegło, ale o tym może za chwilę. Natomiast jeżeli chodzi o Shift Left, mówi się o tym, że im bardziej przesuwamy proces w lewo, im szybciej reagujemy, tym mniejsze jakby poniesiemy nakłady, w sensie związane z późniejszym wydawaniem wersji. Tutaj możemy się z tym… przynajmniej ja mogę się z tym częściowo zgodzić, natomiast nie we wszystkich aspektach. W sensie są takie tematy np. stricte biznesowe, w których biznes między sobą według mnie powinien uzgodnić czego tak naprawdę oczekuje, natomiast później jeżeli już mamy wybraną ścieżkę, którą chcemy podążać, no to jak najbardziej im wcześniej zostaniemy włączeni w tym procesie, tym że tak powiem mniej dziur na drodze napotkamy, mniejsze szanse na to, że się gdzieś po drodze wywrócimy i zrobimy sobie kuku. Natomiast jeżeli chodzi o takie bramki bezpieczeństwa, na samym końcu no to tutaj jest taki case, który często jest tak sprowadzany, czyli wytwarzamy jakieś oprogramowanie, robimy coś i na samym końcu pojawia się, no słuchajcie, to to trzeba jeszcze sprawdzić. Ok, nie? Jakby super, a ile mamy na to czasu? No za dwa dni wydajemy, nie? No i to jakby to jest jak mantra, ja w wielu projektach to widziałem, w wielu projektach to jakby się z tym spotkałem i to możemy oczywiście na to narzekać, dlatego wchodzi QA w tym wszystkim i po prostu chcemy edukować od samego początku, tylko no to trzeba edukować każdą jednostkę w firmie, żebyśmy wszyscy byli na tej samej stronie, że tak powiem, papieru, kartki. Tak, żebyśmy widzieli to samo tymi samymi oczami, gdzie są jakby problemy. Więc jeżeli uświadomimy wysoko biznes, gdzie chcemy się w tym procesie znaleźć, tym szybciej będziemy w stanie w tym procesie znajdować jakieś, powiedzmy, elementy. No i też musimy zdobyć tą wiedzę domenową. To jest coś, co się często pomija w całym doświadczeniu. Wiedza domenowa, która przychodzi po prostu z czasem. Nawet jeżeli przejdziemy pomiędzy, nie wiem, branżą medyczną a medyczną. Nadal musimy poznać produkt, zobaczyć jakie są zależności, kto w ogóle, jak zarządza, kto jest od czego. Masa rzeczy. Kończąc natomiast, jeżeli chodzi o te bramki bezpieczeństwa, no to w naszym przypadku, w naszych projektach, w sensie nieobecnej firmie, ale ogólnie jeżeli chodzi o QAW procesy, też jesteśmy po prostu gdzieś tam na samym końcu. No i to jest z jednej strony krzywdzące, ale tak jak mówię, musimy być świadomi, dlaczego tak się dzieje, podbijać piłkę na sam początek, nie? Jeżeli my tego nie zrobimy, zawsze będziemy na końcu.

Andrzej: I tutaj od razu wtrącę, że to o czym wszystkim mówisz trzeba robić już właśnie z tym o czym wspomnieliśmy z perspektywy biznesowej. Rozmawiając z biznesem musimy mówić jego językiem i jak on na tym skorzysta, a nie tylko dlatego, że chcemy zadbać o czy to bezpieczeństwo czy jakość. Wtedy nikt nie będzie tego słuchał. Liczy się końcem końców zysk i koszt.

Piotr: Tak, pokaż mi jak na tym zyskam, że będę robił to, co ty sugerujesz mi zrobić jako specjalista, tak? No bo po to ciebie zatrudniam, żebyś mi mówił. Jeżeli mnie nie słuchasz, znaczy w sensie mnie jako specjalisty, no to tutaj już zaczynamy mieć problem, tak? No to już jest coś, co będzie ciężko przeskoczyć. Natomiast jeżeli będziemy jakąś część tych uwag faktycznie akceptować, żeby zobaczyć, jakie będą wyniki, no to super, nie? Wtedy możemy spotkać się przy piwie i porozmawiać, że faktycznie miałem rację albo nie miałem racji, nie? Jakby… o to się tak naprawdę rozchodzi, żeby pokazać tę wartość.

Krzysztof: Zaciekawiło mnie to, co powiedziałaś na początku twojej odpowiedzi na moje pytanie, że spotkałeś się na konferencji na początku tego roku z konceptem Shift Right. Ja nigdy o tym nie słyszałem. Słyszałem o Shift Everywhere, ale o Shift Right jeszcze nie słyszałem. Jakbyś mógł rozwinąć.

Piotr: jasne shift right. Wydaje mi się, że bardzo łatwo sprzedać się dla biznesu, bo to są nic innego jak testy na produkcji. Natomiast już wam tłumaczę. Oczywiście to możecie bardzo ładnie wyciąć, że rekomenduję testy na prodzie, ale nie do końca. Chodzi o to, że spotkałem się z podejściem, w którym mamy przygotowane tak swoje środowiska produkcyjne, abyśmy mogli w jakiś sposób tą produkcję testować. Dla przykładu możemy sobie zrobić AB testing, gdzie 95% ruchu puszczamy na jedną maszynę, na jeden serwer, na jedną jakby aplikację, 5% puszczamy na nowe feature. I tak naprawdę to jest jakby z jednej strony z marketingowego punktu widzenia często stosowane, gdzie chcemy po prostu sprawdzić, że tak powiem eksperyment się powiedzie, która wersja lepiej funkcjonuje. Natomiast w tym przypadku po prostu możemy sprawdzić, czy okej 5% użytkowników puściliśmy, nie ma żadnych błędów, nic się ciekawego w logach nie pojawia i tak dalej. Czyli wykorzystujemy już środowiska, które mamy. Co ciekawe, przez to, że to jest produkcja, środowiska są praktycznie tożsame, bardzo zbliżone. Często problemem jest to, że na środowiskach nieprodukcyjnych one odstają wydajnością, odstają konfiguracją, odstają wieloma jego czynnikami zewnętrznymi. Oczywiście, nie w każdym projekcie taki shift rate możemy wdrożyć od tak, natomiast jeżeli mamy projekt, który dopiero startuje, warto o tym pomyśleć na samym początku, bo być może będzie to fajna specyfika pracy, która pozwoli nam oszczędzić koszty na innych środowiskach, i część testów będziemy mogli odciążyć, nie? W sensie, że damy sobie to dla klientów do testowania, ale tylko próbki, więc nie narażamy się na globalny taki fakat.

Krzysztof: Tak, to jest bardzo ciekawe, co mówisz, bo ja w wielu projektach, czy to w których, no może nie pracowałem, bo pracuję akurat 6 lat dla jednego klienta, ale w których konsultowałem, to bardzo ciężko było utrzymać taki stan, w którym to środowiska stagingowe, były naprawdę wierną kopią produkcji. To zawsze był jakiś przeszczep, to zawsze była taka amputowana kończyna, której nikt nie chciał utrzymywać, w której brakowało kilku rzeczy, które były na produkcji i potem faktycznie okazywało się, że wychodziła masa problemów na środowiskach produkcyjnych, których nie dało się, bo nie było możliwości wyłapać na środowiskach czy to developerskich, czy stagingowych, więc ja rozumiem to shift right jako test po prostu przeprowadzane przez jakiś niewielki wycinek naszych klientów, tak, bo im się akurat ta aplikacja załadowała w tym teście.

Piotr: Jasne, dokładnie. Możemy to też oczywiście dopuścić naszych ludzi, którzy będą mogli sprawdzać, to jest w zależności od tego jaka to jest aplikacja, tak? Nie wszędzie powinniśmy mieć dostęp, że tak powiem, do środowiska produkcyjnego, nie wszędzie powinniśmy wpuszczać nasze dane testowe, więc staramy się oczywiście to ograniczyć. Natomiast jest taka możliwość, w której właśnie puszczamy część naszych klientów, tak żeby po prostu nie zrobić im krzywdy i też sobie jakby wizerunkowej, nie? Więc, więc tak, jest to nic innego jakby jak testowanie przez klientów. Ale no tak jak mówię, shift right, czyli wyrzucamy to praktycznie jak najdalej, najbardziej w prawo. analogii oczywiście języka polskiego. Tak, że po prostu są te testy po prostu związane z klientami, nie? Ale też oczywiście możemy wybierać na przykład taką pulę klientów, którzy ugodzą się na testy. Możemy mieć tak zdefiniowaną aplikację, że hej, weź udział w becie, no po prostu na tej zasadzie. I wtedy oni są dozwoleni na te testy i godzą się z tym, że będą, dostaną jakieś benefity powiedzmy za to, ale godzą się z tym, że to co widzą nie do końca jest jeszcze dopracowane, nie?

Andrzej: Ma to sens, ma to sens, tym bardziej, że wspomniałeś o aspekcie jakości, ja znowu odbiję pijeczkę w kierunku bezpieczeństwa, to jest bardzo częsty problem, gdzie system wygląda po prostu trochę inaczej na produkcji niż na środowisku testowym i to nawet z takiego prostego powodu, że większość systemów w dużych organizacjach produkcyjnie jest za web application firewallem. Więc testując je wcześniej, no niejako testujemy je bez, bez obrony WAF-a, a na produkcji są już bronione WAF-em. Więc multum problemów, które można byłoby mitylować na poziomie WAF-a, będzie nam wychodziło i teraz nie ma problemu, tutaj nie chcę mówić, żeby, żeby pomijać wyprowadzanie tych problemów, oczywiście, oczywiście nie. inaczej chodzi o to, że trzeba sobie zdawać sprawę, że być może będziemy wyprowadzać problemy, które taniej byłoby po prostu mitygować wafem, za którego i tak płacimy, bo to też nie jest coś, co dostajemy za darmo. Więc takie testowanie na produkcji w tym aspekcie również może mieć sens. biznesowy, ale oczywiście to znowu wracamy do tego, co powiedziałeś wcześniej, dopiero w momencie, gdy wszyscy w procesie jesteśmy na tej samej stronie, na tej samej kartce z angielskiego.

Piotr: Dokładnie, dokładnie tak.

Krzysztof: No tak, no i też w przypadku takich testów myślę, że trzeba mieć jednak dobrze zbudowaną obserwowalność i monitoring, który pozwoli nam wychwytywać te problemy, bo same testowanie dla testowania i bez tej pętli zwrotnej, feedbacku o potencjalnych problemach to w zasadzie nie będzie miało znaczenia dla nas.

Piotr: Dlatego jeszcze tutaj Krzysztof, to co właśnie wspomniałeś, to też jest duża, bardzo duża część Shift Write, żeby ten monitoring mieć w taki sposób zorganizowany, żeby uzyskać jak największą ilość informacji, bo jeżeli klient dla przykładu przechodzi, nie wiem, jakąkolwiek aplikację i w pewnym momencie jest drop-off, no to dlaczego, nie? Znudziła mu się aplikacja, pojawił się błąd, coś zablokowało taką możliwość, więc tych elementów jest masa. Tak czy w międzyczasie, nie wiem, serwer się wykrzaczył, nie mogliśmy się dostać do aplikacji. Jest tego jakby multum, dlatego jeżeli jakby chcemy się zainteresować Shifter Item, no to na pewno monitoring będzie nam towarzyszył przez cały proces. Także tutaj dzięki za reminder.

Krzysztof: A właśnie mówiąc o jakichś drop offach, pewnie masz multum doświadczenia z testowaniem różnych formularzy rejestracji, to mam do Ciebie takie pytanie, możesz odpowiedzieć pół żartem, możesz odpowiedzieć serio. Najgłupsze wymagania bezpieczeństwa jakie widziałeś w formularzach rejestracji czy logowania, jak zwał tak zwał?

Piotr: Ja największym jestem niefanym, że tak powiem, polityki haseł jakichkolwiek. W sensie z jednej strony rozumiem, że użytkownicy są przeróżni, rozumiem, że trzeba ich chronić, natomiast nie rozumiem, dlaczego nie mogę używać hasła, które mam zdefiniowane. W sensie jeżeli polityka mi go zabrania, no to tak jakby troszkę się z tym nie zgadzam, bo to hasło jest dla mnie czy dla was, nie? Jakby w tym wszystkim. I dlatego odbijam od razu do wymagań, bo tutaj nawiązuję do posta, którego bodajże Andrzej gdzieś tam na LinkedIn’ie zalajkował, odnośnie Paypala i ilości znaków hasla, gdzie no zostało to skrytykowane. Dlaczego 8 do 20? No na zapewne jakby stoi za tym jakaś logika w tym wszystkim i ja jakby ją podzielam i się z niej cieszę. Natomiast jeżeli moje hasło ma 21 znaków, No to co mam zrobić w tej sytuacji? To też jest pytanie, w jaki sposób podchodzimy np. do haseł, do formularzy rejestracyjnych. W jaki sposób np. chcemy określać, jakie maile są dozwolone. Czy dozwalamy np. na maile, że tak powiem one-time, które są temporary, czy też np. nie chcemy dozwalać. To też są takie wymagania, które ktoś np. mieliśmy takie wymaganie dotyczące bodajże bezpieczeństwa, gdzie listowaliśmy całą listę maili, które nie są dozwolone, jakby w sensie tych właśnie one time, nie? No ale jakby definicja była po prostu zhardkodowana, czyli jakich końcówek, że tak powiem, nie dozwalamy. Więc bardzo łatwo jest to obejść. Więc pytanie, jaki jest sens to w ogóle wprowadzać, skoro i tak coś bez większego trudu jest w stanie to, że tak powiem, okroić, nie? Więc są takie, jeżeli chodzi o formularze, to na pewno polityka haseł. No i tutaj jeszcze bym dołożył właśnie te maile, które można w ten sposób jakby ochronić, ale czy to ma sens? Bardziej bym szukał filtra andrys.com’owego. Bardziej, że tak powiem, złożonego niż walidowanie po końcówce np. maila i temporary maili.

Krzysztof: No tak, ten post dotyczący PayPal’a faktycznie trochę mnie rozbawił. Komentarze mnie tego rozbawiły. Był ciekawy, ale wyszło wiele kontekstu z tego, jak ludzie patrzą w ogóle na tego typu problemy, jaką profesjonaliści w IT mają świadomość na temat tego, dlaczego w ogóle tak może się dziać, Bo z mojej perspektywy to nie jest tak, że tam siedzi jakiś, ze przeproszeniem, tłuk w Paypalu i stwierdził nie no dobra to zróbmy od 8 do 20. Raczej tak nie było.

Andrzej: Tak, to jest dokładnie to, do czego ja piłem, repostując tego posta, gdzie po prostu jest. trochę mam taki śmiech przez łzy w momencie, gdy zakładamy, Bo właśnie nie zakładamy, że druga strona miała jakieś powody ku czemuś. Bo jakieś powody musiała mieć. To nie jest tak, że jakaś decyzja została podjęta od tak. Szczególnie jeśli mówimy o czy to firmach, czy ludziach, którzy raczej raczej są ogarnięci. Czy tutaj był konkretnie PayPal, czy czasami widać pewną krytykę dużych postaci, no niech będzie w techu na przykład Ilona Maska, gdzie nie chodzi o to czy ja się z nim zgadzam czy nie. Jeśli ktoś, kto jest na pewno dużo dalej, czy pod kątem biznesowym, bo prowadzi wielomilionowy biznes w korporacji, która jest dostępna na całym świecie, czy osoba, która jest dużo dalej w życiu, osiągnęła dużo więcej, to dobrze byłoby się dwa razy zastanowić, czemu faktycznie coś mówi albo czemu podejmuje jakąś decyzję, bo jest duże prawdopodobieństwo, że po prostu czegoś my nie bierzemy pod uwagę, a możemy sobie zdać sprawę, jeśli po prostu się nad tym zastanowimy. Raczej, znowu wracamy do ekonomii, ludzie wiemy, że podejmują racjonalne decyzje, raczej pojedyncze jednostki nie podejmują nieracjonalnych decyzji. Każdy ma swój jakiś ciąg myślowy, czemu coś zrobił, I często dobrze jest się zastanowić, dlaczego ktoś tak zrobił, bo dzięki temu jesteśmy w stanie wykonać, zegzaminować ten wybór i też poprawić swój proces decyzyjny i poprawić swoje gdzieś tam myślenie, swoją argumentację, więc tak naprawdę na koniec dnia to my korzystamy z tego samego myślenia, a nie ta druga strona, więc my wychodzimy tylko na plus.

Piotr: Jasne, no ale akurat w tym przypadku też łatwo coś skrytykować, jakby nie zastanawiając się nad kwintesencją tego wszystkiego, więc myślę, że to też była kwintesencja tego posta, że łatwo było określić.

Andrzej: Co jest bardzo typowe w branży cyberbezpieczeństwa. Co jest trochę smutne, bo to już o tym dzisiaj mówiliśmy. Szybkie ignorowanie i niebranie pod uwagę szerszego kontekstu gdzieś tam blokuje nas samych, naszą karierę. I dopiero wyjście dalej i pomyślenie szerzej w różnych kontekstach, na przykład w biznesie, implementując bezpieczeństwo, pomyśleć o kosztach związanych z tym, co chcemy zrobić. pozwala nam iść trochę dalej w tej naszej karierze, no bo po prostu patrzymy na problemy głębiej, więc znowu patrzmy głębiej, zastanawiajmy się, będziemy tylko na tym korzystać.

Piotr: Pełna zgoda.

Krzysztof: Dokładnie. Ja z pytań się wystrzelałem, nie wiem Andrzej czy masz jakieś pytania do Piotra?

Andrzej: Ja również się wystrzelałem, natomiast jedno gdzieś tam w zanadrzu trzymałem Piotrze. Trochę rozmawialiśmy na wejściu, jeszcze jak Krzyśka nie było, bo się spóźnił. Ale i tego nie wycinajmy. Niech nie cały świat wie, że Krzysiek się spóźnił. Zwykle się nie spóźnia, a dzisiaj się spóźnił. Więc rozmawialiśmy trochę przed przyjściem Krzyśka i mówiłem, że robisz fajną robotę w socialach. Podoba mi się to, co robisz. Nie tylko to, co robisz, ale też w jakim stylu to robisz. Bo czasami, nawet nie czasami, na LinkedIn jest sporo ludzi, którzy Mocno cisną, nawet potrafią mieć bardzo duże zasięgi, ale robią to w słabym stylu. Ja nie będę wymieniał ich imienia, nazwiska, natomiast z moim personalnym odczuciu robią to w słabym stylu. I dla mnie są niekongruentni, bo zakładam, że ci ludzie w życiu prywatnym nie są tacy, a na LinkedInie są tacy, czyli robią to ewidentnie pod zasięgi. I okej, każdy ma swoją strategię, każdy niech robi to, co chce. Natomiast to, jak Ty to robisz, mi się podoba, jest to spójne. Co więcej, jak teraz sobie porozmawialiśmy, to nawet wydaje mi się, że jest jeszcze spójniejsze, czyli wydajesz się być konkretnym gościem i Twój content też jest konkretny. Powiedz nam, gdzie możemy znaleźć coś więcej, jak możemy dotrzeć? My wiemy, ale jak nasi słuchacze, których na pewno zainteresowałeś sobą, jak mogą mieć z tobą jakiś dalszy, szerszy kontakt?

Piotr: Jasne, no to tutaj zdecydowanie od razu zachęcam do zaobserwowania profilu na Linkedinie. Także Piotr Tuński Linkedin na pewno powinienem się pojawić. W razie gdyby nie, to ptquality.pl, strona na której możecie dołączyć do newslettera, gdzie szerzej jakby informacje dotyczące jakości. Ogólnie też ogólne związane jakby z poglądem z IT, co się dzieje na rynku, jakie są moje światopoglądy. Możecie poznać takie moje personalne zdanie. które też nie jest określone jakoś tak, że tak powiem, bardzo technicznie, bardzo szczegółowo. Myślę, że tak jak Andrzej tutaj to przedstawił lekko, ja oczywiście odbijam piłkę, że bardzo miło mi było również tutaj być gościem u was, także bardzo się cieszę z zaproszeniem, bo uważam, również odbijam tą słodką piłeczkę, że robicie mega fajny content, robicie to właśnie w takiej formie, która mi się podoba, dlatego myślę, że też jesteśmy tu i teraz i razem rozmawiamy, bo gdzieś tam fale, że tak powiem, są podobne.

Andrzej: No tak, ewidentnie, nadajemy tutaj na podobnych falach. Dobra, Piotrze, to ja bardzo dziękuję, dziękuję również za odbicie piłeczki. Myślę, że obaj z Krzyśkiem dziękujemy. I co? I pewnie gdzieś tam słyszymy się kiedyś w przyszłości. Być może uda się kiedyś nagrać jakiś odcinek na żywo, na jakiejś konferencji. Byłoby super.

Piotr: Na to liczę. Mam nadzieję, że jak będziecie organizować jakieś studio, to uda się gdzieś tam was złapać.

Andrzej: Także… Jest plan. Jest plan. Trochę dalekich, ale jest. Ale jest.

Piotr: Jak coś, to wiecie, gdzie mnie znaleźć.

Krzysztof: Tak, znajdziemy ślepem gdzieś na jakiejś konferencji w najbliższej przyszłości, a ja jeszcze dodam ich życzenia, bo będziecie tego odkrywać w dniu testera, także wszystkiego dobrego dla wszystkich testerów i ludzi jakości, a jak wiemy jakość jest odpowiedzialnością wszystkich, więc wszystkiego dobrego dla wszystkich. Dzięki Piotrze, trzymajcie się, hej.

Piotr: Dzięki, trzymajcie się.

---