Cypress for Newbies

Cypress is een automated test tool voor het testen van web applicaties. Het is een gratis tool en best eenvoudig te gebruiken. Echter, het is best lastig om als ‘leek’ op gang te komen. De documentatie is geschreven voor ontwikkelaars. En als je dat niet bent, dan wordt het opzetten van een testproject met Cypress moeilijk.

Om het leven van iedereen die met Cypress wil werken makkelijker te maken heb ik het eBook Cypress for Newbies geschreven. Het bevat alle informatie zonder te veel blabla. Tevens heb ik werkende stukken code toegevoegd, zodat je eea meteen kunt testen.

Download het eBook hieronder.

Volledige naam (*)

Email (*)

Test je website als een pro

Bij het testen van een website wordt er vaak gedacht aan het rondklikken ‘of alles het een beetje doet’. De grootste fout die gemaakt kan worden. Dat zegt een tester.

Zodat jij ook je website als een pro kunt testen heb ik een eBook geschreven. Je kunt het hieronder downloaden.

Succes! En heb je nog vragen, dan weet je dat Testhuis voor je klaarstaat.


Volledige naam (*)

Email (*)


Image by William Iven from Pixabay

IoT – 6. Testen van het Internet of Things

Hoe test je het Internet of Things?

​Omdat ik een tester ben ga ik het uiteraard nu hebben over het testen van het Internet of Things. Dit is een van de meest essentiële onderdelen in het ontwikkelproces van het Internet of Things. Waarom? Simpelweg om alle risico’s af te dekken. Als er geen risico’s waren zouden deze ook niet getest hoeven worden.

Laten we een device eens analyseren. Op de eerste plaats is het een apparaat wat iets kan doen. Het heeft dus een functionaliteit. Op de tweede plaats heeft het een rekencapaciteit, want het gaat dingen voor ons regelen, berekenen, uitsturen en ga zo maar door. Op de derde plaats gaat het ding communiceren via WiFi, LoFi of Bluetooth, etc.. De rekeneenheid werkt op een platform. Dat communiceren gaat gepaard met behulp van allemaal andere devices. Denk daarbij aan routers etc. Dan wordt de data uitgestuurd waar een analyse op uitgevoerd kan worden. Deze data kan weergegeven worden op een webapplicatie.

Als tester kun je nu gaan testen door de verschillende onderdelen op een exploratory wijze aan te vliegen. Beter is het om er iets gestructureerder naar te kijken. Laat ik daarom eens een zijstapje maken.

Lang geleden is er door de international standardisation organization een model bedacht voor het opzetten en analyseren van dataverbindingen tussen twee communicerende partijen (pc’s). Dit model heet het OSI-model. Dit OSI model bestaat uit zeven lagen, waarbij laag zeven de meest visuele is voor de gebruiker. Laag zeven is de Applicatie laag. Dit is daadwerkelijk de applicatie waarmee een gebruiker werkt. Denk daarbij aan een webbrowser met een webapplicatie. De zesde laag is de Presentatielaag. Dat is de laag waarop de applicatie gebouwd is. Denk daarbij aan het Windows of Mac of Linux systeem. De vijfde laag is de Sessielaag. Om uberhaupt iets te kunnen versturen moet een sessie opgezet worden met de ‘andere kant’. Er wordt door de ene pc gezegd: ‘hallo, ik ben pc abc’. De andere pc zegt: ‘Leuk dat je er bent, ik heet xyz. Zullen we kletsen’. Daarna zegt de andere pc: ‘Goed idee’. Vervolgens komen we bij de vierde laag, namelijk de Transportlaag. De transportlaag zorgt dat jouw boodschap in pakketjes wordt opgedeeld, zodat het later over de lijn verstuurd kan worden. Hoe dat gaat is in het geval van het internet via TCP: Transfer Control Protocol. Het verdelen van de berichten in een bepaald soort pakketjes. De derde laag is de Netwerklaag. Deze netwerklaag zorgt ervoor dat de pc of het device bekend is op het netwerk. Dit is de laag waar het IP adres wordt toegekend. Zodoende ontstaat dus TCP/IP. Denk dus aan Routers in het geval van de Netwerklaag. De tweede laag is de Datalinklaag. Deze laag zorgt ervoor dat er gecommuniceerd kan worden binnen een netwerk. Dat devices samen communiceren. Dit gebeurt samen met de netwerklaag. Bij de datalinklaag moet je denken aan hubs en switches. Deze werken samen met de router. En dan komen we op de eerste laag. De Fysieke laag. Dit zijn de fysieke kabels die door de muur zijn getrokken.

Deze zijstap is belangrijk. Waarom? Een Internet of Things device maakt in principe gebruik van alle zeven lagen van het OSI model. Laten we even een eenvoudig voorbeeld nemen, een lichtknop. De gebruiker wil namelijk gebruik maken van de functionaliteit van het device. De Applicatielaag zorgt dat ik daadwerkelijk de knop kan indrukken. Klik aan en klik uit. Een klein stukje software registreert vervolgens een Aan of een Uit. De Presentatielaag is bijvoorbeeld het Arduino operating systeem waarop de software draait. Software zonder operating systeem is even goed als een vel papier met letters. Vanaf dat moment wordt er een sessie opgebouwd met een ander device aan de andere kant, namelijk het lampje. “Hallo ik ben lichtknop.”, “Hallo, ik ben lampje, zullen we samenwerken?”, “Prima idee!”. De transportlaag zal een pakketje versturen waarin de informatie staat om aan te gaan. De Netwerklaag zal zowel de lichtknop en de lamp een IP adres moeten toekennen. Anders zijn de apparaten niet gekend op het netwerk en kunnen ze dus niet communiceren, waardoor er geen functionaliteit te zien is. De Datalinklaag zal in dit geval niet een switch zijn. Er zijn WiFi verbindingen. De Netwerklaag, de Datalinklaag en de Fysieke laag worden zo gecombineerd. Het kan uiteraar ook zijn dat de lichtknop via een kabel daadwerkelijk aan een switch hangt bij een essentieel device als een lichtknop. Dan is de datalinklaag wel hard aanwezig. En vervolgens is er de fysieke laag. Kabels naar de switches en routers, Wifi verbindingen en de stroom van het netwerk.

Om de Internet of Things testen serieus aan te pakken zul je dus serieus moeten gaan kijken naar alle zeven lagen van het OSI model en niet alleen naar de Presentatielaag en fysiek als je een kabel uittrekt. Wat gebeurt er tussen die lagen. Binnen die vijf lagen kan er namelijk heel veel mis gaan. Er zijn veel afhankelijkheden. Het verkrijgen van een IP adres, het wijzigen van een IP adres, versleutelen van data, hoeveelheid data en ga maar door.

Het testen van het Internet of Things komt dus neer op het toepassen en analyseren van het OSI model op dat device. Daarnaast moet er ook eens goed gekeken worden hoe een device vervaardigd is. Er zijn componenten gebruikt die samengesteld zijn. Hoe is dat gedaan en hoe is gecontroleerd of dat met een hoge kwaliteit gedaan is. En hoe is gecontroleerd of het device ook daadwerkelijk functioneert? En nog eerder in de lifecycle. Hoe zijn de verschillende componenten gefabriceerd en op kwaliteit gecontroleerd? Wat is het stroomverbruik? Hoe vaak moet er aangegeven worden dat het device nog op het netwerk bestaat?

Het hele QA traject moet bekeken worden om te controleren hoe snel onderdelen stuk kunnen gaan. Als een apparaat duur is maar daarna altijd feilloos werkt, dan is dat veel prettiger dan dat een apparaat elke twee weken vervangen moet worden, al kost het bijna niets. Vervangkosten moeten ook berekend worden. En dan spreken we nog niet over de maatschappelijke verantwoording. Vele devices worden vervangen, weggegooid etc. Wat is de levenscyclus en de impact op het milieu?

Leuk he dat testen. Het testen van het Internet of Things heeft iets meer voeten in aarde dan je zo in eerste instantie zou denken. Toch net iets uitgebreider dan enkel het klikken op een lichtknop. Ja, dat testvak gaat nog eens groot worden.

IoT – 5. Risico’s van het Internet of Things

Wat zijn de risico’s van het Internet of Things?

​We hebben het gehad over de voordelen van het Internet of Things. Ook hebben we het gehad over de nadelen van het Internet of Things. Nu is het de beurt aan de risico’s. Een tester kijkt namelijk altijd naar de risico’s. Als er geen risico’s zijn, hoeft er namelijk niet getest te worden. Even belangrijk om te weten is dat de nadelen niet meteen risico’s zijn. Risico’s zijn dingen die daadwerkelijk fout kunnen gaan doordat de functionaliteit (in de brede zin des woords) niet doet wat het moet doen.

Op de eerste plaats is een risico dat de algehele functionaliteit het niet goed doet. Denk aan een ding wat geïmplementeerd wordt in andere dingen. Het risico is dat het niet functioneert. Na implementatie kom je daar pas achter. Dingen moeten connected zijn, data moet verstuurd worden. Dus er moet contact zijn met een Wifi of LoFi en er moet een IP adres zijn. De batterij moet het doen. En natuurlijk moet het component zelf niet stuk zijn. En dan hebben we uiteraard ook nog de programmering van het ding zelf. De code kan incorrect zijn. Het niet functioneren kan dus aan meerdere dingen liggen en aan de samenwerking tussen die meerdere delen.

Het risico van het niet functioneren is een financieel risico. Je kunt niet van de voordelen gebruik maken (en niet van de nadelen). De kans zal niet erg groot zijn dat het apparaat niet functioneert. Als het niet functioneert is de impact natuurlijk wel groot. Het ongemak van uitbouwen, terugsturen, reparatie of vervanging, opnieuw inbouwen. Verder is het heel onhandig en ik word als consument niet blij. Mijn kwaliteitsgevoel gaat achteruit.

Tweede risico is dat de connectie wegvalt. Een beetje internet of Thing device zal niet continu connectie hebben, maar alleen op het moment dat een connectie nodig is. Vanuit test oogpunt is het interessant om te weten wat er gebeurt als er geen connectie is. Wordt de data dan bewaard en dan later alsnog gestuurd als er een connectie is. Wat gebeurt er als er data verloren gaat, doordat een connectie langer wegvalt. Wordt data dan overschreven door een beperkt geheugen? Dit is natuurlijk wel erg technisch, maar toch.

Echt spannend wordt het als het apparaat plots niet meer met de WiFi kan verbinden. Het wordt een hele toestand om dat probleem opgelost te krijgen.

Het Internet of Things maakt gebruik van WiFi of LoFi. Het risico bestaat dan dat de data opgevangen of afgeluisterd kan worden. Dus het is met name belangrijk dat er gekeken wordt naar de beveiliging van de data. Onversleutelde data kan direct gelezen worden. Onversleutelde verbindingen zijn ook te gebruiken om op het netwerk te komen. De impact daarvan kan heel hoog zijn. Als je met je creditcard betalingen uitvoert, dan zijn deze gegevens te achterhalen. Voor kwaadwillenden is dat natuurlijk prachtig.

De data wordt verstuurd naar apps, databases en ga zo maar door. Een risico wat daar te vinden is is dat de data van die bronnen te lezen zijn. Al dan niet in verwerkte vorm. De toegang moet dus goed geregeld en beveiligd zijn. De kans op dit risico is toch behoorlijk groot te noemen, want zelfs grote organisaties hebben moeite hun data goed te beveiligen. Echte hackers hebben de tijd en bovendien de kennis om deze centrale datapunten open te breken.

Integrerende applicaties combineren gegevens van jou als gebruiker. Wat wordt er met die combinatie van gegevens gedaan. Bijvoorbeeld: De IoT applicatie bestelt melk met als combinatiedata jouw creditcardgegevens. Of misschien nog interessanter: je bestelt geen melk maar alleen cola en chips. In combinatie met jouw leeftijd en sportieve activiteiten is dan vrij eenvoudig te bedenken dat je gewichtsproblemen kun krijgen. Deze gegevens zijn weer interessant voor verzekeraars.

Dan is er nog het risico dat gegevens verkeerd doorgestuurd worden. Je melk is op, maar boter wordt besteld. Of de verkeerssensoren registreren een file in een bepaalde straat, omdat er veel verkeer achter elkaar rijdt. Echter blijken het geen auto’s te zijn, maar fietsen, waardoor een opstopping nogal meevalt.

Hoe zijn de testen uitgevoerd aan de kant van een fabrikant? Zijn situaties gesimuleerd, of zijn ze ook daadwerkelijk fysiek in praktijk getest?

En wat als er data incorrect is ingevoerd in de achterliggende systemen of applicaties. Denk bijvoorbeeld aan een pak Melk. Als er een typefout is gemaakt door ‘Mlek’ in te voeren, dan zal de betreffende gekoppelde supermarkt heel weinig Melk verkopen.

Wie of welke organisaties krijgen allemaal jouw data? Welke data wordt ongevraagd naar bedrijven doorgezet? Dus er kan door meer organisaties ongewenst gebruik gemaakt worden van jouw data.
Wat is de privacy policy van de bedrijven die de IoT oplossing bieden. Wie controleert dat zij goed met jouw data omgaan. Misschien is de database van de aanbieder wel zo lek als een mandje. De impact is dat de gebruiker allemaal aanbiedingen krijgt die hij niet wil krijgen.

Iets breder kunnen we kijken naar de hele lifecycle van Internet of Things componenten. Veel componenten worden gemaakt in lage-lonen-landen. Hoe ga je er zeker van zijn dat deze componenten niet door kinderhandjes gemaakt zijn? Of bijvoorbeeld in fabrieken waar mensen zich uit de naad werken voor een paar miezerige centen. Er zijn in de wereld nogal wat partijen die het niet zo nauw nemen met de arbeidsomstandigheden. De kans daarop is hoog en de impact op de mensen daar is hoog. Voor ons is de impact natuurlijk nihil. Wij zijn dan de andere helft van de wereld aan het vernielen zodat wij lekker connected kunnen zijn.

Er zijn heel veel meer risico’s te bedenken. Uiteraard zijn deze per project of product anders. Dit is in ieder geval al een leuk lijstje om over na te denken. Als je deze risico’s bekijkt kun je je afvragen of je nog het Internet of Things wilt hebben. Tuurlijk wil je dat! Maar dan moeten de risico’s wel goed afgedekt zijn.

IoT – 4. Nadelen van het Internet of Things

Wat zijn de nadelen van het Internet of Things?

​We hebben het gehad over de voordelen van het Internet of Things. Natuurlijk is zijn er niet alleen voordelen, maar ook nadelen. Als je over de nadelen gaat nadenken zijn er zonder uitputtend te zijn een aantal aandachtsgebieden te onderkennen, namelijk: privacy, regulering, professioneel, kwaliteit en beveiliging.

Om te beginnen kijken we naar de privacy. Als er gegevens verstuurd worden dan kunnen deze interessant zijn voor meerdere partijen. De gegevens kunnen in een negatief scenario op straat komen te liggen door hacking en security issues. Er zijn al een hoop gegevens bekend bij providers en hosts. Als deze gegevens gecombineerd worden met gegevens van het Internet of Things kan dat zeer gevoelige informatie opleveren. De gegevens kunnen bijvoorbeeld gekoppeld worden aan andere gegevens, zoals de gezondheidsgegevens en andere medische data. Dat wil je als gebruiker dus niet hebben.

Nog een nadeel is het gebruik van de gegevens voor verregaande regulering door de overheid. Op de eerste plaats staan ze er niet om bekend zo een goede IT projecten en en beveiliging erop na te houden. Op de tweede plaats heb je de regulering en handhaving. Als ze zien dat je te hard rijdt, dan kunnen ze meteen een boete sturen. Handig, had je maar niet te hard moeten rijden. Eenvoudige inkomsten en je houdt het plebs lekker in het gareel.

Professioneel zijn er ook wat negatieve kanten aan het Internet of Things. Door de dingen worden handelingen weggenomen die nu gedaan worden door mensen die daar een baan aan hebben. Deze mensen hebben straks geen baan meer. Denk bijvoorbeeld aan het vak als chauffeur. Door zelfrijdende auto’s en automatische routes zijn een aantal chauffeurs niet meer nodig. Je kunt het vak natuurlijk anders gaan insteken, maar daar red je niet elke job mee.

De kwaliteit van sommige producten neemt af door 0-marginale kosten. Het levert niets op, dus de aandacht wordt ook minder. Zo ontstaan nu allerlei blogs ‘7 manieren om…’. Deze artikelen triggeren de aandacht, maar bevatten geen kwaliteit. Door de enorme aanbieding van veel kaf, zie je niet altijd het koren. Want, er zijn natuurlijk ook erg goede blogs, maar minder. Net als bijvoorbeeld het testvak door consultants. Door een grote hoeveelheid zogenaamde professionals en dozenschuivers blijven de echte professionals onopgemerkt. Harder schreeuwen heeft geen zin. De verdiensten zijn minder en de kwaliteit van vele applicaties neemt af. Als dus de ‘grote’ partijen of ‘schreeuwers’ zich in het Internet of Things maneuvreren en de kleinere kwaliteitsaanbieder zo buiten spel zetten, dan wordt de aangeboden kwaliteit alleen maar lager, terwijl het Internet of Things het juist hoger kan maken.

Door het Internet of Things worden dingen en service persoonlijker door het gebruik van jouw data. Aan de andere kant wordt het onpersoonlijker doordat je geen andere mensen nodig hebt. Geef ouderen een armband die de gezondheid in de gaten houdt. Je kunt vervolgens sneller de toestand van meer mensen controleren van achter het scherm. Zodra er iets misgaat weet je wel precies wat.

Fysieke beveiliging wordt groter, maar kan aan de andere kant ook kleiner worden. Militair gezien is het positief dat je in de gaten kunt houden dat er bepaalde dingen in ontwikkeling zijn, bewegingen plaatsvinden en ga zo maar door. Nadeel is natuurlijk dat kwaadwillenden door het Internet of Things ook beter aanvallen kunnen plannen en uitvoeren zonder ook maar opgemerkt te worden of andere nadelen te ondervinden.

Ik denk dat er nog een mooie taak is weggelegd voor de professionals die zich nu met de ontwikkelingen van het Internet of Things bezighouden. Als professional moet je altijd kritisch en vooral ethisch blijven kijken naar de ontwikkelingen. En als ik het zo bekijk, zou het vak als ethisch hacker nog wel eens heel groot kunnen worden.

IoT – 3. De voordelen van het Internet of Things

Wat zijn de voordelen van het Internet of Things?

​Hoewel het inmiddels wel bekend is, is het Internet of Things de naam van dingen die via het internet met elkaar communiceren. De dingen maken contact via bijvoorbeeld je WiFi en geven zo data door aan bijvoorbeeld een webapplicatie of aan andere dingen die ook aan het internet hangen. Die data kan vervolgens gebruikt worden of gecombineerd worden met andere data om waardevolle informatie te krijgen. Zoveel was al duidelijk.

Nu kun je zeggen: “Leuk zeg, al dat rondsturen van data. Wat heb ik daaraan?”. Waarom moet een lamp data sturen naar het internet dat hij is aangegaan? Met een eenvoudige bewegingssensor kun je toch ook het licht aan of uit laten gaan, als je dat zo graag wil? En die rekening zie ik wel op het einde van de maand. Dat is natuurlijk één manier van kijken. Maar laten we eens kijken wat voor een echte voordelen het Internet of Things heeft.

Zonder uitputtend te zijn kan ik meteen vijf gebieden aangeven, waarbij het Internet of Things echt een meerwaarde kan hebben. De gebieden overlappen elkaar zodra je over de toepassingen gaat nadenken. Ik heb het over energie, distributie, communicatie, gezondheid en gemak.
Energie kunnen we stroomlijnen. Energie wordt daar gewonnen waar het op dat moment mogelijk is en vervolgens daar ingezet, waar het op dat moment nodig is. Hierbij komt onmiddellijk de overlap met energiedistributie kijken. Maar laat ik dat voor nu gewoon onder energie vallen. Door het Internet of Things wordt data verzameld om zo een efficiënte en goedkope inzet van energie te verkrijgen. Wij als mensen hoeven ons daar niet meer druk over te maken, dat doen de dingen voor ons. Zodoende kunnen wij energiezuinig leven en daarmee behoorlijk kosten sparen, terwijl wij op elk moment inzage kunnen hebben in de verzamelde data.
Distributie heeft alles te maken met transport van mensen, goederen en energie. Door het Internet of Things kan die distributie stukken vlotter. De files worden vermeden door de wegen te verbinden met het internet. Er worden zelfrijdende auto’s gebouwd die de snelste route nemen en levering van producten kan zodoende afgestemd worden op alle andere dingen die van plan zijn te gaan rijden, wat weer efficiëntie en daarmee kostenbesparing op kan leveren. Bedenk bijvoorbeeld dat er per dag in Nederland alleen al 250 kilometer file staat in een ochtendspits. Als een auto 10 meter in beslag neemt en er twee banen file zijn, dan komt dat neer op 50.000 auto’s en daarmee personen die tijd spenderen aan iets wat onnodig is. Een file kost iedere persoon een klein half uur. De opbrengst van een persoon per uur rekenen we op 100 Euro. Dat komt dus neer op minimaal 2.500.000 wat een normale ochtendspits kost. Dat doen we 2 keer per dag en 4 dagen per week 45 weken per jaar is 20 miljoen per week, 900 miljoen per jaar. Makkelijk gezegd dus 1 miljard kosten die bespaard kunnen worden door slimmere manieren van werken en de toepassing van het Internet of Things. Laat ik eerlijk zijn dat mijn berekening waarschijnlijk fors aan de lage kant is. Er zijn genoeg wegen met meer dan 2 banen. De kosten van nutteloos verstookte benzine, milieuschade en onderhoud nog even daargelaten.
Dat brengt ons onmiddellijk op communicatie. Op de eerste plaats heeft het Internet of Things zelf een goede communicatie nodig om te communiceren met andere dingen en web services. Communicatie gaat steeds minder over het leggen van een fysieke verbinding van de ene persoon naar een andere, zoals dat vroeger met de vaste telefoon gebeurde. Communicatie gaat meer en meer over data. Je gesprek wordt in data omgezet en zo via het internet verstuurd naar jouw ontvanger en andersom. Door het Internet of Things wordt de data van dingen gecombineerd met de communicatie van mensen. Thuis wordt je kantoor en je bespaart nog meer tijd door niet eens te hoeven reizen en zodoende te werken wanneer jij dat wil in de outfit die je het beste zit. Of je kunt op elk moment weten waar jouw vrienden zijn om een goede kop koffie te gaan drinken. Maar ook kun je bij het voorbij lopen van een pand wat te koop staat onmiddellijk zien wat de prijs is, de indeling van de kamers en de demografie van de buurt. Sterker nog, misschien staat er niet eens een bord in de tuin dat het pand te koop is, maar wordt je erop geattendeerd door een App terwijl je voorbij loopt. Dit heet augmented reality en is een van de toepassing wat een enorme vlucht gaat nemen zodra het Internet of Things volwassen vormen krijgt.

Nu we toch tijd aan het besparen zijn, kunnen we die tijd best besteden aan het verbeteren van onze gezondheid. We gaan sporten, gezond eten en vooral goed slapen. Een goede verhouding is essentieel. Een activiteitsmeter in de vorm van een armband die met je smartphone communiceert houdt voor jou in de gaten hoe je gesteldheid is. De armband maakt je op het ideale moment wakker en stuurt je bij in de activiteit. Maar tevens kan deze armband vreemde situaties detecteren. Je hart is bezig met een zeer ongewoon ritme wat erop duidt dat je een hartaanval krijgt. De armband zorgt dat je onmiddellijk wakker wordt en notificeert via de smartphone jouw dokter, die klaar staat om in te grijpen op het moment dat het echt verkeerd dreigt te gaan. Dat is een persoonlijk voorbeeld. Maar het is uit te breiden door te voorspellen waar de griep heerst, zodat je op de cruciale momenten weg blijft van de besmettingshaarden. De besparingen die gemoeid gaan met het verbeteren van de gezondheid zijn bijna niet uit te drukken.

En zo komen we vanzelf bij het gemak wat het Internet of Things kan verzorgen. Het heeft geen lange weg meer te gaan, of de chips die nodig zijn om alledaagse zaken met het internet te verbinden zijn vrijwel gratis. Dan is het bijna logisch dat je pak melk uitgerust wordt met de houdbaarheid en mogelijk de inhoud van het pak. Jouw koelkast of pak melk geeft zelf aan dat het op is, waardoor het aan je boodschappenlijstje wordt toegevoegd. Nog beter, je zoekt een paar recepten uit. Alle ingrediënten worden aan de lijst toegevoegd, maar niet die waarvan je nog genoeg in de kast hebt staan. En vrijwel vanzelf komt de bezorgservice jouw boodschappen afleveren. Of wat dacht je ervan dat je thermostaat vanzelf leert dat je elke morgen om half zes de boterhammen smeert. Dat betekent dat het om die tijd al voldoende warm moet zijn in de keuken. Dat instellen of programmeren van de thermostaat gaat nergens over. Dat moet het apparaat zelf maar uitvinden. En nu is er een dag dat je niet thuiswerkt, maar naar een klant toe wilt gaan. Een parkeerplaats is al bekend en wordt gereserveerd voor jou, waarna jouw zelfrijdende auto zich er zo in parkeert. Optimaal gemak dus en niet meer de stress die we nu regelmatig mogen ervaren.

Zomaar een paar functionele voorbeelden van de voordelen van het Internet of Things. Ik denk dat we een heel interessante tijd tegemoet gaan.

IoT – 2. Wat is het Internet of Things

Het Internet of Things, wat is dat eigenlijk?

​Een beetje techgeek kijkt je vreemd aan als je het zou vragen, maar de ‘gewone’ man van de straat heeft eigenlijk geen weet van wat het Internet of Things is. Het is een nieuw fenomeen, dat Internet of Things. Wel, dat lijkt zo. Het is iets wat nu pas merkbaar in opmars is. Het Internet of Things bestaat namelijk al een hele tijd. Daarover zo meer.

Om het Internet of Things een beetje te begrijpen moeten we een stapje terug doen. We zetten de stap terug naar het internet. Wat is het internet? Het internet is een wereldwijd netwerk, waarbij alle computers van mensen gekoppeld zijn met servers. Deze servers staan weer in verbinding met elkaar. Zodoende kunnen de computers communiceren met elkaar. Computers worden in beginsel bediend door mensen. Dus het internet is in de basis een digitaal communicatiemiddel voor mensen en door mensen. Websites worden gebouwd door mensen en mensen zoeken informatie, filmpjes, foto’s en ga zo maar door voor mensen. Je kunt het daarmee ook het Internet of People noemen.

Het Internet of Things is nu opeens veel makkelijker te begrijpen. Het Internet of Things zijn dingen die via het internet communiceren met servers en zodoende met andere dingen. Die dingen lopen uiteen van fysieke dingen tot applicaties of databases, waarna vervolgens via interessante algoritmes uit de data nieuwe informatie kan ontstaan. De tussenkomst van mensen om vervolgens iets met de informatie te doen is niet nodig. De dingen regelen het zelf.

Met een beetje creativiteit kun je nu een veelheid aan toepassingen bedenken die het leven makkelijker, veiliger of energiezuiniger kunnen maken. Al was het maar dat je een melding krijgt dat de melk bijna op is en deze automatisch aan je boodschappenlijst wordt toegevoegd.

Waar staan we nu met het Internet of Things? In principe zijn we al redelijk op weg. Het Internet of Things is namelijk ontstaan op het moment dat er evenveel dingen gekoppeld waren met het internet als dat er mensen gekoppeld waren met het internet. Schokkend of niet, dat was al in 2008 het geval. Het werd alleen nog niet zo herkend en benoemd.

Momenteel zijn de ontwikkelingen vrij eenvoudig. En dat is maar goed ook. Voor je kunt vliegen moet je eerst leren lopen en dan rennen. Er worden sensors ontwikkeld die op eenvoudige wijze ingesteld kunnen worden en via een centrale module aan het internet hangen. In een centrale applicatie kun je vervolgens interessante zaken aflezen die je eerder aangegeven hebt. Er bestaan lampen die automatisch aangaan en zo leren wanneer bewoners thuiskomen. De energiekosten kunnen weergegeven worden en er wordt gemeld wanneer de lamp bijna stuk is, via het internet. De thermostaat leert wanneer er beweging in huis is en past naar verloop van tijd automatisch de temperatuur aan, omdat er patronen herkend worden.

Meer gecompliceerde ontwikkelingen zullen vrij snel volgen. Vrij snel? Denk aan vijf tot tien jaar. Van de eenvoudige ontwikkelingen moet namelijk eerst geleerd worden.

IoT – 1. Economische verandering op komst

Een nieuwe industriële revolutie staat te gebeuren

​Wij staan aan het begin van een enorme economische verandering. Alle tekenen zijn er en wij maken het actief mee. Hoe gaaf is dat?

Maar, laat ik eens vertellen hoe ik bij dit idee kom. Eerst maak ik daarvoor een zijstap met een vraag. Wat zijn de drijvers van een economie?

Op de eerste plaats is er communicatie om mensen te verbinden. Ten tweede energie om de de maatschappij te laten draaien en als derde mobiliteit om de economische activiteit voort te stuwen.

Aan de basis van vooruitgang en hogere productiviteit liggen marginale kosten. Dit zijn de kosten die gemaakt moeten worden om een ding te ‘bouwen’ nadat de investeringen terugverdiend zijn. Technologie heeft gezorgd dat de marginale kosten verlaagd worden door producten te verbeteren en de productie te verhogen. Dit gebeurt om te concurreren met betere, goedkopere of nieuwe producten om als organisatie een bestaansrecht te hebben. De verandering die nu plaatsvindt is dat technologie zich tegen dit systeem van waardetoevoeging keert in heel wat sectoren. De technologie maakt services en goederen vrijwel gratis en vrij verkrijgbaar. De marginale kosten gaan daardoor naar nul, waardoor de services en goederen zich buiten het kapitalistisch verdienmodel gaan bevinden.

Deze ontwikkeling is begonnen met de komst van het internet. Denk bijvoorbeeld aan de krant of wikipedia. De krant is een artikel waarvoor vrijwel niet meer betaald wordt. Er worden slechts sporadisch abonnementen of een toegang tot een betaalmuur verkocht. Het nieuws wat niet gratis is te verkrijgen via de ene aanbieder, is zonder problemen te verkrijgen via een andere aanbieder.
Door het internet wordt op dit moment al veertig procent van de consumenten zelf aanbieder van content. Dit alles tegen vrijwel nul marginale kosten. Dit is precies hetzelfde geval met magazines en boeken. Er zijn zo veel blogs, whitepapers, video’s, muziek en andere artikelen gratis op het internet te vinden, dat het kopen van een fysiek product bijna onzinnig is.

Deze verschuiving begint zich nu voort te zetten naar de fysieke wereld van energie en fysieke producten. Er is namelijk een nieuwe technologie die het personen mogelijk maakt communicatie, energie en fysieke producten te gaan delen. Op dit moment is het nog op kleine schaal maar een versnelling laat niet lang op zich wachten. De technologie is het Internet of Things. Kortweg: dingen die via het internet met andere dingen en mensen verbonden is.
Het Internet of Things bestaat uit het samensmelten van een internet van hernieuwbare energie (in volle ontwikkeling), een logistiek internet van zelfrijdende auto’s en drones (in volle ontwikkeling) en een internet van communicatie, het wereldwijde web (in continue ontwikkeling, maar wel al enigszins volwassen). Ik spreek hierboven over het delen van energie en fysieke producten, want we veranderen naar een delende economie. De marginale kosten zijn vrijwel nul. We gaan energie delen met degenen die het nodig hebben. We hebben het gratis gewonnen uit bijvoorbeeld de zon. We zullen auto’s gaan delen met een groep mensen die samen een paar auto’s hebben en deze auto’s daarmee efficiënt inzetten. De kosten zijn zodoende een fractie. En we delen kennis in de vorm van e-boeken, films en dergelijke door sociale kanalen en wat verder nog meer zal ontstaan.

Maar wacht! Hoe wordt dan geld verdiend, als toch alles gedeeld wordt? Dat gaat op andere plekken gebeuren dan nu het geval is. Ik kan me voorstellen dat bijvoorbeeld een aantal chauffeurs zonder werk komen te zitten door drones en zelfrijdende auto’s. Maar die mensen zijn plots hard nodig bij de juiste sturing van goederen. Allerlei sensors moeten ontwikkeld worden. Sterker nog, er zullen een hoop uitvindingen plaatsvinden, vele applicaties geschreven worden en heel veel werk verricht worden om iedereen en elk gebouw van hernieuwbare energie te voorzien. De focus gaat veranderen. En wij zetten nu de eerste stappen!

Agile – 3. Ontwikkelmodellen en het agile model

Ontwikkelmodellen en het Agile model

In dit deel worden drie ontwikkelmodellen kort besproken en daarbij bekeken hoe deze in principe afgeleiden van elkaar zijn. De ontwikkelmethoden zijn het watervalmodel, het V-model en vanzelfsprekend het Agile ontwikkelmodel.

Het watervalmodel

De ontwikkeling in een klassiek watervalmodel kan als volgt omschreven worden. Als eerste wordt een idee geopperd. Dat idee wordt in business specificaties uitgeschreven waarbij de wensen vanuit de business beschreven worden. De business specificaties worden in functionele specificaties uitgeschreven. Hierbij wordt beschreven hoe een te ontwikkelen stuk software zich functioneel moet gaan gedragen. De functionele specificaties worden uitgeschreven in een architectuur en technische specificaties. De uitgeschreven technische specificaties worden ontwikkeld in componenten van databases tot code en gebruikersinterfaces. Deze componenten worden vervolgens aan elkaar gekoppeld tot een geheel werkend stuk software. Het hele softwarepakket wordt vervolgens aan een test onderworpen. De fouten worden hersteld door het ontwikkelteam. Daarna wordt er nog een korte controle uitgevoerd. Vervolgens wordt de software aan de klant opgeleverd

Het V-model

Het probleem bij het klassieke watervalmodel is dat testen pas betrokken wordt aan het einde van de ontwikkelfase. Testen mag dan een controle uitvoeren, maar door uitlopende ontwikkelingen wordt daar vaak veel te weinig tijd voor ingeschat. Tevens is niet geheel voorbereid en een belangrijke kwaliteitsslag wordt gemist, namelijk het controleren van de documentatie op basis waarvan de software is gemaakt. Testen wordt kortweg te laat betrokken. En het is algemeen bekend dat hoe later fouten gevonden worden in het ontwikkeltraject hoe duurder het is om deze fouten op te lossen. Het is namelijk niet altijd duidelijk waar de fouten het ontwikkelde systeem raken. Dus als een fout wordt opgelost kan het eenvoudig nieuwe fouten introduceren.

Om dit manco tegen te gaan is het V-model ontwikkeld. Het is eigenlijk niets anders dan het aanbreng van een knik op de plek van ontwikkeling in het watervalmodel.

Wat er dan te zien is dat tegenover elke vorm van documentatie een vorm van testen staat. Dat betekent ook dat op het moment dat een eerste stuk documentatie opgesteld wordt, testen al een globaal plan kan opstellen wat er getest moet worden en wat de risico’s in de software gaan zijn. Er kan ook al gecontroleerd worden of er fouten in de documentatie zitten, waardoor deze opgelost kunnen worden nog voordat deze ontwikkeld worden. Er worden Early testcase designs opgesteld, waarbij het vaak is dat de volledige details nog ontbreken, maar het framework er wel al staat.

Wat er met het V-model ontstaat is een kwaliteitsproces vanaf het begin van een project.

Wat grappig is om te zien is dat veel organisaties pretenderen volgens een V-model te werken, maar eigenlijk een watervalmodel hanteren, omdat ze testen niet vanaf dag één betrekken om de kwaliteit te controleren. Testen mag na  het opstellen van de specificaties, eigenlijk aan het begin van de ontwikkeling de testgevallen opstellen om ze vervolgens in meerdere fasen uit te voeren.

Dat is uiteraard wel een verbetering, omdat er meer en dieper getest wordt, maar het is eigenlijk een verlenging van het watervalmodel zonder de voordelen van een V-model te gebruiken.

Grappig genoeg wordt de inzet van testen aan het begin van een project als te duur gezien, terwijl het vinden van een fout in een testfase al vele malen duurder is dan het vinden van een fout in een documentatiefase, voordat software ontwikkeld wordt.

Het agile ontwikkelmodel

Het agile ontwikkelmodel zorgt ervoor dat ontwikkelteams kleine stukken software kunnen maken in korte perioden. Het geheel uitschrijven van een project met complete functionele documenten, uitgebreide technische beschrijvingen en dergelijke wordt achterwege gelaten, zodat er snel een resultaat kan worden neergezet. De klant heeft een directe input en werkt nauw samen om onder andere de betrokkenheid te verhogen.

Zoals dit beschreven wordt is de agile ontwikkelmethode eigenlijk de juiste toepassing van het V-model. Dit wordt verkregen door de ontwikkeltijden kort te houden en direct terug te koppelen en af te stemmen wat er gebouwd gaat worden. Omdat het in feite veel kleine V-modelletjes achter elkaar zijn is het testen binnen een agile project niet slechts testen maar een gehele kwaliteitscontrole (QA of Quality Assurance). Testen dient vanaf moment één in de gaten te houden dat er geen gaten vallen in de specificaties. Alle juiste risico’s vastgesteld worden en alle testsituaties bepaald worden om de kwaliteit van de software binnen een en dezelfde sprint vast te stellen.

Let op: zodra er gesproken wordt dat testen een sprint later wordt uitgevoerd, dan is dit niet meer een schone agile manier van ontwikkelen, maar een afgeleide, waardoor er in principe aan de voordelen van de agile ontwikkelmethode gesleuteld wordt. Vaak overigens niet ten goede. Het doel van één sprint is namelijk werkende software. De basis van de agile ontwikkelmethode.

Het Agile ontwikkelmodel is eigenlijk gebaseerd op de continue terugkoppeling en de wisselwerking tussen alle betrokken partijen. Dit gaat van het samenzitten door ontwikkelaars met de klant, de testgedreven ontwikkeling, de dagelijkse standups, retrospectives, etc. tot het continue verbeteren van het gehele ontwikkelteam en de brede inzetbaarheid van het team in verschillende onderdelen.

Agile – 2. De vormgeving van agile projecten

De vormgeving van Agile projecten

In het eerste deel van Testen in Agile projecten zijn we ingegaan op het Agile manifest en waar in de twaalf principes testen kan thuishoren. In dit tweede deel van Testen in Agile projecten gaan we in op de vormgeving van Agile projecten en waar testen betrokken dient te worden.

Agile projecten

Agile projecten lopen van kleine projecten tot grote projecten. In eerste instantie werd gedacht dat met name kleine projecten zich leenden voor de Agile aanpak, maar meer en meer is het besef gekomen dat ook grote projecten op een Agile manier aangepakt kunnen worden. Het is dan wel zeer belangrijk dat de afstemming en communicatie soepel verloopt. Misschien nog wel belangrijker dan in een normaal project. Er zullen namelijk meerdere scrum teams zijn, meerdere onderdelen en deze dienen allemaal op elkaar aangesloten worden. Hoe groot het project ook is, de basis is uiteindelijk een (deel)project wat uitgevoerd wordt door een scrumteam. De belangrijkste taak voor het testen is zorgen dat er een afstemming plaatsvindt over de impact die nieuw ontwikkelde software kan hebben op de bestaande ontwikkeling en op gerelateerde deelprojecten. De sessies waarin dit plaatsvindt worden ook wel eens grooming sessies genoemd.

De samenstelling van een scrum team

Voor het project wordt een team samengesteld. Dit team bestaat uit een product owner. Dit is in principe de klant of de afgevaardigde, danwel gedelegeerde van de klant. Dan is er een scrum master. Deze persoon leidt, of beter gezegd, begeleid het team. Hij is de persoon die moet plannen, bijsturen en faciliteren. Vervolgens zijn er de teamleden, bestaande uit ontwikkelaars die het product maken. Per 2 á 3 ontwikkelaars is er 1 Quality Assurance expert. Teams moeten klein blijven om wendbaar te zijn. Een team van 3 tot 6 ontwikkelaars met 1 tot 2 Quality Assurance specialisten is ideaal.

De kennis en kunde van de teamleden moet complementair zijn. Liefst wel met enige overlap. Uiteraard mogen er wel personen met gelijke kennis zijn, maar dat is alleen verstandig als er veel van dezelfde soort software ontwikkeld moet worden.

Vanuit het testen is de rol te bewaken dat de kwaliteit van de opgeleverde software van voldoende kwaliteit is. Dit betekent het assisteren bij het unit testen en meedenken in de verschillende situaties die de ontwikkelaars moeten bekijken, maar ook vanuit een functioneel perspectief de software aan een test onderwerpen.

Product owner

De product owner is de klant of de gedelegeerde vanuit de klant. Hij is de persoon die het overzicht van de software moet houden en moet toezien dat de software ontwikkeld wordt gericht op het beoogde eindresultaat. Aan het einde van een sprint wordt de ontwikkelde software dan ook in een demo getoond aan de product owner.

Vanuit testen is de afstemming met de product owner belangrijk om te zien of alle juiste onderdelen ontwikkeld worden en of alle juiste gebruikersscenario’s gecontroleerd worden op hun werking. Verder is het belangrijk om de grenzen van de gebruikersscenario’s te achterhalen. Dat zijn de situaties waar testen het interessantste is.

Scrum master

De scrum master faciliteert het Agile traject. Het is de taak van de scrum master om de binding te behouden, het proces soepel te laten verlopen, processen bijsturen, uitspattingen monitoren en zo nodig bijsturen. Verder dient de scrum master te plannen en de kwaliteit te bewaken.

Vanuit testen gezien is het dus het beste dat er een scrum master is met een sterke testbril op. Op die wijze wordt er meer gericht op een test driven development, waarbij er in eerste instantie gekeken wordt het QA proces vanaf moment één in de ontwikkeling in te brengen. Het leven van QA wordt zo veel gemakkelijker gemaakt. Daardoor wordt de kwaliteit van de opgeleverde software naar de product owner ook hoger.

Korte sprints

In plaats van een volledig project uit te schrijven, te ontwikkelen en te testen, wordt de functionaliteit in korte deeltrajectjes gemaakt. Deze trajecten worden sprints genoemd. In een sprint, die zo’n twee weken duurt wordt een geheel werkend stuk software opgeleverd. Wat de kwaliteit van het werkende stuk software is en de conclusie of het stuk software daadwerkelijk werkt is de taak van testen. En deze taak wordt anders ingevuld dan in standaard V-model trajecten. De specificaties zijn niet uitgeschreven en moeten daarmee achterhaald worden door communicatie met alle partijen. De risico’s dienen telkens nieuw bekeken te worden en elk nieuw onderdeel dan impact hebben op een ander onderdeel.

User stories

De functionaliteit die in een sprint ontwikkeld zal worden wordt beschreven in user stories. Dit wil dus zeggen een vanuit de gebruiker benaderde functionaliteit die kort beschreven wordt. Deze beschrijving bevat meestal niet meer dan een geeltje. De aandachtspunten die komen kijken bij de ontwikkeling en de test van een user story zijn essentieel voor de ontwikkelaars, maar ook voor testen. De aandachtspunten beschrijft tevens de risico’s en daar kan met testen op afgestemd worden.

Planning poker

De planning van wat er in een sprint samengevoegd kan worden wordt bepaald door het hele team. Elk teamlid geeft op hetzelfde moment aan hoe lang, volgens het eigen inzicht, het ontwikkelen en testen van een functionaliteit kost. De twee uitersten gaan met elkaar in discussie waarom de uitersten gekozen zijn en de achterliggende gedachten. Na deze discussie wordt nogmaals door alle teamleden de inschatting gegeven. Als er een gelijke lijn is dan wordt deze inschatting genomen.

Door de functionaliteiten in een sprint samen te voegen op basis van de inschattingen wordt bekend wat er in een sprint ontwikkeld wordt.

Planning poker is een volledige team effort, waarbij testen vooral moet kijken hoe lang het nodig is om een stuk software te testen en in te schatten welke mogelijke onderdelen aan een regressietest onderworpen moeten worden. Deze inschatting kan dus behoorlijke impact hebben op de inschatting van een ontwikkeling.

Als voorbeeld: een database aanpassing kan binnen een uurtje gedaan zijn. Het testen van deze aanpassing kan mogelijk een gehele applicaties op meerdere niveaus raken. De poker planning zal dan fors hoger uitkomen dan een uurtje werk, maar eerder op een paar dagen werk.

Wiki’s

Alle documentatie wordt in een wiki geschreven. Het voordeel is dat iedereen deze documentatie door iedereen in het team kan worden gewijzigd. Aangezien iedereen binnen het team aan dezelfde user stories werkt en de user stories op een hoog niveau beschreven worden kunnen alle teamleden details toevoegen die ervoor zorgen dat de software beter gebouwd wordt en daardoor beter getest wordt.

De rol van testen en met name QA in dit geval is zorgen dat de documentatie in voldoende detail beschreven is om te zorgen dat de software goed gebouwd wordt. Tevens is het de taak van QA om te zorgen dat de gaten opgespoord worden en door de beschrijving van de details de impact op andere onderdelen of systemen helder wordt.

Pair programming

Pair programming is een sterkte techniek waarbij twee ontwikkelaars samen aan 1 pc werken. Hierdoor wordt aan meer details gedacht en wordt door twee personen naar een functionaliteit gekeken, waardoor hogere kwaliteit geleverd kan worden.

Naast pair programming bestaat er ook pair testing. Pair testing is door twee testers werken achter 1 pc, waardoor er twee andere blikken geworpen worden op de software. Het gaat, net als pair programming, niet sneller, maar wel beter en dieper binnen dezelfde tijd.

Retrospectives

Retrospectives zijn sessies waarbij terug gekeken wordt op de afgelopen sprint. Er wordt geanalyseerd wat goed is gegaan en wat minder goed is gegaan. Er wordt tijdens deze sessies door elk van de teamleden enkele hun bevindingen genoteerd. Al deze punten samen worden vervolgens door de alle teamleden aan een stemming onderworpen. Zo komen de grootste aandachtsgebieden voor het hele team naar boven. Uiteraard is het niet zo dat als in het eigen werkgebied iets niet lekker liep er vervolgens niets mee gedaan gaat worden. Vanuit het eigen werkgebied kan dat gewoon opgepakt worden.

De taak van het testen en met name QA is met een blik op QA naar de verbeterpunten kijken. Verder is het belangrijk om te kijken hoe vanuit het testen de belangrijkste aandachtsgebieden meegenomen kunnen worden in het gehele QA proces. QA begeeft zich namelijk overal in de Agile ontwikkeling.

Standups

Elke dag wordt in 15 minuten of minder kort besproken wat ieder teamlid gedaan heeft, wat het teamlid van plan is te gaan doen en wat de knelpunten zijn. Dit wordt gericht aan het team om het team te informeren. Het is belangrijk dat discussies voorkomen worden. Discussies worden offline gehaald.

Vanuit testen zijn de standups essentieel om de testen te focussen op de knelpunten en te achterhalen waar fouten in de software gemaakt kunnen worden.