Hoe test ik mijn technische oplossing en waarom is dit belangrijk?

Testen is één van de belangrijkste stappen in het realiseren van een technische applicatie. Een website, platform of een mobiele app. Het is een onderdeel wat regelmatig onderschat wordt. Een gemiste kans, want de feedback die je in deze fase verzameld zorgt voor een prima uitgangssituatie voor de deployment van je product. Binnen een agile werkomgeving geeft het je ook de informatie die nodig is om vast te stellen of de ingeslagen weg de juiste is of dat er bijgestuurd moet worden. Testen hoeft niet moeilijk of tijdrovend te zijn. Dit zijn onze ervaringen en tips!

Testen van de technische oplossingen: Wanneer begin je hiermee?

De uitwerking van business case naar wireframes is een team aangelegenheid. Hierin wordt vanuit de randvoorwaarden een uitwerking gemaakt. De wireframes zelf kunnen als vertrekpunt van de eerste tests worden gedeeld. Binnen het team en na verwerking van de interne feedback, aan een tweede betrouwbare kritische testers binnen de doelgroep. Je voorkomt op deze manier ervoor dat de voorkennis die er is binnen het projectteam en de persoonlijke voorkeuren de ontwikkeling van de juiste oplossing niet beïnvloed. Het voorkomt ook de ontwikkeling op basis van aannames, waardoor je in een vroeg stadium valkuilen ondervangt. Een zeer interessante toevoeging is dat je in dit stadium de betrokkenheid bij een aantal primaire personen binnen je doelgroep kan realiseren. Dit kunnen naast de stakeholders ook prominente personen zijn binnen het vakgebied. Deze betrokkenheid verhoogt de kans op succes voor de ontwikkeling van de functioneel wenselijke applicatie. Houdt er altijd rekening mee dat de betrokkenheid tijd reserveren voor het testen en het geven van feedback. 

Test document opstellen: Hoe ziet dat eruit?

Om de juiste input te krijgen van je testers is het zeer verstandig een testdocument op te stellen. Binnen het testdocument wordt het doel en een duidelijke scope van de applicatie beschreven. Dit vertrekpunt biedt duidelijkheid over de ambities en doelstellingen van de applicatie, website of het platform. De overige informatie binnen het testdocument functioneert als handleiding. Deze zorgt voor de juiste uitkomsten en feedback en voorkomt dat er onderdelen over het hoofd worden gezien. Houdt rekening met de tijd die geïnvesteerd moet worden door de testers. Hoe meer tijd er verlangt wordt, des te kleiner is de kans op feedback. Zorg er ook voor dat de testomgeving in orde is en past bij je doelgroep. Denk hierbij aan de devices die nodig zijn om de test te kunnen uitvoeren. 

Vanuit OBM ondersteunen we in de ontwikkeling van de juiste technische oplossing. Hierbij wordt er een testprocedure met de opdrachtgevers afgestemd die past bij de business case, de ontwikkeling en de doelstellingen van de applicatie.

De onderdelen die je kan verwachten in het testdocument:

  • Introductie
  • Business case
  • Doel van de testopdracht
  • Randvoorwaarden voor aanleveren feedback
  • Technische benodigdheden voor de test
  • Informatie tester (contactgegevens en relevante informatie)
  • Test vragen
  • Contactgegevens van opdrachtgever van de test

5 tips voor het testdocument:

1. Homepagina tour
Open de startpagina van je test en laat de tester ernaar kijken zonder voorkennis. Zo kom je achter de eerste reactie en indruk van de tester.

2. Opdrachten
Als de mogelijkheid er is, dan is het slim om te observeren terwijl een tester van start gaat. Je ervaart hoe de tester de opdrachten uitvoert, de applicatie ervaart en de functionaliteiten begrijpt die binnen de applicatie zijn opgenomen.

3. Video opname
Neem scherm en audio op. Hiermee worden de bewegingen vastgelegd en is de mogelijkheid om later de test opnieuw te bekijken.

4. Suggesties
Aan het einde vraag je de tester om suggesties en ongezouten kritiek. Mocht er veel feedback zijn, dan is het altijd slim om een mogelijkheid van contact op te nemen.

5. Afronden
Bedank de tester voor zijn tijd en energie! Vraag wat de algemene indruk was en welke punten er zijn uitgesprongen. Afhankelijk van de website, het platform of de app zijn er conclusies na de eerste feedback te maken. Volstaat de oplossing op basis van de feedback en de beschreven business case. Verwerk de feedback binnen de wireframes of bespreek de uitkomsten met de budgethouder, opdrachtgever en/of projectmanager. Een vervolg van de opdracht of uitbreiding van de scope is een logisch vervolg.

Testen van de technische oplossingen: Wanneer begin je hiermee?

De uitwerking van business case naar wireframes is een team aangelegenheid. Hierin wordt vanuit de randvoorwaarden een uitwerking gemaakt. De wireframes zelf kunnen als vertrekpunt van de eerste tests worden gedeeld. Binnen het team en na verwerking van de interne feedback, aan een tweede betrouwbare kritische testers binnen de doelgroep. Je voorkomt op deze manier ervoor dat de voorkennis die er is binnen het projectteam en de persoonlijke voorkeuren de ontwikkeling van de juiste oplossing niet beïnvloed. Het voorkomt ook de ontwikkeling op basis van aannames, waardoor je in een vroeg stadium valkuilen ondervangt. Een zeer interessante toevoeging is dat je in dit stadium de betrokkenheid bij een aantal primaire personen binnen je doelgroep kan realiseren. Dit kunnen naast de stakeholders ook prominente personen zijn binnen het vakgebied. Deze betrokkenheid verhoogt de kans op succes voor de ontwikkeling van de functioneel wenselijke applicatie. Houdt er altijd rekening mee dat de betrokkenheid tijd reserveren voor het testen en het geven van feedback. 

Test document opstellen: Hoe ziet dat eruit?

Om de juiste input te krijgen van je testers is het zeer verstandig een testdocument op te stellen. Binnen het testdocument wordt het doel en een duidelijke scope van de applicatie beschreven. Dit vertrekpunt biedt duidelijkheid over de ambities en doelstellingen van de applicatie, website of het platform. De overige informatie binnen het testdocument functioneert als handleiding. Deze zorgt voor de juiste uitkomsten en feedback en voorkomt dat er onderdelen over het hoofd worden gezien. Houdt rekening met de tijd die geïnvesteerd moet worden door de testers. Hoe meer tijd er verlangt wordt, des te kleiner is de kans op feedback. Zorg er ook voor dat de testomgeving in orde is en past bij je doelgroep. Denk hierbij aan de devices die nodig zijn om de test te kunnen uitvoeren. 

Vanuit OBM ondersteunen we in de ontwikkeling van de juiste technische oplossing. Hierbij wordt er een testprocedure met de opdrachtgevers afgestemd die past bij de business case, de ontwikkeling en de doelstellingen van de applicatie.

De onderdelen die je kan verwachten in het testdocument:

  • Introductie
  • Business case
  • Doel van de testopdracht
  • Randvoorwaarden voor aanleveren feedback
  • Technische benodigdheden voor de test
  • Informatie tester (contactgegevens en relevante informatie)
  • Test vragen
  • Contactgegevens van opdrachtgever van de test

5 tips voor het testdocument:

1. Homepagina tour
Open de startpagina van je test en laat de tester ernaar kijken zonder voorkennis. Zo kom je achter de eerste reactie en indruk van de tester.

2. Opdrachten
Als de mogelijkheid er is, dan is het slim om te observeren terwijl een tester van start gaat. Je ervaart hoe de tester de opdrachten uitvoert, de applicatie ervaart en de functionaliteiten begrijpt die binnen de applicatie zijn opgenomen.

3. Video opname
Neem scherm en audio op. Hiermee worden de bewegingen vastgelegd en is de mogelijkheid om later de test opnieuw te bekijken.

4. Suggesties
Aan het einde vraag je de tester om suggesties en ongezouten kritiek. Mocht er veel feedback zijn, dan is het altijd slim om een mogelijkheid van contact op te nemen.

5. Afronden
Bedank de tester voor zijn tijd en energie! Vraag wat de algemene indruk was en welke punten er zijn uitgesprongen. Afhankelijk van de website, het platform of de app zijn er conclusies na de eerste feedback te maken. Volstaat de oplossing op basis van de feedback en de beschreven business case. Verwerk de feedback binnen de wireframes of bespreek de uitkomsten met de budgethouder, opdrachtgever en/of projectmanager. Een vervolg van de opdracht of uitbreiding van de scope is een logisch vervolg.

Case: Ontwikkeling van een ledenplatform

Case bekijken

OBM Brainstorm Kit: 40 kaarten om een anders naar je organisatie, merk of product te kijken.

 

OBM Brainstorm Kit aanvragen