Gedeelde bibliotheken

Niet zo lang geleden werd mij gevraagd om een advies om het geheugen gebruik van een Java webapplicatie op een JBoss container te verminderen. Het project bestond uit meerdere webapplicaties die allemaal op dezelfde container werden deployed. Een van mijn adviezen was om te overwegen bibliotheken te delen. Per webapplicatie worden bibliotheken in het “Permgen” geheugen geladen. Als dezelfde bibliotheek in iedere webapplicatie wordt meegeleverd, dan wordt er meer “Permgen” geheugen gebruikt. Dit komt doordat iedere webapplicatie opnieuw dezelfde bibliotheek zal laden.

Maven en gedeelde bibliotheken

De meeste containers bieden de mogelijkheid om bibliotheken te delen tussen verschillende webapplicaties. Als een project met Maven wordt gebouwd dan kun je deze gedeelde bibliotheken in een common project plaatsen¹. Dit common project kan dan in de gedeelde folder van de webcontainer worden geplaatst om te voorkomen dat iedere webapplicatie opnieuw dezelfde bibliotheek gaat inladen².

In een multi-module maven project met meerdere webapplicaties, geeft het volgende bash commando een overzicht van de gedupliceerde compile-time bibliotheken in de verschillende modules (gebruik profielen om alleen de modules te selecteren die .war bestanden opleveren):

mvn dependency:tree | grep "compile" | sed 's/\[INFO\]//g;s/+-//g;s/\\-//g;s/|//g;s/^[ \t]*//;s/[ \t]*$//' | sort | uniq -c | awk '$1+0 >= 2' | sort –r

Dit commando zou bijvoorbeeld het volgende resultaat kunnen geven:

  6 org.slf4j:slf4j-log4j12:jar:1.6.2:compile

  6 org.slf4j:slf4j-api:jar:1.6.2:compile

  6 log4j:log4j:jar:1.2.16:compile

  5 oro:oro:jar:2.0.8:compile

De eerste kolom laat zien hoe vaak Maven de compile time dependecy in de tree is tegengekomen. Daarna volgt de naam en het versienummer. Deze bibliotheken zijn kandidaten om naar een common project te verplaatsen. Het projectteam zal moeten overwegen of het verstandig is om bibliotheken te delen. Als de bibliotheken worden gedeeld in een common module, dan moeten ze in de shared lib folder van de container worden geplaatst.

Binaries en gedeelde bibliotheken

Op het moment dat ik werd ingeschakeld om het geheugenverbruik te analyseren was de broncode niet beschikbaar. Ik had wel toegang tot de binaries (.war bestanden) in de deployment directory van de webcontainer. Het volgende commando werd uitgevoerd om uit te zoeken welke bibliotheken werden gedeeld tussen twee binaries:

comm -12 <(unzip -l webapp1.war | grep "lib" | uniq | sort) <(unzip -l webapp2.war | grep "lib" | uniq | sort)

Dit commando zou bijvoorbeeld het volgende resultaat kunnen geven:

  1352924  03-03-2012 17:23   WEB-INF/lib/opensaml-2.5.1-1.jar

  1501575  03-03-2012 17:16   WEB-INF/lib/guava-10.0.1.jar

Als de lijst van gedeelde bibliotheken erg lang is, kan het volgende commando worden gebruikt om het aantal gedeelde bibliotheken weer te geven:

comm -12 <(unzip -l webapp1.war | grep "lib" | uniq | sort) <(unzip -l webapp2.war | grep "lib" | uniq | sort) | wc –l

Ook kan het handig zijn om uit te rekenen hoe groot het aantal gedeelde bibliotheken op disk is. Dit is niet 1 op 1 aan het permgen geheugen te relateren, maar het geeft wel een indicatie hoeveel kleiner de binaries op disk zouden kunnen worden. Met het volgende commando kan dit worden geprint:

comm -12 <(unzip -l webapp1.war | grep "lib" | uniq | sort) <(unzip -l webapp2.war | grep "lib" | uniq | sort) | awk '{ sum+=$1} END {print sum}'

Permgen besparing

Om de geheugenbesparing te illustreren ga ik uit van de Tomcat archetype³. Door het volgende commando uit te voeren wordt een voorbeeld web project aangemaakt:

mvn archetype:generate -DarchetypeGroupId=org.apache.tomcat.maven

-DarchetypeArtifactId=tomcat-maven-archetype -DarchetypeVersion=2.0-beta-1

Voor het voorbeeld wordt de basic-webapp 5 keer (onder een verschillende context) deployed op een Tomcat 7 container. De eerste keer wordt de basic-webapp met alle compile dependencies opgeleverd (exact zoals de archetype). De tweede keer worden alle bibliotheken (behalve die beginnen met basic) op provided gezet en in de lib map van de container geplaatst. De webapp maakt onder andere gebruik van Spring, slf4j, log4j, wsdl4j en jaxb. Het permgen geheugen na deployment ziet er als volgt uit:

43Mb Permgen in gebruik (compile dependencies)

23Mb Permgen in gebruik (provided dependencies)

Het voorbeeld laat zien dat het gebruikte permgen geheugen bijna verdubbelt als de applicatie 5 keer wordt geladen en de bibliotheken niet in de shared lib folder worden geplaatst. Soms is het mogelijk om het permgen geheugen nog verder te reduceren door verschillende modules van dezelfde logging/collections/io bibliotheek gebruik te laten maken. Als module A bijvoorbeeld Log4j gebruikt en module B gebruikt Logback, dan worden twee bibliotheken van hetzelfde type geladen. Het kost in dat geval minder geheugen als beide modules er bijvoorbeeld voor kiezen om gebruik te maken van de Logback bibliotheek.

1. http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependencies.html
2. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
3. https://tomcat.apache.org/maven-plugin-2.0-beta-1/archetype.html

Geschreven door Rino Kadijk

In de afgelopen jaren hebben testers hard gewerkt om erkenning te krijgen voor het testvak. We hebben standaardaanpakken voor het testen van software ontwikkeld en er boeken over geschreven. We hebben cursussen en certificatieprogramma’s opgezet en dit allemaal op internationaal niveau georganiseerd en gestandaardiseerd. Het resultaat is dat testen volwassen geworden is. Het is gestandaardiseerd, geïnternationaliseerd en toolondersteund. We zijn zover gekomen dat het mogelijk is om testen geautomatiseerd uit te laten voeren of zelfs aan de andere kant van de wereld.

Analytische linksbreinige vaardigheden hebben het testvak gebracht tot waar het vandaag staat. Nu je zou kunnen zeggen dat testen een commodity geworden is, moeten we nieuwe manieren vinden waarop we waarde toe kunnen voegen. We moeten ons gaan richten op die gebieden en vaardigheden die minder makkelijk geautomatiseerd of geoutsourced kunnen worden en ons daarin specialiseren. We zijn in een tijd aanbeland waarin onze uitstekende analytische vaardigheden niet langer toereikend zijn. Nieuwe additionele vaardigheden zijn noodzakelijk, vaardigheden die hun basis vinden in de rechter hemisfeer van ons brein.

Laten we kort een blik op de anatomie van onze hersenen werpen. Zoals de meesten weten is ons brein symmetrisch verdeeld in twee helften, de cerebrale hemisferen. Hoewel beide helften min of meer gelijk zijn in vorm en omvang, hebben ze verschillende functies.

De linker hemisfeer is rationeel en verantwoordelijk voor taal, logica (redeneren) en spraak. Het werkt sequentieel en analytisch. Tot vrij recent werd de linker hersenhelft gezien als de superieure van de twee. Het representeerde alles wat ons onderscheidt van de dieren. De capaciteit van het linkerbrein was de drijvende kracht achter de industriële revolutie en het informatie tijdperk.

De rechter hemisfeer daarentegen, is non-lineair, holistisch en gebaseerd op instinct. Het is in staat patronen te herkennen en non-verbale uitdrukkingen en emoties te interpreteren. De rechterhelft neemt de details en combineert ze om zo het grote plaatje te maken.

Ietwat gechargeerd kun je stellen dat links de harde, analytische kant  en rechts de softe creatieve kant is. Als je nu eens een willekeurige functieomschrijving van een tester bekijkt zul je zien dat 90% van de gevraagde eigenschappen, linksbreinige eigenschappen zijn. Voor ‘soft en creatief’ was geen ruimte in IT en al zeker niet in software testen.

Een voorbeeld om het verschil te verduidelijken:

Vraag: ‘Wil je a.u.b. uit de supermarkt een fles melk meebrengen? Als ze eieren hebben, dan doe er maar zes.’
Ik kwam uit de supermarkt terug met zes flessen melk en zonder eieren.
Reactie: ‘Waarom heb je in hemelsnaam zes flessen melk gekocht?’
Antwoord: ‘Omdat ze eieren hadden.’

Wat je hier ziet is een puur linksbreinige interpretatie van de vraag. Analytisch, if-then-else. In de praktijk schiet gelukkig het rechter brein te hulp om alle details samen te voegen tot het complete plaatje van één fles melk en zes eieren. Dit voorbeeld maakt ook duidelijke dat de beide helften niet solo kunnen opereren. Ze vullen elkaar aan en hebben elkaar nodig om tot een compleet functioneren te komen.

In een tijd waarin computers of onze collega’s in Azië in staat zijn linksbreinige taken beter en sneller uit te voeren dan wijzelf, zullen we ons meer moeten gaan focussen op activiteiten die minder gemakkelijk geautomatiseerd, of vanaf een andere geografische locatie uitgevoerd kunnen worden. Activiteiten in de periferie van het eigenlijke systeem en de test die daarop uitgevoerd wordt. We moeten ons veel meer gaan specialiseren in de taken die gebruiker- en klantgerelateerd zijn, in plaats van in taken die systeemgerelateerd zijn. Meer gerelateerd aan de keten van systemen die in z’n totaliteit de business van onze klanten ondersteunen.

Toekomstige testers zullen een beroep op hun rechter brein moeten doen om in staat te zijn alle kleine details samen te voegen tot het grote, complete plaatje. Ze moeten de business van klanten kunnen begrijpen en in staat zijn om risico’s in de keten van applicaties in te schatten en daarop de juiste acties te initiëren. De tester van morgen moet het dagelijkse werk en de problemen van z’n gebruikers daadwerkelijk begrijpen om de kwaliteit van de totale set aan documentatie echt te kunnen beoordelen.

De algemene software tester zal zich moeten specialiseren en bijvoorbeeld een acceptatietestspecialist worden met de capaciteit om echt actief, empathisch te luisteren en de behoeften van de gebruiker te begrijpen. Of hij wordt een review specialist die de details van alle afzonderlijke documenten kan combineren in hun onderlinge verbanden en zo daadwerkelijk de omissies, discrepanties en redundantie identificeren. Misschien is er wel behoefte aan de rol van business risk specialist die de aard van de business van z’n klant zo goed snapt, dat hij de risico’s kan overzien in de keten van applicaties die misschien wel over meerdere bedrijven strekt.

Het spreekt voor zich dat dit niet kan zonder gebruik te maken van ons linker brein. Maar in de toekomst zullen er binnen het testvak steeds meer specialismen ontstaan waarin rechtsbreinige capaciteiten belangrijk zijn; veel belangrijker dan ze ooit te voren geweest zijn. En de rol en het belang van het rechter brein in het testvak zal in de verdere toekomst alleen maar toenemen.

Geschreven door Frank Titulaer
Consultant

Afgelopen november was er weer een groot team van Salves aanwezig op Devoxx, een van de grootste Java conferenties ter wereld, gehouden in Antwerpen. Ook dit jaar weer was Devoxx een geweldige conferentie en een goede gelegenheid om bij te kletsen met oude bekenden. Op Java gebied is het even wachten op echt grote ontwikkelingen, Java 8 komt pas later in 2013 beschikbaar, en ook JEE 7 laat nog even op zich wachten. De belangrijkste ontwikkelingen van dit jaar waren dan ook geen announcements op Java gebied, maar:

• Devoxx London, vanaf volgend jaar is er voorafgaand aan Devoxx France een eerste editie van Devoxx UK.
• Flash/AIR is nu echt verleden tijd, de Parleys website is helemaal omgebouwd in HTML5. Dit bleek ook al door de afwezigheid van Adobe als hoofdsponsor.

 Het leuke aan Devoxx is de grote diversiteit aan onderwerpen; je ziet zaken buiten je normale werkgebied wat je een beter beeld geeft over de ontwikkelingen die gaande zijn op Java gebied. Dit jaar werden we tijdens de keynote verwelkomd door 5 dansende NAO robots, daarnaast werden er in de “Future” track verschillende presentaties gegeven over ontwikkelingen op hardware gebied, zoals Arduino of Raspberry Pi. Dus er zijn allerlei ontwikkelingen op hardware gebied die er voor zorgen dat ook op software gebied nieuwe ontwikkelingen komen.

Wat zeker de moeite waard is om vernoemd te worden is:

• JEE7, infinite extensibility meets infinite reuse – David Blevins. David maakt deel uit van de JEE7 en EJB3.2 expert group, en behandelt een aantal verbeteringen voor de JEE standaarden op een hele duidelijke manier.
• Behaviour Driven Development – John Smart. John gaf een overview van BDD en behandelde daarnaast een aantal frameworks waarmee je BDD kan implementeren.
• En natuurlijk de laatste presentatie op de vrijdag, Adam Bien met een verhaal over “Real world JEE development”. Dit was voor mij het beste verhaal van de hele conferentie en een mooie afsluiter.

En verder heb ik goede verhalen gehoord over de presentatie van Chet Haase over "The Future of Software Development Process Methodology Effectiveness". Dus hierbij een reminder om deze te gaan bekijken op Parleys.

Naast de presentaties is er ook in de avonduren genoeg gelegenheid om te socializen. Op woensdagavond was er een JPoint borrel die erg gezellig was. De donderdagavond begon met de James Bond film Skyfall met daarna een aardig feest in de Noxx. Toch leuk om bekende Javanen en presentatoren te zien dansen. Het is maar goed dat we NAO robots kunnen programmeren om te kunnen dansen, want ik heb nog nooit zoveel mensen uit de maat zien dansen

Al met al blijft Devoxx een ideale manier om je kennis op Java gebied up to date te houden. En geeft het je een hoop nieuwe invalshoeken, en een lijst met onderwerpen en ideeën waar je op een later tijdstip nog eens naar moet kijken.

Geschreven door Joop Duim
ICT-Consultant/Architect

Op 8 november vond de Activiti community day plaats in Berlijn. Een kleine 70 personen kwam luisteren naar een dag vol presentaties over het framework. Een mooi voorbeeld van hoe een actieve community van een open source project een belangrijke bijdrage levert aan de kennis en motivatie van alle geïnteresseerden.

Activiti is een open source framework voor BPM, geheel vanaf de grond opgebouwd om BPMN 2.0 te ondersteunen. Deze relatief nieuwe standaard brengt een standaard notatie en opslagformaat voor business processen. Hierdoor worden de werelden van procesmodellering en procesautomatisering dichter bij elkaar gebracht. Er kan door personen uit beide disciplines aan hetzelfde model worden gewerkt terwijl het proces tot stand komt. 

Activiti is een lightweight en high-performance implementatie van de BPMN 2.0 standaard die een actieve collaboratie vanuit de community verwelkomt naast de sponsoring van het project door Alfresco. Diverse componenten van het framework worden zo door ontwikkelaars met veel enthousiasme bijgedragen om het geheel naar een hoger niveau te tillen. Zo bestaat er inmiddels, naast de procesengine die het kloppend hart van Activiti is, een browser-based modelleertool, een designer tool voor de technische configuratie van processen en services door ontwikkelaars, connectoren voor diverse populaire andere open source projecten zoals Mule en Camel en ondersteunt Activiti ook deployment naar Java EE en OSGi containers. 

In beknopte presentaties werden de ontwikkelingen en aankomende features besproken. Dit is niet alleen interessant om de informatie zelf, maar ook omdat hiermee de achterliggende gedachte van de ontwikkelaars duidelijk wordt. Wat de focus heeft in Activiti? Ten eerste stabiliteit. De kern van het framework staat en doorstaat de proef in de praktijk. In de tweede plaats is gebruiksgemak volop in ontwikkeling. Dat heeft betrekking op het gemak voor een ontwikkelaar (meer databases, eenvoudigere installatie, minder afhankelijkheden, etc) maar ook voor gebruikers, wat duidelijk wordt in producten gebaseerd op Activiti. De aandacht richt zich nadrukkelijk op het benutten van de sterke kern van Activiti om in de praktijk problemen op te lossen. Dit moet zo eenvoudig mogelijk worden.

Waar de kracht van de community echt duidelijk wordt is in de praktijkvoorbeelden. Vanuit diverse sectoren werden presentaties gegeven van hoe het framework wordt ingezet in de praktijk. Dit blijkt sterk te variëren. De componenten van het framework worden selectief ingezet, wat aantoont dat de componenten goed van elkaar gescheiden zijn maar ook dat het integreren van eigen componenten goed realiseerbaar is. Zo toonde 1 van de presentaties een compleet eigen grafische interface op de taken services van Activiti. Ook worden sommige componenten van commerciële partijen ingezet bovenop de standaard tools van Activiti. De sprekers gaven ook aan tegen welke beperkingen van Activiti ze zijn aangelopen en hoe ze dit hebben opgelost. Met name deze punten wekten interesse bij het publiek. Met de ontwikkelaars in de zaal kan dat alleen maar leiden tot meer discussie en verbeteringen!

Dit betekent niet dat er geen werk meer ligt. Sterker nog, het bruist in de community van de ideeën. En niet alleen dat, er is ook de bereidheid hieraan bij te dragen. Dit enthousiasme is van groot belang. Waar kan het beter?

* Er is meer aandacht nodig voor features rondom beheer. De ondersteuning hiervoor is nog matig. Met name bij grote aantallen processen heeft een beheerder niet de gereedschappen om het overzicht te houden.

* De OSGi ondersteuning is nog basaal. Praktijkvoorbeelden moeten duidelijk maken welke zaken hier nog aan toegevoegd moeten worden, maar versionering van services en ontsluiten van meer informatie over de engine zijn duidelijke verbeterpunten.

* Form support. Op dit moment biedt Activiti simpele formulieren aan via het Explorer tool, maar voor elke vorm van maatwerk moet het geheel zelf worden gebouwd.

Zoals het een echt opensource project betaamt, zijn de materialen uiteraard terug te lezen…

Toen ik een kleine zes jaar geleden bij één van 's lands grootbanken werkte aan mijn eerste SEPA project kon ik niet bevroeden dat ik daar anno 2012 nog eens een blog over zou gaan schrijven. Het betrof weliswaar vanuit IT optiek het prille begin van wat voluit de Single Euro Payments Area heet, maar het beeld dat door de zogenaamde European Payment Council (EPC) werd geschetst was dat begin 2011 het grote gros van de nationale Europese betaalproducten zou zijn gemigreerd naar SEPA.

Eerst zal ik de achtergrond schetsen. Om het economische verkeer binnen de EU goedkoper, efficiënter en laagdrempeliger te maken werd door Brussel in het begin van de eeuw voorgeschreven dat er uniforme girale producten moesten worden ontwikkeld, ter vervanging van de nationale producten. Dit was natuurlijk een logisch vervolg op de invoering van één uniforme valuta in 2002. De bankwereld heeft – verenigd in de EPC – de handschoen opgepakt en de SEPA Credit Transfer (kortweg SCT – de 'Europese overschrijving') en de SEPA Direct Debit (SDD core en SDD B2B – de 'Europese incasso') geïntroduceerd. Daarnaast is er ook voor de markt van betaalkaarten één Europese standaard ontwikkeld, het zogenaamde SEPA Cards Framework (SCF). Ook hier geldt dat nationale producten worden vervangen door producten die aan de nieuwe Europese normen voldoen dan wel daartoe aangepast worden. Het gebied SEPA beslaat overigens niet alleen de Eurolanden, maar ook de andere EU-landen en nog een handvol staten buiten de EU. De niet-Eurolanden gebruiken SEPA producten uiteraard alleen voor grensoverschrijdende transacties.

De SCT en de beide SDD varianten worden inmiddels door de duizenden betrokken financiële dienstverleners (naast banken zijn er ook payment processors zoals Equens) ondersteund, dat wil zeggen dat alle interbancaire CT en DD verkeer aan de SEPA standaarden voldoet in vorm van ISO 20022 XML berichten. Natuurlijk hebben deze dienstverleners ook gebruikers in de vorm van bedrijven, instellingen en particulieren. Bedrijven en instellingen zijn nog druk doende hun financiële systemen aan te passen zodat hun bulkbetalingen en -incasso's voldoen aan de SEPA standaarden. Een en ander houdt in dat financiële dienstverleners al enkele jaren zowel nationale als Europese incasso's en overschrijvingen moeten verwerken. Deze situatie eindigt op 1 februari 2014, dan zullen de nationale producten zijn uitgefaseerd.

Voor partijen als Salves zijn natuurlijk vooral de Nederlandse ontwikkelingen relevant. Als de plannen uit het Nationaal SEPA-migratieplan navolging krijgen zullen de grootzakelijke SCT en SDD gebruikers medio 2013 hun systemen gereed hebben. Kleinere partijen hebben nog tot 1 februari 2014 de tijd om over te stappen. In het algemeen zullen vooral de grootzakelijke partijen IT-dienstverleners consulteren om hun systemen te converteren (denk dan vooral aan de conversie van rekeningnummer naar IBAN¹), de kleinere partijen werken veelal met maatwerkpakketten, waarbij de leverancier verantwoordelijk is voor de overstap naar SEPA. Er is momenteel dan ook nog veel vraag vanuit grote bedrijven en instanties naar software- en testconsultants met SEPA kennis.

Hoewel de Nederlandse banken en processors applicatietechnisch gezien al enkele jaren gereed zijn, zullen hier ook ongetwijfeld nog uitdagingen liggen om de infrastructuur op orde te hebben voor de enorme te verwachten toename van SEPA betalingsverkeer. Om een idee te geven: in 2011 verwerkte Equens ruim 300 miljoen SEPA transacties, terwijl de totale omvang van het girale verkeer via Equens (straks voornamelijke via SEPA) jaarlijks ca. 10 miljard transacties beslaat. Wellicht liggen hier vanuit testconsultancy oogpunt nog uitdagingen in de vorm van performance, load en stresstesten.

Is 'giraal' SEPA dan in februari 2014 klaar? Nog niet helemaal. Tot 1 februari 2016 wordt een aantal uitzonderingen op de SEPA regels toegestaan, mits de betreffende lidstaat dit meldt bij de Europese Commissie vóór 1 februari 2013. Zo mogen banken de conversie van de nationale rekeningnummers naar IBANs als service nog blijven aanbieden. Ook mogen banken en processors bulkbestanden die niet aan ISO 20022 voldoen nog blijven verwerken. Beide overgangsmaatregelen zullen in Nederland vermoedelijk niet aan de orde zijn. Een uitzondering op de regels die in Nederland en andere landen wel aan de orde zal zijn is dat banken tot 1 februari 2016 nog van gebruikers mogen verlangen dat bij grensoverschrijdende transacties de BIC² van de tegenrekening opgegeven wordt (naast het IBAN). Daarnaast zal Nederland ook nog moeten vaststellen vóór 1 februari 2013 of er dispensatie nodig is voor nicheproducten als de acceptgiro, zodat ook hier nog extra tijd is om ze aan te passen voor SEPA.

Wat betreft de betaalkaartenmarkt zijn de meeste stappen wel gezet. Banken en aanbieders van betaalautomaten en betaalproducten hebben hun systemen aangepast, zodat het grote gros van de consumenten met zijn pas kan betalen, ongeacht in welk SEPA-land men zich bevindt. Kijken we weer naar de Nederlandse situatie dan zien we dat 'het nieuwe pinnen' al aardig is ingeburgerd. Dit heeft alles met SEPA te maken: het SCF vereist dat betaalpassen (zo ook credit cards) gebruik maken van de ook buiten Europa bekende EMV chip standaard. Daarnaast is er einde gekomen aan de voorheen noodzakelijke 'co-branding', waarbij naast het nationale product (bijvoorbeeld PIN³) een internationaal bruikbaar product (bijvoorbeeld Maestro) op één betaalkaart werd aangeboden.

Concluderend kan gesteld worden dat er vooral op korte termijn nog interessante bouw- en testklussen liggen te wachten bij de groot zakelijke gebruikers inzake de conversie naar IBAN. Op de langere termijn is vanuit de bankwereld wellicht nog vraag naar expertise inzake het bij zoeken van de BIC bij een opgegeven IBAN en het SEPA-proof maken van niche producten. Mogelijk bieden tenslotte performance technische uitdagingen bij de financiële dienstverleners nog kansen.

De mobiele app markt is groot, en groeiende. Hoe groot? De twee populairste mobiele platformen op dit moment, iOS en Android, laten tezamen de volgende cijfers zien:

• 1.250.000 downloadbare apps (85% groei afgelopen jaar)

• 63.000 nieuwe apps per maand (worden niet allen goedgekeurd)

• 2 miljard downloads per maand

• 765.000.000 actieve iOS en Android gebruikers

• 70.000 gespecialiseerde app ontwikkelaars.

Indrukwekkende cijfers. En waar ontwikkeld wordt, moet getest worden! In dit blog probeer ik de volgende vraag te beantwoorden: Is voor het testen van apps gespecialiseerde testkennis nodig, of is het een kwestie van het gebruik van je boerenverstand (zie blog Marcel van Eekeren, januari 2012)? In dit blog bekijk ik waarin de teststrategie voor mobiele apps afwijkt ten opzichte van een “reguliere” teststrategie en probeer ik deze vraag te beantwoorden.

Verschuiving in de teststrategie
Een goede teststrategie is natuurlijk gebaseerd op de productrisico’s. In een reguliere teststrategie blijkt vaak dat 80% van de testinspanning op functionaliteit van de software komt te liggen. Laten we ons boerenverstand eens aanspreken en bekijken of dit voor mobiele apps ook geldt.

Usability
Waarom zijn mobiele app’s zo populair? Juist omdat ze makkelijk en snel in gebruik zijn. Ten behoeve van de gebruiksvriendelijkheid worden in app’s zelfs vaak functionaliteiten geschrapt. Dit in tegenstelling tot desktop software die vaak uitblinkt in allerlei (ongebruikte) functies. Usability prevaleert dus boven functionaliteit. Logischerwijs vormt een usability test dus een belangrijk onderdeel binnen de teststrategie.

Portabiliteit
Apps worden vaak beschikbaar gesteld op meerdere platformen (iOS, Android, Windows, RIM). Van deze platformen zijn vervolgens diverse versies in omloop welke draaien op een diversiteit aan smartphones. Door het testen op portabiliteit zorg je ervoor dat de app ook daadwerkelijk goed functioneert op deze combinaties van hard- en software.

Security
In tegenstelling tot desktop applicaties wordt de data van een smartphone meestal over een onbeveiligd draadloos netwerk gestuurd (3G, WiFi spots). Dat betekent natuurlijk dat er grotere risico’s bestaan met betrekking tot de security. Denk bijvoorbeeld aan mobiel internetbankieren. Een security test vormt hier dus een absolute noodzaak.

Zuinigheid, performance en continuïteit
Tegenwoordig worden databundels steeds verder beperkt. Voor gebruikers is het dus van belang dat apps zuinig omspringen met het dataverbruik. Tevens vormt het 3G netwerk vaak de bottleneck in de performance van een app. Daarom is het testen op zuinigheid en performance belangrijk binnen het testtraject. Ook hebben we in de praktijk vaak te maken met wisselende kwaliteit en interrupties van de dataverbinding. Wat gebeurt er met je data die op dit moment wordt verstuurd? Afhankelijk van de risico’s zou het testen op continuïteit van de dataverwerking ook onderdeel uit moeten maken van de teststrategie.

Kortom, naast het testen van functionaliteit zijn diverse andere kwaliteitsattributen van belang bij het testen van apps. Dit brengt ons al weer een stapje dichter bij het beantwoorden van de vraag: is hier dan ook specialistische testkennis voor nodig?

De app-tester
Voor het testen van performance en security zijn we inmiddels gewend dat er experts worden binnen gevlogen om deze onderdelen te testen. Dit zal voor het testen van apps dan ook niet anders zijn. Minder bekend zijn we met de usability-experts binnen ons vakgebied. Maar omdat dit onderdeel zo belangrijk is in de app-wereld zal deze specialistische kennis en het gebruik van bijvoorbeeld usability labs zeer waardevol zijn in het testtraject.

Portabiliteit is geen onbekend begrip in de testwereld. Webapplicaties worden namelijk vaak op verschillende browsers getest. Het uitvoeren van dergelijke testen voor apps is echter een verhaal apart. Hoe test je een app op zo’n grote diversiteit aan platformen en toestellen? Het emuleren van toestellen lijkt interessant, maar levert in de praktijk vaak geen betrouwbare resultaten. Gelukkig worden hier nieuwe initiatieven voor opgezet zoals de Testdroid Cloud van Bitbar waarmee geautomatiseerd fysieke toestellen getest kunnen worden.

Kennis van dit soort oplossingen maken het mogelijk om op efficiënte wijze te testen op portabiliteit. Daarnaast zal er kennis nodig zijn om testgevallen uit te voeren waarin bijvoorbeeld interrupties in de ontvangst worden getest. Ook dit vormt geen alledaags werk van een normale tester.

Het antwoord op de vraag
Door een goede risicoanalyse zal de testmanager of testcoördinator met zijn boerenverstand een heel eind komen met het opstellen van de teststrategie. Het uitvoeren van deze teststrategie is een heel ander verhaal. Daarom is mijn antwoord op de eerder gestelde vraag als volgt: Ja, er is gespecialiseerde kennis nodig voor het testen van apps.

Is there a tester for that?

Geschreven door Jasper Sens
Testmanager

Momenteel ben ik Kirk Knoernschild's boek “Java Application Architecture” aan het lezen. Het boek gaat over “Modularity Patterns with Examples Using OSGI”. Ik lees wel vaker vakliteratuur. Niet altijd is er even makkelijk doorheen te komen. Bij Kirk's boek is dat in elk geval geen probleem. Het is 'to the point' en wat hij vertelt is relevant en herkenbaar. Een echte aanrader dus.

Nu heb ik eerder wel eens geroepen dat Java (en een hoop andere talen) een goed uitgewerkt, gestandaardiseerd, module-concept mist. Dat klopt en dat klopt niet. Je hebt al een hele tijd dingen die in de buurt komen: Jar files en de bijbehorende class-path problemen, Maven om dit (gedeeltelijk) voor je op te lossen, Webapplicaties (war & ear files), Componenten van verschillende UI-frameworks en zelfs 'echte' modules in de vorm van OSGI bundles. Maar wat is nu een java module?

Geen OSGI

Kirk's boek is zo goed, omdat het niet alleen over OSGI bundles gaat. Het is uit de volgende delen opgebouwd:

1. Wat is een module en hoe dien je deze toe te passen?

2. Welke patterns herkennen we in het toepassen van modules?

3. Een aantal voorbeelden uitgewerkt in OSGI

Ik wil zeker wat meer te weten komen over OSGI, maar deel 3 is niet de reden dat ik het boek zo graag lees. Bij het lezen van deel 1 en 2 herken ik veel dingen die ik tijdens het werken met de genoemde net-niet-modules in de praktijk ben tegengekomen. Hoe zorg je dat een ontkoppelde relatie tussen classes tijdens deployment niet toch een cyclische afhankelijkheid tussen modules introduceert? Hoe ga je om met omgeving-afhankelijkheden? Wat is de juiste granulariteit van mijn modules? Dit soort vragen worden hier besproken. Bij het lezen krijg ik echter de indruk dat Kirk OSGI als de 'holy grail' van java-module implementaties ziet. Op dit moment is dat zeker waar. Toch denk ik niet dat we in de toekomst allemaal opeens OSGI-blundles gaan opleveren.

OSGI bestaat al jaren en heeft zeker zijn nut bij bepaalde toepassingen bewezen. Maar voor de meeste mensen blijft het extra ballast, die je als het even kan niet meeneemt. Hoe goed Kirk's boek ook is, ik denk niet dat hij ons allemaal aan de OSGI gaat krijgen.

Wel modules

Toch voorspel ik dat we straks allemaal in modules gaan denken. Java krijgt namelijk een gestandaardiseerd module-concept. Naast een gemodulariseerde JRE zal Project Jigsaw in Java SE 8.0 het concept 'module' aan de taal toevoegen. Zoals hier te lezen valt, worden module-declaraties een stukje van Java. Je kunt straks gewoon zeggen:

module foo {

    exports foo;
    exports foo.spi;
    exports foo.util;
} 

en daarmee duidelijk aangeven hoe je module heet en wat de public interface van de module is. Encapsulatie van je module is hiermee dus mogelijk. Iedere Java SE 8.0 gecertificeerde developer zal ermee bekend zijn en zal het gaan toepassen. Een applicatie zal niet langer een brei van class-instanties op een classpath zijn, applicaties zullen uit modules bestaan en modules weer uit modules.

OSGI als implementatie

Gaan we dan geen opeens OSGI meer gebruiken? In tegendeel. Ik denk dat we het heel veel zullen gebruiken, maar wellicht zonder er al te veel aandacht aan te besteden. We zullen het net zo gebruiken als we een applicationserver gebruiken om onze webapplicaties op te draaien en niet meer over de thread-afhandeling van elk web-request te hoeven nadenken. Jigsaw wordt namelijk geen kloon van OSGI. Waar OSGI een volledig framework is, laat Jigsaw ruimte en vrijheid. Het schrijft bijvoorbeeld niet voor dat een runtime-environment meerdere versies van een module moet kunnen ondersteunen. Ook deployment terwijl de applicatie al draait wordt standaard niet ondersteund. Als je dat wilt, zul je een runtime moeten gebruiken die dat wel ondersteunt. Waarschijnlijk komen we dan weer bij OSGI implementaties uit, omdat deze volwassen genoeg zijn en Jigsaw modules zich straks als een vis in het water voelen binnen een OSGI container. De ESB, IDE of Applicationserver waarvoor je een module ontwikkelt ondersteunt nu al vaak OSGI bundles en zal straks ook helemaal geen probleem hebben met de Jigsaw-modules. Daarmee is dan meteen ook het punt van meerdere tegelijkertijd gedeployede versies van een module afgedekt.

We zullen OSGI echter soms ook bewust niet gebruiken. Als we onze modules lokaal testen zullen we liever geen OSGI container starten en de module direct op de JVM draaien. De restrictie dat ik dan geen meerdere versies van een module op mijn class-path mag hebben lijkt me dan niet meer dan een goede sanity-check.

Over sanity gesproken. Er bestaat het risico dat mensen modules compleet verkeerd zullen gaan inzetten. Projecten zouden kunnen falen, alleen maar omdat men helemaal euforisch is geworden over de nieuwe mogelijkheden die modules bieden zodat alles een grote module-spaghetti is geworden. Laat ik dit proberen te voorkomen door nog een keer te zeggen dat we allemaal Kirk's boek moeten lezen en het straks met gezond verstand over zaken als 'Independent Deployment' en 'Acyclic Relationships' van modules kunnen praten. Dan hoeven we het wiel op dat gebied in elk geval niet opnieuw uit te vinden.

Geschreven door Mark Kikken
Senior (JAVA) Lead Developer

Onlangs kwam ik onderstaande afbeelding tegen op de site van Alistair Cockburn, met als vrijwel enige toelichting dat het door Kent Beck gebruikt werd bij een aantal presentaties die hij gegeven heeft in het jaar 2000. Hoewel een plaatje als bekend meer zegt dan duizend woorden, spreekt dit buiten zijn context 12 jaar later niet meer helemaal voor zich.

Ten eerste helpt het als je weet waar XP voor staat. XP, Extreme Programming, is een werkmethode die in de jaren negentig van de vorige eeuw uit experimenten is ontstaan. Het doel waarop gemikt werd, was zo snel mogelijk, zo betrouwbaar mogelijk, zo consistent mogelijk over een langere periode nieuwe functionaliteit met business relevantie op te kunnen blijven leveren. 

Met “Swiss XP project” wordt het payroll systeem bedoeld dat gemaakt werd voor Chrysler. Chrysler werd in 2000 overgenomen door Daimler Benz, waarop het project werd gestopt. Zo eindigt de vette lijn bij “what would this mean?”, zonder dat het Swiss XP project zelf nog op zoek kon gaan naar het antwoord. 

Ik denk dat het plaatje destijds gemaakt is om een van de neven effecten van het zoeken naar de meest effectieve werkmethode te illustreren, namelijk dat de release cycles steeds korter werden. Door de Y-as logaritmisch te maken, oogt het ook lekker, met zo'n vette rechte streep, en dat er niet bij staat wat er op de X-as wordt afgebeeld geeft in die context ook niks meer. 

Doordat de streep van links naar rechts daalt wordt gesuggereerd dat “Days of work not yet in production” een slechte zaak is. En dat is natuurlijk ook zo. Want in economische termen laat zich dat vertalen in “een investering waar nog niks tegenover staat”. Pas in productie komt er Return On Investment. 

XP is als proces nogal streng. De moderne agilist zal bekend zijn met het begrip "Work In Progres", en geneigd zijn een verschil te zien tussen "Days of work not in production" en WIP. Binnen XP wordt dit onderscheid echter geen betekenis toegekend. Want naarmate de Gedane Arbeid langer op de plank ligt en niet in productie gebracht is, stijgt de kans dat de Gedane Arbeid (niet begroot) nawerk vereist. 

Het is daarom uit het oogpunt van risicomanagement zinvol om de dichotomie tussen “Days of work not yet in production” en “Work In Progress” niet te accepteren. WIP is af als het ROI maakt. 

Niet voor niets is “release early, release often” een van agile's mantra's. Men slaat bovendien ten minste twee vliegen in een klap: niet alleen wordt de ROI daadwerkelijk zichtbaar, het nog steeds grootste gevaar voor de kwaliteit of zelfs het slagen van projecten, geen of weinig feedback van “expert users” die echt ook iets anders te doen hebben dan ontwikkelaars begeleiden, wordt ook ondervangen.

Inmiddels is de agile bal vrolijk door het software ontwikkellandschap gerold. In de Java wereld zijn 12 jaar later de build server, het schrijven en automatisch uitvoeren van unit-testen, het gebruik van Maven voor het managen van depencies en bouw gemeen goed geworden, zo zelfs dat de afwezigheid van deze tooling gevoeld wordt als onverantwoordelijk gedrag, helemaal los van de mate waarin het project over zichzelf denkt als meer of minder agile. Het bijzondere is gewoon geworden. Niet zoveel projecten gaan dagelijks naar productie, maar met een beetje nadenken over hoe je nieuwe functionaliteit implementeert zou het best kunnen.

En "what would this mean?" In 2007 al werd er door "Express yourself in thé world's largest 3D Chat and Dress-Up community" IMVU inc. tot 50+ keer per dag "live" gegaan. Zoals in eerste instantie het test – build process zo veel mogelijk geautomatiseerd werd (de avant garde van rond de eeuwwisseling), staat technisch niets ook het automatiseren van de deployments in de weg. En zoals in de loop van de tijd de build en test tools gerijpt zijn, zullen ook de release en configuration management tools steeds volwassener worden.

Over hoe te komen tot een productiestraat die Continous Delivery mogelijk maakt en waarom je dat zou willen is in 2010 een mooie pil verschenen in de Addison Wesley Signature Series van de hand van Jez Humble en David Farley met als titel “Continuous Delivery, Reliable Software Releases through Build, Test, and Deployment Automation”.

Of Continuous Delivery een zonnige toekomst tegemoed gaat? Ik denk het wel, op dezelfde manier waarop de productie van software grosso modo veel gewonnen heeft door inzichten, processen en tooling die met de verspreiding van agile gemeen goed zijn geworden. En net zo min als vandaag de dag de dagelijkse release gangbaar is, zal over 10 jaar de 50+ keer per dag live gaan, die de huidige avant garde 5 jaar geleden alweer haalde bij IMVU, gangbaar noch nodig zijn. Maar, zullen we zeggen, als we er een beetje slim over doen, kan het best. 

Het plaatje laat, met dank aan de logaritmische Y-as, ook nog een gedachten experiment toe: Wat gebeurt er wanneer we de lijn nog verder naar beneden door trekken, door de X-as heen? Dan hebben we software gedeployed voor we hem gemaakt hebben. Mooi man. Maar waarom daar gestopt? We trekken de lijn gewoon nog wat door. Dan draait morgen geheel automagisch de oplossing voor het probleem waarvan we ons overmorgen bewust gaan worden. Now we're talking!

De kredietcrisis, de bankencrisis, de financiële crisis: veel namen voor de economische situatie van de afgelopen jaren. Naar de oplossingen wordt al tijden gezocht en dé oplossing wordt maar moeilijk gevonden. Het onderliggende probleem: de ongebreidelde mogelijkheden die bestaan hebben schulden te maken. Schulden die in sommige gevallen zelfs de mogelijkheden van aflossen te boven gingen en nu elke vorm van economische groei tegenhouden.

In de IT hebben we ook al jaren last van schuld. En hoewel het een andere schuld betreft dan een pure schuld in geld, kost de rente ons al jaren handen vol geld. Ik heb het over Technical Debt : de schuld die we opbouwen door gebrek aan kwaliteit, waarbij we de rente betalen in gebrek aan productiviteit. Hoe we hier als Salves over denken, mag duidelijk zijn, kwaliteit staat bovenaan. Maar wat als je al in de situatie zit dat je het Griekenland van de IT dreigt te worden?

Wellicht kunnen we wat leren van de verschillende maatregelen die genomen zijn tijdens de huidige crisis en de mate waarin die maatregelen wel of niet gewerkt hebben. We kijken hierbij naar verschillende maatregelen en proberen een equivalent te vinden in de IT om te helpen onze eigen schuldencrisis op te lossen.

Binnen de vergelijking staan de verschillende projecten of systemen voor landen; is de schuld de al eerder genoemde technical debt; en kan de economie gezien worden als het vermogen van projecten (teams) of functionaliteit te creëren (dus de productiviteit). De wereld en bijbehorende economie staan dan voor de organisatie als geheel.

S&P, Moodies en Fitch

Het eerste dat we gezien hebben zijn de signalen van de ratingbureaus: afwaarderingen van de rating afhankelijk van de schuld. In feite gaat het hier om het vertrouwen dat anderen hebben in de projecten of teams. Binnen de IT hebben we dergelijke ratingbureaus niet. Wel is er duidelijk aanwezig het vertrouwen van management en gebruikers in het vermogen van het project om functionaliteit te realiseren. Veel organisaties kennen Q&A-achtige afdelingen welke deze signalerende functie (kunnen) vervullen. Anderzijds kan – indien Agile gewerkt wordt – een teruglopende Velocity gezien worden als signalering.

Signalering kwam echter wel te laat: inzicht in de risico’s van gemaakte schulden ontbrak en ratingbureaus waren mogelijk niet gebaat bij afwaarderingen. Er moet dus continue voor gewaakt worden een toezichthouder die zijn taak niet afdoende uitvoert: “Qui custodiet ipsos custodes?” is dan van toepassing.

Ook leverden landen zelf veelal de benodigde informatie aan, waardoor fraude op de loer ligt. Bij het inzetten van tools is het dus van belang om te zorgen dan objectieve metingen en interpretaties gedaan worden.

Bezuinigen…

Veel van de acties die de afgelopen tijd gedaan zijn, zijn gericht op bezuinigingen: het in sterke mate terugdringen van de schuld. Het voordeel is duidelijk, de schuld wordt direct teruggebracht om in de toekomst minder rente te hoeven betalen waardoor de economie gaat stijgen (de Monetaristische gedachte). Het nadeel is natuurlijk dat de mindere bestedingen op korte termijn leiden tot een recessie.

Binnen de IT is deze parallel ook te trekken: het terugdringen van Technical Debt wordt hierbij gedaan door uren te steken in het verbeteren van de kwaliteit. Bezuinigingen worden dan gedaan op de geleverde functionaliteit. Dit biedt ruimte voor aflossingen van de schuld. Deze verbeteringen zorgen ervoor dat productiviteit op langere termijn kan groeien. Op korte termijn kosten de uren die gestoken worden in het verbeteren van kwaliteit direct productiviteit: elk uur gestoken in verbeteringen wordt niet gestoken in functionaliteit.

… En groei.

Na een aantal jaren van forse bezuinigingen wordt binnen de wereld de roep om maatregelen om groei te stimuleren en bestedingen vanuit de overheid groter. Hogere bestedingen leiden tot economische groei. Door de economische groei ontstaat financiële ruimte waarmee in hoogtij dagen de leningen die gebruikt zijn voor de bestedingen afbetaald kunnen worden (de Keynesiaanse school). Groei wordt daarnaast vaak ook gestimuleerd door het nemen van structurele maatregelen voor verbeteringen, zoals ingrijpen in de woningmarkt, hypotheekrenteaftrek en de arbeidsmarkt.

Binnen de IT is het nemen van grotere leningen op de kwaliteit lastiger te realiseren. Op hele korte termijn kan dit wellicht tot wat resultaten leiden, maar als snel leidt dit waarschijnlijk tot meer problemen. Meer is veelal te halen in het investeren in structurele hervormingen op technisch vlak (verbeteringen aan de toolchain), procesmatig vlak (efficiëntere processen adopteren) of menselijk vlak (beter mensen of scholing van mensen).

Externe steun

Soms kunnen landen het niet zelf meer aan. Voorbeelden hiervan kennen we in de vorm van Griekenland of (hopelijk in mindere mate) Spanje en Italië. Voor hen is het lastig om zelfstandig uit het dal te klimmen. Wat we hierbij gezien hebben is ingrijpen vanuit de ECB en andere landen. Voor een deel is zelfs gekozen voor het kwijtschelden van een deel van de schuld.

Kwijtschelden van een deel van de schuld is binnen de IT lastig. Een mogelijkheid hiertoe is om de regels die gelden te versoepelen. Een andere optie is het team te ontlasten voor een deel van de functionaliteit. Beide maatregelen zijn verre van ideaal en net als in de echte economie ligt het risico op de loer dat projecten in de verleiding van herhaling van gemaakte fouten vallen. Daarnaast is schuld in de echte economie vooral een virtueel begrip; in de IT blijft de kwaliteit een probleem, ook al veranderen we de regels, de echte schuld blijft bestaan.

Ingrijpen vanuit de ECB of vanuit andere landen kan gezien worden als de inzet van medewerkers van andere teams of organisatieonderdelen om de kwaliteit van het project te verbeteren. Deze medewerkers gaan dus concreet meewerken om functionaliteit op tijd af te krijgen – het equivalent van het Europese garantiefonds.

Anderzijds kan ook een Trojka ingesteld worden die gaat werken aan het terugdringen van de schuld. De medewerkers van deze groep (het mogen er meer dan drie zijn) kunnen meewerken met en/of toezien op de uitvoering van de (structurele) verbeteringen aan de kwaliteit.

In beide gevallen is één ding van belang: het team dat onder curatele staat moet elke keer bewijzen om zelf de benodigde progressie te willen boeken, zelf de investeringen maken om de schuld terug te dringen. Uitblijven hiervan leidt tot wantrouwen en in het ergste geval tot het failliet van het land: het team wordt ontbonden, het project wordt gestopt.

Ingrijpen?

Net zoals bij het oplossen van de kredietcrisis is het oplossen van dit soort productiviteitsproblemen binnen de IT geen sinecure. Bij grote tekorten lijkt het goed om eerst flink te bezuinigen om het huishoudboekje op orde te krijgen. Daarna moet een moment gekozen worden waarbij gekozen wordt voor het stimuleren van de groei. Enerzijds wordt dit moment ingegeven vanuit de economische theorie (die hier geen sluitend antwoord op lijkt te hebben), anderzijds door de wil van het volk (het team en de gebruikers binnen de IT).

Het tweede aspect moet hierbij niet onderschat worden: continue bezuinigingen kan leiden tot bezuinigingsmoeheid bij gebruikers en het team. Gebruikers gaan klagen over het uitblijven van nieuwe functionaliteit en na maanden van alleen kwaliteit verbeteren wil het team ook wel wat anders: de motivatie daalt. Zeker aangezien we in de praktijk zien dat in dit soort situaties het herstel altijd langer duurt dan verwacht: het is een traject van vallen en opstaan.

Duidelijk is wel dat snel, daadkrachtig en effectief ingegrepen wordt, waarbij af en toe heilige huisjes geslecht moeten worden. In Italië zien we hierbij de installatie van een technocratenkabinet: een zakenkabinet van deskundigen dat los van enige ideologie de noodzakelijke maatregelen neemt. Binnen de IT kan hierbij gekozen worden voor de formatie van een interventieteam van de top ontwikkelaars, architecten, testers, enz.; eventueel aangevuld met externe kennis.

Anderzijds kan natuurlijk gekozen worden voor het maken van een verbeterplan gesteund door management over de verschillende afdelingen heen.

Wanneer komt u met uw eigen Lente/Kunduz-akkoord?

Geschreven door Jeroen Benckhuijsen

Salves ICT Consultant / Architect / Gecertificeerd Scrum Master

Vroeger was alles heerlijk simpel: je had testers die altijd zeurden over de vele bugs van de door de developers opgeleverde software en je had developers die zeurden over de testers en hun onmogelijke eisen en gevonden issues. En daar tussenin stond een hoge muur, zodat je fijn met je eigen soortgenoten kon werken en geen last had van de andere kant.

Tegenwoordig zie je met de opkomst en het toenemende gebruik van Agile methodieken, dat deze gescheiden werelden compleet verdwijnen en dat testers en developers steeds meer schouder aan schouder samen werken aan het product. Hierdoor verdwijnen ook de grenzen tussen traditionele test activiteiten en developer activiteiten en ontstaat de "testdev" of de "devtester". Een goede zaak!

 

Deze overlapping en ineenschuiving van activiteiten heeft een aantal oorzaken:

• De Agile werkwijze dwingt testers en developers om nauw samen te werken in kleine teams. Hierdoor ontstaat een saamhorigheidsgevoel en een gezamenlijke verantwoordelijkheid voor het opleveren van een goed eindproduct. Dit leidt tot een betere communicatie tussen testers en developers, begrip voor elkaars werk en zelfs de bereidheid om elkaar te helpen als het op het ene vlak wat drukker is dan op het andere vlak.
• Moderne ontwikkeltechnieken gaan vaak uit van Test Driven Development (TDD), waarbij testen nauw is verweven in het hele development proces en eerst de requirements en tests worden opgesteld, voordat daadwerkelijk iets wordt ontwikkeld. In kleine Agile teams zullen testers en developers dit gezamenlijk opstellen en uitvoeren en zullen testers steeds nauwer betrokken worden bij tools die voorheen puur voor developers waren bestemd. De testers zullen hier dus ook kennis over op moeten doen, zodat ze toegevoegde waarde hebben in kleinschalige Agile projecten.
• Omdat de Agile werkwijze vaak in internet projecten wordt toegepast, zie je ook een overlapping van tooling ontstaan. Developers gebruiken specifieke unit testing tools, maar zullen ook algemenere test tools gebruiken om het eindresultaat te testen, die ook vaak door de testers worden gebruikt voor hun tests. Testers en zeker testautomatiseerders, gaan steeds meer verschillende en specifiekere test tools gebruiken om alle functionele en non-functionele requirements te testen, zoals performance tests, usability tests, browser compatibility tests, etc. Hier onstaat deels een overlap en testers en developers zullen kennis gaan delen en samenwerken.

Al deze factoren zorgen ervoor dat we op weg zijn naar een gedeeltelijke samensmelting van testers en developers: de testdev of de devtester. Natuurlijk zal altijd ruimte zijn voor specialistische testers en developers, zeker in grote projecten, maar voor de generieke testers en developers ontstaat een nieuwe en uitdagende ontwikkeling voor de deur, die zeker voor testers zeer interessant is. Testers zullen deels mee gaan ontwikkelen en developers zullen deels mee gaan testen, naar gelang de drukte in het project.

 

Dit vereist voor testers dat ze zich ook gaan verdiepen in ontwikkelmethodieken, frameworks en programmeertalen, zoals Java, .NET en Ruby on Rails, en ook in testtechnieken zoals Test Driven Development, Behaviour Driven Developement, Rspec en Cucumber. Daarnaast kan een traditionele testanalist zich niet meer beperken tot Excel spreadsheets en het Tmap boek, maar zal hij ook een basiskennis moeten hebben van functionele testautomatisering en performance testing.

 

Dit maakt het vakgebied voor de generieke tester echter zo veel leuker en uitdagender, want niet alleen blijf je jezelf altijd ontwikkelen in nieuwe technieken en werk je veel concreter mee aan het eindproduct, ook ontstaat een nieuw carrière perspectief. Want vroeger leek alles wel mooi simpel, maar als generieke tester liep je wel altijd tegen een dilemma aan: blijf ik tot in lengte van dagen testgevallen maken in Excel of ontwikkel ik me richting test coördinator of test manager? In dit huidige mooie en opwindende tijdperk wordt de rol van generieke tester misschien wel een van de belangrijkste en leukste rollen die je kunt vervullen in de testwereld.

 

 

 

Geschreven door John van Arkelen
Testconsultant