Dit interview is opgesteld aan de hand van e-mail verkeer met Michel Stomp (Creative Director) en Jellek Raats (Project Manager) van Studio Stomp.
In welke fase’s wordt er getest bij Studio Stomp?
Studio Stomp kent binnen een project een iteratief proces met meerdere fases.
Deze fases kunnen in verschillende samenstellingen één project vormen. Een project kan bestaan uit alle fases of uit één of meerdere fases. Studio Stomp kent de volgende fases:
• Inceptie: Concept ontwikkeling, briefing /
debriefing, vaststellen outer scope
• Functioneel ontwerp: Keuze medium,
vaststellen randvoorwaarden, innerscope
• Interactieontwerp: Persona’s, user stories, user
flow, interaction design, wireframes
• Visueel ontwerp: Grafisch ontwerp, UX design • Development: Technische realisatie van
product(en)
• Implementatie
• Monitoring en onderhoud
Iedere fase wordt getest. Volgens de processen van Studio Stomp heeft iedere fase een aantal voorwaarden waaraan het deelproduct moet voldoen. Daarnaast worden uit iedere vorige fase de criteria gesteld voor de volgende fase. Hoe eerder in het proces een fout wordt gevonden, hoe minder fouten later kunnen worden teruggevonden.
Na afronding van iedere fase moet een checklist worden opgesteld voor de volgende fase. De checklist bestaat voor een deel uit vaste punten en deels uit punten die specifiek voor een project gedefinieerd zijn. In een ideale wereld wordt iedere fase door meerdere subjecten getest. Per fase kan verschillen of meer dan één test nodig is, bijvoorbeeld gericht op type gebruiker. Wie zijn de eindverantwoordelijken bij het testen?
Het is per fase verschillend wie de
eindverantwoordelijke is bij het testen. In 99% van de gevallen zijn de algemeen,
technisch of creatief directeur de
eindverantwoordelijke bij het testen. Bij zeer kleine en korte projecten kan het voorkomen dat de gene die aan het project heeft gewerkt de eindverantwoordelijke is voor het testen. Onderstaande lijst geeft aan wie in welke fase eindverantwoordelijke is:
• Inceptie: Algemeen directeur • Interactie: Creatief directeur • Visueel: Creatief directeur
• Development: Technisch directeur • Implementatie: Algemeen directeur • Monitoring en onderhoud: Algemeen
directeur
Welke testmethodes worden er op dit moment ingezet bij Studio Stomp?
Studio Stomp test zijn producten doormiddel van testplannen. Deze testplannen worden opgesteld door de project manager. In de testplannen worden vooral de functionaliteit van de website of applicatie behandeld. Het testplan is een Word document waar het voor de tester mogelijk is de vragen met ja of nee te beantwoorden en eventueel een opmerking te plaatsen. Denk hierbij aan vragen als “Linkt het logo terug naar de homepage?”, “Werkt het formulier?”
en “Is de navigatie responsive?”.
User Scenarios worden er op dit moment nog niet gebruikt tijdens het testen, dit wilt
Studio Stomp echter wel in de toekomst gaan toepassen.
Hoe wordt op dit moment feedback verzameld en verwerkt?
Alle testers krijgen een testplan. Na het invullen van dit testplan levert de tester het testplan weer in bij de project manager. Deze bundelt alle testresultaten en neemt deze door. Als alle testplannen zijn verzameld volgt er een zo gehete testresultaten bespreking. In deze bespreking worden alle resultaten door genomen en behandeld. Zo wordt er in dit gesprek gefilterd wat echte problemen zijn en wat voor prioriteit deze hebben.
Na deze bespreking verwerkt de
projectmanager alle problemen in Redmine (issue tracking systeem).
Nadat elke fase wordt er ook een link of bestand, hangt af van de fase, naar de klant toegestuurd. Deze bekijkt de voortgang en test de website of applicatie voor zichzelf. Zijn bevindingen kunnen dan op erschillende manieren worden teruggekoppeld aan
Studio Stomp. De ene klant stuurt een mail, de ander belt Studio Stomp op of er wordt een Word document terug gestuurd met feedback en testresultaten.
Dit alles is een erg tijdrovende klus en is niet naar wens van Studio Stomp. Ook raakt Studio Stomp snel het overzicht kwijt. Zeker in het geval van feedback van de klant. Deze komen via allemaal verschillende manieren binnen en er is op dit moment geen centraal punt waar dit verzameld en
gearchiveerd kan worden.
Welke problemen treden zich op bij de huidige manier van testen?
Studio Stomp geeft aan dat de test vaak onvolledig zijn. Ze missen een generieke checklist per type project of fase met criteria waaraan alle (deel)producten (van dat
type) moeten voldoen.
Op dit moment zijn de tests vaak niet gebaseerd op input en resultaten uit
voorgaande fases. Dit komt mede omdat het al snel onoverzichtelijk wordt wat de vorige resultaten waren en wat daar mee is gedaan. Het verzamelen van feedback is daarom erg tijdrovend. Er zitten op dit moment teveel
tussenstappen in het testen en het verzamelen en het verwerken van de testresultaten.
Studio Stomp ziet dit graag geautomatiseerd worden.
Ook is Studio Stomp niet tevreden met de testplannen die zijn opgemaakt in Word. Deze zijn moeilijk tot niet doorzoekbaar, slecht geformatteerd en fout gevoelig.
Interview Michel Stomp
Dit interview is opgesteld om meer te weten over jullie testmethodes en de redenen waarom jullie testen. Om tebeginnen, op welke manier testen jullie een product?
Op dit moment hebben wij geen vaste methodes om te testen. Eigenlijk is het een beetje een rommeltje. In het verleden hebben wij wel gebruik gemaakt van
testmethodes. Deze werden geleid door de project manager. Die schreef aan de hand van criteria, waaraan het product moet voldoen, user scenario’s en functionele vragen. Dit kwam in een document en deze werd verspreid onder een aantal testers. Elke tester kreeg een aantal platformen met bijbehorende browsers. Bijvoorbeeld ik, Michel, jij moet deze scenario’s doorlopen op een Mac met de browsers Chrome
en Safari. Met vragen als “Zit dit erin?”, “Werkt alles goed?” en “Staat alles op de goede plek?”. Daarnaast heb je developers die gewoon moeten testen wat ze bouwen.
We hebben een aantal keer de focus proberen te leggen op zelf je browser tests uit te
voeren, maar dit is nog niet voldoende in ons systeem verankerd. Momenteel benoemen we een aantal testers welke het product op verschillende devices en browser proberen. Dit doen ze zonder dat er een plan of
document of iets dergelijks achter zit. Dit zijn ook meestal de mensen die al aan het product werken.
Bevalt deze manier van testen? Kunnen jullie op deze manier de grootste gedeelte van de fouten opsporen?
De testscenario’s werden meestal aan het einde van het proces geschreven. Dit is eigenlijk niet ideaal. Ze zouden aan het begin van het proces moeten worden
geschreven. Iets als hier en hier moet het aan voldoen en deze criteria tijdens meerdere testrondes laten terug komen. Als je dit van tevoren doet kun je ook steeds terugvallen op de testscenario’s en kan je tijdens het developen steeds je product daarop testen.
Waarom is het voor Studio Stomp belangrijk om een product goed te testen?
Dit is belangrijk om de kwaliteit van het product te waarborgen. Als je niet test kun je alles wel maken. Maar dan weet je dat het vol fouten gaat zitten. Je doet het om fouten van je product of het nou design of functionaliteit is, zo vroeg mogelijk eruit proberen te halen. Het gebeurt nu nog steeds te vaak dat wij pas aan het eind beginnen met testen, terwijl dit toch eerder naar voren zou moeten komen.
Merken jullie verschil in resultaten met geteste producten tegenover niet geteste producten?
Ja, ik denk dat het op het moment wel steeds beter gaat. Dat het bij ons nu echt een product af is als wij zeggen dat het af is. Voorheen zeiden we wel eens dat een product af was en dan kregen we feedback terug van de klant of gebruikers met problemen waar wij helemaal geen rekening mee hadden gehouden. Door goed te testen loop je hier minder vaak tegen aan.
Testen jullie alle producten op dezelfde manier?
Nee, dat is heel verschillend. Ik denk dat dit ook altijd verschillend zal blijven.
Dit komt omdat wij verschillende soorten producten bouwen. Zo heb je producten die specifiek mobile zijn, die kun je bijvoorbeeld niet hetzelfde testen als een desktop product. Welke problemen heb je door het testen kunnen achterhalen, die anders niet naar voren waren gekomen?
Een voorbeeld is bijvoorbeeld een aanmeld formulier op een website. Je kan je dan aanmelden op drie verschillende manieren. Met e-mail, Facebook en Twitter. E-mail is dan vrij gemakkelijk. Je laat je e-mail adres achter, je krijgt een bevestigings mail en dat is dat. Bij Facebook werkt dat anders, je bent ingelogd of niet ingelogd op Facebook. Als developer ben je vaak ingelogd op je Facebook en dat geeft een heel ander scenario terug als dat je niet ingelogd bent. Als je dat niet goed test loop je tegen problemen aan. Dan krijg je feedback van gebruikers terug dat het niet werkt om in te loggen met Facebook, terwijl wij dan zeggen ja het werkt wel. Maar de fouten die zich voor doen komen dan van gebruikers die nog niet zijn ingelogd in Facebook. Tegen dat soort dingen loop je aan als je niet goed en uitvoerig test.
Ik weet dat de testscenario’s die wij
voorheen gebruikte vrij functioneel gericht
waren, mis je bijvoorbeeld een usabillity test?
Ja, zeker bij projecten die wij helemaal zelf maken, waar we zelf bezig zijn met het
ontwikkelen van een nieuw concept. Dan zou je wel gebruikerstests willen doen. Om er echt achter te komen of wat wij hebben gedacht goed werkt. Dit hebben we in het verleden ook bij sommige projecten niet goed gedaan. Maar vaak missen wij tijd en budget. Het gebeurt nu ook te vaak dat wij de producten laten testen door de mensen die het hebben gemaakt. Je zou willen dat bijvoorbeeld drie andere mensen van kantoor, die niks met het project gedaan hebben, het product testen.
Interview Avinash Changa
(DSRPT, We Make VR)
Bedankt dat je tijd wilt vrij nemen om een interview met mij te houden. Zou je
jezelf kunnen voorstellen?
Mijn naam is Avinash, oprichter en eigenaar van DSRPT Communications. Wij
produceren digitale producten in het breedste zin van het woord. Dit loopt uiteen van
digitale karakter animaties, after effects voor films, muziekvideo’s, maar ook websites en apps. Daarnaast ben ik eigenaar van het bedrijf We Make VR. We Make VR specialiseert zich in het maken van virtual
reality en wij zijn één van de pioniers op het gebied van VR en de Oculus Rift. Zo zijn wij bezig met het ontwikkelen van een camera voor de Oculus Rift waarbij het mogelijk is 360 graden te filmen.
Hoe zijn jullie in aanraking gekomen met Studio Stomp?
Ik ken Michel al een langere tijd. Via via zijn wij in contact gekomen. Michel wou naast muziek maken leren developen. Hij is Flash gaan leren en mensen uit mijn vrienden kring geef ik altijd een kans. Toen hij net begon heb ik hem wat kleine klusjes gegeven. Dit ging eigenlijk prima. Zodoende heb ik Studio Stomp zien ontwikkelen, later kwam Benjamin erbij als zakenpartner en zijn ze een paar keer bij mij terecht gekomen als ze zakelijke of juridische vragen hadden. Als er nu een web gerelateerd project binnenkom denk ik als eerst aan Studio Stomp.
Welke projecten heeft Studio Stomp voor jullie gedaan?
Één van de eerste projecten die wij samen hebben gemaakt was een online vertaal systeem. Het doel van dit project was om digitale producties gemakkelijker te laten verlopen. In onze branche komt het voor dat er bijvoorbeeld een tv commercial wordt
gemaakt. Deze commercial wordt gemaakt in het engels, maar dat het ook moet worden vertaald naar vijf andere talen. Het vertalen ging doorgaans via een excel sheet of power points, want klanten hebben daar meestal geen standaarden voor. Toen ben ik met het idee gekomen om een online systeem te maken. Het systeem bestond uit online invul formulieren, voor de vertalingen, die konden worden ingevuld en deze gingen dan automatisch naar de developer. Dit was één van de eerste projecten die ik samen met Studio Stomp heb gedaan. Daarnaast veel nieuwsbrieven, flash banners en promosites. Op dit moment zijn wij bezig met het
bedenken en uitwerken voor een app voor de kanaal rondvaartboten in Amsterdam.
Hoe test u het product dat Studio Stomp oplevert?
Via verschillende manieren. Wij testen het intern, afhankelijk van het target platform, op verschillende machines en browsers. Hierbij houden wij ons eigen excel sheets bij met bugs en andere zaken die ons opvallen. Na het verwerken van de eerste feedback en bugs wordt er een versie gestuurd naar de eindklant. Met de klant maken wij afspraken dat zij groepen hebben van verschillende gebruikers en deze laten wij bepaalde
handelingen en functies uitvoeren. Dus naast functioneel testen wij ook op usability. Wij proberen van het feedback dat wij
terugkrijgen een onderscheid te maken tussen technische bugs, usabillity issues en non- issues. Dit is altijd het lastigste, want als je een klant laat testen komen ze altijd terug met feedback als “Het werkt niet.” of “Ik kan geen tekst copy/pasten”, maar in welke situatie dit zich voordoet, waar dit niet kan en op welke platform dat gebeurt is altijd heel erg lastig te achterhalen. Het is voor een klant, die weinig tot geen technische kennis bezit, erg lastig om aan te geven op welke browser ze werken, welke versie van de browser en welke versie van bijvoorbeeld Mac OSX. Dat stuk van het proces is heel moeilijk te formaliseren. Zelfs als je ze een heel gestructureerd vragenlijst en instructies stuurt krijg je nog feedback terug als “Het werkt niet als ik op die knop druk”, maar wat de context is kom je niet achter. Je gaat dan toch proberen dingen te reproduceren en je in te leven in de gebruiker, maar je komt er dan toch niet achter.
Op welke manier levert u testresultaten en feedback aan Studio Stomp?
De excel sheets gaan door naar de gene die het project managet bij Studio Stomp. Als een excel sheet niet voldoende is proberen wij
het uit te werken in een pdf met screenshots en notities. Dit hangt ook van het probleem af. Sommige problemen moet je zien om te begrijpen wat er aan de hand is.
Doen jullie dit op dezelfde manier voor projecten die je niet bij Studio Stomp laat doen?
Dit hangt heel erg van het soort product af. Veel dingen die wij maken is geanimeerd werk en dit testen wij dan vooral op kleur en render kwaliteit. Op het moment dat het gaat om de wat complexere zaken. Bijvoorbeeld een project dat wij hebben gedaan voor een nieuwe attractie in een pretpark in Oslo, kan je dat niet goed intern testen. Dan moet je zelf in het vliegtuig stappen, in de karretjes gaan zitten en kijken of alle projecties kloppen en of de beleving is zoals wij bedoeld hebben. Wat wij wel proberen is om de gebruikersbeleving hier te simuleren, maar een exacte test is niet altijd mogelijk.
Is het voor u altijd duidelijk wat er met uw feedback wordt gedaan?
Soms wel, soms niet. Soms, zeker als je dicht tegen de oplever fase zit, dan zijn er veel dingen die tegelijk lopen. Wat er dan bijvoorbeeld dgebeurt is dat er nog acht
issues openstaan. We hebben dan een versie getest waarbij een aantal punten zijn opgepakt. Dit wordt doorgestuurd naar de klant en komt dan weer feedback op. Dit sturen wij weer door naar Studio Stomp, die op zijn beurt dan weer aangeeft dat deze punten al opgepakt zijn en geen issues meer zijn. De versies komen dan niet meer overeen. Hierdoor gaat er wel eens feedback verloren of loopt er feedback door elkaar.
Hoe vindt u het huidige testproces gaan bij Studio Stomp?
Wisselend. Er is zeker ruimte voor
verbetering. Er wordt nu een lijst opgesteld met punten die moeten werken. Dit wordt getest en dan zijn er een paar die werken, maar ook een paar niet. Wat je dan eigenlijk wilt is dat bij een volgende versie al deze punten weer mee worden genomen en opnieuw worden getest. Dit gebeurt op dit moment niet. Wat wel een gemis is. Dit zorgt ervoor dat je niet voort kan bouwen op
eerdere test resultaten. Van onze kant
proberen we dat te structureren, maar het zou makkelijker zijn als Studio Stomp daar een systeem voor had.
Studio Stomp geeft meestal een deadline voor het leveren van feedback. Zou je
het prettig vinden als dit op een centrale plek wordt bijgehouden, waar je altijd terug kan kijken wanneer er ook alweer een deadline is?
Dit gaat altijd via e-mail. Dit betekent dat er aan onze kant de project manager de
deadline in de agenda zet. Er is op dit moment niet een online systeem hiervoor, waar je bijvoorbeeld automatisch een e-mail reminder krijgt met een mededeling dat er een deadline aankomt. Het is op dit moment niet een echt gestructureerde manier van deadlines plannen. Meestal zijn het de project managers die met elkaar overleggen
wanneer de deadlines plaatsvinden.
Is het voor jullie duidelijk welke issues er tijdens een project openstaan en aan welke Studio Stomp werkt?
Dit gaat via e-mail verkeer. Dit is ook de rede dat het soms een beetje scheef loopt. Wij houden een lijstje bij met welke issues uitstaan en het komt dan voor dat er bijvoorbeeld acht van de tien issues zijn opgelost en dat er bij de volgende versie de openstaande niet meer op de lijst staan. Die zijn dan gewoon vergeten. Vaak komt dit omdat er dan een versie wordt afgesloten en in die versie zouden alle tien de issues zijn opgelost, maar dit is dan niet altijd het geval.
Dit kan irritatie opwekken bij de klant, omdat die bijvoorbeeld twee maanden geleden het probleem al hebben aangegeven. Dit is doorgegeven aan Studio Stomp en dan een maand later en twee versies verder is dit probleem nog niet opgelost. Dit komt voornamelijk door het e-mail verkeer, mensen die langs elkaar heen werken en het niet inzichtelijk genoeg maken van de issues voor iedereen.
Als Studio Stomp een applicatie ontwikkelt waarin het gemakkelijk is een product te bekijken en daar feedback op te leveren, zou je dit dan overwegen om te
gebruiken?
Ja zeker. Dit zou bijvoorbeeld voor het meest recentelijk project wat wij samen met
Studio Stomp hebben gemaakt voor Syngenta zeker een oplossing zijn geweest. Want dan heb je een online omgeving waar je je versies en feedback kan bijhouden. Dit zou helemaal ideaal zijn als het feedback wat wordt