Testautomatisering

Unit Testen versus Integratie Testen

Integration Testing vs Unit Testing.jpg

De meeste software bedrijven maken al gebruik van Unit Testen. Benieuwd naar de verschillen en in wat voor scenario je welke vorm van Testing gebruikt? In deze blog zullen we je aan de hand van voorbeelden laten zien, wanneer je Unit Testen gebruikt en kiest voor Integratie Testen. Doe er dus je voordeel mee!


Unit Testen

Om je geheugen op te frissen zullen we beiden Testen eerst verder toelichten. We beginnen met ‘Unit Testen.’ De term geeft het eigenlijk al aan: Unit Testen worden gebruikt om een unit van een code te testen. Daarbij wordt het kleinste mogelijke stukje code dat van nut is getest. Dit is in praktijk meestal een methode. Bij een methode verwacht je een vaste output bij een bepaalde input. Dit concept is wat Unit Tests testen. Een Unit Test is voornamelijk bedoeld voor programmeurs; zij kunnen hiernaar kijken en begrijpen de uitkomst van de test. Het doel van Unit tests is om te bewijzen dat de unit correct is in ieder omstandigheid.

 

Integratie Testen

Een breder begrip vormen Integratie Testen. Dat wil zeggen dat je meerdere componenten met elkaar samen gaat testen. Integration Testen worden toegepast om te bewijzen dat de componenten samen met elkaar kunnen werken. In tegenstelling tot bij Unit Testen zijn de uitkomsten van Integratie Testen voor buitenstaanders wel interessant, omdat deze makkelijker te begrijpen zijn. Voorbeelden van Integratie Testen zijn:

 

  •   Een web client testen die met de backend praat.

  •   Het testen van een component die praat met de database.

 

De belangrijkste verschillen tussen Unit Testen en Integratie Testen

De begrippen Unit Testen en Integratie Testen zijn nu duidelijk. In de onderstaande tabel staan de verschillen tussen beiden testvormen op een rijtje:

Unit Testen versus Integratie Testen

Beiden Testen toepassen

Integration Testen zijn vaak moeilijker te schrijven. Daarom is het belangrijk om verschillende en kwalitatief goede Unit Tests te hebben. In de praktijk is dit ook vaak het geval. Wanneer je genoeg unit tests hebt geschreven kun je ervan uit gaan dat de componenten het doen. Verder hoef je in deze situatie ook niet opnieuw door middel van Integration Testen uit te voeren, waardoor je je kunt focussen op de interactie tussen de componenten.

 

Daarnaast is het belangrijk om Unit Testen en Integration Testen met elkaar te combineren.
Als twee componenten veel met elkaar communiceren en het over belangrijke complexe data gaat, kun je niet zonder Integratie tests, want je moet kunnen garanderen dat de dataoverdracht tussen de componenten goed verloopt en dat fouten goed worden afgehandeld. Je kunt je voorstellen dat dit meer tijd kost om te schrijven dan een unit test, maar op deze manier wordt wel op de juiste manier de integratie tussen beiden componenten getest. Dit wordt ook wel de interactie genoemd. Daarnaast is investeren in Unit Testen en Integratie Testen een goed idee om het product schaalbaar te houden voor de toekomst. De meeste programmeurs gebruiken hierin de volgende opzet, wanneer het gaat om Testen:

  • Unit Testen (80%)

  • Integratie Testen (10%)

  •     Systeem Testen (10%)

 

Unit testing versus integration testing.jpg


Learning: zorg dat Unit Testen niet op elkaar afhankelijk zijn!

In deze blog delen we tot slot nog een learning. Het volgende gaat namelijk in de praktijk vaak mis: dat Unit Tests op elkaar afhankelijk zijn. Hierbij doet de volgende situatie zich voor: één unit test data verandert en de andere unit gaat deze data vervolgens gebruiken. Een unit test moet namelijk onafhankelijk van elkaar kunnen runnen. Het is de bedoeling dat één stuk code getest wordt en als deze afhankelijk is van een ander gaat het al snel mis. Houdt hier dus rekening mee bij de opzet van een Unit Test.

 

Dit blogartikel heeft je inzichten gegeven in de verschillen tussen Unit Testen en Integratie Testen. Met welke vorm van Testing ga jij binnenkort aan de slag? Kun je hier wel wat hulp bij gebruiken? Neem dan vrijblijvend contact met ons op.

A/B testing

Door Ewan Klomp

directionalsign_83858.png

Veel mensen denken dat A/B testing enkel iets is voor grote bedrijven, met heel veel gebruikers zoals Facebook of Amazon. Maar niets is minder waar. Met de komst van tooling zoals Google Optimize is het mogelijk om ook bij kleine bedrijven A/B tests effectief uit te voeren. A/B testing met weinig moeite en zeer beperkte kosten. Op deze manier ontstaat een nog betere en completere teststraat. Ook kan de Product Owner nog beter inzicht krijgen in het softwaregebruik.

Wat is A/B Testing ook al weer?

Om nog even het geheugen op te frissen: bij een A/B test krijgen gebruikers applicatieversie A of applicatieversie B. Op basis van tevoren bepaalde metrics wordt uiteindelijk één van de versies als definitieve versie gekozen voor alle gebruikers.

Door A/B tests kan een softwareproducent betere beslissingen nemen op het gebied van User Interfaces, door bijvoorbeeld te kijken naar welke versie correleert met de grootste conversie.

Google Optimize als A/B test tool, biedt een goede integratie met Google Analytics.

Google Optimize

In dit artikel gaan we dieper in op Google Optimize. Optimize biedt een goede integratie met Google Analytics. Daarnaast heeft het een gratis versie waardoor je snel alle opties kunt onderzoeken. Uiteraard zijn er meer tools waarmee A/B tests uitgevoerd kunnen worden, zoals the A/B testplatform van VWO of het experimentenplatform van Optimizely. Welke het best bij jouw organisatie past is afhankelijk van je teststrategie.

google-optimize-logo-480x480-1-140x140@2x.png

Implementatie A/B Testing

Een A/B test opstellen is in feite een experiment uitvoeren. Je begint met een hypothese, verandert een element en bekijkt de statistieken (lees resultaten) van de vooraf bepaalde metrics.

Google Optimize heeft een editor waarmee je webelementen gemakkelijk kunt bewerken. Je meet met deze webelementen de metrics vanuit je Google Analytics doelen. Een andere nuttige functionaliteit van Google Optimize is dat je je direct op op bepaalde gebruikers kunt richten, op basis van bijvoorbeeld gedrag of locatie.

A/B Testing en Continuous Delivery 3.0

Met A/B testing leg je ook een directe link met het Continuous Intelligence en Continuous Planning gedeelte van Continuous Delivery 3.0. Op deze wijze krijg je nog meer informatie van gebruikers, op basis van de verzamelde metrics. Hier kan de Product Owner de backlog prioritering op aanpassen

AB_testing.png

Het figuur toont hoe de resultaten van A/B testing het Continuous Intelligence proces en Continuous Planning proces voeden

Bijvoorbeeld: als de conversie met de nieuwe versie niet is verhoogd, kan je een work item aanmaken waarin je onderzoekt hoe je de conversie wel kunt verhogen.

Via de bovenstaande aanpak kun je laagdrempelig kennismaken met de mogelijkheden om je product en je ontwikkelprocessen te verbeteren met A/B Testing, Continuous Intelligence en Continuous Planning. Ik hoop je geïnspireerd te hebben om A/B testen te implementeren in jouw teststraat! Download nu de whitepaper over A/B-testing.

Introductie Ewan Klomp - DevOps Engineer / Continuous Delivery

20180815_195621.jpg

Hallo, mijn naam is Ewan Klomp en ben bij Search4Solutions werkzaam als Continuous Delivery Expert.

Als eerste Young Professional heb ik het programma en de groep zien groeien in professionaliteit en kennisdeling. We zijn begonnen met een kleine club informaticastudenten die een passie voor software development hebben. Inmiddels zijn we uitgegroeid tot een grote club young professionals die met passie aan onze projecten werken.

Zelf heb ik mij kunnen specialiseren op het gebied van Continuous Delivery, door intern een traineeship te volgen. Daarna met de opgedane kennis in het bedrijfsleven te stappen, in projecten die mij deze kennis liet benutten. Deze projecten waren leuk en succesvol. Eveneens heb ik in die tijd mijn studie Informatiekunde met veel plezier afgerond. 

Nu maak ik als Young Professional de stap naar voltijd. Ik kijk er zeer naar uit om deze stap te mogen maken en ik ben benieuwd wat het mij gaat brengen.

In de tussentijd wil ik mijn opgedane kennis delen met de community die we hebben opgebouwd. In de komende tijd komen er op deze pagina daarom artikelen die u zou kunnen helpen met uw Continuous Testing processen. Vorige week is een artikel uitgekomen over cross platform UI Testing met Xamarin als voorproefje op deze reeks.

In de volgende delen zal u meer kunnen lezen over AT testen, performance testen en A/B testing. Wilt u eerder meer weten? Neem dan contact met ons op.

Broken Authentication

Door Lucas Dresscher

Wat is het en waar komt het voor?

In dit tweede artikel van mijn serie over de “OWASP Top 10 Application Security Risks – 2017” lijst behandel ik de kwetsbaarheid Broken Authentication. Misschien herkent niet iedereen direct deze officiële term, maar wel zeer herkenbaar is de zoveelste krantenkop waarin staat “Miljoenen accounts gehackt door datalek”. Broken authentication heeft hier veelal mee te maken.

Broken authentication kan de oorzaak zijn van zo'n krantenkop, maar vaker is het een gevolg. Vrijwel alle applicaties volgen namelijk voor inlog processen en dergelijke het volgende drie stappen principe:

1. Identification: “Wie ben je?” - dit is vaak de gebruikersnaam.
2. Authentication: “Ben je wie je zegt dat je bent? - dit is vaak het wachtwoord.
3. Authorization - “Wat mag je?” - dit zijn de rechten die deze gebruiker heeft.

Zoals de naam Broken Authentication doet vermoeden, doet het zich voor in de tweede stap. Een aanvaller gebruikt verkregen credentials om zich voor te doen als een bepaalde gebruiker om op deze manier diens rechten te krijgen. De aanvaller kan aan deze gegevens gekomen zijn door bijvoorbeeld eerdere datalekken, maar ook door zelf een Brute Force Attack (BFA)/Dictionary Attack of een ietwat geavanceerdere Rainbow Table Attack uit te voeren.

Wat kunnen de gevolgen zijn?

Bij een applicatie die kwetsbaar is voor Broken Authentication is het risico op identity theft zeer groot. Tevens kan er andere (bedrijfs)gevoelige gegevens geopenbaard worden. Dit zou niet moeten gebeuren, aangezien de meeste accounts die gehackt worden van gewone gebruikers zijn. Deze groep hoort in theorie zo weinig mogelijke rechten te hebben. Echter, de praktijk leert dat - veelal uit gemakzucht - dergelijke groepen veel meer rechten hebben dan nodig is. Hierdoor kan zelfs een matige hacker met het kraken van een simpel account al ver komen, laat staan een gevorderde hacker. Onder het volgende kopje “Hoe beveilig je je er tegen?” behandel ik dit probleem verder.

Hoe beveilig je je er tegen?

Om te voorkomen dat je direct in gevaar bent als de secretaresse op een phishing mail geklikt heeft, is het van belang dat je als bedrijf goed nagedacht hebt over Identity and Access management (IAM). Dit is gebaseerd op de volgende drie principes: (1) need to know basis, (2) least privilege en (3) segregation of duties. Ofwel, ga voor elke gebruikersrol precies na welke rechten nodig zijn en stel het systeem vervolgens zo in – en niet meer. Zorg er daarnaast voor dat gebruikerstaken gescheiden zijn; iemand die een aanpassing kan voorstellen, moet deze niet zelf kunnen goedkeuren.

Hieronder geef ik een korte lijst met do’s en don’ts om Broken Authentication tegen te gaan.

DO'S

  • Multi-factor authentication: hiermee laat je de gebruiker met twee of meerdere verschillende manieren authenticeren, in plaats met alleen een wachtwoord. Een veelgebruikte implementatie is een combinatie van een wachtwoord en een code verkregen via SMS of via een authenticator app zoals Google Authenticator.

  • Bouw een weak-password check in, die controleert of een gebruiker geen wachtwoord uit de lijst met met 1000 of 10000 slechtste wachtwoorden (uit gemak) wilt instellen.

  • Beperk het aantal inlogpogingen die iemand kan doen en log alle mislukte inlogpogingen.


DON'TS

  • Gebruik geen default credentials. Oftewel, stel geen standaard gebruikersnamen, wachtwoorden of andere accountgegevens in. Denk aan standaardgebruikersnamen admin of gebruiker1 en standaardwachtwoorden als password of wachtwoord.

  • Leg de gebruiker buiten de weak-password checker en een standaard minimumlengte van in ieder geval 8 tekens niet teveel restricties op tijdens het instellen van hun gebruikersgegevens. In tegenstelling tot wat sommige bedrijven nog steeds denken, is onderzocht dat verplichtingen als speciale tekens en hoofdletters of het verplicht periodiek aanpassen van je wachtwoord juist averechts werkt.


Vooruitblik

In het volgende artikel zal ik een kwetsbaarheid behandelen die velen verwarren met degene die ik hier heb besproken: Sensitive Data Exposure. Sensitive Data Exposure heeft zeker overeenkomsten met Broken Authentication, maar is op meerdere vlakken toch fundamenteel anders. Waarin zit dit verschil? Kun je je als bedrijf met enkele hier besproken preventiemaatregelen ook direct tegen deze kwetsbaarheid beveiligen? En welke rol speelt encryptie hierin? Lees het in het derde artikel van mijn Cybersecurity reeks.


 


 


 

 

Cross-platform UI testing met Xamarin

Door: Ewan Klomp

Nadat Microsoft begin 2016 Xamarin overnam, heeft Microsoft grote stappen gezet om cross-platform applicaties met goede performance in C# te bouwen. De snelheid is nog niet helemaal als Native code. Maar door de mogelijke code sharing tussen de twee platformen (iOS en Android) is het een degelijke optie. Zeker wanneer er geen zware computationele berekeningen nodig zijn. Dit artikel gaat dieper in op hoe je User Interface tests uit één project, op beide platformen draait.

Simpele werkwijze

De user interface test van Xamarin werken met een interface. De user interface test library heet Xamarin.UITest en de interface de IApp interface. Xamarin kan met dezelfde interface beide platformen bedienen. Door de IApp interface is het klikken van een object op iOS en Android heel simpel, met dezelfde app.Tap(string) method call.

Creëren van test cases

De methoden die de IApp interface heeft zorgen dat er diverse, geavanceerde test cases gecreëerd kunnen worden. De mogelijkheden zijn vergelijkbaar met die van grotere test platformen zoals Selenium. Ook kan je met Xamarin objecten makkelijk vinden door middel van naam of XPath. Vervolgens kun je ze klikken of er tekst bij invoeren. Natuurlijk bevat Xamarin specifieke methoden voor gestures zoals drag/drop, pinching, en swiping om een gebruiker zo goed mogelijk na te bootsen.

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

Hoe het werkt

Als je dus binnen je test een object aan wil klikken genaamd ´buttonHome´, voer je de functie app.Tap(buttonHome) uit. Dit zoekt dan het object met id ´buttonHome´ op in de huidige views die open staan. Om er voor te zorgen dat de juiste view de juiste ID heeft moet de ID op de juiste plek in de layout files toevoegen: .xib voor iOS en .xaml voor Android.

  • Op iOS geef je een id op deze manier mee aan een element in de .xib file:
    <accessibility key="accessibilityConfiguration" identifier="buttonHome"/>

  • Bij Android in de .xaml op deze manier:
    android:id="@+id/buttonHome"

Let hier op

In principe is het mogelijk om een test te schrijven die draait op Android en IOS. Het probleem zit soms in het verschil van gedrag tussen de platformen op het gebied van views. Hier moet dan binnen 1 testcase een verschillende implementatie voor geschreven worden. Verder is het van belang dat elk element van een testcase waarmee je werkt zijn eigen unieke ID heeft en hetzelfde zijn op beide platformen. Bij een juiste implementatie is het enige verschil de initialisatie van de applicaties voor het testen. Let er op dat je de ID’s van de objecten gelijk houdt op beide platformen. Hierdoor kunnen juiste objecten op de juiste plek gevonden worden.

En nu jij

Hopelijk heb ik je enthousiast gemaakt en ga je zelf met Xamarin aan de slag. Als je hier meer over wilt weten kun je me bereiken via ons contactformulier:

Introductie Lucas - Cybersecurity

Foto.png

Mijn naam is Lucas Dresscher, ik ben 22 jaar oud en ik studeer informatica aan de Universiteit Utrecht.

Daarnaast werk ik 2 dagen per week als Cybersecurity expert in het Young Professional programma, voor Softwarebedrijven in Nederland.

Cybersecurity is een zeer omvangrijk vakgebied; het is letterlijk overal in de IT-wereld. Daarbij is Cybersecurity ook nog eens enorm relevant en actueel. Dit maakt het fenomeen voor velen al snel ontastbaar en afschrikwekkend. Dat wordt versterkt wordt door de enorme hoeveelheid vaktermen en de honderden beschikbare Cybersecurity tools.

Het is dan ook mijn persoonlijke doel om deze ongrijpbaarheid van cybersecurity weg te nemen en het PEN-testen praktisch in te richten. Ik wil de onnavolgbare Wizzkid wegen vervangen door duidelijkheid.

Een kleine hoeveelheid van mijn kennis over cybersecurity deel ik op dit blog, door een reeks van de meest voorkomende kwetsbaarheden in software. Hiervoor hanteer ik de erkende “OWASP Top 10 Application Security Risks - 2017” van het Open Web Application Security Project, zijnde: 

  1. Injection

  2. Broken Authentication

  3. Sensitive Data Expose

  4. XML External Entities

  5. Broken Access Control

  6. Security Misconfiguration

  7. Cross-Site Scripting

  8. Insecure Deserialization

  9. Using Components with Known Vulnerabilities

  10. Insufficient Logging & Monitoring

Bij elk van deze kwetsbaarheid geef ik een uitleg over de kwetsbaarheid, waar het zich in applicaties voordoet en bovenal, wat je er tegen kunt doen.

In het eerstvolgende blog begin ik meteen met de nummer 1 van de lijst: Injection. De meesten zullen deze beruchte kwetsbaarheid herkennen in de vorm van SQL injection, maar er bestaan nog vele andere varianten. Welke zijn dit allemaal? Wat kunnen de gevolgen ervan zijn? En wat doe je er nu precies tegen? Lees het binnenkort in mijn cybersecurity reeks.

Cybersecurityavond Hogeschool Utrecht

Op 23 mei hebben Ewan Klomp, Lars Tijsmans en Jan Vlietland van het Young Professional programma een Cybersecurity avond met Hogeschool Utrecht gehouden.

IMG-20180529-WA0010.jpg

Het onderwerp van de avond was:

"Cybersecurity en de softwareontwikkelaar".

 

De stelling was: 

"elke ontwikkelaar moet verstand hebben van Cybersecurity". 

Het was een avondvullend programma waarin presentatie, discussie en experimenten speels werden afgewisseld. Een leerzame avond vol ontmoetingen tussen professionals en young professionals, met als doel om met elkaar antwoorden te vinden.

IMG-20180529-WA0003.jpg

De eindconclusie was dat:

"bijna elke ontwikkelaar moet verstand hebben van Cybersecurity".

We danken Hogeschool Utrecht voor de interesse en gastvrijheid. Tot een volgende keer!

Je applicatie hosten in containers

Het verplaatsen van de hosting van een eigen rekencentrum naar een cloud-omgeving kan veel besparing opleveren. Bedrijven verplaatsen daarom hun hosting op grote schaal naar de cloud.

Veel organisaties denken daarbij dat virtual machines dan de beste oplossing is. Jammer want ze missen dan de kans om software te hosten in containers. Hosten in containers heeft vele voordelen. In dit artikel leggen we uit wat containers zijn en wat de voor- en nadelen zijn van containers.

Wat zijn containers?

Een container biedt de mogelijkheid om het Operating Systeem te sharen over meerdere containers. Ze zijn daardoor veel goedkoper qua hosting dan virtual machines. 

Het Operating Systeem onder de container bevat alle benodigde libraries die een applicatie nodig heeft om te functioneren. De containers zelf zijn daardoor zeer compact en zijn binnen een paar seconden te creeren. Dit maakt ze niet alleen goedkoper, maar ook veel flexibeler.

Containerization is geen nieuw begrip. Het idee om de OS laag te virtualiseren bestaat al sinds begin deze eeuw. 

Het container framework ‘Docker’ heeft het begrip containers praktisch gepopulariseerd. Veel innovatieve bedrijven hebben Docker snel geadopteerd. 

 
VM_vs_Container_stack.png
 

De nadelen van containers.

Evenals de virtual machine niet de universele vervanger is van de fysieke server, is de container dit niet van de virtual machine. Beide technologieën hebben hun krachten. Containers floreren in een omgeving met microservices. Ze schalen mooi, doordat ze zeer snel te creeren zijn afhankelijk van het benodigde dataverkeer.

Containers zijn echter wel gevoeliger voor virussen doordat ze het onderliggende Operating Systeem delen. Ook kunnen ze diep reiken in het OS om überhaupt te functioneren. VM-instanties bieden deze controle en veiligheid wel. 

Overweeg containers

Bij veel bedrijven staat veiligheid op nummer één en kennis omtrent containers is vaak niet paraat, virtual machines zijn daarom een veilige keuze.

Jammer, want de toekomst van containers is veelbelovend en het zal niet lang duren voordat de meerderheid deze techniek adopteert, zoals dit nu gebeurt met VM-instanties in de cloud.

Meer informatie? Bekijk dan de volgende onderwerpen: Continuous Delivery 3.0, Cloud Software Engineering, Cloud Deployments en Testautomatisering.