Podcast z Krzysztofem Witczakiem z Global App Testing zagłębia się w crowdtesting, omawiając jego potencjał w identyfikacji „edge case’ów” w oprogramowaniu dzięki globalnej społeczności 80 tys. testerów. Odcinek podkreśla również synergię między crowdtestingiem a bezpieczeństwem cybernetycznym, czerpiąc inspirację z programów Bug Bounty. Jest to istotne dla firm działających na rynku cybersecurity.
Kluczowe tematy poruszane w podcaście (poza „crowdtesting”) to:
- Rola sztucznej inteligencji (AI) w automatyzacji procesów testowania oprogramowania.
- Znaczenie compliance (zgodności z przepisami) dla globalnych przedsiębiorstw, w tym szczegółowe omówienie norm ISO 27001, SOC 2 oraz regulacji RODO (GDPR).
- Prezentacja projektu Wipeout, narzędzia służącego do anonimizacji danych, co ma kluczowe znaczenie dla prywatności i bezpieczeństwa informacji.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Krzysztof Witczak: Witam.
Krzysztof Korozej: Witam. Cześć Krzysztof.
Andrzej: W zasadzie mamy dwóch Krzysztofów. Krzysztof jeden, Krzysztof dwa.
Krzysztof Witczak: Który jest który?
Krzysztof Korozej: Ja jestem ten Jarzyna ze Szczecinem.
Andrzej: O tak, to nawet się łapię. Krzysztof, ja od razu mam takie pytanie, nazwijmy to z grubej rury, uderzę cię. Czym się zajmujesz jako Head of Engineering at Global App Testing? Już nie tylko czym ty się zajmujesz w swojej roli, ale czym w ogóle zajmuje się ta firma? Co robicie? Bo to nazwa coś z testowaniem, ale jest więcej do opowiadania niż mogłoby się wydawać.
Krzysztof Witczak: Tak. W zasadzie jako Head zajmuję się wieloma różnymi rzeczami, wszystkim i niczym. Takimi rzeczami, gdzie np. brakuje nam ludzi specyficznej roli, żeby to objąć. Ale przede wszystkim można powiedzieć w skrócie zarządzanie zespołami, dbanie o to, żeby wszystko grało. A to co jest może specyficzne w samej firmie to jest to, że zajmujemy się crowd testingiem. No i pewnie większość osób nie bardzo nawet słyszało o tym, nie wie co to jest. Nie jest to taka popularna forma testowania. A ona właśnie zakłada, że testujemy z wykorzystaniem crowdu, czyli ludzi, którzy rejestrują się na naszej stronie, chcą właśnie na przykład sobie dorobić poprzez testowanie aplikacji naszych klientów. Lubię czasami mówić, że to jest trochę jak taki Uber dla testerów, że nasza firma jest trochę jak taki właśnie łącznik, który pozwala klientom uzyskać dostęp do tego crowdu. I crowd jest dosyć liczny, 80 tysięcy ludzi z całego świata, 190 krajów. Usługi 24 na 7, więc możecie sobie wyobrazić, że właśnie też Dev Support i tak dalej, tego typu rzeczy. No i usługi QA najróżniejszej maści, ale myślę, że to gdzie dajemy taką usługę extra, poza taki standardowy QA, to jest właśnie to, że możecie coś stestować z różnych krajów, gdzie nie macie po prostu swoich ludzi, swoich placówek i wtedy wychodzą ciekawe rzeczy. albo możecie stestować coś, co nie jest proste normalnie do stestowania. Jakieś aplikacje, które wymagają właśnie przemieszczania się fizycznie, chociażby różnego rodzaju weryfikacje np. streamów na żywo, tego typu rzeczy. To jest miejsce, gdzie my właśnie wchodzimy i dajemy taką usługę rozszerzającą trochę klasyczny QA.
Andrzej: To ja mam tutaj już jedno pytanie. Czy mógłbyś trochę przybliżyć i Rzucić jakimś przykładem takich ciekawych jakichś edge case’ów, które można wyłapać właśnie korzystając z usługi crowd testowej, która w takim normalnym wydaniu Quality Assurance gdybyśmy mieli np. swój własny działk trudno byłoby coś takiego wykryć.
Krzysztof Witczak: Jedna z rzeczy takich, która też jest opisana wręcz w książce naszego Foundera jako taki ciekawy case to sytuacja z Filipin, gdzie firma testowała po prostu w formularze rejestracji logowania, klasyczna i najprostsza rzecz do testowania, w różnych miejscach na świecie i nie byli w stanie dojść do tego, dlaczego ludzie bounceują z ich formularza właśnie w rejonie Filipin, który był z jakiegoś powodu ważny. No i nie byli właśnie w stanie dojść do tego. Widzieli, że ludzie wchodzą na stronę. Są na tej stronie? No i opuszczają ją, nie wypełniają. No i właśnie skorzystali z naszych usług. Wzięliśmy kilku testerów z Filipin i oni praktycznie momentalnie, w kilka minut powiedzieli, nie mogę wziąć tego formularza, bo wymagacie nazwiska, a ja nie mam nazwiska.
Andrzej: Fajny edge case.
Krzysztof Korozej: Obywatel bez NIP-u.
Krzysztof Witczak: Tak i dlaczego nie mam nazwiska? i tam były powody historyczne dlaczego 30% populacji nie miało nazwisk. Normalnie jakby było to jakoś tam uregulowane ale no wiecie firma gdzieś z USA nie miała pojęcia o tym. To jest jakiś totalny edge case dla nich. No więc to jest pewnie taki klasyczny przykład tych takich różnic o których nie wiemy po prostu że w jakimś kraju coś wygląda tak a nie inaczej.
Andrzej: I teraz mam takie, nazwijmy to follow up question. Przykładowo mamy taki przypadek, to jak w takim, nie chodzi mi teraz o takie mocno niskopoziomowe operacyjne rzeczy, ale jak na dużych klockach wygląda taka komunikacja takiego testera, bo zakładam, że to nie jest tak, że po prostu mają dostęp do Jiry i zakładają tikety, tylko robią to, mają jakiś proces wokół tego, macie jakieś, nie wiem, apki mobilne czy webowe i to tam jest jakoś wypełniane. Chodzimy głównie o to czy taka osoba testująca działa tak jak normalny tester QA czy nie.
Krzysztof Witczak: Sytuacje są różne, no bo z racji, że te projekty są też nietypowe to bardzo często musimy podchodzić case by case do różnych sytuacji, ale takie najbardziej klasyczne podejście polega na tym, że my potrzebujemy po prostu instancji QA od klienta, dane jak się tam dostać i razem z klientem tworzymy scenariusze jak podejść do tego testu. Idealnie jeżeli klient sam ma już QA na wysokim poziomie i jest stanie nam po prostu to dostarczyć, ale czasami na przykład takie testy mogą nie być skonstruowane pod crowd. Na przykład mogą zakładać jakąś wiedzę domenową, albo były pisane dla testerów w ich firmie, który zna tą aplikację dobrze i może operować tam skrótem i tak dalej. Czasami trzeba to po prostu dopasować do crowdu, żeby to było takie bardziej właśnie trochę multitrading. No i później przechodzimy do kolejnej fazy, czyli mamy jedną aplikację, która jest wejściem dla klienta do tworzenia requestów i później pobierania wyników. W środku jest cały nasz engine, który zajmuje się dobieraniem najlepszych ludzi do tej pracy itd. Patrzymy na ich dostępność, umiejętności, predyspozycje, urządzenia, wszystkie tego typu rzeczy. No i tester potem właśnie mając te dane wchodzi na specjalny portal, który też mamy, on się nazywa Testerwork. I tam widzi po prostu, że jest zlecenie, do którego może dołączyć lub nie. No i kiedy dołącza, wykonuje te operacje, które tam są. Po prostu przekazuje rezultaty swojego testu. I to w dużej mierze wygląda jak taki klasyczny, zwykły test. Prawda? Gdzie zgłaszają błędy, robią reproduction steps. Z racji, że to jest crowd, no to też wymagamy zawsze artefaktów, które potwierdzają wykonanie tej czynności, nagrania wideo, screenshoty. Jeżeli to są jakieś bardziej skomplikowane testy, to też mogą być jakieś snapshoty z przeglądarki, jak ten networking wyglądał, tego typu rzeczy. Wszystko po prostu, żeby deweloperom było łatwiej potem debugować ten problem.
Krzysztof Korozej: i wtedy jest taki element odbijania tego, że deweloperzy w tej firmie, która zgłasza zapotrzebowanie na takie usługi właśnie crowdtestingowe otrzymują ten ticket przez Waszą platformę, poprawiają to zgłoszenie, które ten tester tam wysłał i potem robi retesty.
Krzysztof Witczak: My oferujemy również usługę pre-testowania. To też jest ciekawe, bo jak pomyślimy sobie, co może się wydarzyć, jeżeli 20 osób losowych będzie szło przez testy, to myślę, że dojdziemy szybko do wniosku, że oni mogą zgłosić te same problemy. Teraz z punktu widzenia biznesowego to można różnie obsłużyć. Czy płacimy im wszystkim, bo wykonali dobrą pracę, czy może mówimy, że jest jakiś duplikat. Różnie można do tego podejść, ale też można powiedzieć, że to potwierdza, że to jest zreprodukowany błąd. Tak, więc to też zwiększa jego wagę. Więc na przykład tak możemy to zrobić, potem pracujemy z klientem.
Andrzej: I technicznie jeśli jakaś instancja baga wyszła większej ilości osobom to jest to potwierdzenie, że statystycznie jeżeli puścimy tam produkcję to więcej użytkowników będzie też miało styczność z tym bagiem. Nazwijmy to krytyczność albo waga tego baga rośnie.
Krzysztof Witczak: Też jest ciekawy case, że prosimy też testerów o opinię, po prostu, jako człowiek. Coś, co automat nie zawsze nam dostarczy. I może się okazać, że coś było trudne dla tego testera. I nagle mamy też feedback UX-owy, co jest też ciekawe, że klient może powiedzieć, a to nie jest błąd. Ale jak 20 razy usłyszę o błędzie UX-owym to może pomyśleć hmm, może jednak założenia designu były niepoprawne, może to jest problem.
Krzysztof Korozej: Czyli ten element testów eksploracyjnych jak najbardziej. Mi to co mówisz, dla mnie to nie jest obce. Ja sam wchodząc do branży słyszałem już o crowd testingu jako świetnym sposobem w ogóle na zdobywanie doświadczeń dla młodych testerów, młodych adeptów.
Andrzej: Właśnie. Bo to dla mnie brzmi jako coś, gdzie osoba, która chciałaby wejść do branży może wykorzystać jako pewnego rodzaju drogę, którą przejść, żeby nauczyć się pewnych rzeczy i wykazać, że umiem to robić.
Krzysztof Korozej: Tak. I przy okazji Andrzej to się… Zobaczcie, Andrzej Krzysztof, że to się bardzo fajnie też łączy z bezpieczeństwem, bo my mamy coś takiego w bezpieczeństwie.
Andrzej: Ja od razu.
Krzysztof Korozej: Tylko nie nazywa się crowd hackingiem, a nazywa się bug huntingiem.
Andrzej: I bug bounties. I bug bounties, dokładnie.
Krzysztof Witczak: Nawet oferujemy bug bounty.
Andrzej: Jak zacząłeś właśnie o tym mówić, ja słyszałem wcześniej o crowdtestingu, ale tak naprawdę nie wchodziłem w temat. Keyword znałem, ale to tyle. Ale jak zacząłeś o tym mówić, to cały czas mi… To wygląda jak Bug Bounty. Czyli koncept znasz. Tak, tak.
Krzysztof Witczak: Mówiłem, że Operujemy Bug Bounty. Miałem na myśli, że my jako firma też akceptujemy zgłoszenia, że nasze systemy Ale w zasadzie to taka eksploracja troszeczkę jest takim bug bounty, kiedy testerzy po prostu patrzą co w aplikacji może działać niepoprawnie i tak dalej.
Andrzej: Tak, tym bardziej, że ja zawsze lubię to powtarzać, bezpieczeństwo jest pod zbiorem jakości, więc No jeśli dbamy o jakość, czyli szukamy bugów, no to podatności to końcem końców bug tylko taki, który ma implikacje związane z bezpieczeństwem, ale to też jest po prostu bug. I podobało mi się też to, że wspomniałeś o tym, że a co jeżeli kilku testerów znajdzie tego samego buga, bo przykładowo w Bug Bounties jest podobny problem, co jeśli kilka osób zgłosi tą samą podatność. i teraz komu zapłacić? Bug Bounties. najczęściej się to rozwiązuje tak, że płaci się temu tej pierwszej osobie, która zgłosiła, a reszcie się mówi, że to jest duplikat. Ale jest też pewnego rodzaju edge case, gdzie co? jeśli jakiś błąd albo podatność zostanie zgłoszona, zostanie oceniona jako informacyjna. Okej, to jest problem, ale nie musimy go rozwiązywać. A potem ktoś inny przyjdzie zgłosić tą samą podatność bez żadnych innych dodatkowych problemów. I jednak pokaże jakiś impakt i krytyczność pójdzie do góry. I teraz kto powinien dostać bounty? Ta pierwsza osoba, która zgłosiła, czy ta druga, która już uargumentowała swoje zgłoszenie? Co o tym myślicie? To pytanie otwarte.
Krzysztof Korozej: Albo słuchajcie, wykorzysta tą podatność, która podatność, błąd, który został oznaczony jako jako info albo jakieś tam o niskiej istotności i wykorzysta go w jakimś czejnie.
Andrzej: Tak i teraz biorąc pod uwagę, że no ale to było wcześniej zgłoszone, to teraz powinniście, gdybyście to wyprowadzili wtedy, kiedy wam to zgłosiłem, to by inna osoba nie mogła tego wykorzystać? Więc może priority byłoby niższe i albo byś nie musieli wypłacać albo mniejsze bounty byłoby wypłacone. I technicznie jeżeli naprawicie tego buga no to dlaczego go naprawiać? Wcześniej uważaliście, że nie jest problemem, nie? Co o tym sądzisz? To jest takie pytanie otwarte. Jak ty byś do tego podszedł? Bo ja wiem, że na szybko to trudno powiedzieć, ale Pytasz jak do tego podchodzimy. To jak do tego podchodzicie?
Krzysztof Witczak: No w zasadzie to jest znany problem i dlatego też mamy warstwę moderatorów, która pomaga tego typu konflikty rozwiązywać różnego rodzaju. My faktycznie też podchodziliśmy do sytuacji, że najpierw wypłacaliśmy pieniądze tym, którzy byli najszybsi w pewnym oknie testowania, które się działo, dajmy na to 48 godzin i To często zdawało egzamin, ale czasami były sytuacje, gdy ktoś był, nie wiem, tylko troszeczkę wolniejszy, albo powiedzmy godzinę, dwie wolniejszy, ale jego raport jest znacznie wyższej jakości, ma więcej dowodów itd. I my w takiej sytuacji najczęściej po prostu obu tym osobom płaciliśmy. z uwagi na to, że raport tej osoby będzie wykorzystany w rezultatach dla klienta. On nie pójdzie na zmarnowanie. Więc było tam trochę takiego human hand w tym podejściu. Teraz coraz bardziej skręcamy z szybkości w stronę tej jakości. Bo ludzie po pewnym czasie zaczęli po prostu abuse’ować trochę ten system. Jeżeli chodzi o abuse, to tutaj jest jeszcze więcej takich historii, bo wspominałeś o priorytecie. My już jakiś czas temu, nie wiem, z pięć lat temu pewnie, pracowaliśmy nad klasyfikatorami, które pomagały ocenić automatycznie severity problemów. No i też właśnie ciekawy case, że okazuje się, że po latach współpracy z nami ludzie są w stanie przewidzieć jak troszeczkę można oszukać tego klasyfikatora odpowiednim doborem słów. Jak go podkręcić. I to tak trochę wtedy wpływa dobrze na tą wypłatę. Więc to jest trochę bezustanna też ewolucja z tym crowdem. Musimy monitorować właśnie liczbę high severities i tak dalej. Zastanawiać się czy tam nie ma manipulacji. i ten czynnik ludzki właśnie moderatorów jest ważny. A jeżeli ktoś naprawdę długo z nami pracuje i jest skuteczny, to może wtedy być użyty jako pomoc w moderacji. Kolejna forma współpracy.
Krzysztof Korozej: Tak, ta moderacja jest niezbędna. My nawet w ostatnim odcinku z Andrzejem rozmawialiśmy o Common Vulnerability Scoring System, w którym branża dostrzega taki problem, że wszystko w zasadzie jest krytyczne. Może nie wszystko, ale dużo rzeczy jest krytyczne. i jeżeli dużo rzeczy jest krytyczne, to następuje taki efekt zmęczenia i tak naprawdę nikt nie bierze tych podatności na poważnie. coraz więcej jest takich ruchów w stronę tworzenia własnych taksonomii, Zoom, tak jak Andrzej wspominał ostatnio, tutaj mówisz, że Wy wykorzystujecie jakąś własną metodę tego w jaki sposób określać krytyczność tych zgłoszeń, także to tylko tak potwierdza. że to jest jakiś ruch, który się dzieje.
Andrzej: Przy tym abuse to jeszcze dodam, że faktycznie w tym moim przypadku krańcowym, bo miałem taką rozmowę niedawno, parę dni temu z Grzegorzem Niedzielą. Myślę, że słuchacze będą kojarzyć. Na Twitterze i oczywiście counter argument to jest taki, że No ale jeśli będziemy płacić tym, którzy pierwsi zgłosili, no to co stanie się, że ja zgłaszał każdego buga, licząc na to, że jeśli ktoś kiedyś udowodni większą severity, no to ja dostanę za to wypłatę. No był prosty abus. I to pokazuje, że Nie jest łatwo rozwiązywać takie systemy, no bo ludzie też się uczą i tam, gdzie wchodzą do gry pieniądze i jeszcze w momencie, gdy dla tej drugiej strony te pieniądze mogą być znaczące, bo jeżeli ktoś na przykład z kraju trzeciego świata zarabia 100-200 dolarów, to dla niego to jest dość dużo w jego ekosystemie, no to oczywiście, że będzie ta incentywa, żeby oszukiwać system. To jest ludzka natura. Każdy to ma. Mamy to wbudowane.
Krzysztof Witczak: Wszystko się zgadza i też z racji, że pracujemy z ludźmi, to też są ludzkie sytuacje. Są sytuacje, gdy ktoś rano przed pracą szybko wchodzi, widzi, że coś jest, znalazł błąd, zgłasza go i pisze dosłownie w tym samym momencie maila do moderatora, hej, mam raport, załączniki, wszystko, wrzucę po pracę, muszę lecieć. Tego typu rzeczy. I nagle bez tego czynnika ludzkiego ciężko byłoby ogarnąć takie rzeczy, nie? Tak. To się zdarza.
Andrzej: Automat mógłby odrzucić i czekać, a tak naprawdę no jeśli ktoś już to miał, a nie może teraz tego zrobić, no ale on to już wykonał pracę i zgłosił jedno.
Krzysztof Witczak: Tak.
Krzysztof Korozej: Też powiedziałeś Krzysztof, że oferujecie bug bounty. To jest tak przy okazji. Jak często klienci, Wasi klienci, firmy, które się do Was zgłaszają z zapotrzebowaniem na crowd testing. mówią też o tym właśnie aspekcie bug bounty, które by chcieli.
Krzysztof Witczak: Czy w ogóle wspominają Wasi? Szczerze mówiąc, właśnie jak mówiłem o backbounty to miałem na myśli ogólnie nasze systemy, że ja na przykład akceptuję zgłoszenia czy nasz system ma jakieś błędy od zupełnie zewnętrznych aktorów. Jeżeli chodzi o takie testy z crowdem to Nie jest to raczej jedna z najważniejszych domen. Założenie jest po prostu takie, że pewnie ludzie z crowdu nie są specjalistami security. W rezultacie te firmy raczej followują do usług pentestowych czy tego typu. A u nas to właśnie raczej testy eksploracyjne mają na zasadzie wyłapać takie błędy, może niekoniecznie związane z security. Mogą być, ale to nie jest tak, że to jest postawione jako priorytet albo główny cel.
Andrzej: Ja mam tutaj jeszcze pytanie, już takie w zasadzie biznesowe, bo jesteś wysoko w organizacji. Czy myśleliście kiedyś, czy w ogóle rozważaliście, żeby pójść w tym kierunku? No bo jesteście w takiej pozycji, że technicznie moglibyście rozszerzyć wachlarz usług i po prostu dodać to jako pewną linię biznesową. I znowu ja też nie chcę mówić, że a to po prostu sobie dodamy i będzie. jest jakiś nakład pracy, pieniędzy, to jest koszt, inwestycja. Ale czy w ogóle myśleliście o czymś takim? No bo Bug Bounty to nie jest nic nowego. Te platformy już działają od wielu lat i możecie na nich popatrzeć jako pewnego rodzaju konkurencję lub wzór i przemyśleć, a może byśmy poszli w tym kierunku, a może nie. Mieliście takie przemyślenia w ogóle czy nie?
Krzysztof Witczak: Raczej przez ostatnie lata bardziej skłaniamy się ku zwiększeniu naszego takiego coverage’u wokół UX-a. Z uwagi na to, że okazuje się, że crowd po prostu jest całkiem dobry w tym. Bo w sytuacji kiedy właśnie szukamy błędu to też jest takie zderzenie z opinią czy ten błąd ma wysokie severity czy niskie. W security często też są tego typu rzeczy, że może się okazać na przykład, że coś znaleźliśmy, ale to jest z jakiegoś legacy software’u, który jest odcięty i tak dalej. Więc to też tworzy takie biznesowe po prostu problemy czy górki przez które trzeba skakać. UX natomiast jako opinia ma pewne właśnie takie pozytywne aspekty, że ciężko jest z tym walczyć, bo to jest po prostu opinia. Okazuje się też, że po prostu firmy są skłone dowiedzieć się jak ich system się prezentuje, bo kiedyś mam wrażenie, że tak powiedzmy nie wiem 5-10 lat temu często wygrywał ten, który był najszybszy na rynku. Prawda? A dzisiaj jest raczej tak, że zamiast robić MVP wskakujesz bardziej w ten minimal lovable product. On musi już dysponować jakąś jakością, bo inaczej nie przebije się po prostu w rywalizacji.
Andrzej: To jest to co rozumiałeś mi przed nagrywaniem tego odcinka, że w zasadzie to można rozszerzyć nie tylko na produkty takie techniczne jakiejś aplikacji ale również na jakiekolwiek projekty medialne podcasty właśnie czy kanały YouTube. Powszeczka jest wyżej konkurencja jest większa i niejako wskakując już trzeba mieć wyższy poziom niż było to powiedzmy dekadę temu.
Krzysztof Witczak: Tak jest. Mamy też takie nawet stwierdzenie, że po prostu jakość zmienia się z czasem, czy percepcja jakości zmienia się z czasem. Rośnie. Dokładnie.
Andrzej: Niestety, rośnie to w górę.
Krzysztof Korozej: Dokładnie. A ja mam pytanie z innej beczki, o ile możesz. Czy jest gdzieś u Was miejsce, w którym wysoko adoptujecie to wszystko, co się dzieje w związku z dużymi modelami językowymi? Mam taki koncept, żeby może rozwinąć, podpowiedzieć Ci w tym moim pytaniu o co mi chodzi. Tester piszący raport jest wspierany przez jakiegoś agenta, który podpowiada mu jak bardziej wypłucować ten raport, żeby był ładniejszy.
Krzysztof Witczak: Jak najbardziej. Myślę, że szkoda, że GPT nie pojawiło się rok wcześniej. Ci, którzy są z mojej firmy będą wiedzieć o co chodzi, ale mieliśmy bardzo długo koncepcję wykorzystania ogromnej ilości danych po prostu, które mamy z uwagi na to, że mamy crowd. Jak i również projekty i wizje takiej totalnej automatyzacji tego typu pracy związanej z QA. Było to niezmiernie trudne. Dzisiaj, kiedy pojawiło się GPT, znowu pewnie pomysły tego typu, mają rację bytu, otwierają się. Na przykład klasyfikatory, które budowaliśmy w przeszłości. Teraz możemy uzyskać wyższe accuracy, korzystając z OpenAI. dwa rzędy taniej jeżeli chodzi o koszty. Jakby to są tego typu improvementy, które możemy robić. To co wspominałeś o wsparciu. Również o tym myśleliśmy. Też taka ciekawa rzecz. Testowaliśmy czy OpenAI byłby w stanie zrobić taki eksperyment, że wchodzi trochę w skórę człowieka z innego kraju i czy byłby w stanie właśnie przewidzieć jak on może zinterpretować daną stronę. Mieliśmy taki eksperyment, trochę ciekawy, że miał imitować człowieka z USA. Powiedział, że pomarańczowe akcenty na stronie mają podtekst polityczny. Nie podobają mu się. Nie wiem czy domyślacie się o jaki pomarańcz chodzi, z kim on jest związany. Można pewnie sobie wyobrazić. Później doszliśmy do takiego wniosku, że wartością naszej usłuzy może być to, że my dalej trzymamy się ludzi. i że właśnie to nie jest usługa zautomatyzowana i że wciąż jesteśmy tym vendorem, u którego możesz uzyskać prawdziwą opinię od człowieka. Co się teraz dzieje? Wszyscy idą w GPT. My również jakby uwzględniamy to w naszych usługach, jakby wdrażamy to w translacji i tego typu rzeczy, ale firmy chcą testować AI. firmy chcą użyć ludzi do zweryfikowania czy usługi, które wykorzystują GPT działają poprawnie. To jest bardzo ciekawe, bo tu się okazuje, że już ludzie są w stanie pobawić się promptem i zobaczyć czy są w stanie tam troszeczkę zrobić injection. Namieszać.
Andrzej: Tak, prompt injections i wszystko związane z hackowaniem LLM.
Krzysztof Witczak: Tak, więc teraz okazuje się, że interfejs jest na tyle wygodny dla przeciętnego użytkownika, że jest w stanie wykryć dużo problemów właśnie poprzez eksplorację. Więc testowanie AI trochę zaczyna być ciekawym obszarem u nas w kraju.
Andrzej: Ja teraz mam pytanie trochę takie niezwiązane z tym, trochę z boku cię zaatakuje. Jak to wyszło, że z programisty w zasadzie zostałeś head of engineering i w takiej nietypowej domenie biznesowej, no bo wiem, że byłeś inżynierem, ale oprogramowaniem, dewelopowałeś, czyli pisałeś kodzik za pieniądze od 9 do 17.
Krzysztof Witczak: albo nawet dłużej.
Andrzej: Zwykle pisze się dłużej.
Krzysztof Witczak: No cóż. Rozpoczynałem programując w Ruby. Też w innych technologiach. Wiem, że Ruby też twoja czeszłość.
Andrzej: Ruby najlepsze.
Krzysztof Witczak: Tak. Programiści Ruby dzielą się na, znaczy programiści dzielą się pewnie na dwie grupy. Ci, co uwielbiają Ruby i ci, co nienawidzą Ruby. Ciężko jest być w pośrodku.
Andrzej: Tak, dokładnie.
Krzysztof Witczak: Mamy napięku z Pythonowcami i tak dalej. Ale generalnie To był faktycznie gdzieś tam mój świat. Pracowałem wtedy dla amerykańskiego startupu. No i szybko okazało się, że z uwagi na różnice czasowe była potrzeba, aby tak mocno leadować w naszej strefie czasowej. No i gdzieś tam po prostu poprzez leadowanie zespołów odkryłem, że prowadzenie zespołów, leadowanie, rozmowy z różnymi stakeholderami, priorytazacja to są rzeczy, które dość łatwo mi przychodzą. No i w pewnym momencie uznałem właśnie, że spróbuję karierę engineering managera. To było 3 lata temu ponad i wtedy w Polsce było bardzo mało takich ofert. Dzisiaj jest już troszeczkę więcej.
Andrzej: Też zauważyłem wzrost.
Krzysztof Witczak: Tak. Kiedyś było raczej tak, że szukaliśmy tech leadów bądź team leadów. Nie bardzo też ludzie widzieli różnicę między tymi dwoma tytułami. Teraz pojawia się engineering manager. Już popularniejsza rola, ale wtedy też tak naprawdę jak przyszedłem to Cała reszta firmy nie do końca wiedziała, co ten człowiek będzie robił w ogóle. Bo on nie będzie za bardzo chodził z nami. Ma tam w kontrakcie od 0 do 30%. Tak dziwnie trochę. I też to mocno mnie bolało, to odcięcie od kodu, ale wciąż blisko technologii. No i teraz akurat tak się złożyło, że po prostu przez rotację firmy też stałem się headem. Wciąż pełnię te same funkcje, które pełniłem wcześniej jako menadżer przez 3 lata i doszły mi jeszcze takie właśnie bardziej wysokopoziomowe elementy, jak i również gdzieś tam rzeczy związane z SMS-em, security i to również właśnie z kolegą z pracy, z Karolem. wspólnie ogarniamy we dwójkę. Ale to też otworzyło mocno nam oczy, kiedy to zaszło z naszego poprzedniego heda na nas, jak dużo jest tych elementów właśnie dookoła, o które trzeba dbać związanych z cyber security. I też one mocno propagują na rzeczy związane z developmentem. Wcześniej myślałem, że to czysta biurokracja, a teraz przechodzę na stronę zła i widzę, że tam jest też parę mądrej rzeczy.
Andrzej: Coś tam się znajdzie w tym security.
Krzysztof Witczak: Da się czasami złapać.
Krzysztof Korozej: Dla waszych klientów bezpieczeństwo waszej usługi jest taką kartą przetargową, bo wspominałeś o e-smsie, więc rozumiem, że pewne firmy nie mogą nawiązywać kontaktów biznesowych z firmami, które nie mają.
Andrzej: Szczególnie, że wy działacie worldwide, więc macie klientów z różnych krajów i ja z doświadczenia wiem, że szczególnie jak firmy wychodzą z Polski gdzieś na zagranicę, żeby oferować usługi czy produkty, to wtedy zaczyna się takie przebudzenie pod kątem formalizacji bezpieczeństwa w organizacji, czyli różnego rodzaju ISO czy SOKI.
Krzysztof Witczak: Powiedziałbym, że ISO 27001 czy SOC 2 to jest taki totalny baseline. Jak tego nie mamy to nawet te filmy w ogóle nie wchodzą w relację. Wręcz otrzymujemy sprawdzenia czy regulacje, które weryfikują poziom implementacji powyżej tego baseline. My też bardzo mocno musimy się bronić, bo myślę, że możecie sobie wyobrazić jak produkt ewoluuje i my cały czas coś tam zmieniamy, chcemy ulepszać usługę. To w sytuacji, w której pracujemy z crowdem jest dość takie tempting, żeby zbierać jeszcze więcej danych. Prawda? Bo wtedy możemy lepiej dobierać.
Andrzej: Przydadzą się.
Krzysztof Witczak: Przydadzą się na kiedyś. No i wtedy wchodzi GDPR z przytupem. Nagle okazuje się, że musimy bardzo mocno uważać na compliance, bo w sytuacji, w której mamy użytkowników ze 150 krajów, nagle się okazuje, że jeżeli przekroczymy liczbę 250, 500 testerów z jakiegoś stanu w Kalifornii, to nagle mamy jakieś dodatkowe obowiązki. Więc musimy to monitorować, więc im mamy mniej danych takich personalnych, tym lepiej dla nas. Więc właśnie compliance jest taką rzeczą, która pewnie najczęściej gdzieś tam nas blokuje czy męczy. Z uwagi też na to, że się zmienia.
Andrzej: Tak, trzeba monitorować cały czas.
Krzysztof Korozej: Ja sobie mogę tylko pomyśleć, jak trzeba sprytnie podchodzić do tematu, żeby lawirować w tematach komplajansu, który dotyczy 190 krajów na całym świecie.
Krzysztof Witczak: Problemy się zaczynają dopiero kiedy przekraczamy te liczby krytyczne użytkowników, ale musimy mieć je po prostu na oku. Natomiast wiemy, że jak tylko zbieramy jakieś dane krytyczne to zawsze nasze wszystkie ryzyka rosną do góry. No i tutaj akurat monitorowanie ryzyk z ISO okazuje się być fajną rzeczą, fajną czynnością, bo z tego bąbelkują projekty techniczne często do redukcji tego ryzyka, więc mamy takie zatrzymanie się raz na jakiś czas, żeby zastanowić się czy coś się zmieniło i tak dalej, więc to jest całkiem fajne.
Andrzej: I reassessment. Ale podobało mi się to stwierdzenie, które użyłeś, że właśnie z monitorowania bąbelkują projekty techniczne, że tak naprawdę te projekty techniczne one się nie biorą znikąd. To nie jest tak, że ktoś tam nagle się budzi i sobie myśli, a kurcze wdrożyłbym sobie coś tam, coś tam. Nie, to z czegoś wynika i teraz jeśli przykładowo jesteśmy niżej w organizacji na poziomie operacyjnym, i chcemy iść wyżej to dobrze zdawać sobie sprawę z czego to wynika bo na koniec dnia biznes po to żeby zarabiać pieniądze a nie po to żeby robić wewnętrzne techniczne projekty, które nie przynoszą pieniędzy.
Krzysztof Witczak: Tak i tutaj fajnie to mi się kojarzy z projektem Phoenix. pewnie gdzieś tam czytaliście. No więc tam też jest historia o gościu od Security, który na początku bardziej formalizował biurokrację, będzie przekładał dobre praktyki nad pragmatyczność. No i to jest też coś na czym po prostu musimy uważać. Coś co w ISO mało kto na to zwraca uwagę, bo właśnie biurokracja, ale tam też jest taki zapis, że nigdy inwestowanie w bezpieczeństwo nie powinno być droższe niż strata, która wynika z tego ryzyka.
Krzysztof Korozej: No to tak samo w gpdrze. Środki zaradcze muszą być odpowiednie do danych, które przetrzymujesz. Tam nie ma wprost napisane jak ty masz coś zrobić, żeby być zgodny z gpdr.
Andrzej: Dokładnie.
Krzysztof Korozej: To ma wynikać z twojej pogłębionej analizy ryzyka.
Andrzej: Tak, dokładnie. Cel jest taki, żeby to po prostu zrobić i przed samym sobą móc jasno powiedzieć, Albo inwestuję w security, albo w nie. Nie inwestuję, ale mam jakąś argumentację, czemu tego nie robię. I ogólnie szerzej w jakość, bo to dotyczy całej jakości.
Krzysztof Witczak: Zwłaszcza, że niektóre rzeczy są po prostu sprzeczne. W sensie, że mamy w TDPR na przykład zapis związany z odpowiedzią w 30 dni. No i teraz to wpływa na przykład na to, jak my robimy backupy. Prawda? Bo jeżeli ktoś nam zgłosi chęć usunięcia danych, a my trzymamy te backupy dłużej, no to nagle się okazuje, że nie jesteśmy compliant, bo nie usunęliśmy go danych z backupów, bo nikt tego nie zrobi nigdy i tak dalej. Ale okazuje się, że niektóre dane związane np. też z tymi samymi użytkownikami potrzebujemy pod kątem podatkowym. Więc nie możemy ich usunąć wszystkich. Tak. No to wtedy wchodzi temat właśnie poprawy anonimizacji. My zrobiliśmy open source. Nazywa się Wipeout. Sprawdźcie, dajcie gwiazdkę.
Andrzej: Wipeout?
Krzysztof Witczak: Wipeout, tak.
Andrzej: Podlinkujemy, podlinkujemy w odcinku.
Krzysztof Korozej: I gwiazdkujcie.
Krzysztof Witczak: O, gwiazdkujcie. Więc to jest po prostu problem. Ale tak jak mówicie, wskazujemy środki zaradcze. To nie jest tak, że ten temat ignorujemy. Adresujemy go, ale w miejscach, w których mógłby uszkodzić biznes albo nie ma to sensu, to trzeba mieć tego świadomość.
Andrzej: Ja powoli się wystrzelałem.
Krzysztof Korozej: To była bardzo ciekawa rozmowa, która zahaczała o wiele wątków. Od crowd testingu przez Bug Bounty kończąc na ISO 27001, więc poczuliśmy chyba wszystko.
Andrzej: Tak, przy czym mi bardzo się podobał ten wątek kompliansowy i ISO, bo często jest, szczególnie od osób, które z krwi i kości są inżynierami, jest trochę takie spychanie tego tematu, że a to tylko komplians, a to jakieś tam ISO, to są wymysły. I z jednej strony tak, ale z drugiej strony nie. I raczej takim zdrowym podejściem jest to o czym wspomniałeś w książce The Phoenix Project, którą znowu po raz kolejny każdemu polecam. To jest klasyka. Każdy kto pracuje w IT powinien przeczytać Phoenix Project. Bo poświetnie opisuje i świetnie pokazuje co jest celem, a cel zależy od kontekstu, więc to jest ważne. Bardzo Ci dziękuję za rozmowę Krzysztofie. Tobie Krzysztofie również. Dziękuję obu Krzysztofom. Dziękuję Andrzeju. I do usłyszenia kiedyś gdzieś w przyszłości.
Krzysztof Witczak: Pogadamy wtedy o compliance’ach związanych z AI.
Andrzej: Challenge accepted.
Krzysztof Witczak: Już wyszło. Tak jest prototyp. Teraz czekamy.
Andrzej: Będzie o czym rozmawiać. Będzie. Będzie. Z AIem to będzie sporo zabawy.
Krzysztof Witczak: Dzięki. Cześć.