Man bör alltid tidsbegränsa digitala tester. Även i de fall då man i realiteten vill att de testande ska få obegränsat med tid är det i praktiken nödvändigt att begränsa tiden. Utan tidsbegränsning kan användare ligga kvar i systemet oändligt länge. Det skapar en osäkerhet för administratörerna som man vill undvika, vid exempelvis nedstängning för underhåll eller vid avslut av ett test. De som fortfarande är registrerade som aktiva, håller de faktiskt på att göra testet eller har dom bara stängt ner webbläsaren för att aldrig återvända?
Vill man att de testande inte ska påverkas negativt av tidsbrist är det bättre att sätta en extra lång tid för att slutföra testet. En enkel tumregel är att man bedömer den maximala tiden det tar att göra testet och lägger till 50% till den tiden.
Tidsbegränsningar bör alltid vara centralt baserade, det vill säga bestämmas från servern. Anledningen till att man aldrig ska lägga in tidsbegränsningar lokalt hos användaren är för att det är mycket lätt att kringgå tidsbegränsningen. Exempelvis kan användaren under testets gång ändra i sin dators tidsinställningar eller lägga in ett skript som påverkar webbläsarens interna tidshantering.
Ibland använder man sig av en tekniska lösningar som inte kommunicerar mot en central server. Det kan till exempel vara appar där frågor och svar finns sparade lokalt för att man ska kunna utföra testerna utan att behöva vara uppkopplad. I dessa fall är det viktigt att tidshanteringen sker inom appen och inte genom enhetens tidshantering, eftersom den kan manipuleras.
Det finns tre huvudsakliga sätt att tidsbegränsa tester. Det vanligaste är att man har en bestämd totaltid som begränsar tiden för hela testet. Anledningen till att majoriteten av test använder sig av en bestämd totaltid beror på att det är lätt att administrera och lätt att förstå för samtliga inblandade: beställare, testande såväl som konstruktörer.
Ett alternativ tidsbegränsning är för varje fråga. Fördelarna med uppdelad tidsbegränsning är att man minimerar de fel som uppstår i och med att testande förmåga att prioritera tiden är olika. Dessutom innebär en uppdelad tidsbegränsning att man hindrar testande från att fastna på tidiga frågor och därför få ett missvisande resultat på frågor som kommer senare i testet.
Den tredje typen av tidsbegränsning är relativt öppen. Det finns en väl tilltagen totaltid för testet. Dock, den slutgiltiga tiden för användaren läggs till testresultatet. Metoden kan med fördel användas då man förväntar sig att en stor del av de testande kommer att placera sig på samma nivå. Detta gäller till exempel programmering där flera personer klarar de ålagda uppgifterna och man vill använda tidsaspekten för att att skilja dem åt.
Den viktigaste frågan vid själva testkonstruktionen är: Vilken grad av tidsbegränsning ska man använda sig av? Svaret beror huvudsakligen på tre saker.
Vad är det man testar? Om man testar färdigheter vill man ha en snävare tidsbegränsning, eftersom den extra pressen leder till en bättre spridning av de testandes resultat. Om man däremot utför personlighetstest vill man generellt sett använda sig av en vidare tidsbegränsning.
Vad testar man för? Ett test som syftar till att hitta personer som ska utföra enkla uppgifter utan strategiskt tänkande bör ha en snävare tidsbegränsning. Till exempel test för juniora programmerare som ska utveckla enskilda funktioner och objekt i stället för verka som arkitekter bör vara hårt tidsbegränsade, eftersom snabbheten är mycket viktig i det fallet. Å andra sidan, när man testar för mer komplexa uppgifter där kreativitet och analytisk förmåga är en viktig del i beslutsfattandet är det viktigt att man skapar vida tidsbegränsningar eftersom alltför smala tidsbegränsningar har en negativ effekt på dessa färdigheter.
Var vill man ha den största spridningen av resultaten? När det är viktigare att särskilja på en grundläggande nivå ska man erbjuda en vid tidsbegränsning. Fast oftast vid tillsättningar av tjänster vill man skapa ett urval bland toppskiktet. Då passar det bättre med en snäv tidsbegränsning som ger en bättre åtskillnad på de högre nivåerna.
Sammanfattningsvis bör man alltid ha en tidsbegränsning för digitala test. Om det är tekniskt möjligt ska man alltid utgå ifrån serverns tidshantering. Omfattningen av tidsbegränsningen bör man justera utifrån vad man testar, vad man testar för och på vilken nivå man vill att testet ska vara mest utslagsgivande.