Hogeschool-Universiteit Brussel · 2014. 6. 19. · 9 De volledige omschrijving van het project is...

Jan Verbeeck Stage portfolio 10/06/2014

1

Naam: Jan Verbeeck

Klasgroep: 3TI (Software Engeneering)

Studentennummer: 243601 / r0342420

Vak: Stageportfolio

Hogeschool-Universiteit

Brussel

Academiejaar 2013-2014

Toegepaste Informatica


2

Voorwoord

Eerst en vooral wil ik mijn collega’s van Cloud Explorers bedanken, vooral Stephen en Tristan.

Daarnaast wil ik ook Tor-Morten Grønli van NITH en Geert Vandendriessche van de HUB

bedanken voor het begeleiden van mijn stage.

Mijn stage is een heel avontuur geweest. In plaats van in België stage te doen heb ik mijn stage

op Erasmus in Oslo gedaan. Deze ervaring bestond dan ook uit veel meer dan mijn stage alleen.

Hoewel ik in het begin sceptisch was, ben ik uiteindelijk heel tevreden over mijn tijd in Oslo. Ik

ben zelfs van mening dat ik in geen beter bedrijf terecht kon komen waar dan ook. Het bedrijf

waar ik stage liep, Cloud Explorers, is nog steeds in de start-up fase maar de mensen die er

werken zijn echte veteranen in de IT-sector. Zij hebben mijn kijk op werken volledig veranderd.


3

Inleiding Cloud Explorers, mijn stage bedrijf, is een start-up die ongeveer 3 jaar geleden is opgericht. In

deze eerste 3 jaar zijn ze er in geslaagd om een fantastisch product uit te bouwen. Ze leggen zich

vooral toe op Mobile en Big Data. Cloud Explorers is een bedrijf waar er een gemoedelijke sfeer

heerst, ze hanteren een principe van 3 F ’en: Freedom, Fun en Financial gain. Ook geloven ze

niet in tijd investeren in planningen maken. Het meest memorabele citaat van Stephen, de CEO,

is dan ook: “De dag dat wij een project manager aannemen weten we dat we niet goed bezig

zijn.” Hun tactiek lijkt zeer goed te werken en daar is maar een verklaring voor: passie. Elke

medewerker is zeer gedreven en zeer intelligent. Het zijn echt de mensen die het bedrijf maken.

Elk van mijn collega’s is een geweldig persoon op zich: slim, vriendelijk en een gevoel voor humor.

Ik heb mijn verslag kort gehouden. In de bijlage vindt u mijn verslag voor NITH, dat iets dieper

ingaat op de opdrachten.


4

Inhoud Voorwoord ................................................................................................................................. 2

Inleiding ..................................................................................................................................... 3

1 Specifieke termen en afkortingen ........................................................................................ 5

2 Beschrijving van de opdracht .............................................................................................. 6

2.1 Oorspronkelijke opdracht ............................................................................................. 6

2.2 Mobile Testing voor Lexus ........................................................................................... 6

2.3 Image Recognition voor Lexus ..................................................................................... 8

2.4 Codan Forsikering........................................................................................................ 8

2.5 Data Visualisatie / TNS Opinion ..................................................................................10

3 Persoonlijk ontwikkelingsplan .............................................................................................12

3.1 Communicatie .............................................................................................................12

3.2 Relaties onderhouden .................................................................................................13

3.3 Verzamelen van gegevens ..........................................................................................14

3.4 Zelfstandig werken ......................................................................................................15

3.5 Toekomst gericht ........................................................................................................16

3.6 Conclusie ....................................................................................................................17

4 SWOT-analyse Codan .......................................................................................................17

5 Tijdsverdeling en planning .................................................................................................18

6 Bijlagen ..............................................................................................................................20

6.1 Slides presentatie HUB ...............................................................................................21


5

1 Specifieke termen en afkortingen NITH: Norges Informasjonsteknologiske Høgskole, de school in Oslo waarvoor ik mijn

stage heb gedaan.

Codan: Codan Forsikering, een groot verzekeringsbedrijf actief in Groot-Brittannië,

Denemarken, Zweden en Noorwegen

TNS: TNS Opinion, het bedrijf achter Eurobarometer, een enquête voor Europese

burgers

Solr: Apache Solr, zoeksoftware

BankID: systeem voor het digitaal ondertekenen van documenten, het merendeel van

de Noren maakt gebruik van dit systeem

ST: Sencha Touch, een framework voor het maken van hybrid mobile apps. Maakt

gebruik van html, CSS en JavaScript

Confluence: product van atlassian. Een soort van interne bedrijfswiki.

D3: Data Driven Documents, een data visualisatie library geschreven in JavaScript

Choropleth: Soort van data visualisatie om waarden aan een geografische locatie toe te

kennen.


6

2 Beschrijving van de opdracht

2.1 Oorspronkelijke opdracht

Voor mijn stage moest ik een projectbeschrijving indienen tijdens de eerste weken bij de school.

In mijn stagebedrijf werd er dan een bepaald project omschreven. Dit project hield in dat ik een

SDK of software development kit moest maken voor hun systeem. Aangezien zij gebruik maken

van Sencha Touch, een reeks Javascript libraries die het mogelijk maken om hybrid mobile apps

te maken, moest ik deze SDK als library maken voor Sencha Touch. Dit wil zeggen dat ik een

JavaScript library moest schrijven die communicatie tussen ST en hun systeem mogelijk maakt.

Ik moest ook een voorbeeld UI maken waaraan sommige functies al vasthingen zodat de

gebruikers, de klanten van Cloud Explorers, een voorbeeld hadden.

Dit project werd echter niets. Bij het begin van mijn stage kreeg ik boeken en video’s

voorgeschoteld die mij zowel JavaScript als Sencha Touch moesten bijbrengen. Ik maakte

gebruik van dit materiaal en begon ondertussen met mobiele apps te maken om te oefenen. Toen

ik deze apps had afgewerkt en deze gebruiksklaar op mijn smartphone had staan werd er mij

echter een nieuwe opdracht aangeboden: Testing op Mobile Devices voor Lexus onderzoeken.

2.2 Mobile Testing voor Lexus

Dit was mijn eerste ‘echte’ project bij Cloud Explorers. Het bedrijf was in onderhandelingen met

Lexus voor een project waarin Lexus een mobile app nodig had om informatie aan potentiele

kopers van hun auto’s te geven. Deze app moest onder andere een foto van de auto uit hun

brochure kunnen scannen zonder dat daar enig token aan verbonden was. Verder in dit document

zal ik hier ver op ingaan. Het probleem bij deze onderhandelingen was dat Lexus zeker wou zijn

dat de app op minstens 15 verschillende devices werkte. Het is echter zeer duur en tijdrovend

om effectief op 15 echte apparaten te testing. Er moest dus een oplossing gezocht worden voor

dit probleem. Aangezien niemand bij Cloud Explorers hier specifiek ervaring mee had werd er

aan mij gevraagd of ik hier onderzoek naar kon doen.

De requirements van deze opdracht waren wel vrij hoog. Ik moest op 15 devices kunnen testen

via een geautomatiseerd proces maar dit moest cross-platform gebeuren, dus zowel voor Android

als iOS. Daarbij was er ook een zeer sterke voorkeur voor real devices. Dit betekende dat ik een

service moest vinden die het toelaat om op echte, fysieke apparaten te testen. Deze tests

moesten ook automatisch worden uitgevoerd en liefst dan nog op een betekenisvolle manier. Dit

wil zeggen dat er niet willekeurig op het scherm wordt gedrukt maar effectief op bepaalde punten.

Een laatste voorkeur was dat deze tests werden opgenomen door de handelingen zelf uit te

voeren op voorhand. Een combinatie van all deze requirements was echter niet realistisch. Als

deliverable maakt ik een vergelijking van verschillende services op de Confluence, een interne

wiki, van het bedrijf.


7

Figure 1 Vergelijkingstabel Mobile Testing


8

2.3 Image Recognition voor Lexus

Dit was het tweede project voor Cloud Explorers en deel van hetzelfde project als mijn eerste. De

bedoeling was net zoals bij het eerste project onderzoek te doen naar iets waar Cloud Explorers

geen ervaring mee had. De projectomschrijving kan u bij het vorige project lezen. De vereisten

van het project waren de volgende: Er moeten afbeeldingen gescand kunnen worden zonder een

token zoals een QR code, het moet werken op fysieke brochures, het moet werken met hun

bestaande technologie (dus cross-platform). Ik was aangenaam verrast hoe snel ik de oplossing

vond. Ik experimenteerde hier wat mee en mijn collega’s waren hier zeer enthousiast over. Gard

kwam naar Oslo en ik hielp hem met de implementatie voor iOS. Dit zorgde ervoor dat mijn kennis

over iOS development een klein beetje uitgebreider werd. Uiteindelijk liet Lexus dit project vallen.

Spijtig maar dit is nu eenmaal de realiteit en hieruit leerde ik dus ook de les dat niet alle projecten

uiteindelijk verwezenlijkt worden.

2.4 Codan Forsikering

Na mijn projecten voor Lexus begon ik te werken aan mijn oorspronkelijke project. Ik kreeg

uiteindelijk een beetje informatie maar liep al snel tegen problemen aan. Kort nadat ik begonnen

was aan dit project kwam Stephen met de vraag of Kenneth en ik een brainstorm sessie wouden

houden met hem over een nieuw project. We stemden toe en Stephen legde ons het project uit.

Het ging om een project voor een verzekeringsmaatschappij, Codan, die een mobile app nodig

had om ongevallen te melden en zo een verzekeringsclaim te maken.

Ook moesten er functionaliteiten in verband met reisverzekering inzitten. Stephen had van in het

begin het idee om alles anders te doen dan de andere bedrijven die voor het project boden. In de

plaats van het aanrijdingsformulier simpelweg te digitaliseren kon Cloud Explorers gebruikmaken

van hun Big Data systemen. Zo zou de informatie die de verzekering al weet niet meer ter plekke

ingevuld moeten worden. Dit verkorte de tijd waarin het formulier ingevuld kon worden aanzienlijk

en maakte het mogelijk om de verzekeringsmaatschappij direct te verwittigen.

Na zijn initiële uitleg liet Stephen de rest aan ons over. Met behulp van een whiteboard en wat

stiften tekende we ons idee in een soort van flowchart uit. Stephen stelde wat veranderingen voor

en keurde dit concept goed. Dit project gaf ons een zeer goed voorbeeld van hoe het er in Cloud

Explorers aan toe ging. De volgende stap was een prototype uitwerken dat aan Codan tijdens

een presentatie getoond kon worden. Dit project nam het meeste van mijn tijd bij Cloud Explorers

in beslag en werd dus een soort van hoofdproject.


9

De volledige omschrijving van het project is als volgt: Als iemand een ongeval met zijn auto heeft,

moet het mogelijk zijn om de verzekeringsmaatschappij direct te verwittigen. Dankzij Big Data

kunnen de basisgegevens van de verzekerde persoon al opgehaald worden. Dit verkleint het

aantal aan informatie dat ter plekke ingevuld moet worden. Vervolgens kan de gebruiker via een

visueel model aanduiden waar er schade is aan de auto. Daarna kan men een schets maken op

een kaart over hoe het ongeval gebeurd is. Dankzij de sensoren van de smartphone en het

internet worden er gegevens als locatie, tijd en weersomstandigheden opgehaald. Tenslotte wordt

alle informatie naar Codan doorgestuurd. Later werd dit prototype uitgebreid met

reisverzekeringsfunctionaliteiten. Zo konden reisverzekeringsdocumenten digitaal worden

opgeslagen, claims aan de hand van rekeningen verzonden worden en de reisverzekeringskaart

gedigitaliseerd worden.

Figure 2 Screenshots van het Codan prototype


10

2.5 Data Visualisatie / TNS Opinion Hoewel het Codan project het meest interessante was om een echt project van begin tot einde te

volgens was het project voor TNS waarschijnlijk het leukste. Tijdens mijn stage bij Cloud

Explorers werd er vaak getoond waar zij op dat moment mee bezig waren. Vaak ging dit over

data visualisatie voor hun Big Data segmentatie dashboard. Deze visualisaties ging van simpele

barcharts tot ingewikkelde infographics. Voor deze visualisaties werd gebruik gemaakt van D3,

een JavaScript library. Toen ik klaar was met het Codan project en moest wachten op het

antwoord van Codan ben ik met D3 beginnen experimenteren. Dit werd aangemoedigd door

Cloud Explorers.

Wanneer Eric naar Oslo kwam liet hij mij zijn werk zien en gaf hij mij zijn code. Blijkbaar maakten

ze voor hub platform gebruik van Highcharts, een andere, beperktere data visualisatie library. Met

highcharts was het echter veel simpeler en sneller om een bepaald soort visualisatie te maken.

Highcharts had echter nier alle visualisaties die men nodig had. Dus had Eric een systeem

ontwikkeld dat Highcharts nog eenvoudiger maakten en waarin ook D3 visualisaties in verwerkt

konden worden. Dit systeem werkte ook met data van hun Big Data platform.

Eric gaf mij de opdracht om een bepaald soort visualisatie, de negative stacked barchart, te

implementeren. Dit was een van de visualisaties van Highcharts maar moest aangepast worden

om in het systeem en met hun data te werken. Vervolgens moest ik ook een choropleth maken.

Dit is een soort kaart met gekleurde vlakken die aan de hand van hun kleur aangeven welke

waarde een bepaald land krijgt. Hij sprak ook over het opslaan van visualisatie als afbeeldingen

of het printen daarvan. Dankzij mijn eerdere kennis over SVG van het Codan project vertelde ik

hem dat dit mogelijk moest zijn. Na een tijd daaraan gewerkt te hebben had ik een werkende

versie voor Google Chrome.

Deze opdrachten waren voor hun algemeen platform maar hadden ze nu nodig voor de data van

Eurobarometer te visualiseren. Eurobarometer is een enquête uitgevoerd door TNS Opinion die

Europese burgers in bijna alle Europese lande ondervraagt over allerlei onderwerpen. Nadat mijn

opdrachten klaar waren kreeg ik te horen dat Highcharts niet gratis is voor commercieel gebruik,

Cloud Explorers wou dit dus uiteindelijk vervangen door D3. Zonder dat me iets gevraagd werd

begon ik zelf aan een systeem zoals dat van Eric dat werkt zonder Highcharts. Momenteel heb ik

een 6-tal visualisaties afgewerkt. Hoewel Cloud Explorers nog niet bevestigd heeft of ze dit gaan

gebruiken waren ze zeer enthousiast.


11

Figure 3 Mock-up dashboard for TNS


12

3 Persoonlijk ontwikkelingsplan Mijn stage bij Cloud Explorers was meteen ook de eerste keer dat ik in contact kwam met een

professionele IT omgeving. Ik had al wel eerder vakantiewerk gedan maar nooit in de IT sector.

Ik had dan ook enkele verwachtingen. Cloud Explorers is echter geen traditioneel IT bedrijf. Ze

zijn helemaal niet strikt of stijf maar hanteren eerder een toffe sfeer en een minder formele relatie

tussen collega’s. Zoals eerder vermeld werken zij met het principe van 3 F ‘en: Freedom, Fun en

Financial gain.

Met de eerste F, Freedom, onderscheiden zij zich al direct van andere bedrijven. Hun planning is

immers niet strikt en als zij iets moeten verwezenlijken dan houden ze samen brainstorm sessies

in de plaats van grote planningsdocumenten te maken.

Dit brengt ons naar de volgende F: Fun. De medewerkers van Cloud Explorers hebben plezier in

hun job en eigenlijk zien ze dit zelfs niet als hun job. IT is gewoon een passie van hun, iets wat

ze graag doen.

Tot slot is er de laatste F: Financial gain. Dit is natuurlijk ook niet onbelangrijk wat zonder winst

zou het geen commercieel bedrijf zijn en zouden ze niet verder kunnen doen met wat ze graag

doen. Toch verkiezen ze altijd jobs waar ze creatief kunnen zijn, iets wat een uitdaging is.

3.1 Communicatie Het communiceren binnen Cloud Explorers ging zeer goed. Deze vrije, toffe sfeer zorgde ervoor

dat communicatie niet al te zakelijk verliep. Er was tijd voor grapjes of willekeurige weetjes. Zo

kon Stephen, de CEO, blijven doorgaan over wat een ‘Mechanical Turk’ is of hoe de Russen er

in slaagden de Amerikaanse bommenwerpers te kopiëren tijdens de Koude Oorlog. Natuurlijk

was er ook tijd om te praten over zaken die wel met het werk te maken hadden. Aangezien

iedereen IT als passie had, werden er vaak mails zowel tijdens als buiten de werkuren gestuurd

met allerlei onderwerpen.

Communicatie gebeurde vooral in het Engels aangezien Stephen van Groot-Brittannië afkomstig

is. Aangezien ik geen Noors spreek werd er met Gard ook in het Engels gecommuniceerd. Tristan

en Eric zijn beide Fransmannen die in België wonen. Zij communiceerde echter ook in het Engels.

Af en toe werd er wel eens een woordje Frans gesproken maar dat is niet mijn beste kant. Met

Kenneth communiceerde ik meestal in het Nederlands maar soms ook in het Engels. Er was niet

zo zeer een ontwikkeling in de communicatie tijdens mijn verblijf. In het begin werd er wel veel

videoconferencing gedaan om de status van ons project te evalueren. Later naarmate iedereen

het drukker begon te krijgen werden dit mails. Ik werkte echter ook zelfstandiger naar het einde

toe en het aantal mails over het project verminderde dan ook.


13

Ik zou niet zozeer zeggen dat mijn competenties qua communicatie verbeterd zijn tijdens mijn

verblijf in Noorwegen. Het gaat echter meer over durven communiceren. Een mailtje sturen om

iets te vragen bijvoorbeeld. Ik denk dat hier nog wel wat verandering in mogelijk is. Ik wou vaak

mijn collega’s niet lastig vallen omdat zij weinig tijd hadden. Maar langs de andere kant hebben

ze liever dat je dat wel doet, ook al hebben geen tijd om de mails direct te lezen. Ik heb hier geen

feedback over gehad en ik denk dat ze hier in het algemeen wel tevreden over waren.

3.2 Relaties onderhouden Relaties met klanten moest ik niet onderhouden. Aangezien Cloud Explorers B2B werkt waren

deze klanten dus vaak managers of bedrijfsleiders. En omdat ik vooral software engineering deed

was het dus niet de bedoeling dat ik met klanten in aanraking kwam. Stephen stelde mij echter

wel af en toe voor aan een klant. Zo kwam ik soms in aanraking met mensen uit de IT-sector.

Stephen was dan meestal vol lof over zijn stagairs. De relaties met collega’s waren gemakkelijk

te onderhouden en waren zeer informeel. Op een vrijdag avond werden er wel al eens foto’s

doorgestuurd getiteld ‘Friday beer’. Als Gard, Tristan of Eric naar Oslo kwamen gingen we dan

ook meestal iets drinken samen.

Stephen nam ons ook vaak mee uit eten. Zo gingen we de eerste dag samen kebab eten, zeer

informeel dus. Tijdens deze ‘zakenlunches’ ging het dat vaak over de toekomst, ontwikkelingen

in IT maar bijvoorbeeld ook series zoals ‘Game of Thrones’. Stephen heeft ons ook eens

meegenomen naar de cinema samen met een voormalige collega van hem. Ten slotte nodigde

Stephen ons ook uit om iets te gaan drinken met twee mensen die hij graag wou rekruteren. Er

was echter een sterk gevoel dat het om 4 mensen ging en dat Kenneth en ik hier ook deel van

maakten.

Mijn competenties qua communicatie zijn in Oslo niet sterk toegenomen. Noren zijn zeer

vriendelijk maar eerder gesloten mensen. Als je ze leert kennen zijn de meeste zeer aangename

mensen. Buiten het werk was het vaak moeilijk om nieuwe mensen te leren kennen. Op school

volgde ik een vak van de masteropleiding. De meeste van mijn medestudenten waren dus wat

ouder dan mij en hadden vaak andere interesses. Sommige brachten bijvoorbeeld al eens foto’s

van hun kinderen mee.

De communicatie binnen Cloud Explorers evolueerde wel een beetje maar dit was vooral omdat

ik mijn collega’s beter leerde kennen. De communicatie verliep eerder als tussen vrienden. En

uiteindelijk is iedereen in Cloud Explorers buiten collega’s ook zeer goede vrienden. Ik had het

gevoel dat ik deel van uitmaakte. Zo hebbe we bijvoorbeeld een uitnodiging gehad om volgend

jaar naar Stephen’s vakantiehuisje te gaan.


14

3.3 Verzamelen van gegevens Een van de competenties die aan bod kwam was het verzamelen van gegevens. Zo moest ik voor

het project voor Lexus onderzoek doen naar mobile testmogelijkheden en image recognition. We

moesten ook deel aantal bronnen van Open Data onderzoeken. Toen ze mij dit vroegen aan het

begin van mijn stage had ik geen idee hoe ik dit moest doen. Ik begon wat op google te zoeken.

Zoals blijkt uit hun gebrek aan grote gestructureerde planningen hadden zij ook niet bepaald een

voorkeur. Ik stuurde Tristan steeds een mail met mijn bevindingen. Deze waren puur gebaseerd

op mijn persoonlijke ervaring en enkele reviews die ik kon vinden.

Tristan vroeg steeds om hier wat dieper op in te gaan en een vergelijking te maken. Uiteindelijk

kreeg ik toegang tot de Confluence van het bedrijf. Een soort interne Wiki. Ik zette hier mijn

vergelijking op waarin ik feiten over elk getest platform in opsomde, gevolgd door persoonlijke

ervaring en ten slotte een tabel met de vergelijking.

Ik schreef ook een advies voor mobile testing. Iedereen bij Cloud Explorers is echter altijd druk

aan het werken en ik kreeg dus niet echt feedback over deze tekst. De e-mails waren belangrijker.

Dit was mijn aanpak voor het onderzoeken van mobile testing. Voor mijn onderzoek naar image

recognition werkte ik op dezelfde manier. Het was echter gemakkelijker om een duidelijke

kandidaat te selecteren en hier ging ik dan mee aan de slag. In de plaats van documentatie

hierover te schrijven kwam Gard naar Oslo en moest ik hem uitleggen hoe hij met dit framework

moest werken.

Zoals ik al zei had ik hier geen ervaring mee. Ik begon echter zoals de meeste mensen zouden

beginnen: zoeken op Google. Dit was verassend effectief. Hoewel dit voor grote, meer zakelijke

bedrijven misschien niet de juiste manier is, was dit voor Cloud Explorers voldoende. Zoeken op

Google is uiteraard geen ingewikkelde vaardigheid. Maar ik leerde vooral dat het belangrijk is om

dingen zelf uit te testen, een soort van trial-and-error. Ook leerde ik een vergelijking maken en

leerde ik met atlassean Confluence werken. Over mijn opzoekwerk heb ik uiteindelijk ook werk

heb ik weinig feedback gekregen over het eindproduct. Ik kreeg echter na elke mail wel wat

feedback. Hier is een voorbeeld van zo’n mail:


15

Figure 4 Mail van Tristan met feedback over Image Recognition

3.4 Zelfstandig werken Voor het project voor Codan moesten Kenneth en ik zelfstandig werken. Stephen gaf ons uitleg

over het project en brainstormde kort met ons. Hij had echter niet veel tijd en liet het meeste dus

aan ons over. Na brainstorm sessies die lang na onze werkuren doorliepen kwamen we met een

soort prototype. Stephen gaf hier dan zijn mening over. Nadat het concept was uitgewerkt gingen

we over naar een prototype. Dit was een functionele versie van hoe de app uiteindelijk ging

werken. Deze was enkel bedoeld voor een presentatie te geven en dus niet als eindproduct.

Stephen vertaalde voor ons de verwachting van de verzekeringsmaatschappij en vertelde ons

wat hun doel was. Wij verwekte dit steeds in onze applicatie en voegde functionaliteiten toe naar

gelang Stephen er naar vroeg. Dit werd dus volledig zelfstandig gedaan en zonder vereisten in

verband met technologie. Dit wil zeggen dat we zelf alle functionaliteiten moesten uitdenken. Het

was echter een zeer goed project en zowel Codan als Cloud Explorers waren zeer blij met het

resultaat.

Ik denk dat ik in verband met zelfstandig werken het meeste vooruitgang heb geboekt. Vooral

door de aanmoediging van Cloud Explorers hebben we het Codan prototype tot een goed einde

kunnen brengen met zeer weinig hulp. Een sleutelmoment in deze ervaring was toen Vincent aan

Kenneth en mij vroeg hoe de afbeeldingen voor de applicatie er moesten uitzien. Dit gaf me ook

meteen een voorsmaakje van decision-making. Voor ik vertrok kon ik ook al zelfstandig zerken

zoals blijkt uit mijn bachelorproject maar toen werkten we met 3 nauw samen. Hoewel ik aan het

Codan project ook met Kenneth samenwerkte was het werk zelf zelfstandig met vaak een

evaluatie tussen ons twee.


16

Figure 5 Bedankingsmail van Stephen voor het Codan project

3.5 Toekomst gericht Hoewel de applicatie voor Codan maar een prototype was heb ik van in het begin gewerkt met

oog op de toekomst. Ook bij het data visualisatie project. Deze competentie is eigenlijk vooral

geëvalueerd tijdens mijn werk aan mijn bachelorproef. We waren daar namelijk aan begonnen

door verder te bouwen op een eerder project. Echter toen we keken naar wat het uiteindelijke

resultaat moest zijn, besloten we bijna geheel opnieuw te beginnen om ons werk in de toekomst

gemakkelijker te maken.

Bij het Codan project ben ik ook direct beginnen experimenteren met technologie die het in de

toekomst gemakkelijker zou maken als er bijvoorbeeld naar grotere schermresoluties wordt

verandert op smartphones. Dit was naar mijn inzien een zeer goede zet aangezien ik later tijdens

mijn werk met data visualisatie geconfronteerd werd met dezelfde technologie. Deze keuze

beloonde dus op twee verschillende manieren.

Ondertussen ben ik dus zeer toekomst gericht. Dit zette mij dan ook aan voor mijn laatste project.

Ik werd gevraagd om iets te maken voor Cloud Explorers in verband met data visualisatie. Ik

voltooide deze opdracht maar later kreeg ik te horen dat het project waaraan ik gewerkt had

gebruik maakte van een technologie die niet Open-Source is voor commercieel gebruik. Ik ben

dan zelf beginnen experimenteren en ben er in geslaagd om deze technologie compleet te

vervangen met een Open-Source framework waardoor het project meer future-proof werd.


17

3.6 Conclusie Hoewel deze competenties vaak niet merkbaar geëvalueerd zijn tijdens mijn stage is mijn ervaring

met deze competenties wel gestegen. En hoewel competenties zeer belangrijk zijn is bij Cloud

Explorers nog altijd passie en de interesse om meer over IT te leren het belangrijkste. Cloud

Explorers heeft mij zeer hard beïnvloed en getoond dat werken en doen wat je graag doet samen

gaan. Ook innovatief zijn is iets wat ik bij Cloud Explorers geleerd heb. Mijn beeld over de IT-

industrie is zeker veranderd en Cloud Explorers is een bedrijf waar ik zeker zou willen werken.

Gelukkig hebben we hier dan ook een jobaanbieding gekregen.

4 SWOT-analyse Codan

Innovatief

Visueel gericht

Werkt slecht op Windows Phone

Uniek

Nieuwe manier van vragenlijst invullen

Nog prototype

momenteel niet gebruiksvriendelijk


18

5 Tijdsverdeling en planning Aangezien Cloud Explorers op een zeer losse manier werkt en niet op voorhand plant heb ik geen

bepaalde planning. Langs de andere kant moet je zeer flexibel zijn om bij Cloud Explorers te

werken. Hier vindt u een overzicht van de tijdsverdeling en op de volgende pagina een tijdslijn die

ik heb gemaakt met D3, de data visualisatie library.

Event start end

Arrived in Oslo 7/02/2014

Started Internship 10/02/2014

Social Media Mangagement Course 11/02/2014 20/02/2014

First info about main project - Start js research and ST 16/02/2014 21/02/2014

Mobile testing research 21/02/2014 7/03/2014

Image recognition research 5/03/2014 19/03/2014

Start SDK project 19/03/2014

AJAX and authorization testing 19/03/2014 26/03/2014

First info about Codan, map and geodata research 26/03/2014 10/04/2014

Start Codan prototype 10/04/2014 16/04/2014

Vacation Tromso 16/04/2014 23/04/2014

Start Open Data Project 23/04/2014

Mix of Open Data and some work on SDK 23/04/2014 2/05/2014

Start Data Visualisation 2/05/2014 9/05/2014

Data Visualisation for TNS 9/05/2014 22/05/2014

Adding Travel to Codan 22/05/2014 3/06/2014


19


20

6 Bijlagen 1. Slides presentatie HUB

2. Paper NITH

3. Slides presentatie NITH


21

6.1 Slides presentatie HUB


22


23


24


25


26


27


28


29


30


31

31.05.2014 Studentnumber: 701975 Title: Internship at Cloud Explorers AS Page 1 of 25

Student name Jan Verbeeck

Student number 701975

Signature

The signature of the student testifies that all content is the student’s own work and that all sources are referred to.

Course code and name PJ6000

Project title Internship at Cloud Explorers AS

Date of submission 30/05/2014

Number of pages 15 (excluding apendices)

Number of words 4101

Work placement project report – PJ6000


Internship at Cloud Explorers AS

Abstract To complete my education applied IT at College University Brussels I had to do an internship. I did mine at a great yet small start-up called Cloud Explorers. While planning wasn’t very strict Cloud Explorer consists of a couple of very smart and wonderful people. Some of the topics I learned about at Cloud Explorers include: mobile testing, image recognition, hybrid mobile app development and data visualization. I truly had an amazing time and it’s almost impossible to describe it.


Contents

1. Introduction ....................................................................................................................................... 4

2. Project Plan........................................................................................................................................ 5

3. Project: Codan Forsikring .................................................................................................................. 7

4. Project: Lexus Mobile Testing Research .......................................................................................... 11

5. Project: Lexus Image Recognition ................................................................................................... 12

6. Data Visualisation ............................................................................................................................ 13

7. General Results & Discussion .......................................................................................................... 14

8. Evaluation of Project Plan ............................................................................................................... 15

9. Conclusion ....................................................................................................................................... 15

10. References ..................................................................................................................................... 15

11. Appendices .................................................................................................................................... 16

Appendix 1: Cloud-based testing solutions ..................................................................................... 16

Appendix 2: Automated UI Testing ................................................................................................. 24


1. Introduction My name is Jan Verbeeck, I’m an exchange student from Belgium. I study Applied Informatics at College University Brussels. This internship is part of my final semester as a bachelor in Applied IT. I did my internship at a company called Cloud Explorers. Right from the start it seemed like an interesting company because they were doing a lot of different things mostly focusing on Big Data and Mobile. Cloud Explorers has an office in Oslo and one in Belgium. While still a small company it is truly an international one. One of the founders, Stephen is an Englishman who lives in Oslo, then there’s Gard who lives on the east coast of Norway. There’s also Tristan & Eric, two Frenchmen and co-founders who live in Belgium and finally there’s Vincent who lives in France. All of these people really nice and friendly and possess a huge amount of knowledge of almost all things IT. For my internship I needed to list a single project. However this project gradually became less important as I started to get more involved with the day-to-day business of the company. The original project, making an SDK for their mobile Prism platform got put on hold. Instead I got involved in a project for a potential customer. I was tasked, together with Kenneth to come up with a solution for accident claims for an insurance company. This ended up becoming somewhat of my main project. There have also been some smaller projects I did for Cloud Explorers. These include research for mobile testing, image recognition and data visualization. Their main product is the Prism platform. It consists of different technologies. It’s a Big Data platform that uses Apache Solr to search and return data. It also makes use of the content management system Drupal for things like creating a custom dashboard or creating marketing campaigns. One of its main functions is creating segmentations so you can for example target a specific group of people for a marketing campaign. The prism platform also provides a system for portfolios and storing & signing documents. While Cloud Explorers focused on the financial sector first, they are now moving towards retail customers.


2. Project Plan The original plan was to complete a specific project for them. When Tristan first told me about it I was excited because it seemed like a very interesting project. Everything started out fine. I got some books and tutorials on JavaScript and Sencha Touch. I completed the tutorials and showed them to Tristan. Eventually I was running out of tutorials and I needed something else to do. Filling my days reading about JavaScript wasn’t really the most fun to do. So Tristan gave me a new assignment: Research mobile testing platforms for Lexus. After I completed that assignment I went on to the next one: Image recognition also for the Lexus project. More than a month had passed from starting my internship at this moment. However I don’t regret working on the Lexus project because I gained a lot of knowledge from it. Everyone at Cloud Explorers is very busy, it’s a small company and they are still in their start-up phase. When Tristan comes to Oslo he’s usually in a meeting. However he explained what he wanted to do with the project. He helped me with the first steps to get started. I had to be able to log in to their service using Sencha Touch. He drew a sketch about the basic structure of their systems and how the framework should work. Then I started working on the project but the structure wasn’t entirely clear and Tristan ended up changing some things. Meanwhile I was having a lot of problems getting the login to work. I had trouble getting AJAX to work in Sencha Touch. However a few days after I started on the SDK. Stephen asked Kenneth and me if we would be interested in having a brainstorm session with him. Eventually this project for Codan became more of a main project and work on the SDK ceased. While Stephen was busy writing up the proposal I had a lot of time to really make a great prototype. I ended up spending a lot of time on getting the situation sketch on the map working. Eventually after Easter I took another look at the SDK project and finally found out that my code had been correct the entire time. The problem was with the testing environment. I tested the app on Chrome. However Chrome’s insane security settings didn’t allow me to log in. I used another browser to test it called Maxthon. And eventually it also worked on the phone. By this time it was clear that this project didn’t really have priority. I asked Tristan about a new project he had mentioned before and if there were other things I could do for the SDK. He didn’t say anything about the SDK but I had a new project: open data research. I didn’t list it here as a project because there’s not much to tell about it. I found some resources and test tools like OpenRefine and Data Wrangler. Soon after that I started experimenting with D3, the data visualization library. Eric, who usually creates the visualizations came to Oslo and showed me what he was working on. He said I could add some charts to his work. I ended up starting on a small project on my own. On the next page you’ll find a timeline which I created using D3.


3. Project: Codan Forsikring The project for Codan is the largest project I’ve worked on while doing my internship. It was more like my main project instead of the original SDK project. The project started out with the purpose of competing with other companies to secure a contract with Codan Forsikring. Codan was in need of a mobile solution to report accident claims right after the accident happened. To do this they wanted an app where you could make insurance claims. This was required to secure a large client who had requested such technology. Apart from that they were also looking for a solution for travel insurance. This project kicked off when Stephen asked us if we would like to have a brainstorm session with him to see how it’s like to work on a real project. I agreed and he explained the project. Right from the start he wanted to do something different than the competitors. Basically every app that’s out there which lets you report damage works the same: You fill in a form and send it to the insurance company. However using their big data platform Cloud Explorers could greatly reduce the amount of things you need to fill in and get your information which the insurance company already has. Kenneth and I had multiple brainstorm sessions about his project and together with Stephen and a lot of help from the whiteboard we came up with something that seemed like it would work. It would be a step ahead of the competition for sure. However the first part of this project didn’t work out as Codan’s funding fell through. They failed to secure the client and thus had no need for the app anymore. However they had been quite excited about the technology during earlier meetings. Eventually Codan came to the point where it was about to secure another huge client. If they would secure it they would have the funding to implement our technology. They also wanted to have the travel insurance functionality in the app which included storing travel documents digitally and having a digital insurance card. For this purpose we added these functionalities to the accident reporting app. Goals/requirements Part A:

Provide a way to report an insurance claim from an accident right after it happened Create a prototype to provide an idea of the functions of the app

Part B:

Provide a way to have your travel documents digitally on a smartphone

Eliminate the need for a physical insurance card by making it digital Theoretical grounding Part A: Currently when you are in an accident you usually have to fill in a paper form. After that you have to bring that form to the insurance company or call them to report your claim. The theory behind this first part is that you don’t have to fill in a paper, that the insurance company instantly knows an accident has happened and that you don’t have to fill information that the insurance company already knows anyway. We didn’t base our app on any existing apps but rather used common sense to create something that is both easy and fun to use.


Part B: The purpose of the second part is to eliminate the need for a physical insurance card and to make sure you don’t have to have tons of documents with you when you are travelling. This can easily be achieved by digitalizing everything by means if scanning or photographing documents. For the travel card itself the information can be retrieved from Codan’s databases and eventually the big data platform. Design/Architecture The solution we came up with for Codan was a complete product of our own imagination. It came to be by using a whiteboard to sketch use cases. During long brainstorm sessions we kept improving our concept by simply employing logical thinking and common sense. While we don’t have any experience with insurance claims we looked at it from the point of view of the user, keeping in mind what is technically possible. For the prototype we used Sencha Touch. This is a framework to create hybrid cross-platform apps based on another Sencha product: Ext-JS, which is a JavaScript framework to create webapplications. I chose Sencha Touch because Cloud Explorers had experience with it and it was the same framework I was using for my initial project. So I had learned to use it from the start. It was also likely that the commercial version of the app would eventually be created using Sencha Touch. Perhaps it doesn’t seem like the optimal thing to do, to start working on a prototype using the same technology it will eventually be implemented with. However since it uses web technology the app can be tested instantly in a browser without compiling the code. It also paid off for the interactive demo of the second part. The demo was a really good indication of how the actual app would be. Sencha touch is based on the MVC or Model-View-Controller model. This means the prototype employs this model. However since it’s a prototype that is meant to show the user interface and imply the possible functions the largest focus is the View part. One of the things we envisioned for the app is geolocation of the accident and allowing the user to sketch the accident on the map using models of cars. For this we used Google Maps which already has bindings in Sencha Touch. I also made use of SVG files to replace most images. SVG has a great advantage because it doesn’t lose quality when you scale it. Simple SVG image are usually smaller in size than there PNG counterparts. I chose them because of this advantage but also because it was a challenge and would make the app more future proof. One of the positive effects was that the images looked great on tablets. However I didn’t get them to display correctly on Windows Phone and eventually added a PNG fallback. However experimenting with SVG would later help me a lot when I started with data visualization.


Results & Discussion While the first part of the project didn’t work out for Codan. I think it’s still a success. We came up with something that nobody has ever done before. We compared a lot of apps and came to the conclusion that they are basically just forms you have to fill in. The goal of the project wasn’t to make a complete app but rather a prototype of what would be possible and I think we succeeded in doing that. It could use some improvements to the user friendliness of the accident sketching. But as a demo app it works great. For the second part we added some extra functionality to the original app from the first part. While we didn’t have a lot of time to do it, it worked out great. When Stephen went to demo this app they were blown away. Currently Codan is still in the process of acquiring this huge client. But things are looking promising. Should they secure it, they would be extremely interested in our solution. We are also still working on this app at the moment. Conclusion This certainly was the largest and perhaps most interesting project. It showed me how real project work. I was with this project from the concept stage up to an interactive prototype. This project gave me a taste of what it’s like to be innovative. Doing something that no one has done before gives you a truly amazing feature. Especially when you read things about people that started working on it while we had already completed it. One of the most important skills I learned from this project was probably brainstorming. There’s something about just drawing on the whiteboard, thinking about it and discussing it with others that no other method or software can compete with. It’s also great when you are brainstorming till early hours while eating pizza and trying out technology like the Leap Motion.


Here are some screenshots from the Codan project:


4. Project: Lexus Mobile Testing Research This is my first real project at Cloud Explorers that I started working on while I was learning how to work with Sencha Touch. Cloud Explorers was competing to make a mobile application for car manufacturer Lexus. However Lexus had some questions about compatibility with different kinds of devices. They wanted to make sure the app would work on a lot of devices. While the contract wasn’t secured yet, some research needed to be done. Goals/requirements

Search for mobile testing solutions Make a comparison of these solutions The testing needs to be performed on 15 devices or more The tests need to be cross-platform because it’s an hybrid app The user interface needs testing in a useful way (no random presses) The tests have to be automated The tests preferably needed to be recorded (on a device) The tests preferably have to be on real devices

Results & Discussion Nobody at Cloud Explorers had any experience with mobile testing. So I started researching. I think the requirements were quite high. But I was amazed how quickly I found what seemed like a good solution. However it didn’t meet all requirements. Eventually it seemed like an ideal solution that meets all requirements doesn’t exist. Something I expected from the start. I compared the different solutions based on free trials which I used to test a demo app. And based on their features. So I couldn’t only compare their features but also give a basic idea of how they would work. The results of this research where published on the company’s Confluence, their internal wiki. Conclusion While this project seemed quite difficult and dull at the start it turned out to be rather interesting. It surprised me because most current testing frameworks aren’t very rich in features. It even seems like there is a market for cross-platform UI testing using real devices. It’s also interesting to see how all these frameworks are chancing. I started in February and I still regularly get mails about updates of testing frameworks. It’s quite impressive to see how some frameworks have changed in just a few months.


5. Project: Lexus Image Recognition For the Lexus project Cloud Explorers needed to implement another special function they didn’t have experience with: Image Recognition. The idea was that Lexus would provide brochures with their products. Customers would then be able to scan the cars in this brochure by using their smartphone. However they didn’t want to put tokens like QR-codes in the brochure. Goals/requirements

Be able to scan images of cars in a brochure to recognize them Must work on the (glossy) paper of the brochure Must be cross-platform Should be compatible with Sencha Touch

Results & Discussion This was the second project I did for Cloud Explorers and a part of the Lexus project. Yet again I was amazed at how quickly I was able to find what seemed to be the perfect solution: Moodstocks. And eventually it turned out to be this way. Like with testing frameworks I started to compare image recognition software. Although it wasn’t possible to test most of them I quickly came to the conclusion that Moodstocks was the only viable option. Moodstocks works with Phonegap which is a framework that packs hybrid apps like the ones you can make with Sencha Touch in a native format. I tried implementing it using Sencha Touch using a demo app from their site. However that wasn’t without problems. Eventually I worked out the problems and helped Gard compile the demo for iPhone. Though in the end Lexus dropped the project in favor of another one. However my research wasn’t in vain because it might be useful in the future and it also gave Cloud Explorers something to demo to potential clients. Conclusion It’s really a shame that Lexus dropped this project. At first I thought my research was wasted but now I’m fairly sure it will come in handy later on. I gained some knowledge in 2 new areas of expertise: image recognition and creating projects for iOS.


6. Data Visualisation Data visualisation isn’t a project per se. But it has become some kind of a passion and I ended up spending quite some time with it during my internship. It is one of the things that reflects the way Cloud Explorers works. During my internship I was introduced to their product which consists of lots of different technologies. One of the important things is data visualisation. Data visualisation is mostly Eric’s job and I came to admire his work. So I started experimenting with it. Something that was only encouraged by Cloud Explorers. This let me to creating some visualisations for Eric and starting on some kind of framework. The visualisations are part of a demo for TNS Opinion and are meant to display the data from Eurobarometer in a nice way. Goals/requirements

Make a stacked negative bar chart using Highcharts Implement a D3 chart Create a choropleth Make it possible to save charts as Images and print them (Self-defined goal) Create a framework without Highcharts.

Design/Architecture Currently Eric is working on a framework to display all kind of visualization based on Highcharts, a framework for displaying charts and other visualizations. Why is he making his own framework? Well in Highcharts you can’t make your own visualizations. Highcharts also has a lot of options that usually don’t need to be adjusted. By creating a framework you are able to just choose which type of visualization you want and it will be generated using default values which you can still adjust. However this means that every type of visualization needs to be implemented in the new framework. Eric asked me to do this for the stacked negative bar chart. After I implemented the new chart I looked at how to implement saving charts as an image. I found a solution based on my previous work for the Codan project which makes extensive use of SVG files. The Highcharts solution uses server-sided code to convert the images. This potentially includes a security risk because all charts go through their servers. My solution is completely written in JavaScript and thus client-sided. It currently only works in Google Chrome. But there’s a good indication that it might work in Firefox as well with some additions. But the framework isn’t limited to Highcharts. By overwriting the render function of a chart you can create a completely different chart. For example by using D3 (Data Driven Documents). D3 is a very powerful framework that allows you to create any data visualization that you can possibly imagine. My second challenge was to implement a choropleth (a map with colored regions based on data). It’s not that difficult because you can just implement the entire chart straight into the render function. However when you use D3 maps they still use a Highcharts type of structure. Especially to be able to export them to images you need to merge the Highcharts structure into the D3 visualization. While creating the choropleth I also created a wrapper for D3 that merges it with the Highcharts structure.


Later Stephen told me that they wanted to get rid of Highcharts eventually because it’s not free for commercial use and their product is marketed as using open-source software. D3 however is open-source. This is when I started over from scratch with a framework of my own. It’s still based on Eric’s but it ditches Highcharts completely in favor of D3. Because D3 is so powerful everything from Highcharts can be implemented using D3 as well. Results & Discussion I’m really happy with the results and others at the company seem to like it as well. I haven’t had feedback from Eric yet. Currently my framework has only about 6 types of charts but you can implement new ones very quickly. Conclusion Data Visualization is really awesome and has become somewhat of a passion. You can just do amazing things with it. If you combine Cloud Explorers’ Big Data platform with D3 you get truly amazing results. Here’s an example of my work:

Data Visualization dashboard using D3 (unspecified data from Eurobarometer)

7. General Results & Discussion Overall I’m very happy with the results myself. Instead of focussing on just one project I felt like I really was a part of the company. Cloud Explorers gained quite some knowledge from me thanks to my research in mobile testing, image recognition and open data. Furthermore our Codan prototype might provide to be a great help in securing a deal with Codan Forsikering. So I got a feeling we really helped the company move forward.


8. Evaluation of Project Plan There was no project plan from the start but I don’t think that’s a disadvantage. I learned to be flexible and got the chance to work on multiple projects instead of just one. This meant that I was able to acquire a wider spectrum of knowledge. Instead the lack of time of my colleagues was more of a disadvantage. However I don’t blame them because they are in the progress of finding the right customers. Cloud Explorers isn’t really about planning. It’s about being innovative, doing what you like and of course trying to earn money by doing it. And they seem to get away with it. 9. Conclusion I’m not even sure how to describe my experience at Cloud Explorers. I couldn’t have imagined a better place to do my internship at. Not only is the company great but so are the people who are part of it. Each of them is a fun and interesting individual. They are all really passionate about their work and amazed me with their wide range of knowledge of IT. I learned a lot at Cloud Explorers. Probably more than I’ve learned during any semester in school. Cloud Explorers works on a principle of 3 F’s: Freedom, Fun and Financial gain. This really reflects what the company is about. Some of them are SCRUM certified but they don’t really believe in SCRUM. They kind of just do what they are best at. I think the key element in this is that they are all very passionate about their job. It’s almost like not going to work every day, it is just doing what you like. I really like one quote from Stephen. He said: “The day we hire a project manager, we know we aren’t doing well.” At Cloud Explorers I acquired a large amount of knowledge on new subjects and on familiar ones as well. I learned the power of JavaScript and how to use it. Got experience with AJAX, JSON, CORS, etc. I learned about open data and data visualization. I got an insight in the industry, met a lot of people and had the feeling I was really a part of the company. So I think I can tick off every box when it comes to internship experiences. And I might have even acquired a contract at the company. 10. References Resig, J. and Bibeault, B. (2013). Secrets of the JavaScript ninja. 1st ed. Shelter Island, NY: Manning.


11. Appendices Included here are two documents I wrote for Cloud Explorers on their internal wiki. One is a comparison of cloud-based testing solutions. The other is an advice about Automated UI Testing.

Appendix 1: Cloud-based testing solutions

Cloud-based testing solutions Cloud-based testing is the ideal way to test apps on multiple devices while you don’t have to

buy each device. The following services are solutions for testing apps on mobile devices. There

are a lot of differences and variables to hold into account when considering a solution. I listed

the facts and my experiences below. All these solutions used the Android version of my Note

App to run the tests. This means my personal experience comes exclusively from an android

perspective.

Tested solutions

These solutions all provided some sort of trial. Not all of them provided an automated testing

trial so it is possible that there’s a difference between my experience and the actual automated

testing product.

AppThwack

Site: appthwack.com

Company: AppThwack

Platforms: Android, iOS and Web

Pricing: pay for testing minutes monthly, 100 free minute trial available

Type of devices: Real devices only

Testing type: Automated only

UI Testing: Yes, Calabash and standard automation

Test recording: No

Screenshots: Yes

Amount of devices: 248 (202 Android + 46 iOS)

Reporting: CPU, Memory, Threads and Frame draw time and logs about Install, Launch and

Explore, Exerciser Monkey, Uninstall

Tested: yes

https://appthwack.com/


Personal experience

Apptwack is a great service, it has lots of devices and easy to use. It provides support for a lot

of testing frameworks. (Stress test, JUnit (Robotium, Espresso), UI Automator, Calabash for

Android and Stress test, Calabash, KIF 1.0, OCUnit, UI Automation, XCTest for iOS) The

reporting is also straightforward but does mostly list hardware performance. Without your own

UI tests it will use the UI exercise monkey. The screenshots are a nice addition and show how

the UI looks on al screens and orientations. However there is no way to control when these

screenshots are made unless you configure your own tests. The biggest advantage is that it

only uses real devices. The disadvantage is that it doesn’t have its own tools like a UI test

recorder so you have to write all tests in advance using code.

DeviceAnywhere

Site: keynotedeviceanywhere.com

Company: Keynote


Pricing: per month, 10 minute free manual testing sessions


Testing type: Manual and Automated

UI Testing: Yes, using built-in tools

Test recording: Yes

Screenshots: Yes, even live recordings

Amount of devices: 500+

Reporting: From logs to full recordings

Tested: yes, only manual

Personal experience

I didn’t take much time to test this test suite extensively because the trial only consists of

manual testing. What it does is it gives you a real device that you can control remotely. The nice

thing about this is that you can do anything with the device, you are not limited to the app you

are testing. However this also means you have to install the app yourself. I didn’t get a chance

to test out automated testing. But I think automated testing is where this test suite really shines.

The manual testing is fine but the performance is rather poor.

http://www.keynotedeviceanywhere.com/


Perfecto mobile

Site: perfectomobile.com

Company: Perfecto Mobile


Pricing: per project or subscription, free manual test available

Type of devices: Real devices and emulators

Testing type: Manual and Automated

UI Testing: Yes, using built-in keyword-based functions

Test recording: No (not verified)

Screenshots: Yes (not verified)

Amount of devices: 100+

Reporting: Entire device session data

Tested: yes, only manual

Personal experience

Perfecto mobile is comparable to DeviceAnywhere and works using the same principle: you

control a real device remotely for manual testing. However perfecto mobile seems to have more

options and some basic reporting for manual testing. I also didn’t try out the automated testing

but the test suite is probably similar to DeviceAnywhere. As with DeviceAnywhere performance

is rather poor.

http://www.perfectomobile.com/


Telerik

Site: telerik.com

Company: Telerik

Platforms: Android, iOS, web, (Windows phone)

Pricing: Monthly, free trial available

Type of devices: Emulators

Testing type: Manual and automated

UI Testing: Yes, with scripting

Test recording: no

Screenshots: no (not verified)

Amount of devices: 5 emulators (3 iOS, 2 android)

Reporting: Full reporting

Tested: yes

Personal experience

Telerik seems to promise a lot on their site, but it seems to only deliver on few things. Telerik

consists of a cloud-based app builder. This is fine when you use it to build apps from scratch

and you can use it to make phoneGap apps. But Telerik seems to dislike existing apps. They

provided project importing using github repositories but sadly this functionality almost never

works. Telerik isn’t very user-friendly and seems to lack detailed documentation. I couldn’t even

figure out how to start testing. In short Telerik seems promising but still needs a lot of work

before it is usable.

http://www.telerik.com/


Testdroid

Site: testdroid.com

Company: Bitbar


Pricing: monthly, free test available (only nexus devices)


Testing type: Automated

UI Testing: Yes

Test recording: yes (Android only)

Screenshots: Yes

Amount of devices: 300+ (280+ Android, 20+ iOS)

Reporting: Logs, performance

Tested: yes

Personal experience

Testdroid is very much like appthwack but I think it’s slightly worse. Testdroid has nice features

and works well. However somehow the tools don’t have a very professional feel. I also noticed

the logs didn’t seem to work (probably a small bug) and the report was quite limited. Like their

name suggests they also seem to favor android. For example their UI test recorder only works

on android. Testdroid also seems determined to sell their product and they tried to call me

several times. Overall it looks like a nice product that could use a design overhaul to make it

look more professional and they could enhance their iOS support.

http://testdroid.com/


TestObject

Site: testobject.com

Company: TestObject

Platforms: Android and web, iOS support planned

Pricing: monthly, 1 free app

Type of devices: Mostly emulators, some real devices (11)

Testing type: manual and automated

UI Testing: Yes

Test recording: Yes, only on emulators

Screenshots: Yes

Amount of devices: 51 (40 virtual, 11 real)

Reporting: Full logs from stress tests and steps from UI tests

Tested: yes

Personal experience

My experience with TestObject has been very positive. Of course the biggest disadvantage is

that they use mostly emulators. However TestObject doesn’t see of it as a disadvantage. But

one definitive disadvantage of using emulator is that they don’t handle PhoneGap well: There’s

a graphical bug when using an emulator with Phonegap which shows black squares on the

screen and makes it untestable. However I built my project as a Sencha Touch app without

PhoneGap and that works fine. TestObject offers a system similar to AppThwack. It runs stress

tests using UI exercise monkey, shows the complete logs and shows screenshots. It also tests

on a few real devices.

The standard test are useful but it really starts getting interesting when you make your own tests

using the recorder. These tests use image recognition to duplicate the tests on all devices. This

means that your test are dependent on this system doesn’t always work. But if you take some

time to build a test the results will be useful at least. (You have to factor in a percentage of fails

due to the recording software). Currently these recorded tests only work on emulators. But you

can also manually test on both emulators and real devices. Their customer support was very

good and they told me iOS support is planned for the future.

http://testobject.com/


Functionality table

Platforms Pricing Devices Testing UI testing Test

recoding

Screenshots # of

devices

AppThwack Android, iOS, HTML5

Monthly

(Per

minute)

Real Automated Yes, using

calabash

or native

automation

No Yes 248

DeviceAnywhere Android, iOS, HTML5

Monthly Real Manual &

automated

Yes, using

built-in

tools

Yes Yes 500+

Perfecto Mobile Android, iOS, HTML5

Per

project

or

monthly

Real and

emulators

Manual &

automated

Yes, using

built-in

tools

No Yes 100+

Telerik Android, iOS, HTML5

Monthly Emulators Manual &

automated

Yes, using

built-in

tools

No No 5

TestDroid Android, iOS, HTML5, WP

Monthly Real Automated Yes, using

built-in

tools

Yes

(Android

only)

Yes 300+

TestObject Android, HTML5

Monthly Emulator

and some

real

Manual &

automated

Yes, using

built-in

tools

Yes

(Emulators

only)

Yes 51


Untested solutions

The following solutions are all for testing apps but aren’t necessarily even cloud based,

automated or just weren’t available for testing. Some of them I only found recently and I just

didn’t have the chance to test yet. Some of these are traditional Business-to-business testing

services. I list them here to show what other testing solutions are out there. The provided info is

mostly based on their sites.

360 Logica: A testing and consultancy company. Offer a complete testing service to

companies.

Apkudo: Very simple interface to test android apps. Tests if apps install correctly and runs a UI

exerciser monkey. Also provides logs. Offers 239 android devices. (Tested briefly)

Appurify: Provides automated tests for iOS and Android using real devices. Also provides

support for a wide range of your own functional automation tests.

Bsquare: Offers automated testing on Android and different Windows mobile systems.

Contus Support Interactive: Provides automated tests on real devices. Supports iOS, android

and Windows Phone.

Infostretch: Provides various quality assurance services and (mobile) testing services.

MobileLabs: Offers cloud-based testing on real devices for android and iOS.

QualityLogic: Offers QA and testing services to businesses.

Ranorex: Offers test recording on real devices and provides testing of anything from desktop to

mobile.

Sauce Labs: Seems to use emulators. Supports various tests using appium, a test automation

framework.

SOASTA: Has recording software to record tests and provides testing on real devices. Supports

iOS and Android. Also has cloud-based testing.

StarDust: French mobile test lab that offers testing solutions to businesses on request. They

run the tests for you.

Xamarin: Offers cloud-based testing, owners of calabash. Seems focused on mobile C#

development.

XBOSOFT: Provides all kinds of testing from acceptance to user experience and QA services.


Appendix 2: Automated UI Testing

Automated UI Testing Unit tests are great for testing your code but ultimately the things end-users get to see is the UI

of your app. The problem with UI is that it depends on a number of factors. First of all there are

different platforms like iOS, Android and Windows Phone. However this problem is easily solved

by using hybrid apps. To make hybrid apps we use Sencha Touch and PhoneGap. However

even when using the same platform there are other things to take into account. Resolution and

dpi can differ a lot depending on the device especially if you look at the difference between

phones and tablets. To make sure we our apps works on different devices it has to be tested.

But testing 100s of devices isn’t really practical that’s why we resort to automated testing. A list

of solutions for automated UI testing can be found here: Cloud-based testing solutions.

Writing tests

Writing UI tests is a pretty straightforward but tedious process. It’s counter-intuitive to write code

to test a graphical user interface. However every form of UI testing has code behind it. There

are ways to make writing UI tests easier. A good example of this is Calabash which makes use

of a language called Gherkin which is part of the behavior driven Cucumber framework.

Calabash makes it possible to write UI tests in a human-like language. These language is

parsed into predefined steps by Gherkin. Here’s an example of Calabash:

Calabash example

Feature: Rating a stand

Scenario: Find and rate a stand from the list

Given I am on the foodstand list

Then I should see a "rating" button

And I should not see "Dixie Burger & Gumbo Soup"

https://cloudexplorers.atlassian.net/wiki/display/ZERO/Cloud-based+testing+solutions


Recording tests

One tool that drastically improves the speed to write tests is recording a test on either a real

device or an emulator. Recording tests is a double edge sword however. While it simplifies the

test creation process it still relies on a test that is recorded for a specific device. This means that

if the test is performed on a different device with different resolution or dimensions they can’t

just use fixed positions. There are a few ways to fix this.

The most used on is detecting which objects where interacted with. For example if a button was

tapped it will get the ‘object’ behind that button. Another way is using image and text

recognition. With this technique the recording software takes an image of the clicked area tries

to recognize either text on it or just to find a visually similar area on a different device. However

this technology isn’t very reliable since a lot depends on the captured image. For example an

image of a complete button doesn’t usually work well because buttons tend to have different

aspect ratios or text sizes on different screens.

Reliability

Without a doubt automated UI tests can help you improve your app. However it remains a

question if these tests are reliable. Most UI tests rely on finding UI elements based on code

rather than visual cues. This means if a button is only partly visible or even entirely invisible on

the screen but is still present on the page the code will still be able to find this object. This is

why image recognition might be better but unfortunately the image recognition software is

unreliable itself especially when scaling to different aspect ratios. A possible solution is to make

recoded tests for every aspect ratio or even resolution. However this negates some of the

advantages of automated testing.

Conclusion

Automated UI testing can certainly help you find issues however you shouldn’t spend too many

time and resources to make tests. And if you must invest those resources in making visually

based recorded tests. Making a UI test for each aspect ratio will also greatly increase your

chances of performing reliable tests. Real devices are of course preferred over emulators and

last but not least: humans still test UI far better than any software is capable of at this moment.

Bijlage 2: Presentatie NITH

Hogeschool-Universiteit Brussel · 2014. 6. 19. · 9 De volledige omschrijving van het project is...

Documents

Transcript of Hogeschool-Universiteit Brussel · 2014. 6. 19. · 9 De volledige omschrijving van het project is...