Mennyire kell tudnia angolul egy tesztelőnek?

Érdemes egyáltalán megtanulni angolul? Igen: én például pont kétszer annyit kerestem az első multis munkahelyemen, ahol már tudni kellett angolul, mint azelőtt.

De mégis, mennyire kell tudnia egy tesztelőnek angolul?

Az első kérdés, hogy kell-e napi szinten külföldi kollégákkal beszélned. Ha igen, akkor értened kell a beszélt nyelvet és meg is kell szólalni, sőt: tudnod kell érvelni angolul. A nyelvtani hibák viszont nem nagyon számítanak, amíg érthető maradsz. Én az évek alatt még sohasem hallottam, hogy bárki kínos helyzetbe került volna nyelvtani hiba miatt, vagy hogy kibeszélték volna a háta mögött. Kevesen beszélnek annyira jól angolul, hogy ne ejtsenek nyelvtani hibákat menet közben.

Éppen ezért, ha van lehetőséged nyelvtanfolyamra járni, nem az a jó választás, ahol akkurátusan végighaladtok a tankönyvek egyre magasabb szintjein, és ahol a tanár hosszasan magyarázza a nyelvtani szerkezetek jelentését. Az a jó nyelvtanfolyam, ahol megszólalsz, ahol egy idő után beszélgetni tudsz.

Ha viszont a hétköznapi kommunikációs nyelv a magyar, mihez kellhet az angol egyáltalán? Ott van például az írásos anyag, a dokumentáció, ha van egyáltalán. De jó esetben személyesen fog egy magyar kolléga betanítani a szoftver használatára…

Vagy ott vannak a tesztesetek és a bugok, amiket esetleg angolul kell megírni. Ezekhez egy nagyon szűk szókincs elegendő, az viszont elengedhetetlen. Click the button – the window opened. The software crashed. Ami eggyel nehezebb, az a bugok indoklás része – miért gondolod ezt egyáltalán hibának, ehhez már eggyel nagyobb szókincs szükséges. Viszont amíg csak írásban kell megnyilvánulni, számíthatsz a barátaidra: Google Translate, ChatGPT, CoPilot.

Végül a meetingek: egy bizonyos szint alatt megúszhatod, hogy külföldi kollégákkal kelljen beszélned. Megfordítva viszont: egy bizonyos szint fölé nem fogsz eljutni, ha nem tudsz külföldi kollégákkal beszélni.

Oltári srácok Nyíregyházán

Öt oltári musical sztár egy színpadon: Kerényi, Dolhai, MÁZS, Serbán, és a turné kedvéért Amerikából hazalátogató Szabó Dávid – ezt nyilván látni kell. Mi február 8-án láttuk Nyíregyházán.

Oltári srácok plakát

Az Oltári srácok című darabot 2007-ben már játszotta ugyanez a csapat a Thália Színházban. Azoknak, akik akkor is látták már, nyilván nosztalgikus élmény újra látni a darabot ugyanazokkal a szereplőkkel. Persze öregedtek azóta, de egyrészt még mindig jól néznek ki, másrészt az öregedést ironikusan kezelik, az este legjobb poénja, amikor a nézői levelek elolvasásához szemüveget vesznek elő…

Maga a színdarab, az Oltári srácok című musical nem jó. A történet szerint öten fiúcsapatot alkotnak, csakhogy ez öt keresztény férfi, akiknek a dalai kizárólag hitről, szeretetről, Istenről szólnak, ilyen kínosan fiatalos, fiúcsapatosan táncoló, rappelős módon. A sztori annyi, hogy elmesélik, ahogy találkoznak – ez vicces szeretne lenni, de nem vicces. Továbbá térítenek, egy nagy számláló mutatja a falon, hogy mennyi bűnös lélek van még a teremben…

Nem hittem volna, de a második felvonás még ennél is kínosabb volt. Az egyik kamu olvasói levél nyomán Dolhai Attila hosszasan beszélt az önmegtartóztatás fontosságáról, hogy az esküvő előtt senki ne szexeljen, csak azzal, aki majd a gyerekei anyja/apja lesz. Nem tudom, hogy ez a darab része, vagy Dolhai tényleg ezt gondolja? Ki kíváncsi rá? MÁZS végleg kilépett a szerepéből és a saját életéről beszélt, ahogy a két végén égette a gyertyát, Kerényi Miklós Máté pedig az édesanyja haláláról. Serbán általánosságokat mondott, Szabó Dávid pedig az Amerikába költözése kapcsán mondta el, hogy azt hitte, cserben hagyták a társai, erre ő hagyta itt őket…

Nyilván ezeknek a személyes monológoknak is van létjogosultsága. Ezeket a színészeket sokan évtizedek óta követik, nézik a színházban, és a rajongókat érdeklik a személyes történeteik. Engem viszont sajnos nem, és a nyíregyházi csarnok többi nézőjében sem vagyok biztos. A színészeknek ezekkel a személyes monológokkal leginkább saját magukat sikerül meghatni: mindegyikük többször sírva fakadt, az öt pasas vigasztalta, ölelte, puszilgatta egymást, mintha egy melegbár műsorát látnánk…

Alaposabban utána kellett volna nézni előre, hogy mit fogunk látni. Az a baj, hogy a szereplők névsora annyira erős, Dolhai és Kerényi neve eddig külön-külön is garancia volt egy jó előadásra – hát, ez most elmúlt. Legközelebb figyeljünk oda jobban, hogy mire veszünk jegyet…

Mi a legjobb bugok két titkos összetevője?

Egy időben hetente tartottunk bug scrub nevű rendezvényeket, ahol összeültek a projekt vezetői és elolvasták, majd priorizálták az adott időszakban riportolt bugokat. A probléma az volt, hogy aki vezette a meetinget és felolvasta a bugokat, az

  1. nem értett a termékhez,
  2. diszlexiás volt, nehezen értette meg a leírt szöveget.

Ott tanultam meg jól bugokat írni. Az a bug volt jól megírva, amit a terméket nem ismerő, diszlexiás igazgató is azonnal megértett. Ennek két titka volt:

  1. A description rész elején elhelyezett rövid, nagyon jól érthető indoklás
  2. Screenshot, amin a hibát nagy, piros ellipszissel jelöltem meg. Ha van pozitív ellenpélda, azt egy másik screenshoton nagy, zöld ellipszissel jelöltem meg.

A jó screenshot hasznosságát talán nem kell magyarázni, ahogy mondani szokták: egy kép többet mond ezer szónál. Ebben az esetben gyorsan és hatékonyan megmutatja, hogy pontosan hol és mivel van probléma.

Az indoklás rész már bonyolultabb. A Description kitöltése amúgy is mindenkinek gondot okoz, mert szabad szöveges mező, nincs a többi mezőre jellemző fogódzó, választási lehetőség. Mit kell oda írni egyáltalán? Steps to reproduce, Expected results, Actual result – ez a szentháromság, és a többség ezzel meg is elégszik.

A személyes felfedezésem az volt, hogy a bug életciklusában résztvevő minden kollégának (projektvezető, fejlesztők) segít, ha megindoklod, miért hiszed a riportolt jelenséget problémának. Leginkább az „impact” faktort érdemes körülírni:

  • a jelenség kinek okoz problémát (végfelhasználónak > belsős adminisztrátornak > tesztelőknek)
  • mekkora problémát okoz (anyagi vagy reputációs kár a cégnek > nehezíti az életet, de nem állítja meg > nem okoz gondot, de javíthatná a terméket)
  • mekkora eséllyel, milyen gyakran fordul elő (élesben is jó eséllyel bekövetkezik > kicsi az előfordulás esélye > speciális esetben fordul elő)

Mert mindenki azt hiszi, hogy ha a mezőket alapszinten kitöltötte, az már elég, abból már mindenki másnak is értenie kell, hogy milyen súlyos problémát fedeztünk itt fel. A valóságban viszont mindenki más ellenérdekelt abban, hogy hibákat fedezzünk fel a termékben és azok javításával időt, energiát töltsünk. Éppen ezért, ha mégis el rá akarjuk venni a csapatot a hiba javítására,  érdemes alaposan megindokolni, miért jelent ez a dolog problémát, miért lenne fontos mégiscsak kijavítani.

A legnagyobb mítosz: a tesztelés automatizálása

Az egyik leggyakoribb buzzword vezetői oldalról: automatizáljuk a tesztelést! Mindig, mindenhol hallani ezt, teljesen függetlenül attól, hogy a tesztelési kultúra milyen érettségi szinten van a szervezetben, és hogy technikailag mit lehetne egyáltalán automatizálni.

Kezdjük az alapokkal: mit várunk el a teszteléstől? Még az élesítés előtt vizsgáljuk meg a terméket, találjuk meg a hibákat, csökkentsük az élesítéssel járó kockázatokat. Mit lehet ezen automatizálni?

A tesztelés automatizálásának két szituációban van értelme. Az első a regressziós tesztelés: a rendszeresen, ugyanúgy megismételt tesztelési feladatok. Ezeket manuálisan végrehajtani unalmas, nagyobb a hibalehetőség, illetve a manuális tesztelés lassú, automatizálva gyorsabban, több tesztet lehet lefuttatni.

A probléma, hogy a változásokat és a fejlesztéseket az automata eszköznek egyesével be kell programozni – ez viszont csak lassan megy, tehát adott funkció leteszteléséhez az automata tesztelőnek sokkal több idő kell, mint a manuális tesztelő kollégáknak. Az agilis módszertani elképzeléseknek általában része, hogy az adott sprintben az új fejlesztésekhez tartozó automata tesztek is készüljenek el, de én még soha, sehol nem láttam, hogy ez ténylegesen megtörtént volna, az automata tesztelés általában hónapokkal lemaradva követi csak a fejlesztéseket.

Tisztában kell lenni továbbá a Pesticide paradoxon nevű alapelvvel: ha ugyanazokat a teszteket ismételjük újra és újra, végül ezek a tesztek már nem fognak új hibákat találni. Ezért a teszteseteket rendszeresen felül kell vizsgálni, karbantartani, új teszteket kell hozzáadni, hogy az automata hibákat találjon. A regressziós tesztelést hosszútávon érdemes automatizálni.

A másik szituáció, ahol az automatizálás hasznos lehet a load test, a terhelés szimulálása. Például ha manuális tesztelőből nem tudunk annyit felsorakoztatni, amennyien a végfelhasználók lesznek – a számítógép viszont szimulálni tudja ezt a helyzetet, ahogy a hosszan tartó, folyamatos terhelést és sok más nehezítést is.

Kik azok a tesztautomatizálók? Az automata eszközök programozásához programozói tudás kell. Az automata tesztelők ezért a fejlesztők/tesztelők tengelyén a fejlesztőkhöz állnak közelebb, gyakran fejlesztők specializálódnak automata tesztelésre. Mivel a fejlesztők többet keresnek a tesztelőknél, a „tesztelés automatizálása” viszonylag drága mutatvány, mármint ha a cél simán csak a manuális tesztelők kiváltása.

Hogyan mérhető, hogy megéri-e? Minden automata tesztelő előszeretettel hivatkozik a lefuttatott tesztesetek számára. Száz, ezer, tízezer API hívást indítottunk, jó alaposan leteszteltük tehát a rendszert. Valóban?

Szerintem mindenféle tesztelés értelmét és eredményességét végső soron a riportolt, majd kijavított hibák száma mutatja meg – ennyivel fejlődött ugyanis a szoftver a tesztelő tevékenysége nyomán. Ha egy automata tesztelő évek óta dolgozik a csapattal, de soha, egyetlen hibát sem riportolt (megtörtént), ott el kellene gondolkozni, hogy valóban megérte-e a tesztelés automatizálása…

Priority, Severity – mit jelent ez egyáltalán és hogyan kellene a bugokat helyesen priorizálni

Az a helyzet, hogy mindenki gondol erről valamit – de mindenki valami mást.

Minden teszt adminisztrációs rendszerben van a bugokhoz legalább két mező, általában Priority és Severity néven, amelyekkel elméletileg a hiba súlyosságát, a javítás sürgősségét, valamint az okozott kár nagyságát lehet jelölni. Minden cégnél, minden csapatban van valamilyen definíció arra, hogy ezeknek az értékei, és az értékek kombinációi mit jelentenek: azonnal kell a javítás, sürgősen javítani kell, nagyon fontos, kevésbé sürgős stb.

Ezek a definíciók azonban kissé homályosak, egy idő után összefolyik, hogy a Major és a Critical között mi a különbség. Pontosabban, tapasztalatom szerint mindenki pontosan tudja, hogy mi jelentenek – de mindenki másképp…

A hibát ott követjük el, hogy a definíciókat a saját szempontunkból írjuk meg. Ehelyett arra kellene gondolni, ami a fejlesztők oldalán történik:

  1. Dobjanak el mindent azonnal, javítsák ki a hibát és küldjenek hotfixet
  2. Vegyék előre a hiba javítását, és már a következő sprintben, következő buildben szállítsák is le
  3. Később is ráér a hiba javítása, de az élesítésig legyen készen
  4. A hibával az éles működés során is együtt tudunk élni

A fenti besorolásokat nevezzük el például úgy, hogy Blocking, Critical, Major, Minor, és a szerződésbe írjuk le a vonatkozó határidőket (pl. két munkanap / következő sprint / élesítés dátuma) és kész is vagyunk. Minden más (pl. a Severity mező használata) csak felesleges bonyolítása a csapat életének.

Nizza és Monte Carlo

Ez az út Noémi karácsonyi ajándéka volt, már amennyire egy családi út egyvalaki ajándéka lehet. Péntektől hétfőig tartott, a WizzAir menetrendhez igazodva. Nizzában január közepén is 10-15 fok körüli hőmérséklet van, néhány napos feltöltődés az itthoni szürke, nyirkos, hideg időből.

Nizza

A nizzai repülőteret a tengerre építették: a repülőgépből pont úgy nézett ki, mintha a tengerre szállnánk le, csak az utolsó pillanatban került alánk beton.

A városba villamossal jutottunk el, amihez az applikáció pont úgy működik, ahogy 2025-ben elvártam: QR-kód volt hozzá a falon, pillanatok alatt letöltődött az app, amiben pillanatok alatt meg tudtam venni négy jegyet, és a villamoson azonnal sikerült azokat érvényesíteni.

Az első délután elsétáltunk a Mont Boronra, ami elvileg alacsonyabb, mint a Gellért-hegy, de a tüdőnket is kiköptük, mire felértünk (a Gellért-hegyen nem szoktuk kiköpni). A kilátás viszont nagyon szép:

Nizza látképe a Mont Bolonról

Másnap az óvárosban sétáltunk, megnéztük a Cimetière du Château nevű temetőt, benne Gaston Leroux, Az operaház fantomja szerzőjének sírjával. A Colline du Château és a Bellanda Tower egy-egy újabb kilátópont a városra, a Marché Aux Fleurs pedig egy piac, amit mindenhol a nevezetességek között említenek, de semmi különös nem volt benne.

Délután a tengerparton sétáltunk, majd megnéztük a Musée des Beaux-Arts de Nice-t, ahol nekem Rodin: A csók című szobrának gipsz változata tetszett legjobban. Szüleim lakásában kint volt egy fénykép az eredeti szoborról, egész gyerekkoromban szem előtt volt, úgyhogy érdekes volt végre szobor formában is látni. Tetszett még a XX. század elején, a Riviérán alkotó nők alkotásai közül Julie de Cistello: Az almafák alatt című festménye is.

Julie de Cistello: Az almafák alatt

Monte Carlo

Már az út tervezése közben éreztem, hogy Nizzában nem tudunk mit csinálni két napig. Egy blogban lett meg a megoldás: Monte Carlo, ami vonattal 20 perc alatt kényelmesen elérhető Nizzából. Ezeket láttuk:

  • Jardins de la Petite Afrique – egy park a város közepén, amitől Zsófi és Noémi is rögtön ide akart költözni…
  • Fairmont Hairpin – a híres hajtű kanyar a Forma-1-ből
  • Princess Grace Japanese Garden – nagyon szép hely, bár a zuglói Japánkert is van ilyen szép
  • kaszinó – délelőtt turistaként is be lehet menni belépőért. Elegáns és érdekes hely, legalábbis nekem, mert én még sosem jártam kaszinóban, itthon se, nem hogy Monte Carloban…

Az egyetlen komoly problémánk az volt, hogy hol és mit együnk, erre nem gondoltunk előre. Már csak azért sem, mert eddig bárhol jártunk Európában, mindenhol voltak büfék, megfizethető kis éttermek, gyorséttermek, a kajálás sehol sem okozott gondot. Monte Carloban viszont a Gucci, Valentino, Hermes üzletek melletti elegáns éttermekre nekünk nem futotta… Végül a palotanegyed hátsó sarkánál találtunk egy pizzériát, ahol megettük életünk legdrágább három pizzáját… Ha nem vagy extrém gazdag, Monacoba érdemes szendviccsel készülni.

Délután a hercegi palotánál sétáltunk, aztán a Bateu busszal átkeltünk az öböl másik oldalára. Ez egy jópofa dolog: a Port Hercule egy híres öböl Monaco közepén (ekörül halad a Forma-1-es futam is), tele van luxus jachtokkal. A Bateu bus itt jár oda-vissza az öböl két partja között. Ha például a hercegi palotából átmennél a kaszinóba, de elromlott a Ferrarid és nincs kedved körbesétálni, 2 euróért átvisznek…

A tesztelés adminisztrációjához miért nem elég az Excel?

Röviden: a bugok miatt.

Hosszabban: a tesztesetek megírására és az eredmények (Passed/Failed) rögzítésére bőven elegendő az Excel. Sőt, az Excel tűnik az ideális megoldásnak: kell néhány oszlop (Chapter, Steps to reproduce, Expected result, Actual result, Notes), és lehet is írni a teszteseteket egymás alá. Az Excel erre tökéletes, volt, ahol még akkor is Excelben írtuk meg a teszteket, ha volt erre bevezetett, specializált eszköz – megírtuk Excelben, aztán betöltöttük őket a rendszerbe.

A probléma a hibáknál kezdődik, amiket riportolni akarunk. Eleve túl sok mező kell egy hibajegy leírásához: ID, title, description, environment, reported by, assigned to, priority, status, comments – és ez csak egy elméleti minimum. Nem fér el szépen se vízszintesen, se függőlegesen. És további problémák is felmerülnek majd, ha mégis Excelt akarsz használni:

  • description: nehéz szép, formázott folyószöveget írni Excelben. El kell férjen a probléma alapvető bemutatása, az indoklás, hogy ez miért probléma, elvárt és aktuális eredmény, workaround – nem egy tipikus Excel cella tartalma
  • attachments: ezt nem is tudod Excelben megoldani (vagy csak nagyon rondán)
  • értesítések: minden teszt admin toolban beállítható, hogy a kiválasztott bugok körében minden változtatásról e-mail értesítést kapj. Bárki bármit matat: tudni fogsz róla. Excelben ez nincs, így észre sem veszed, ha valaki pl. az egyetértésed nélkül megváltoztatja a bugod prioritását (megtörtént) vagy lezárja a hibádat (megtörtént)
  • kommentek: sok hasznos információt, kontextust nyújtanak a kollégák által beírt kommentek. Például: nálam is reprodukálható a hiba, másnál viszont nem, kell-e javítani egyáltalán és hogyan, lezártam ilyen és ilyen okból… Számtalan téma felmerülhet egy bug kapcsán, amit egy kommentfolyamban kényelmesen meg lehet beszélni – Excelben ez szintén lehetséges, de ronda lenne
  • history: amiből látszik, hogy hogy milyen változtatások történtek a bugban, tipikusan: ki és miért módosította a prioritását és a státuszát. Excelben ez az információ elvész (vagy csak bonyolultan elérhető a SharePoint history-n keresztül)

A professzionális teszt adminisztrációs eszközök sok más hasznos funkciót is nyújtanak még: kapcsolatot a specifikációval, Jirával, automatizáló eszközzel, kényelmesen lekérhető riportokat, szabályozható felhasználói jogokat… De ezek nélkül még elkezdhető a tesztelés akár Excelben is – a hibajegyek kulturált kezelése viszont már nem.

Sziluett fotóim az AKH nagytermében

Már korábban egyeztettük, hogy az AKH-ban egy ideig a kávézóban és a nagyteremben egyszerre lehetnének kint fotóim. Ehhez nem volt elég keretem, ezért rendeltem még tízet az IKEA-ból. A kiszállítást DPD-vel kértem egy közeli automatába – ez hiba volt. Karácsony előtt jártunk, a DPD-t nyilván elhavazták az ajándékok, semmi gond. A gond az volt, hogy a csomagot szilveszterre sem hozták ki, aztán január első hetében sem… Információ nincs, telefonon nem érhetőek el, üzenetre nem válaszolnak. A csomagot a DPD végül visszaküldte az IKEA-nak és az elvileg visszafizeti a pénzt – de erről se a DPD, se az IKEA nem kommunikált velem.

Többet nem fogok DPD-vel való kiszállítást kérni.

Az AKH-ban az eredeti terv az volt, hogy koncertek reflektoros fényözönét bemutató képek a sziluettekkel felváltva lesznek kint – fény és árnyék váltakozva. De ehhez nem volt elég keret, így maradtak csak a sziluettek – így se rossz egyébként, legalább egységes a koncepció.

A kiállítás szokás szerint az Albertfalvi Közösségi Ház nagytermében látható, ingyen, de csak nyilvántartási időben, várhatóan február végéig.

Follow the Flow sziluett

 

 

A legnagyobb tévedés: a kimerítő tesztelés lehetősége

A tesztelés hét alapelvéből az első: kimerítő tesztelés nem lehetséges. Ennek ellenére jaj, hányszor hallottam: ezt most nagyon alaposan teszteljétek le, és ha bármilyen hiba van benne, azt találjátok meg!

Nagyon vicces volt, hányféle szinonimát találtak a kollégák a „kimerítő” szóra:

  • kívülről-belülről teszteljétek le
  • teszteljétek szét
  • tüzetesen fésüljétek át
  • teszteljétek szénné

Elméletben persze érdekes eljátszani a gondolattal, hogy például egy adott szoftver modul kimerítő tesztelése mit jelentene:

  • minden lehetséges input adatot (minden lehetséges ekvivalens input adatot),
  • minden lehetséges futtatási opciót (összes gomb, összes menüpont, összes opció kipróbálása)
  • minden lehetséges futás közbeni beavatkozási módot (gombok nyomogatása, egér kattintás, környezet módosítása)
  • ezeket az összes lehetséges sorrendben
    • leírni
    • lefuttatni

Végtelen ideig tartana vagy végtelen erőforrást igénybe véve lehetne megvalósítani. Hétfőre kell? Nem probléma!

A valóságban pedig nyilván adott már az ún. regressziós teszt set, amit adott idő alatt le lehet futtatni. Hibákat találni pedig a kollégák tapasztalata, és az új fejlesztésekről megismert információk függvényében lehet. Szerintem a fejlesztő kollégák se örülnének, ha belátható időn belül minden hibát megtalálnánk…

Évértékelés, 2024.

Kényelmes évünk volt a közös home office-nak köszönhetően: Noémi hetente egyszer, én kb. havonta egyszer megyek be az irodába. Így sokat lehetünk itthon, nincs tömegközlekedés, valamint iskola előtt és után is találkozunk a csajokkal.

Az év elején lebonyolítottunk egy lakásfelújítást, mondjuk az pont nem volt kényelmes, viszont mindkét lánynak saját szobája lett, ahová el tudnak vonulni kamaszodni, akár a barátaikkal együtt. Persze mi is élvezzük a felújított lakást, az új bútorokat, és hogy kisebb a zsúfoltság.

Tavasszal tíz alkalmas rocky tanfolyamra mentünk, aminek a megkoronázása volt, hogy júniusban a Hungária élő koncertjén tudtunk bulizni a Puskásban. Ősztől újra jártunk salsázni, és voltunk három salsa táborban is.

Zsófit felvették az első helyen megjelölt gimnáziumba, Dóri pedig felső tagozatos lett, most mindkettejüknek mást és többet kell tanulni. A rocky-t azért mindketten aktívan űzik tovább, edzések, táborok, versenyek és fellépések váltják egymást. A versenyeken korábban Zsófi volt eredményesebb, ez idén megfordult és Dóri nyert szinte mindenhol, szólóban és Martinnal párosban is.

Utaztunk a csajokkal Máltára és nyaraltunk a Velencei-tónál, kettesben voltunk Siófokon és Koppenhágában. Voltunk több, mint húsz koncerten, amelyek közül a már említett Hungária, valamint az ABBA Tribute, a NOX és a Visions of Atlantis volt kiemelkedő. Színházban a motel.com, moziban a Futni mentem voltak a legjobbak.

Elolvastam huszonvalahány könyvet, a legjobb David Yarrow fotós módszertana volt, illetve a Hivatásos rajongó Gálvölgyivel. Rengeteget játszottam Valheimet és még benne vagyok a Lost újranézésben a Netflixen. Társasjátékoztunk itthon és vendégségben – a Ticket to ride-dal mindenképpen szeretnék még játszani ezután is. Eljutottunk DJ Alan egyik bulijába és Madame Tussauds budapesti panoptikumába.

Voltak és lesznek is fotóim kiállítva az AKH-ban és az Üllői úti könyvtárban. Ez is szinte rutinná vált, egyik sorozat a másik után két helyszínen, pedig kivételes lehetőség és megtiszteltetés.

Úgyhogy megvagyunk mi is, a család is, sose legyen rosszabb évünk. Egészségetekre:

Ananászból iszok szívószállal a máltai Blue Lagoonnál