Afgelopen maart 2013 konden we officieel spreken van een tabletrevolutie. Voor het eerst werden er in Nederland meer tablets verkocht dan notebooks en in december 2012 werd er zelfs meer aan tablets uitgegeven dan aan alle pc’s, netbooks en notebooks bij elkaar.
Consumenten verwachten dat ze vanaf ieder device ongebreideld toegang krijgen tot alle websites, webwinkels en app’s. Ze vinden het vanzelfsprekend dat de omgeving zich aanpast aan het device. Of ze nu een iPhone met een scherm van 4 inch, een Samsung tablet met een scherm van 10,1 inch of een Windows tablet van 7 inch gebruiken, dit mag een goede weergave niet in de weg zitten. Organisaties willen natuurlijk graag inspelen op deze verwachtingen van de consument. Slechte prestaties willen zij vermijden.
Door de tabletrevolutie is het belang van testen alleen nog maar groter geworden. Echter, een revolutie gaat nooit zonder slag of stoot en ook voor de testwereld heeft deze nieuwe ontwikkeling gevolgen.
Met de komst van responsive design…
Om in te spelen op het brede scala aan devices, besturingssystemen en platformen omarmen organisaties massaal responsive design om de optimale webervaring te realiseren. Responsive websites schalen mee met de afmetingen van het scherm (en de schermoriëntatie) van de gebruiker, zonder concessies te doen aan de leesbaarheid van de tekst of de bruikbaarheid van de interface. Een ontwikkeling die roept om een nieuwe testaanpak.
…neemt het belang van de responsiveness test toe
Een responsive gebouwde webomgeving wordt doorgaans aan een zestal functionele testen onderworpen: Functionele acceptatietest (fat), gebruikers acceptatietest (gat), systeemtest, integratietest, ketentest en responsiveness test. Van deze zes testen is de fat het meest essentieel. Deze wordt handmatig en vaak uitputtend uitgevoerd en is daardoor ook het meest tijdrovend.
Simpel gezegd test de fat of de webomgeving doet wat het moet doen. In het geval van een e-commerce omgeving wordt bijvoorbeeld de betaalmethode, de winkelwagen en de bezorgmethode getest. In de laatste fase van het testproces wordt de webomgeving pas onderworpen aan de responsiveness test. Hier wordt het gedrag van de webomgeving onder de loep gelegd aan de hand van omgevingsfactoren, zoals browsers en besturingssystemen. Dat door de tabletrevolutie deze test een cruciaal onderdeel is geworden, staat gelukkig al bij velen als een paal boven water. Als er niet op responsiveness getest wordt kan je er van uitgaan dat de webomgeving niet goed doorgetest is, wat kan leiden tot slechte prestaties.
In de praktijk worden de zes functionele testen zoals hierboven beschreven vaak als losse testen uitgevoerd. Daarnaast zijn er ook nog een drietal niet-functionele testen: de performance test, de load test en de platform compatibility test. Deze testen gaan na of de randvoorwaarden voor een goed werkende webomgeving aanwezig zijn, maar hebben verder niks te maken met de wensen en eisen van de gebruiker. Deze niet-functionele testen gaan bijvoorbeeld na of de webomgeving snel genoeg laadt en of de webomgeving vanaf ieder platform beschikbaar is. Echter, door elke test als los onderdeel van de totale testsuite te zien, wordt er best veel tijd en geld verspild. Dit kan ook anders…
Sla drie vliegen in één klap
Als je tijdens de fat toch diverse betaalmethodes gaat testen, waarom dan niet elke methode testen op verschillende devices vanaf meerdere platformen? Het is veel efficiënter om de responsiveness test en de platform compatibility test te integreren in de fat. Door tijdens de fat ook te testen op responsiveness en platform compatibility worden alle effecten van de tabeltrevolutie geïntegreerd afgedekt en sla je zelfs drie vliegen in één klap.
Nieuwe ontwikkelingen op technologisch gebied vragen meer dan eens om een nieuwe aanpak. Het is daarom verstandig om bij nieuwe ontwikkelingen, zoals de tabletrevolutie in combinatie met reponsive design, eens opnieuw te kijken naar de huidige werkwijze en na te gaan of bestaande processen nu misschien efficiënter en sneller uitgevoerd kunnen worden. Niemand wordt blij van dubbel werk. Als je een loodgieter nodig hebt omdat je een kapotte douche én een verstopte gootsteen hebt, laat je hem toch ook niet twee keer voorrijden?
Mijn gevoel voor Nederlands schudt toch ook wel even als ik de titel zo lees.
Met deze titel zet je jezelf eigenlijk een beetje voor schut 🙂
Sjoerd,
het lijkt mij eerder noodzakelijk om onder andere de performancetest later in de keten uitgebreid te doen. Er kunnen externe factoren (of partijen) in de keten zijn die de performance van je app kunnen aantasten.
Wel mooi artikel om te lezen, zet tot nadenken over je testcyclus!
Aangezien redactie nog weleens titels wil veranderen – en deze daardoor niet altijd de lading dekken – is het aan de auteur om gebruik van schutten in plaats van schudden uit te leggen. Desondanks heb ik het idee dat de titel in de context van responsive design prima past als ik de werking ervan een beetje begrijp. Het is tenslotte een soort van sluisdeur die bedoeld is om kleine en grote bootjes toegang te geven tot dezelfde informatie. Tekstueel lijken er nog meer ‘woordgrapjes’ in te staan “…staat gelukkig al bij velen als een paal boven water.”
P.S.
Er op het laatst pas achter komen dat er ook nog andere (mobiele) schermpjes zijn en deze dan pas gaan testen lijkt me een ontwerpfout.
Op de eerste plaats ben ik een voorstaander van zinvolle feedback. Dat vind ik meer passen in de huidige tijd.
Ik lees uit het artikel dat het bedrijfsleven geconfronteerd wordt met een groei in gebruik van devices en m.n. tablets. Dit gebruik heeft een aanzienlijk impact kwantiteit en kwaliteit van testmiddelen.
Terecht zegt de auteur dat er met enige spoed maatregelen genomen dienen te worden om uiteindelijk het bedrijfsrisico in de lijn te brengen met de geldende bedrijfseisen.
@Pradiep
Als je testmiddelen niet goed zijn heb je volgens mij ergens al in het begin een fout gemaakt, iets van het doel heiligt de middelen…..
En iedereen krijgt wat hij geeft, zinvolle feedback genoeg in andere artikelen van auteur maar geen één reactie daarop.
NEXT, NEXT, FINISH?
De komst van tablets en smartphones zal een extra activiteit geven bij het testen.Denk alleen maar aan het verschil van IPhone en Android. De hoeveelheid browser die beschikbaar zijn. M.i. is het niet een veranderd testproces, maar keuzes maken middels riscoanalyse. Waar moet het optimaal zijn en waar doe je het iets minder.
Dat we tegen technologische ontwikkeling aanlopen is zeker, het smart horloge is al in opkomst.
na gaan of bestaande processen nu misschien efficiënter en sneller kunnen zou ik niet willen zeggen wel efficiënter en effectiever.
De stelling dat al die verschillende devices een uitdaging is voor testen, is helemaal juist. Het kost extra werk en vaak nog saai werk ook. Ik had wel iets meer willen lezen over de oplossingen. Ik zie hele mooie dingen gebeuren met testautomatisering over devices heen die denk ik een hele goede stap zijn om dit probleem onder controle te brengen.
Overigens kan je met risicoanalyse, zoals een eerdere reactie al noemt, ook al een heel eind komen in de reducering van complexiteit.