Interview met… Demis Plomp

Demis Plomp ● dplomp@comscore.com
Kan je iets over jezelf vertellen?
Ik ben Demis Plomp, 38 jaar en werkzaam in QA sinds 1999 na een valse start als mainframe programmeur. Ik speel gitaar als hobby en ben een fervent festival bezoeker. Afgelopen maart ben ik begonnen als QA manager bij ComScore, een toonaangevend bedrijf op het gebied van Marketing onderzoek en bezoekers-metingen.
Heb je een bepaalde focus in je rol als tester opgedaan?
In de tijd hiervoor was ik eigenlijk gespecialiseerd in testautomatisering, hoewel dat bij mijn voorlaatste functie niet echt naar voren kwam. Ik ben wat automatisering betreft een fan van Selenium geworden en ben dat dan ook aan het introduceren in mijn team. Behalve testautomatisering heb ik een brede QA kennis opgedaan in de afgelopen jaren, ik ben bekend met verschillende ontwikkelmethodes waarbij Agile/Scrum de laatste tijd het meest populair lijkt.
Ik probeer op het moment mijn kennis zo goed mogelijk over te brengen op de rest van het QA team en vice versa leren ze mij veel over het product dat we testen, Digital Analytix.
Waarin onderscheidt Selenium zich, dat je zo’n fan bent?
Selenium kan met verschillende talen aangestuurd worden, Java is favoriet maar Perl, C# of Ruby horen ook tot de mogelijkheden. Dat geeft een hoop vrijheid maar ook een hoop mogelijkheden voor development-ondersteuning. Een goede samenwerking tussen QA en Development geeft alleen maar voordelen en met Selenium is het mogelijk om dat ook op code-niveau te doen.
Dus je programmeert zelf?
Nee, ik ben geen programmeur. Ik heb in het verleden wel veel met JAVA gewerkt voor GUI automatisering maar dat zou ik niet echt programmeren willen noemen. Het blijft bij simpelweg objecten identificeren en methods voor die objecten schrijven. Om effectief te kunnen automatiseren heb je niet veel meer nodig dan dat.
Wat moet ik verstaan onder QA kennis? Ben je dan ook bezig met het verbeteren van processen of bedoel je hiermee de testkant van IT kwaliteit bijvoorbeeld?
Met QA kennis bedoel ik inderdaad het verbeteren van processen en dergelijke, testen is per slot van rekening slechts een onderdeel van Quality Assurance. Ik draai intussen lang genoeg mee om de standaard ‘pitfalls’ direct te herkennen en ze ook te voorkomen.
Wat zijn de standaard pitfalls volgens jou en hoe kan je organisaties vanuit jouw perspectief hiermee helpen?
De meest voorkomende pitfall is om te proberen de tijdens ontwikkelfases verloren tijd terug te winnen in de testfase. Dit levert behalve lagere kwaliteit ook vaak irritaties op tussen QA, Development en Project management. Om dit te voorkomen is het noodzakelijk om vertragingen zo vroeg mogelijk te melden en acties te ondernemen. De Agile ontwikkelmethode geeft alle partijen de mogelijkheid om de voortgang te rapporteren in een vroeg stadium en om de planning aan te passen als dat nodig mocht zijn.
Een andere pitfall is het idee dat automatisering volledig de plaats kan innemen van handmatig testen. Het kan, maar het betekent wel dat er enorme kosten gemaakt worden in automatisering terwijl het vaak veel effectiever is om gedeeltes handmatig te blijven testen. Een voorbeeld hiervan zou bijvoorbeeld kunnen zijn het automatiseren van de GUI layout. Het is zeker mogelijk om geautomatiseerd screenshots te vergelijken maar in de meeste gevallen is het sneller en vooral goedkoper om gewoon je ogen te gebruiken.
Waarom vind je dat testen ‘slechts een onderdeel’ is van QA? Is het niet een geheel andere tak van sport?
Testen is fouten opsporen in een door developers afgeleverd product. Quality Assurance is een continu proces van design, risicoanalyse, informatie verzamelen en doorgeven, kritische vragen stellen, foutopsporing en verwachtingen managen. Uiteindelijk is het een manier om geld te besparen door fouten zo vroeg mogelijk in de ontwikkelingsfases op te sporen en te zorgen dat de eindgebruiker in iedere fase centraal blijft staan. Kwaliteit wordt nu eenmaal grotendeels bepaald door de ervaring van de klant met het eindproduct.
Als ik het goed begrijp, zie je testen als iets wat je achteraf doet en alle activiteiten ervoor als QA?
Niet helemaal, het belangrijkste van Quality Assurance is naar mijn mening namelijk het verbeteren van het gehele proces. Na het testen komt dus nog de evaluatie: Wat ging er goed, wat kan er verbeterd worden en wat hebben we gemist en hoe kunnen we zorgen dat we dat in het vervolg niet missen. Wat mij betreft is het ‘assurance’ gedeelte een belofte om een fout nooit te herhalen.
Dan moet je dus als organisatie leren van je fouten. Hoe realistisch zie je dit over het algemeen?
Het leren van je fouten is belangrijk voor iedereen, individu of bedrijf. Binnen QA kunnen we voorkomen dat een fout herhaald wordt door te documenteren wat er precies is gebeurd en die documentatie bij een latere release te gebruiken. Dat kan via testcases gaan of door een observatie uit het verleden te delen bij de requirementsbesprekingen waardoor een stuk functionaliteit er misschien iets anders uit komt te zien.
Kijk je met deze manier van aanpak ook naar andere industrieën? Bijvoorbeeld luchtvaart of autofabrikanten?
Ik haal wel wat inspiratie uit andere industrieën voor de zogeheten Usability checks (het toiletpotverhaal is een goed voorbeeld) en om aan te tonen hoeveel geld bespaard kan worden als bugs zo vroeg mogelijk worden opgespoord. De autofabrikanten en bijbehorende ‘recalls’ zijn daar inderdaad altijd een goede bron voor.
Ter aanvulling op het toiletpotverhaal: het toiletpotverhaal was dat de uitvinder een spatvrije pot had ontwikkeld die werkte als er op het water gemikt werd. Hij had echter geen rekening had gehouden met het feit dat het geluid dat dit produceerde ertoe leidde dat maar weinig mensen die instructie wilden opvolgen. Ik heb geen idee of dit op feiten is gebaseerd maar het illustreert usability concerns wel erg effectief.
De filosofie die vliegtuig-onderhoudsmensen hanteren om niets aan te nemen en altijd, na elke wijziging, vlucht of andere handeling, alles opnieuw te controleren zou in een ideale wereld ook in de IT toegepast moeten worden. Helaas is dat in de praktijk qua tijd en geld niet te doen en dus moeten we daar vaak wat flexibeler in zijn. En laten we wel zijn, de consequenties bij een fout zijn bij ons natuurlijk heel wat minder verstrekkend.