Een les die mislukt, doe je de volgende keer over. Bij een toets ligt dat anders. Loopt een toets halverwege vast, dan heeft de hele klas de vragen al gezien, is de spanning opgelopen en past een nieuwe afname vaak niet in de planning. Bij een toets uit het PTA komt daar de vraag bij of de afname nog eerlijk was. Daarom doet het ertoe hoe een leverancier met nieuwe functies omgaat. Nieuwe functies zijn welkom, maar elke wijziging in software is ook een risico.
Waarom is een toetsplatform gevoeliger dan andere software?
Bij een toets komt alles samen op één moment. Een hele klas, soms een hele jaarlaag, logt tegelijk in. Elk antwoord moet direct bewaard worden. De vergrendelde modus moet werken en de cijfers tellen mee. Een fout in een rooster of een berichtenapp is vervelend. Een fout in een toets ziet iedereen in het lokaal meteen, en je kunt hem achteraf niet meer goedmaken.
Hoe test je een nieuwe functie goed?
Goed testen bestaat uit een paar lagen die elkaar aanvullen:
- Automatische tests bij elke wijziging. Kleine tests controleren bijvoorbeeld of een score goed wordt berekend. Grotere tests doorlopen een hele toets: aanmaken, maken als leerling en nakijken.
- Een testomgeving. Een aparte versie van het platform waar een nieuwe functie eerst draait en waar je hem kunt bekijken voordat scholen hem zien.
- Handmatig testen op echte apparaten. Een iPad, een Chromebook en een Windows-laptop gedragen zich niet hetzelfde. Wat een automatische test niet ziet, zoals hoe iets in de klas werkt, moet een mens bekijken.
- Testgegevens. Een verzonnen school met verzonnen leerlingen, zodat je alles kunt uitproberen zonder echte gegevens te raken.
- Een test bij elke opgeloste fout. Glipt er toch een fout door, dan hoort er een test bij die precies die fout voortaan vangt.
Geen enkele laag vangt alles. Samen maken ze de kans klein dat een fout pas in de klas opvalt.
Waarom niet uitrollen tijdens toetsmomenten?
Ook een goed geteste update kan een afname verstoren. Een nieuwe versie kan betekenen dat een pagina opnieuw laadt of dat de server even herstart. Voor een leerling midden in een toets is dat precies wat niet mag gebeuren. Een zorgvuldige leverancier rolt daarom niet uit terwijl er toetsen lopen, en controleert dat vooraf. Als school help je mee door toetsweken en grote afnames op tijd door te geven.
Terugdraaien hoort bij testen
Testen maakt de kans op een fout kleiner, maar niet nul. Daarom is het minstens zo belangrijk hoe snel een leverancier terug kan naar de vorige versie. Dat gaat makkelijker als wijzigingen klein zijn, met één onderwerp per keer. Het lastigste deel is de database. Ook een wijziging daarin moet terug te zetten zijn, zonder dat er gegevens verloren gaan.
Testen hoort met nepgegevens
Testen met echte leerlinggegevens lijkt handig, maar het hoort niet. Een leverancier is onder de AVG verwerker en mag de gegevens van jouw leerlingen alleen gebruiken voor de doelen die de school heeft vastgelegd. Nieuwe functies uitproberen hoort daar normaal gesproken niet bij. Bovendien belanden testgegevens snel op plekken waar ze niet horen, zoals in een schermafbeelding of een testbestand. Een goede leverancier test daarom met een verzonnen school en verzonnen leerlingen.
Wat mag je als school vragen?
Met deze vragen krijg je snel een beeld van hoe een leverancier werkt. Een goede leverancier beantwoordt ze in een paar zinnen.
| Vraag aan de leverancier | Waar je op let |
|---|---|
| Is er een aparte testomgeving? | Nieuwe functies draaien daar eerst, voordat scholen ze krijgen. |
| Draaien er automatische tests bij elke wijziging? | Ook voor de kern: antwoorden opslaan, nakijken en cijfers berekenen. |
| Is er een testplan voor grote veranderingen? | Met een handmatige controle op de apparaten die jouw school gebruikt. |
| Wordt er uitgerold tijdens toetsmomenten? | Het antwoord is nee, met uitleg hoe dat wordt bewaakt. |
| Hoe snel kan een wijziging terug? | Er is een vaste werkwijze, ook voor wijzigingen in de database. |
| Wordt er getest met echte leerlinggegevens? | Het antwoord is nee: er wordt getest met verzonnen gegevens. |
| Hoe hoor je wat er verandert? | Zichtbare wijzigingen worden vooraf of direct gemeld. |
Blijft een leverancier vaag op deze vragen, dan bestaat testen daar waarschijnlijk vooral uit het zelf even proberen. Dat is te weinig voor software waar cijfers van afhangen.
Hoe dit bij TestWisely werkt
Bij TestWisely werken we met deze afspraken:
- Elke voorgestelde wijziging gaat automatisch langs tests voor de server en de website, een volledige bouw van de site en een controle dat elke databasewijziging een terugdraaiscript heeft. De afspraak is dat die controles groen zijn voordat een wijziging wordt samengevoegd.
- Bij het uitrollen draaien de tests opnieuw. Zijn ze rood, dan wordt er niet uitgerold. Na het uitrollen wordt automatisch gecontroleerd of het platform weer reageert.
- Een zichtbare wijziging komt eerst op een aparte testversie van de website. Bij elk voorstel hoort bewijs, zoals een schermafbeelding.
- We testen met een aparte testschool met testleerlingen. Echte leerling- of docentgegevens komen niet in de code, in testbestanden of in schermafbeeldingen.
- We rollen niet uit terwijl er een toets of les bezig is, en kijken dat vooraf na.
- Wijzigingen zijn klein, met één onderwerp per keer. Een databasewijziging wordt eerst op proef uitgevoerd en weer teruggedraaid. Gaat er na een uitrol toch iets mis, dan kan de vorige werkende versie opnieuw worden uitgerold.
