Mihai Balan

European Testing Conference 2016

The wall @ Euro Testing Conference 2016

TL;DR: 11-12 februarie 2016, Radisson Blu București. 4 keynotes, prezentări și workshop-uri pe 3 track-uri. Testeri și developeri din Europa, US, Australia. Lean coffe. Open space. Awesome. 2017 @ Helsinki.

Mai pe larg

Pe 11 și 12 februarie 2016 am participat, împreună cu mai mulți colegi din Adobe România, la prima ediție a European Testing Conference. O să încep prin a spune că a fost una din cele mai faine conferințe la care am participat în ultima vreme – atât din punct de vedere al prezentărilor cât și al participanților la conferință. Am văzut prezentări faine, am întâlnit oameni pasionați de testare și am plecat cu câteva idei bune.

În cele ce urmează o să fac o scurtă trecere în revistă a lucrurilor pe care le-am văzut și mi s-au părut interesante, a lucrurilor pe care nu le-am văzut dar de care mi-au povestit alții, a celor pe care nu le-am văzut dar, post-factum, mi-aș fi dorit să le văd și a ideilor furate sau doar puse într-o lumină nouă din discuțiile cu ceilalți participanți la conferință. Această trecere în revistă nu ar fi fost posibilă fără notițele Oanei Goanță și insight-urile, rafinate la berea de după conferință și în 1:1-uri, ale lui Andrei Jucan.

Organizatorice

Din punctul meu de vedere, conferința a început cu dreptul cu câteva zile înainte de debutul oficial, o dată cu crearea unui grup pe Slack în care toți participanții au fost invitați (de ce îmi place Slack, în altă postare). Mi s-a părut un lucru fain, atât pentru că a existat un mediu realtime în care puteai pune o întrebare sau rezolva o problemă cât și pentru că era un mod oarecum centralizat de a purta conversații pe marginea conferinței. De asemenea, grupul de Slack a fost folosit și după încheierea conferinței pentru schimb de insights și resurse, legate direct sau indirect de sesiunile din timpul conferinței. Tot legat de lucruri care s-au întâmplat după conferință, slide-urile de la prezentări, inclusiv keynote-uri, sunt publice, și se lucrează la publicarea înregistrărilor video la prezentările care au fost înregistrate ca și înregistrările lor.

Conferința a avut un format similar în cele două zile – fiecare zi a început și s-a terminat cu un keynote; sesiuni (workshop-uri, prezentări) pe 3 track-uri paralele până în prânz; „activități de grup”, după prânz. În prima zi a fost vorba de un Massively Offline Lean Coffee :), facilitat de organizatori. „Activitățile de grup” din a doua zi au constat într-un open space în care oricine putea propune o temă de workshop/prezentare/discuție și apoi să o livreze celor interesați.

Din punct de vedere al organizării, totul a mers foarte lin, fără să fie în vreun fel evident sau intruziv: oameni prietenoși la standurile sponsorilor, voluntari activi și interesați de ce se discuta, goodies exact cât trebuie :) Singurul lucru pe care l-aș avea de reproșat ar fi poate pauzele de cafea socializare care au fost cam scurte, mai ales că sălile în care s-au desfășurat sesiunile erau mai departe de holul mare în care se aduna lumea între sesiuni.

Ce am văzut

The Agile Mindset

Conferința a început în forță cu keynote-ul Lindei Rising, The Agile Mindset. Până a discuta despre keynote, e necesară o foarte scurtă precizare biografică: de formație biochimistă, Linda Rising și-a luat doctoratul în computer science la vârsta de 50 de ani; asta se întâmpla acum 24 de ani. Sau, în cuvintele ei, «she's ancient» :) Cu ceva din experiența de viață și tonul sfătos al unui bunic, Linda a povestit despre cum mindset-ul în care funcționăm ne influențează acțiunile și atitudinile sau cum lucruri aparent mărunte te pot îndrepta spre un mindset sau altul.

Dincolo de ideile pe care le-am auzit de multe ori, sub diverse forme, de «embracing challenge» sau «learning from failure», mi s-a părut interesantă și ideea că mindset-ul nu este ceva ce caracterizează doar un individ, ci este ceva ce poate caracteriza o echipă, o familie, o organizație sau chiar o țară. Și că sunt oameni care-și propun să schimbe mindset-ul unei țări. Mai mult decât o prezentare despre sau pentru software craftsmanship (ăsta pare a fi termenul la modă), keynote-ul Lindei mi-a dat de gândit și ca lecție de viață – de la felul în care a început, îndemnându-ne să ducem mai departe prezentarea asta, pe care nu și-a pus niciun copyright, până la diversele moduri în care tipul de mindset afectează inclusiv relațiile de zi cu zi, nu doar în mediul profesional. Iar îndemnul de la final, m-a cucerit: «Don't let anyone tell you you're too old, too young, too Romanian to do something» :)

Testing versus Checking

Am participat apoi la prezentarea lui Richard Bradshaw – Testing versus Checking. Deși la început mi s-a părut un pic pedantă diferențierea între checking și testing (poate și din cauza exemplului cam in your face), până la urmă, dincolo de confortul lingvistic, cred că diferențierea e necesară, măcar de ținut minte și reconsiderat din când în când. În contextul prezentat de Richard, testing este activitatea creativă, de învățare și de adunare de informații despre sistemul testat, în timp ce checking se referă la abordarea algoritmică, rigidă, al cărui rezultat este doar un PASS/FAIL, indiferent că vorbim de testare automată sau manuală. Practic, chiar în fraza anterioară eu am „supraîncărcat” termenul – ideea e că nu poți face verificări și să le automatizezi, fără să fi făcut în prealabil partea de testare și învățare asociată.

În sensul ăsta, toată lumea testează în permanență - de la developer-ul care vrea doar să vadă dacă bucata de cod pe care tocmai a scris-o merge, până la testerul care încearcă mai multe tipuri de date invalide până se decide pe care să îl folosească în verificările automate.

Dincolo de discuțiile de semantică, mi s-a părut interesantă și ideea că testerii sunt mai degrabă cei care colectează și codifică informația (despre sistem, utilizatori, etc.) decât „gardieni” (gatekeepers) ai calității unui produs software.

Alte idei mai punctuale care mi s-au părut interesant de ținut minte ar fi:

Testing with Code Seams

Testing with Code Seams a fost un workshop de white-box testing ținut de un developer, Llewllyn Falco. Totul a pornit de la întrebarea „cum putem «trișa» ca să scriem teste mai rapide și/sau mai robuste?”, având access la detalii interne de funcționare a sistemului sau chiar la codul sursă. Primul exemplu a fost testarea funcției Update profile din gitHub: dacă în prima iterație testul trecea prin 3 pagini, testul final verifica direct API-ul de actualizare a profilului – după o versiune intermediară cu ID-uri adăugate în markup-ul paginii pentru a face găsirea elementelor mai robustă.

Exemplul următor, care a fost codat live cu voluntari din audiență în sistem mob coding (despre asta, imediat), presupunea testarea unui generator de nume de entități într-o aplicație desktop Java. În acest caz, a fost nevoie de mai mult coding pentru a extrage funcționalitatea testată din codul de UI și pentru a-l aduce la o formă (cât de cât) funcțională (ca antonim al lui imperativă). Una din ideile centrale ale exercițiului a fost că un cod scris de manieră funcțională (fără side-effects) este semnificativ mai ușor de testat, mai ales cu unit-teste. Iar în momentul în care codul are side-effects sau este strâns cuplat, există câteva trucuri prin care poate fi modificat în așa fel încât să fie adus mai aproape de aceste deziderate.

Nu în ultimul rând, tot aici a apărut o idee pe cât de simplă și poate chiar evidentă, pe atât de utilă: mai ales în etapa inițială de explorare, e util să faci schimbări foarte evidente (fonturi enorme, fundaluri roz, etc.) sau să folosești date de test foarte vizibile pentru a detecta ușor fluxul datelor prin aplicație.

Ce este mobbing?

Mobbing, de cele mai multe ori sub formă de mob coding, sau mob testing, este un tip de extreme programming, care presupune ca o echipă de N persoane să lucreze la un moment dat la un singur calculator. La orice moment există un driver și N - 1 navigatori: driver-ul este cel care stă la calculator și scrie doar ce i se spune de către navigatori. La un interval de timp stabilit de comun acord (de obicei 15 minute), se schimbă driverul și se continuă procesul.

În cadru conferinței au fost mai multe workshop-uri care au folosit mobbing-ul, cu echipe variind între 5 și 25 de oameni.

Truth – The state of not yet proven false

Dacă Richard Bradshaw a menționat doar în treacăt intentional blindness ca unul din trucurile pe care ni le joacă mintea în timp ce testăm, prezentarea lui Abby Bangser a intrat în mai multe detalii despre scopul testării cât și tehnici de eficientizare e ei.

Ca misiune a testerului, Abby a punctat două aspecte: găsirea fisurilor logice și eliminarea detaliilor irelevante pentru a face lucrurile importante vizibile. În ceea ce privește testarea ca efort cognitiv, următoarele idei mi s-au părut demne de ținut minte:

O ultimă idee care mi s-a părut interesantă, mai ales în contextul propriei mele experiențe, a fost folosirea sesiunilor de onboarding – formale sau nu – ca ocazie de a discuta lucruri legate de contextul proiectului, de „folclor” și de a readuce în discuție felul în care sunt făcute lucrurile.

Lean coffee

Ce este lean coffee?

Lean Coffee este o formă de organizare a discuțiilor pe teme propuse de participanți. O dată propuse temele se face o grupare/eliminare a duplicatelor, apoi fiecare participant are un numar fix de voturi pe care îl poate folosi pentru a desemna temele sale de interes. O dată votate temele de discuție se începe cu tema care a strâns cele mai multe voturi: dacă mai este nevoie, cel care a propus-o detaliază mai exact tema și scopul ei (ex. idei de abordare, soluții existente, schimb de idei) iar în următoarele N minute (de obicei 5-8) se poartă discuția efectivă. La finalul timpului alocat, participanții votează cu thumbs up / meh / thumbs down prelungirea sau nu a discuției cu încă N minute. În momentul în care o discuție nu mai este prelungită se trece la următoarea temă.

Ce am discutat

În cazul nostru, ne-am împărțit în grupuri de 5-6 persoane, iar temele propuse au fost dintre cele mai diverse. Discuțiile au cuprins:

How to keeping testing fresh while testing APIs?

Totul a pornit de la rutina care apare atunci când ai de testat API-uri REST pentru care clasele de teste sunt cam mereu aceleași, iar părțile interesante și diferite de la API la API sunt destul de puține. A fost sugerată o abordare model based testing pentru a face testele mai ușor de structurat și pentru găsirea unor teste de integrare care nu sunt evidente la prima vedere.

Getting developers fired

Deși titlul inițial era foarte generic și un pic scary, discuția avea în vedere un caz foarte concret: ce faci atunci când în echipă există un developer care nu lucrează deloc cu ceilalți și produce cod de calitate foarte proastă care mai nou însă face parte dintr-o componentă critică a sistemului. Iar tu ca tester ești cel căruia îi revine sarcina ingrată de-a pleda cu managementul pentru concedierea lui pentru că toate celelalte „căi de apel” au eșuat – deși „neoficial” cam toți din echipă s-ar lipsi de prezența lui.

Sugestiile s-au învârtit în jurul ideii de-a face decizia asta să fie cât mai mult una a echipei și nu a unui individ anume, dar nu mai țin minte detaliile. Știu doar că am fost recunoscător că până acum nu mi-a fost dat să am parte de astfel de interacțiuni/colegi :)

What to do when you run out of test ideas

O întrebare care mi s-a părut interesantă pentru că putea fi atacată din multe unghiuri a fost ce să faci atunci când pare că ai epuizat toate tipurile de testare și toate ideile de teste. S-a discutat despre model based testing, fuzz testing, diverse euristici de testare exploratorie, pair și mob testing ca și metode de-a lua o gură de aer proaspăt.

Solutions for cross browser test automation

Întrebarea asta a fost pentru mine un „Aha moment” – mă așteptam să fie vorba despre cine știe ce scenariu super complicat pe care tool-uri ca Browserstack să nu le acopere. S-a dovedit că lucruri care mie mi se păreau comune și cunoscute să nu fie nici pe departe atât de cunoscute. Pe scurt, dacă aveți nevoie să rulați teste automate în mai multe browsere, folosiți cu încredere Browserstack, SauceLabs sau servicii similare.

Dark Patterns – A Tester' Quandary

Prezentarea Emmei Keaveny, Dark Patterns – A Tester' Quandary a fost una oarecum la limita dintre UX și testing, atingând însă inclusiv aspecte de etică și legalitate. Unul din aspectele menționate a fost diferențierea între dark patterns – al căror scop este „păcălirea” utilizatorului prin enervare sau abaterea atenției și anti-patterns – idei care par bune în teorie dar care în practică se dovedesc suboptime sau chiar păguboase.

În acest context, „păcălirea” utilizatorilor poate merge de la a-i face să instaleze un software pe care nu-l vor până la a trimite invitații prin SMS la toată agenda sau a plăti mai mult pentru niște servicii extra. Exemplul cel mai uluitor mi s-a părut cel cu site-ul Ryan Air (între timp actualizat) în care pentru a nu cumpăra asigurare de călătorie, trebuia să cauți și să găsești țara numită Don't insure me în rubrica Country of residence.

Emma a prezentat o serie de euristici de detectare a dark patterns și moduri de abordare a lor în momentul în care, ca tester, te lovești de un astfel de dark pattern.

Pentru mine personal prezentarea a fost interesantă și prin prisma faptului că Flash Player a fost un exemplu popular de dark pattern din cauza antivirusului McAffee care se oferă implicit să se instaleze o dată cu Flash Player. Fiind oarecum în „tabăra inamică” în cazul ăsta m-a făcut să mă gândesc mai bine care pot fi argumentele aduse pentru un folosirea unui dark pattern și în ce măsură așa ceva este justificabil în contextul mai mare al unei platforme existente.

Learning in Layers

Pentru cei care nu mă cunosc, un mic disclaimer: sunt un mare fan mind maps. Astfel că prezentarea Learning in Layers a lui Maaret Pyhäjärvi a fost destul de sus pe listă de când am aflat că va fi cu/despre mind maps.

Prezentarea în sine a fost mai degrabă un demo de folosire a mind mapping-ului ca instrument de documentare a testării și structurare a ideilor pe măsură ce testezi. Mi s-a părut un unghi interesant, pentru că eu până acum nu am folosit mind maps decât ca să îmi planific în avans testarea și eventual să urmăresc progresul pe un astfel de test plan schițat într-un mind map.

A mob for Selenium WebDriver tests

Descrierea inițială a workshop-ului era ceva care aducea mai mult a Writing better Selenium WebDriver tests, astfel că am intrat în sală cu așteptări mari și mult entuziasm. Când am aflat că de fapt va fi un workshop întreg de mob coding m-am mai temperat însă. Ideea în sine cred că era bună, dar cumva, un mob cu 25 de oameni, pe un Mac, cu tastatura în suedeză nu cred că a fost cea mai reușită implementare. Dacă ar trebui să aleg in nou probabil că m-aș orienta spre alt workshop, deși discuția cu Richard de după workshop a fost foarte utilă.

Exercițiul viza scrierea de teste folosind WebDriver pentru o mini-aplicație web compusă din câteva pagini independente. Planul era să ajungem să folosim inclusiv Selenium Page Objects, dar lucrurile au mers mult mai lent, după cum spuneam.

Testing Responsive Websites

Prezentarea Testing Responsive Websites ținută de Gita Malinovska a fost cam în părți egale informare și invitație la discuție – despre tool-uri, servicii și modalități de testare a website-urilor responsive. Pentru oricine a mai dezvoltat și testat aplicații web pe mobile, lucrurile menționate de Gita țin oarecum de un bun-simț ingineresc:

Open space

În Open space organizatorii au pus la dispoziția oricui vroia să țină prezentări, workshop-uri sau simple discuții, mai multe săli, cu whiteboard sau proiector, slotul de timp alocat implicit fiind de jumătate de oră. Apoi participanții care au dorit să țină prezentările în open space și-au prezentat ideile, apoi s-a negociat planificarea lor, în așa fel încât toți doritorii să poată ajunge la un număr maxim de prezentări.

Eu am participat la două prezentări și am ținut încă una, detaliate mai jos:

Most basic intro to programming for manual testers

Am participat la prezentarea asta mai mult din curiozitate și din dorința de-a face ceva foarte diferit. Eram curios să văd cum ar arăta un crash-course de programare, de jumătate de oră, pentru oameni familiari cu calculatoarele dar care nu au mai programat niciodată. Audiența a fost destul de mică – vreo 3-4 persoane plus Peter Kofler care a ținut prezentarea.

Peter a plecat de la premisa că orice bucată de cod este formalizarea unei soluții găsite deja, la o problemă clar definită. Am discutat apoi structurile prezente în cam orice limbaj de programare imperativ: blocuri, condiții, bucle, proceduri, variabile. Iar pentru că un exemplu face cât 100 de explicații, totul a fost discutat pe marginea problemei (aparent simple), cum pregătești micul dejun :)

Test Data as a Service

Cu Test Data as a Service am avut mai multe lucruri în vedere. În primul rând am prezentat arhitectura microserviciului (implementat de colegii mei) de generare de date de test pentru diversele suite rulate pe mediile de continuous integration și nu numai. Apoi eram curios dacă au încercat și alții o astfel de abordare pentru managementul datelor de test, ce probleme au avut sau ce sugestii de îmbunatățire pot oferi.

Discuția în sine a fost destul de interesantă, dar impresia mea a fost că ce am încercat noi să rezolvăm cu acest microserviciu nu era o problemă reală de care să se fi izbit și alții.

Presentation Karaoke

Conceptul de Presentation Karaoke este destul de simplu: se alege un voluntar, care trage la sorți un titlu de prezentare dintr-o listă propusă de participanți. Voluntarul trebuie să țină apoi o prezentare pe baza titlului tras la sorți și a 5 slide-uri aleatorii, pe care nu le-a mai văzut vreodată. E un mod interesant de a destinde atmosfera, dar și de a-ți exersa skill-urile de improvizație.

Un mic utilitar pentru Presentation Karaoke puteți găsi aici – conține inclusiv link la o colecție de slide-uri care pot fi folosite.

Software Craftsmanship and Testing: why SoCraTes is right

Eric Talboom a încheiat conferința cu un keynote despre importanța testării și a testerilor, spusă prin prisma propriei experiențe. Eric a povestit despre cum a trecut de la ostilitate față de testeri la a face un curs de testare și a promova importanța testerilor într-o echipă și includerea testării ca parte integrantă în procesul de software development (sau software craftsmanship). Prezentarea mi-a plăcut mult atât datorită stilului de prezentare – având ceva dintr-o poveste de viață spusă la un pahar de vin – cât și multitudinii de situații reale, multe dintre ele bune exemple de a face haz de necaz.

Ce n-am văzut eu, dar au văzut alții

În Testing in a continuous delivery world, Wouter Lagerweij a povestit despre rolul pe care ar trebui să îl joace un tester în procese care folosesc continuous delivery. Ideea principală a fost că testerii ar trebui să fie implicați în toate fazele procesului de dezvoltare, unul din rolurile importante fiind acela de a detecta și umple golurile de comunicare sau informație dintre product owners, developeri, UX și operations. Același lucru l-am mai auzit și in prezentarea Testing versus Checking – testerii ar trebui să fie mai puțin gardieni (gatekeepers) ai calității unui produs și mai mult information collectors / codifiers, oameni care descoperă informație nouă despre produs, explicitează informații implicite și pot distribui aceste noi informații despre produs sau utilizatorii săi în cadrul echipei.

În Symbiosis of Mobile Analytics and Software Testing, Julian Harty a explicat moduri de folosire a analytics și feedback-ului de la utilizatori atât pentru a crea o experiență mai bună pentru aceștia, dar și pentru a ghida testarea – prin prisma problemelor cele mai des întâlnite, a celor mai neplăcute, sau a platformelor cele mai relevante pentru testare. Un alt lucru de notat ar fi faptul că toți participanții la conferință au primit de asemenea și un exemplar din cartea lui Julian The Mobile Analytics Playbook.

Mobing-ul a fost metoda de lucru preferată la multe din workshop-uri, ca și în cazul sesiunii Security Testing Hands-on as Mob Testing facilitată de Daniel Billing și Maaret Pyhäjärvi. Spre deosebire de celelalte sesiuni de mobing unde scopul era scrierea de cod, aici scopul era găsirea cât mai multor buguri de securitate într-o aplicație web, porning de la Top 10 vulnerabilități OWASP.

Un alt lucru interesant pentru o conferință declarată de testare, a fost prezența multor developeri, atât printre prezentatori cât și printre participanți. O astfel de prezentare ținută de un developer a fost și Developer experience to testing în care Claudia Roșu a povestit despre infrastructura pe care a creat-o pentru a o ajuta în automatizarea testelor în lipsa unui tester. În cazul ei a fost vorba de Jasmine, Spock și Geb.

Tot o prezentare despre test automation, dar de dată asta într-un context mai atipic, a fost cea a lui Ru Cîndrea – Dealing with device fragmentation in mobile games testing. Dacă pentru testarea aplicațiilor mobile în general există câteva tehnici și instrumente care pot reduce timpul sau cantitatea de teste, în cazul jocurilor pe mobil multe dintre ele nu se mai aplică, sau doar într-o mult mai mică măsură. Ru a explicat cum au creat un framework de testare automată bazat pe OpenCV – pentru recunoaștere de imagini, Appium – pentru instalarea aplicației și interacțiunea cu ea și TestNG și Testdroid Cloud pentru rularea în paralel a testelor pe mai multe dispozitive în paralel.

Cu cine am vorbit

Din punctul meu de vedere, o parte importantă a participării la conferințe – și pe care nu o pot suplini slide-urile sau înregistrările video publicate post-factum – sunt discuțiile live cu ceilalți participanți, fie ei speaker-i sau nu. Dintre multele discuții pe care le-am purtat în cele două zile de conferință două merită menționate aici.

Cu Richard Bradshaw am discutat mai pe larg despre WebDriver și câteva probleme de care m-am izbit în propriile mele teste. Printre lucrurile de ținut minte, pentru mine cel puțin, se numără:

Pe Linda Rising am abordat-o căutând o părere cu mai multă experiență de viață :) despre cum să ieși dintr-un mindset fixed, cum să depășești teama de eșec și cum să interacționezi cu cei din jur chiar când îți vine să-ți iei câmpii. Am discutat despre cum să împachetezi „Failure is an option” pentru management, și situații conflictuale, la muncă și acasă. În ceea ce privește situațiile conflictuale, Linda mi-a dat și un exemplu de „protocol” pe care ea și soțul ei îl îl folosesc în astfel de cazuri. În puține cuvinte, acest „protocol” sună așa:

No bad words.

Say nothing. Listen.

Don't argue about point of view

Only say what you see

Ce mi-aș fi dorit să văd / să fac

Mi-aș fi dorit să particip la prezentarea Christinei Ohanian despre creativitate și comunicare vizuală ca skill-uri și instrumente în testarea software. Nu regret că am fost la prezentarea lui Richard Bradshaw – pur și simplu eul meu artistic e foarte curios cum ar putea fi util în munca de testare de zi cu zi. Una din ideile prezentării, faptul că o imagine poate face cât o mie de cuvinte și porni discuții despre presupunerile făcute de membrii echipei, am verificat-o și eu pe propria piele, cu doar câteva zile în urmă.

Prezentarea Alexandrei Casapu era una din prezentările pe care aș fi vrut în mod expres să le văd, dar am reușit să încurc intervalele orare. Dincolo de exercițiul de black box testing (literalmente), discuția despre testing skills și cum să ți le descoperi / identifici / cultivi mi s-a părut foarte faină, cel puțin din spusele celor care au fost la prezentare. O altă idee pe care am mai auzit-o în cu totul și cu totul alt context – a-ți face un obicei din scurte retrospective zilnice, în care să pui pe hârtie ce ai făcut și ce ai fi putut face mai bine (și cum), e unul din lucrurile pe care chiar vreau să le încerc.

Sunt două keynote-uri despre care n-am povestit nimic. La finalul primei zile Anne-Marie Charrett a vorbit despre Test Management Revisited – lucru care nu prea m-a prins, poate și unde am prins prezentarea de pe la jumătate. Keynote-ul lui Chris Matts – We don't need testers! What we really need is testers! de la începutul celei de-a doua zile l-am ratat cu totul, dar chiar sunt curios să văd înregistrarea.

Nu în ultimul rând, mi-aș fi dorit să ajung la party-ul de după prima zi. De fapt, a fost prima oară când chiar m-aș fi dus la un party de conferință, dar din motive dependente de voința mea, până la urmă nu am mai ajuns.

Concluzii

Pe scurt, au fost două zile foarte cu folos investite și mi-aș dori să pot participa și la ediția de anul viitor, de la Helsinki.