Biznisz Boyz: A magyar vállalkozói podcast show

Így építkezz, ha specialista céged van - A TesterLab-sztori

· PT1H34M41S

Összefoglaló

A Biznisz Boyz podcast vendégei Hamana Zsolt és Hargitai Zsolt, a TesterLab alapító tulajdonosai. A szoftver tesztelés speciális területén a TeszterLab világszinten elismert tudással rendelkezik. A műsorban a specializáció előnyeit és hátrányait tárgyalják, valamint azt, hogyan…

Röviden

Műsor
Biznisz Boyz: A magyar vállalkozói podcast show
Megjelenés
2026. 01. 13.
Hossz
1 óra 35 perc
Szereplők, említett nevek
Hamana Zsolt, Hargitai Zsolt, Sándorfy Adrián, Pál Zoli
Témák
vállalkozás, szoftvertesztelés, specializáció
Átirat
Az epizód beszélt szövege alapján indexelve

Ebben az epizódban

Sziasztok kedves nézőink, kedves hallgatóink.

Ez itt egy újabb Business Boys Podcast epizód.

Én most egyedül vagyok, de a vendégoldalon két Zsolttal, Hamana Zsolttal és Hargitai Zsolttal beszélgetek.

Ti a Teszterlabnak vagytok az alapítói tulajdonosai, ami egy szoftver teszteléssel foglalkozó cég.

És az a nagyon izgalmas szerintem, hogy mind a ketten valamilyen szempontból egy ilyen nich területen belül vagyunk, specializációval foglalkozunk.

Ugye az én cégem a Brokasters podcast gyártással foglalkozik, ami a nagy marketing bubarékon belül egy kicsi bubarék.

Itt pedig a szoftver fejlesztés programozás területen belül egy másik bubarékon bekal foglalkoztok.

Ez a szoftvereknek a tesztelése.

Nem csak szoftver tesztelésről fogunk beszélgetni ma, hanem kifejezetten így a specializációnak a az előnyeiről, a hátrányairól.

Ebből majd én is szívesen elmondom, hogy mik a tapasztalataim.

Az is nagyon hasonlít a mi bizniszünkben, hogy próbáljátok pont emiatt a specializáció miatt lefedni a teljes életútvonalát, amit egy egy tesztelési szolgáltatás vagy egy tesztelővel való együttműködés jelenthet kezdve a az oktatástól, amiben nagyon aktívan részt vesztek globális szinten, ha jól tudom, ennek a ennek a tesztelői kultúrának meg közegnek a fejlesztésében.

Ö, illetve hát általában egy nagyon jó mindig egy másik podcaszterrel vagy podcasterekkel beszélgetni, és a nálunk működött podcast, ami a digitális döntéshozóknak szól, az szinten ebben a stúdióban forag, és ti vagytok ennek a műsorvezetőji.

Sziasztok, üdvözöllek titeket. >> Sziasztok, köszi szépen a meghívást. >> És a annyit a nálunk működötről, hogy adjunk egy kicsi promót ennek a podcastnek, hogyha lehet itt az elején, hogy hogy mennyire kell hardcore szoftver teszteléssel kapcsolatban érdeklődőnek lenni. illetve mennyire elég az, hogy digitalizáció iránt nyitott vállalkozó valaki, mert utóbbiakból sokkal többen vannak a hallgatók között, előbbiekben jóval kevesebben.

És a mai adással kapcsolatban is az az ígéretem nekik, hogy nem fogunk nagyon-nagyon mélyen belemenni a szoftver tesztelésbe, de azért megpróbáljuk megérteni egy kicsit az elején.

Igen, a nálunk működöttben sem megyünk bele nagyon mélyen a szoftver tesztelésben.

Olyanok, akik mondjuk az IT-ban dolgoznak, de nem pont tesztelőként vagy fejlesztőként, azoknak az egy teljesen követhető, érdekes műsor.

Azt nem állítanám, hogy minden átlagembernek ez szuper izgalmas, ami ott történik, de igazából nem is a célja ennek ez a ennek a podcastnek azt, hogy népszerű legyen nagyon nagyobb széles tömegek között.

Inkább az a fontos benne, hogy a a ebben az iparákban dolgozók egyel mélyebb megértésük legyen avval kapcsolatban, hogy miért fontos a szoftver minőség.

Az első adást azért attól függetlenül, hogy hogy a témák spektrumával mennyire akar valaki megismerkedni, azt azért mindenképpen ajánlom, mert ott például hoztok, ha jól emlékszem, egy egy csomó olyan példát, ilyen ilyen életből származó példát, ahol kiderült az, hogy a szoftver tesztelés az mennyire problémás, hogyha elmarad, vagy hogyha nem megfelelő.

Mondasz egy-két példát erre Zsolt, hogy hogy így a a való életből, amit így tudunk a vagy akár amit ebben az első epizódban is megemlítettetek, hogy mik azok a ugye nagyon jól ismert szoftver hibák, amiket hogyha kicsit jobban teszteltek volna, akkor nem került volna akár sok milliárd Fintba vagy dollárba a kijavítású?

Hát az egyik klasszikus példa, amikor két csapat együtt dolgozott egy terméken, Amerikába, illetve Európába, és dübörgött a projekt.

Igen ám, csak az egyik egyik csapat incbe, a másik meg centiméterbe adta meg az értékeket, és az előbb-utóbb azt okozta, hogy fölrobbant egy ilyen kilövött kilövött űrrakéta. >> Ajjaj. >> Úgyhogy ez az egyrészt fájó, másrészt annyira banális.

A harmad részt fillérekből lehetett volna kezelni, hogyha ezt időbe erre odafigyelnek. >> Másik saját példa például az, hogy amikor saját, tehát hogy saját projektem történt, hogy tesztelés közben vettük észre, hogy teszt eseten keresztül, amikor indítottuk a scripteket, akkor tudtuk törölni az adatbázist.

És ugye ez mondjuk egy luftzás példa, és az azért az elég mélyére megy.

És hogyha ott így >> hirtelen élesbe letörölnéd a járatokat az adatbázisból, az az fájóan milliárdok mennének óránként a levesbe. >> Igen.

Sok ilyen példát hoztok még ebben a podcast sorozatban, tehát így alá tudom írni, hogy nem tehát megérthető és érdekes a az átlag cég tulajdonos számára is.

De mielőtt így jobban belemennénk a teszterlap sztorijába, meg a specializációba, és akkor itt egy záróillet nyitok, hogy szerintem a hallgatóknak azért lesz az izgalmas, hogy megnézzük azt, hogy egy nagy iparágon belülan lehet tök jól érvényesülni, hogyha van egy specializált tudásunk, és hogy próbálunk majd a mai adásban olyan univerzális elemeket hozni, amiket tőletek, esetleg tőlünk, de el lehet úgy lopni, vagy ki lehet próbálni, hogy ha valaki egy picit célzottabb pozicionálással akar működni, akkor arra, hogy lehet egy céget építeni.

Úgyhogy valószínűleg ezt mond teszterlap példáján keresztül nagyon jól meg fogják érten a hallgatók, de légyszi kezdjük azzal, hogy mi az a szoftver tesztelés és miért van eg erre egyáltalán szükség. hiszen azt gondolnám én tök laikus szoftverekhez azért egy picit így konyító vállalkozóként, hogy hát az a dolga a programozónak, hogy tesztelje le, aztán az a dolga az üzleti megrendelőnek vagy az igény feltárójának, hogy ő is tesztelje-e.

És a végén amikor van egy cégtulajdonosunk, aki kitalálta mondjuk azt, hogy legyen egy, nem tudom, valamilyen szoftver a cégen belül, akkor még ő is végigkattogtatja az egészet, és azt mondja, jó, oké, akkor mehet ki a piacra.

Most ehhez képest, >> hát ehhez képest egy érdekesség egyébként, amit a mostani generációk már nem is tudnak, hogy mondjuk elég csak 70 évet visszamenni az időbe, és ott látnád, hogy nem is volt tesztelés, és IT már volt, de az ugye a fejlesztésbe merült ki, és ha innen innen nézel rá a tesztelésre, akkor igazán fölértékelődik a az értéke a tesztelésnek, mert a mert régen is mindenki ezt gondolta, hogy ott a feladat, valaki lefejleszt, és akkor az majd úgy jó.

Ezért a így az évtizedek során fölértékelődött a tesztelés, merthogy az elkészült termék nagyon gyakran nem hozza azt a színvonalat, azt a minőséget, amit elvárnak tőle.

És pont ennek a hiánya, vagy ez a ez az űr, ez hozta létre igazából azt, hogy hogy kell szoftver tesztelés.

És akkor az IT az így szépen fejlődött, a fejlesztés előrébb járt, de ez a ez a fajta elmaradása a tesztelésnek azáltal zárkózott föl a fejlesztéshez, hogy hogy hogy egyre nagyobb hangsúlyt kaptak az IT rendszerek.

Elég, hogyha ott a laptopodat megnézed, vagy a mobiltelefonodat, é két évente duplázódik a kódbázis.

Ez ez ugye azt jelenti, hogy egy akkora hatalmas kód lesz, tudod, amikor már nem két évről beszélsz, hanem mondjuk 25-30 évről, ahogy fejlődik az IT, akkora kódbázis lesz annyi hibával, amit már nem engedhet meg magának egyik cég se.

Itt igazából arról van szó, hogy annyira komplexé válnak a a a piacra kirakott szoftverek, hogy annyiféle változó lehet, ami ami elromolhat, hogy ezt talán talán egy egy specializált tudás kell ahhoz, hogy ezeket a teszteseteket meg ezeket a különböző hibapotenciálokat feltárja valaki. egyébként a a teszteléssel kapcsolatban, amikor a Zsolt most ez a 70 évvel ezelőtről indult, de egy kicsit az jutott eszembe, hogy nézzük meg azt, hogy ma mi az, ami a tesztelés, és ezt hogyan lehet ilyen érthetően elmagyarázni gyakorlatilag bárkinek.

Tehát sokféle dolgot lehet tesztelni.

Van az a nagyon egyszerű dolog, hogy van mondjuk egy webshopod, ahol te mondjuk focicipőket árulsz, és mondjuk le kell tesztelni azt, hogyha valaki berakja a kosárba ezt a focicipőt, akkor az ott megjelenik-e a kosárba.

De ezen kívül van nem funkcionális jellegű tesztek is.

Tehát hogyha én megnyomom azt, hogy az a focicipő bekerüljön a kosárba, és az 15 másodpercig tart, akkor senki nem fogja azt mondani, hogy az úgy jó, úgy. >> Igen. >> És most ez két nagyon jó példa, amit kiemeltél most.

Adrián, képzeld el, hogy ilyenből van 40.

Tehát amire a földi halandók azt gondolják, hogy na jó-e a termék, igen vagy nem, >> az nem így van, hanem 40 különböző szempontból mondhatod rá, hogy jó.

Jó, de akkor ti a UX tesztel is foglalkoztok, hogy milyen a felhasználó élmény. >> Igen, >> van egy ilyen kifejezés, ez a validálás, ezt így hívják. >> Aha. >> Hogyha például te megveszed ezt a focicipőt, és berakod a kosárba, és utána megjelenik a kosárba, de érkezik neked egy olyan üzenet ott, hogy egyébként pedig nem tudom, iratkozz fel a hírlevelünkre, és hogy ehelyett mondjuk az az üzenet jelenne meg ott, hogy figyelj, vettél egy fociipőt, hát vegyél egy sportszárat is hozzá.

Ühüm. >> Nyilván az utóbbi a jobb, igaz? >> Ühüm. és hogy ezt validáljuk, hogy az a működés, amije van ennek a szoftvernek, az tényleg úgy jó lesz, vagy ennél lehetne jobb is. >> Ühüm.

De akkor igazából két irány van, ha jól értem.

Azt lehet, hogy van még több is.

Majd mondjátok, >> akkor majd mondjátok el a kettőt.

Akkor azt a kettőt lefordítom először is saját magamnak, meg a hallgatóknak.

Az egyik verzió az az, hogy hogy készül egy szoftver termék, vagy annak egy modulja, és végig kell kattogtatni, hogy különböző felhasználói száriókban, különböző környezetekben az az ugyanazt csinálja el, mint amit eredetileg szerettünk volna.

A másik eset az, hogy jól működik technikailag, vagy úgy működik, mint ahogy a programozó szánta, hogy működjön a a szoftver termék, vagy az a funkció, csak éppen a felhasználónak nem élmény végignyomkodni ezt a funkciót, és ez emiatt >> árt vagy káros a megrendelőnek vagy a projekt tulajdonosának szponzorának.

Ezt ezt a két utat látom most abból, amit ti csináltok.

Van még másik is, vagy más irány?

Tehát ez nagyon jó, ha már ezt mind a mind a két csapásirányt lefednék tisztességesen a az IT projekten dolgozók, akkor már jók lennénk. >> Akkor nem lenne munkátok végülis.

Tehát akkor ez a két nagy irány, de vannak ilyen al területek. >> Hogyne?

Na ez ez már az a szakmai réteg, amibe most nem akarunk belemenni. >> Jó, >> de így van.

Nagyon hát ettől lett szakma egyébként, amit most kérdezel, az attól vált szakmává.

Akkor mégis muszáj lesz majd kiszednem belőletek, hogy ez pontosan hogy van, de akkor szerintem menjünk egy másik útról, hogy hogy a hallgatók azt is értsék, hogy hogy született meg ez az egész történet, hogy azért ez egy specializált irány.

Én azt gondolom, hogy ehhez kellett valamilyen fajta bátorság, hogy ehhez beleálljatok, és azt mondjátok, hogy pozicionáltok egy ilyen topicra, ahelyett, hogy mondjuk egy szoftverfejlesztő céget építenétek.

Alapvetően az én utam az nem volt szerintem annyira egyértelmű, mint a a tied Zsolt, mert te már 18 év az lehet, hogy most nem is túlzok, amióta ezzel foglalkozol. >> Alálőttél? >> Alálőttem.

Jó ez a lufthanzán elindult, ugye?

Ott ott még a ilyen tesztelői pozíciókban lépkedtél fölfelé.

Igen. >> Íg és a lufthaz az gyakorlatilag a a magyarországi tesztelés kezdete, amikor elkezdtek Magyarországon szoftvereket tesztelni, az a lufthanzához erősen köthető. meg ahhoz a szakmaisághoz, ami ott van.

De de a az én utam az sokkal egyszerűbb volt ennél.

Én közgazdász végzettségem van, hosszan dolgoztam újságíróként és utána egy startup cégnek az alapításában is részt vettem, ami ilyen igazából ilyen nem volt sikertelen cég, tehát nem egy év alatt csődölt be, hanem hat.

Voltak évek, amikor igazából ilyen nyereséget is termelt. viszont ott nagyon gyorsan szembe jött velem a szoftvert tesztelés nélküli szoftverfejlesztés valósága >> mert hogy amikor kezdődött ez a beszélgetés mondtad hogy majd akkor jön a cégvezető és még rányom kettőt és hogyha jólak látja akkor mehet ki tehát hogy ezt 10 évvel ezelőtt ez teljes valóság volt szerintem Magyarországon >> csak hát ebből nem lesz rentábilisan fenntartható módon működő működtetett szoftver >> és hogy ott ott láttam azt a dolgot az ilyen két 2015-16 magasságában vagyunk, hogy hiába vannak mondjuk szenior fejlesztők egy csapatban, de hogyha nincsen megfelelő szoftveres minőségbiztosítással megtámogatva az a munka, akkor ott az nem lesz jól szállítható a szoftver.

Nem fogunk tudni rendesen sprintekben, agilisan, két hetente új szoftvert kiadni.

És akkor én elkezdtem magamat képezni ebbe a ebbe a témában, tehát teljesen autóidaktó módon menjünk föl az Amazonra és vegyünk könyveket. >> Na oké.

És hogy akkor megértettük, hogy akkor ez hogyan hogyan is kéne vagy egy részhalmazt megértettünk.

Ez így pontosan volt kiegészítve, hogy melyik részt nem értettük meg ott annó. >> Aha.

És akkor elkezdtük, hogy először a saját csapatunknak szoftver tesztelést kialakítani, aztán másoknak is segítettünk szoftver tesztelést kialakítani.

És egy idő után azt láttam, hogy ez egy teljesen valid üzleti lehetőség, hogy szoftveres minőség biztosítással kapcsolatban különböző szolgáltatásokat lehet nyújtani Magyarországon, mert van rá piac. >> Ühüm.

És akkor én nagyon kerestem magam mellé egy szakmailag erős társat, akit aztán meg is találtuk egymást egy tesztéstel a meetupon, és utána nem is sokkal, szerintem el is kezdtünk közös projekteket csinálni, majd egy-két éven belül megalapítottuk a testerlabot, >> de ez úgy volt, hogy véletlenül mentetek be erre a meetupra, és eg egy egyszerre nyúltatok a népkártyáért, házsoltos népkártyáért.

Ugye azért azért ritka, amikor valaki tehát hogy nagyon hasonló névkombinációval alapító társak lesztek, azért gondolom ezt megkapjátok párszor. >> Mindig mindig, mindig. >> Oké.

Na de hogy akkor véletlenül így összesodort titeket az élet és azt azt lehet mondani, hogy hogy te te Hargitai Zsolt, te csinálod a vagy te voltál az, aki a szakmai részét jobban építette ennek a biznisznek és a Hal van a Zsolt, aki meginkább mondjuk így az operációt, hogy ez…

Említett entitások

Témák

Személyek

Szervezetek, cégek

Hallgasd meg

Gyakori kérdések erről az epizódról: „Így építkezz, ha specialista céged van - A TesterLab-sztori”

Miről szól ez az epizód: „Így építkezz, ha specialista céged van - A TesterLab-sztori”?

A Biznisz Boyz podcast vendégei Hamana Zsolt és Hargitai Zsolt, a TesterLab alapító tulajdonosai. A szoftver tesztelés speciális területén a TeszterLab világszinten elismert tudással rendelkezik. A műsorban a specializáció előnyeit és hátrányait tárgyalják, valamint azt, hogyan… Az epizód a Biznisz Boyz: A magyar vállalkozói podcast show című magyar podcast egyik adása, megjelenés: 2026. 01. 13..

Kik szerepelnek vagy kiket említenek ebben az epizódban: „Így építkezz, ha specialista céged van - A TesterLab-sztori”?

Az epizódban a következő nevek szerepelnek vagy hangzanak el: Hamana Zsolt, Hargitai Zsolt, Sándorfy Adrián, Pál Zoli.

Milyen témákat érint ez az epizód: „Így építkezz, ha specialista céged van - A TesterLab-sztori”?

Fő témái: vállalkozás, szoftvertesztelés, specializáció.

Mikor jelent meg és milyen hosszú ez az epizód: „Így építkezz, ha specialista céged van - A TesterLab-sztori”?

Megjelenés: 2026. 01. 13.. Hossz: 1 óra 35 perc. Az epizód a Podiverzumon hallgatható meg: https://podiverzum.hu/podcast/biznisz-boyz-a-magyar-vallalkozoi-podcast-show/igy-epitkezz-ha-specialista-ceged-van-a-testerlab-sztori

Több epizód a Biznisz Boyz: A magyar vállalkozói podcast show-ből

Hasonló epizódok más magyar podcastokból