Skip to main content

Auteur: Andre Boeters

Continuous Everything – najaarsevenement Testnet

Geschreven door Andre Boeters op . Gepost in Activiteiten.

 

Afgelopen woensdag bezochten we het testnet najaarsevent in Nieuwegein. Het thema was Continuous Everything, een verwijzing naar de richting waarin de IT sector zich ontwikkelt. Dit uit zich vooral in steeds korter wordende release cycles van software. Voor het testen betekent dat dit continue gedaan wordt. Immers, bij elke release wil men nog steeds weten of de functionaliteit nog werkt.

Naast onze belangstelling voor de nieuwste ontwikkelingen in ons vakgebied dreef ook een ander gegeven ons naar dit evenement: onze collega’s Erik Bits en Tobias Verhoog stonden op het podium met een allegorie over de overgang van de sequentiële wereld naar agile testing. Zo kregen we de mogelijkheid om vast te stellen of Tobias en Erik de “Ars Dicendi” ook zouden beheersen buiten de veilige contouren van ons 2B4QA kantoor.

Op mijn programma stond workshop waarin ik zou leren een Jenkins pipeline te maken. Jenkins is een platform waarop men aan continuous integration doet, vooral in combinatie met Git. Omdat ik al menig commitje en pull requestje heb gemaakt in Git maar geen idee had hoe dit samenwerkte met Jenkins, leek dit me een goede gelegenheid om daar eens wat inzicht in te verkrijgen. Nadat ik een bak pleur naar binnen had gewerkt om de nodige arbeidsvitamines te verkrijgen begon ik met mijn collega Sonny aan de cursus. Hoewel de cursus interessant was hadden we graag wat meer achtergrondinformatie gehad over de werking van continuous integration. Maar de procedurele kennis die we op hebben gedaan biedt ons voldoende basis om zelf eens een CI / CD pipeline op te zetten.

Na een stevige lunch begon het middagprogramma met een keynotespeaker die de relatie legde tussen het persoonlijke leven en werkleven in een CI / CD omgeving. Af en toe smeet hij daarbij ballen in het publiek waarvoor de reden me tot op de dag van vandaag nog steeds onduidelijk is. Na enkele bakken koffie en nog een presentatie over valkuilen bij de transitie naar continuous development, was eindelijk het moment aangebroken waar we voor komen: de presentatie van Tobias en Erik: “The Wizard of Oz.”

Hoewel ik niet over dezelfde retorische kwaliteiten beschik als Erik en Tobias, doe ik mijn best om de presentatie te omschrijven. Het verhaal voerde ons mee naar het magische “Land of Oz.” Dit verhaal geschiedde in het midwesten van Amerika, in de staat Kansas, waar het “saai vertoeven” was, aldus hoofdpersonage Dorothy (in navertelling door Erik Bits). Op een dag kwam er een tornado die haar huis in het land van Oz neersmeet en daarbij een heks plette. Dorothy ging vervolgens op queeste om de tovernaar te vinden die haar kon helpen om weer terug te komen in Kansas waarbij ze hulp kreeg van enkele sprookjesfiguren. Deze sprookjesfiguren hadden kennelijk allerlei persoonlijke problemen, en hoopten dat de tovenaar die problemen kan oplossen. Na vele avonturen kwamen ze bij de tovenaar aan, die tot verbijstering van de hoofdpersonages een flessentrekker bleek te zijn.

Tobias en Erik gebruikten het verhaal om het tornadomodel te beschrijven. Een model waarbij in het begin van de Agile Tornado er creative destruction onstaat van het oude: in het geval van de IT sector de problemen behorend bij het sequentiële model, zoals bureaucratie, lange time to market en een gebrek aan transparantie. In het geval van the Land of Oz wordt de slechte heks geplet en de gevangenen vrijgelaten. Een tornado zorgt dus voor een hoop ontregeling maar lost tegelijkertijd problemen op.

Hoe groter de tornado, hoe verder je zit op de mate van continuous integration (en agile werken). Wie de flessentrekker was in tornadomodel, is mij nog niet helemaal duidelijk geworden. Wellicht dat dit tijdens een volgende sessie wordt onthuld….

Ketenregie – Van idee tot werkende software

Geschreven door Andre Boeters op . Gepost in Activiteiten.

Op 14 juni was er een TestNetavond. Deze avond had als onderwerp Ketenregie. Mij trok dit aan aangezien ik in mijn opdracht in een team zit dat ook de keten overziet om zo de performance van het softwareproduct te verbeteren. Mijn eigen kennis van ketenregie was dan ook beperkt tot aan het vele regressietesten. De spreker Jos van Rooyen heeft mij met deze avond meer begrip gegeven over ketenregie. Daarnaast heeft hij ook een model als handvat aangereikt. Al met al was het een leerzame avond. Waarbij ik heb geleerd wat ketenregie is en hoe je dat zou kunnen toepassen.

Ketenregie

Aangezien ik me wat verder wilde verdiepen in ketenregie en het proces heb ik eerst eens wat begrippen opgezocht. Het eerste begrip is keten. Vanuit NORA (Nederlandse Overheid – Referentie Architectuur) komt het begrip keten neer op: “een samenwerkingsverband tussen (afdelingen binnen) organisaties die naast hun eigen doelstellingen, één of meer gemeenschappelijk gekozen (of door de politiek opgelegde) doelstellingen nastreven. Deze ketenpartners zijn zelfstandig, maar zijn ook afhankelijk van elkaar waar het gaat om het bereiken van de gezamenlijke doelstellingen.”

Nu het woord keten duidelijk is heb ik ketenregie opgezocht. Ensie geeft hier een uitleg: “Ketenregie is het besturen en beheren van logistieke ketens. Ketenregie omvat alle activiteiten die in dienst staan van het beheren van de gehele keten, van grondstof tot eindproduct.” Ook Jos van Rooyen geeft een uitleg over ketenregie: “Ketenregie is een professionele aanpak waarbij de stabiliteit, veranderbaarheid en performance van de keten wordt gemaximaliseerd. Dit wordt gerealiseerd door belemmeringen op te ruimen en ontwikkelmogelijkheden te identificeren en door te voeren.”

Nu ketenregie iets duidelijker is, rijst de vraag hoe je dit dan kan toepassen.

Waarom ketenregie toepassen?

In een groot bedrijf loopt de organisatie eigenlijk waterval. Directie heeft een plan. Architecten maken daarvoor het plaatje, ontwerpers delen het plaatje op en maken ontwerpen, ontwikkelaars bouwen 1 van de ontwerpen en testers testen dat.

Je kan wel geloven dat er dan veel communicatie verloren kan gaan. Allereerst zal het lastig zijn om door deze ketens van beneden naar boven te communiceren. Een ontwikkelaar kan bijvoorbeeld aan de hand van een ontwerp zien dat het (voorbeeld) niet gaat werken. Die zegt dit dan aan de ontwerper, deze zal het weer tegen de architect vertellen en die aan de directie. Komt hierdoor de oorspronkelijke tekst van de ontwikkelaar nog aan?

Dit is een voorbeeld van waarom ketenregie nodig is, ketenregie verbetert inefficiënte processen, de samenwerking in de keten en de communicatie van en het begrip voor product versus productie gereedheid.

Een gebrek aan ketenregie is dan ook vaak een gebrek aan overzicht van de keten. Mogelijke oorzaken hiervan zijn:

  • De toenemende fragmentatie, ketens worden langer waarbij de complexiteit ook toeneemt,
  • Een verandering in een stuk software kan in een keten lastiger traceerbaar zijn, de traceability wordt complexer,
  • Processen zijn inefficiënt ingericht,
  • Er is gebrek aan goede communicatie tussen partijen, dit kan binnen een bedrijf zijn maar ook tussen bedrijven (toeleverancier en ontvangende partij),
  • De kijk op het proces is erg beperkt, er wordt bijvoorbeeld alleen gefocust op de ICT,

Het model

Om ketenregie toe te passen zijn er volgens Jos van Rooyen 6 principes waaraan gehouden moet worden.

  1. Werk vanuit een visie,
  2. Organiseer de regie,
  3. Werk met alle mensen,
  4. Creëer ritme,
  5. Durf vanuit overzicht,
  6. Meet en borg.

Dit zijn simpele principes, ook om je aan te houden. In deze principes is meteen te zien dat er een overzicht van de keten wordt gecreëerd. Het model wordt hierdoor zo:

Een iteratief proces waaruit een visie spreekt en waardoor regie wordt gehouden, alle mensen betrokken zijn, ritme en overzicht gecreëerd worden en documentatie (meet en borg) wordt opgesteld. Een model om iedereen op en om het bedrijf tevreden te stellen en vooruitgang in het vooruitzicht te stellen.

 

 

Aan de slag met Postman, LiveCode en Agile risicoanalyse bij TestNet ZomerWorkshops 2017

Geschreven door Andre Boeters op . Gepost in Activiteiten.

Het was op 10 juli weer tijd voor het ZomerWorkshops event van TestNet. Ondanks dat het mijn verjaardag was ben ik naar Nieuwegein afgereisd, waar ik een aantal 2B4QA collega’s heb ontmoet en twee workshops heb gevolgd.

Testautomatisering voor Dummies

We begonnen de dag na het gebruikelijke kopje koffie in de ochtend met een workshop die beloofde “Testautomatisering voor dummies” helder te maken. Dit was een boeiende sessie over het gebruiken van de ontwikkeltool LiveCode als hulp bij het testen.

De noodzaak hiervoor werd beschreven door uit te leggen dat als je een onderdeel van het systeem wilt testen terwijl nog niet het hele systeem klaar is je dit soort tools kunt gebruiken als hulp. Ook wanneer een proces in het systeem bestaat uit veel stappen die nog niet allemaal af zijn kun je met een testtool al wel bepaalde onderdelen testen. We hebben in de workshop eerst Postman gebruikt om een service te testen en later zelf een tool gemaakt in LiveCode om meer verandering aan te kunnen brengen.

testautomatisering voor dummies

Zoals docent Rob Kuijt van Valori het uitlegde “op deze manier kun je ook alleen pagina 19 in een werkproces van 20 pagina’s testen”. Ik kan me erg goed vinden in het voorbeeld dat je een heel proces door moet om uiteindelijk een klein nieuw onderdeel te kunnen testen. Ik ben van mening dat het ook belangrijk is om een end-to-end test te doen voor nieuwe functionaliteit, maar het scheelt vaak veel werk en tijd om een groot deel van de test cases uit te voeren met een tool als Postman.

We zijn toen verder gegaan met uitleg over het gebruik van Postman. Postman is een API testtool waarmee je simpel gezegd een service kunt testen door een request in te sturen en een antwoord kunt ontvangen. Dit is dus erg handig als er een service veranderd of opgeleverd is, terwijl de front-end misschien nog niet beschikbaar is. Je kunt Postman gemakkelijk als app toevoegen aan Chrome.

De groep is toen onder leiding van Rob en Curd Klaassen verder gegaan met een volgende tool. LiveCode is een visuele ontwikkelomgeving waarbij je op een canvas een aantal elementen zoals knoppen en velden kunt toevoegen waarna je dan code toevoegt om te bepalen wat de elementen moeten gaan doen. Je maakt hierdoor snel zelf een applicatie. We hebben dezelfde functionaliteit als van Postman toegevoegd aan een nieuwe applicatie in LiveCode. We hebben hierbij een case gevolgd die ook na te lezen is op het blog van Valori.

We hebben bij deze workshop geleerd om de basics van Postman te gebruiken en een eerste applicatie in LiveCode te maken die wel direct bruikbaar is als testtool. De waarde van zo’n tool is dat je delen van een keten die nog niet opgeleverd zijn al wel kunt nabootsen om nieuwe functionaliteit te kunnen testen.

Agile Risico Analyse

Als tweede heb ik een workshop bijgewoond over Agile risicoanalyse door Gijs op den Beek en Thomas Veltman van Sogeti. Gijs had bij een klant een nieuwe manier van risico’s analyseren ontwikkeld en beoefend. Hierbij kun je op een agile manier risico’s per user story inschatten. Ik was hier zeer in geïnteresseerd omdat ik het lastig vind om risico’s bij een agile team onder de aandacht te brengen. Stakeholders vinden vaak alles belangrijk en willen alles “goed getest” hebben.

Gijs begon met een lange opfrissing van de agile principes en de rol van risico’s daarin. Via Kahoot hebben we een inventarisatie geprobeerd te doen van het gedeelte van het publiek dat in een agile omgeving werkt. We hadden helaas wat netwerkproblemen met de wifi van het congrescentrum. Na een inventarisatie door hand opsteken bleek dat minder dan de helft van de aanwezigen vond dat hij in een agile omgeving werkte. Veel aanwezigen werkten in een agile/waterval hybride omgeving.

We gingen verder met risicoanalyse door de risico’s van een vakantie in te schatten met de groep. Wat kan er misgaan en wat is de kans daarop? De formule risico = faalkans x schade passeerde de revue.

Voor een waterval project is het goed om een uitgebreide risicoanalyse vooraf te doen en vervolgens actiepunten uit te zetten voor de risico’s. Bij een agile werkwijze kun je tijdens de planning risico’s benoemen en acties definiëren. In de methode van Gijs gebruik je een soort risicopoker. Tijdens refinement kun je met verschillende aanwezigen ook de faalkans en de potentiële schade inschatten op een schaal van een tot drie.

We zijn hierna met een voorbeeld in groepjes aan de slag gegaan. Hierbij kwam de uitleg meer tot leven. We kregen verschillende teamrollen toebedeeld en hebben voor een vijftal user story’s de risico’s ingeschat. Hierbij merk je dat het handig is om eerst de faalkans en schade apart in te schatten, maar dat je later met je team ook in één keer het risico kunt inschatten en dat je nog later misschien wel het risico direct in de pokerpunten kunt meenemen. Dit was ook de ervaring van Gijs in zijn opdracht.

agile risico analyse

Er waren vragen vanuit de zaal over hoe je dit kunt implementeren. Door met het hele team risico’s te bespreken kun je de test strategie makkelijker bepalen, de test resources beter verdelen en ook al een aantal risico’s verminderen. Voor het beheersen van risico’s werd de ROAM methode uit SAFe genoemd. Het kost het team uiteindelijk ook steeds minder werk om de risico’s te benoemen. Ook het samenpakken van alle risico’s per story zorgt voor snelheid. Iemand vroeg nog naar de mogelijkheid om ook non-functionals te betrekken. Deze kunnen ook goed per project of product in een PRA besproken worden.

Aqua: agile improvement voor teams

Mijn collega Liset ging bij deze workshop aan de gang met de pijnpunten van een agile implementatie. Deze workshop was erg interactief. In groepjes van 5 werd er besproken wat de lastige punten zijn bij een agile implementatie en  wat het voor jou moeilijk maakt. Er werd ook gepraat over hoe jouw bedrijf agile verbeterd en wat je daarvan vind. Daarnaast had de spreker Huib Schoots van Improve een model gemaakt om in een agile werkomgeving een team te optimaliseren. In de groepjes hebben ze van dat model kunnen proeven.

Bijna iedereen heeft wel ervaring met de implementatie van agile bij een organisatie. Door dit met elkaar te delen kom je toch weer tot nieuwe inzichten. De spreker had ook veel energie waardoor je toch makkelijk meedoet en je ideeën deelt.

Internet on Wheels en BDD met Robots

Collega Sonny had zin in een dagje aan de gang met robots en is naar de workshop Internet on wheels van Parasoft en BDD met Robots van Bartosz gegaan. Bij internet on wheels moest er een robot door een doolhof geleid worden. Dat kon door via bluetooth opdrachten te sturen in python. Dit bleek erg lastig te zijn en het was niemand gelukt om de robot op die manier het einde van het doolhof te laten vinden. De robot kon ook bestuurd worden door sensors die erop zaten. Hiermee was het makkelijk om hem een kant op te laten gaan.

Ook in de sessie van Bartosz moest een robot door een doolhof geleid worden. Deze Mbot kun worden bestuurd door opdrachten in programmeertaal Scratch in BDD scenarios te geven. De geprogrammeerde scenarios zorgden met ingebouwde sensors ervoor dat de robot zijn weg kon vinden. Door de juiste commandos in te voeren en ook de juiste snelheid aan te houden was het Wall-e team van Sonny het snelste van de dag!

Afronding

Uiteindelijk liep de dag voor mij ten einde bij het dinerbuffet. We hebben met de aanwezige collega’s van 2B4QA nog even zitten napraten en grijpen het diner van TestNet ook altijd aan om samen te eten.

Bedrijfsbezoek Tricentis

Geschreven door Andre Boeters op . Gepost in Continuous Learning, Tosca.

Van afgelopen donderdag tot zaterdag zijn we met 2B4QA in Wenen geweest om onze partner Tricentis te bezoeken. Tricentis is de ontwikkelaar van Tosca, een suite voor testcase management, testautomatisering en test reporting. De laatste jaren hebben ze een enorme groei doorgemaakt en wordt er op hoog tempo nieuwe functionaliteit toegevoegd aan de Tosca test suite. Reden voor ons om eens  de banden aan te halen met onze partner.

Een goed begin?

Donderdag vertrokken we naar Wenen. Na enige treinvertragingen vanwege blikseminslagen bleek ook onze vlucht twee uur vertraging te hebben. We waren hierdoor genoodzaakt om wat tijd door te brengen in een authentiek Schiphol etablissement wat ons de gelegenheid bood om te reflecteren op de vraag  waarom het samenreizen van twee niet nader te noemen individuen altijd samenhangt met vertraging.

Na een kort nachtje en een stevig ontbijt voor sommigen werden we hartelijk ontvangen bij Tricentis door Franca en Peter. Franca werkt als implementatie consultant en Peter is director of Alliances van de regio EMEA. Franca trapte de dag af met een presentatie over de mogelijkheden van Tosca. Ze koppelde de theorie van test case design in Tosca aan de praktijkervaring die ze heeft bij klanten. Uit haar ervaring bleek bijvoorbeeld dat het stellen van een korte termijn doel een hogere kwaliteit van risk assessment biedt. Wanneer er te lang over gedaan wordt en alle actoren hun plasje over het gewicht van de requirements moeten doen kan er de neiging tot politieke correctheid ontstaan. Uit de praktijk blijkt dat de risico’s een egaal gewicht wordt toegedicht. Dit voorkomt een zuivere analyse van de risico’s. Franca: ”Political correctness kills the assessment.”

Theorie en praktijk

In de praktijk wordt testautomatisering niet optimaal gebruikt om kwaliteit van software te vergroten. De grote beloftes die testautomatiseringstools in de afgelopen decennia hebben gemaakt zijn tot nu toe nog niet waar gemaakt. In het geval van Tosca komt dit voornamelijk omdat er niet goed wordt nagedacht over wat een efficiënte manier is van het bepalen van de testcases. De module testcase design biedt mogelijkheden om op een gestructureerde wijze testcases samen te stellen die gebaseerd zijn op de happy flow door een systeem. De happy flow is het pad door het systeem met de hoogste business value. Over het algemeen is dit een pad dat veel gebruikt wordt en daarmee de kern is van het verdienmodel van de klant.  Met testcase design is men in staat om op basis van deze flow testcases te genereren die steeds één stap afwijken van de happy flow. Als er een testcase faalt, dan weet je precies door welke teststap dit komt.

Demo

Na de presentatie van Franca doken we met Roman van Tricentis in een demo van oude en nieuwe functionaliteiten van Tosca. De mogelijkheden op het gebied van API testing, test case management, testcase design en exploratory testing werden besproken. In exploratory testing is een feature opgenomen waarmee mensen zonder Tosca licentie uitgenodigd kunnen worden voor een testsessie. Zo kan je hun bevindingen integreren in een Tosca test report. Zodoende krijgen stakeholders een volledig, integraal en samenhangend overzicht van de uitgevoerde testen. Daarnaast sprong de API testing feature er voor mij uit omdat het een efficiënte manier biedt om functionaliteit van een applicatie te testen met een hoge performance.

Great expectations

Wolfgang Platz, CEO en founder van Tricentis hield een vurig betoog over de rol van Tosca in de toekomst van testen. Zijn idee is dat er in het algemeen meer nagedacht moet worden over het efficiënt inzetten van middelen zodat je met minder mensen een veel hogere testdekking van applicaties kan realiseren (zie afbeelding) . In de huidige situatie zijn te weinig testen geautomatiseerd, test redundancy (overbodige testen) is veelvoorkomend en testers zitten niet dicht genoeg op het vuur waardoor ze vaak te laat op de hoogte zijn van de ontwikkelingen in hun applicatie. Door in te zetten op goed opgeleide mensen die in staat zijn om Tosca in de volle breedte te gebruiken kan zowel het marktaandeel van Tosca vergroot worden en de inzet van Tosca specialisten bij organisaties. Door grondige kennis van Tosca en van continuous development te hebben gaan Tosca specialisten continuous testing implementeren bij organisaties om zodoende continu inzicht te bieden in de kwaliteit van de opgeleverde software. Hierbij heeft Tricentis een maturity model ontwikkeld dat organisaties helpt bij de overgang naar continuous testing.

Verkennend onderzoek

Naast het opdoen van kennis over testautomatisering hebben we gedurende weekend ook onze exploratory test vaardigheden aangesproken om het recreatie aanbod van de stad Wenen te testen. Alle collega’s van 2B4QA hadden ervoor gekozen om ook de zaterdag met elkaar in Wenen door te brengen. Daarbij hebben we gelet op de kwaliteit van de plaatselijke horeca, de mate van architectonische waarde van bezienswaardigheden, de klantvriendelijkheid van de plaatselijke markkoopmannen. Er kan gemeld worden dat deze cases allen succesvol gerund zijn.

Carrièrebeurs 2017

Geschreven door Andre Boeters op . Gepost in Activiteiten.

Teamuitbreiding

2B4QA is op zoek naar gepassioneerde testers om 2B4QA te versterken. Dit kan middels een aantal strategieën worden benaderd. Zo is het een mogelijkheid om ervaren testers van buitenaf binnen te halen of om zelf gemotiveerde afgestudeerden op te leiden. Gezien het feit dat 2B4QA kennisdeling en continuous learning hoog in het vaandel heeft staan, kiest ze voor de tweede optie. Het past goed bij het karakter en de strategie van 2B4QA om zelf ambitieuze starters op te leiden. Hiermee kom je als bedrijf ook voor een deel tegemoet aan het tekort aan ICT’ers op de arbeidsmarkt. Bovendien biedt het een goede gelegenheid voor de kwaliteitsconsultants van 2B4QA om hun opgedane kennis en competenties over te dragen naar de volgende generatie.

 

Uniek en eigenzinnig

Vervolgens is het zaak om te bedenken wie de ideale kandidaat is om het team mee uit te breiden. Na hier veel over na te hebben gedacht hebben we geconcludeerd dat de ideale kandidaat niet bestaat, niet echt althans. Als we als team in de spiegel kijken dan kunnen we eigenlijk alleen maar concluderen dat we allemaal verschillende types zijn. En dat is juist goed! We hebben allemaal onze eigen sterktes, uitdagingen, karaktereigenschappen, passies, hobby’s en visies. Dit zijn elk karaktereigenschappen waarmee we elkaar aanvullen en van elkaar kunnen leren. We willen dus vooral geen eenheidsworst zijn. Dat wil echter niet zeggen dat er niets is dat we zoeken in een ideale kandidaat. Er zijn een aantal – doorgaans abstracte – punten die wij belangrijk vinden. Zo vinden we het belangrijk dat er een opleiding op HBO of WO niveau is afgerond, als teken van voldoende intellectuele bagage en/of doorzettingsvermogen. Daarnaast vinden we het belangrijk dat diegene ambitieus is en zichzelf wil blijven ontwikkelen. Als kwaliteitsconsultant wordt er, buiten de vakinhoudelijke kennis en competenties, van je verwacht dat je goed feedback kan geven, kan presenteren en soms de vinger op de zere plek moet kunnen leggen. Daarom vinden we een open, eerlijke houding en een sterk karakter belangrijk. Ten slotte moet de kandidaat affiniteit met ICT hebben. Je zal immers niet snel ergens in uitblinken als je er geen plezier in hebt.

 

Naar de RAI in Amsterdam

Nu we voor onszelf een goed beeld hebben van de kandidaat die wij willen opleiden tot kwaliteitsconsultant, is de vraag hoe we deze gaan vinden. Cv’s zoeken via de gangbare kanalen is een goede optie, maar heeft als nadeel dat dit vrij arbeidsintensief is. Bovendien is het lastig om enkel aan de hand van cv’s een goed beeld te krijgen van iemands persoonlijkheid. Toen kwamen we met het idee om onszelf te vertegenwoordigen op de nationale carrièrebeurs op 17 en 18 maart in de Amsterdam RAI. Een mooie bijkomstigheid hiervan is dat we ons als bedrijf tentoon kunnen stellen aan een grote groep mensen, en zo onze naamsbekendheid op een effectieve wijze vergroten. We kunnen direct in gesprek gaan met de bezoekers van de beurs voor een volgende stap in hun carrière. Door een praatje met ze te maken kunnen we ze beter leren kennen en, ook niet onbelangrijk, zij ons.


Wat wordt de nieuwe superkracht?

Als je jezelf als bedrijf in de kijker plaatst op een beurs is het belangrijk om na te denken over wat je wilt uitstralen om zo de juiste mensen aan te trekken. Wat wij als bedrijf willen uitstralen is onze vakmanschap en diversiteit. Iedereen in het team is uniek, en heeft zijn eigen superkracht. Dit hebben wij vertaald naar een grote poster met daarop de befaamde cartoontekeningen van onze teamleden, afgebeeld als superhelden, elk met zijn of haar bijzondere krachten. Het gaat om dezelfde tekening als de banner op onze website, maar dan erg groot. Wat wij inhoudelijk wilden uitdragen was het traineeship die wij aanbieden. Wij wilden helder maken waar deze voor stond, wat je er allemaal leert, hoe je je kennis direct in de praktijk kan brengen, welke certificaten je kan behalen en hoe je je daarna verder kan blijven ontwikkelen. Hieraan hadden we overigens nog een prijsvraag gekoppeld: In welke Europese hoofdstad zal je een deel van de traineeship doorlopen? Bezoekers die deze vraag juist wisten te beantwoorden (aan de hand van een afbeelding) in combinatie met de vraag hoeveel bugs (snoepjes) er in onze pot zaten, maakten kans op een waardebon van €100,- bij Media Markt!

 

Another fun day at the office

Het resultaat was twee erg gezellige, effectieve dagen met veel nieuwsgierige blikken, grote hoeveelheden uitgedeelde snoep, 2B4QA pizzarollers, keycords en flyers, gesprekken over de superkrachten van de bezoekers en veel opgestuurde cv’s. Bovenal hebben we vooral veel plezier met elkaar gehad. Er waren live optredens van onder andere Lange Frans en was er een leuke interactie met standhouders van andere organisaties. Door deze interactie konden we ook nog van alles leren en ook nog wat voor elkaar betekenen, zoals bijv. door bezoekers met een bepaald profiel te adviseren langs te gaan bij stands die je beter bij hen vindt passen. Met de andere standhouders hebben we aan het einde veel van onze goodies en lekkernijen uitgewisseld. Al met al was het een groot succes en de gesprekken met onze nieuwe superhelden zijn in volle gang!