Etikettarkiv: digital testning

Slump i digitala tester

Förr i tiden, innan det digitala genombrottet, var man hänvisad till en specifik ordning av frågor och svarsalternativ när man använde pappersbaserade test. Ville man ha någon form av randomisering av tester var man hänvisad till muntlig testning, ett både dyrare och mindre tillförlitligt alternativ.

I dag ser det annorlunda ut. Tack vare digitala tester kan vi med enkelhet slumpa ordningen på såväl frågorna som svarsalternativen. Är det alltid bättre att låta sannolikheten ha sin gång? Svaret är ett entydigt nej. Ett genomtänkt test gynnas så gott som alltid av att ha en bestämd ordning på frågor och svarsalternativ.

När man skapar ett test vill man kunna åtskilja de testande på flera nivåer. Har man bara lätta frågor får man en sämre urskiljning på de högre nivåerna. Med bara svåra frågor får man en sämre urskiljning på de lägre nivåerna. Ett välkonstruerat test innehåller frågor på flera olika svårighetsnivåer.

När man skapar ett test med frågor av olika svårighetsgrad, bör man alltid inleda med de lätta frågorna. Dels får man en uppvärmningsfunktion, så att de testande lättare kommer in i en gynnsam sinnesstämning för de svårare frågorna. Dels skapar vi ett inlärningsmoment av testsituationen. Dessutom skapar vi en känsla av trygghet och mildrar nervositet för de testande. Men vi undviker också risken att de testande ”fastnar” på alltför svåra frågor i början och därför får ett missvisande resultat för att missar frågor som de skulle ha klarat och får ett sämre resultat än deras kunskapsnivå.

Ibland vill man varva lätta och svåra frågor. Detta gäller framförallt då man testar olika områden vid ett och samma testtillfälle. Vid dessa fall är fördelen större att testa område för område för att underlätta så mycket som möjligt för de testande i testsituationen. Det innebär att man inom varje enskilt område har en stigande svårighetsgrad på frågorna. När man konstruerar sådana typer av test är det viktigt att man sätter specifika tidsbegränsningar på varje fråga, för att i största möjliga mån undvika att de testande fastnar i för svåra sektioner för att missa lättare.

Det främsta skälet till att behålla samma ordning på svarsalternativen vid flervalsfrågor är för att skapa så lika testförhållanden som möjligt mellan de testande. Ordningen av svarsalternativ har störst betydelse när de innehåller en ”teaser”, det vill säga ett felaktigt svarsalternativ som man lätt kan missta för det riktiga. Ligger det felaktiga svarsalternativ före det rätta, kommer en större andel av de testande att välja det felaktiga än när det ligger efter. Därför får vi lägre reliabilitet om ordningen av dessa svarsalternativ är olika för olika testande.

Dock, väljer man att konstruera sitt test med en vald ordning av svarsalternativen är det viktigt att förstå och anpassa sig till en psykologisk faktor som återfinns hos såväl de testande som dig som testkreatör. Människor är dåliga på att uppfatta och skapa ett randomiserat utfall. Man växlar i större utsträckning än slumpen.

Låt mig ta ett exempel. Låt en person skapa ett slumpmässig utfall av slantsinglingar 100 gånger, alltså utan att faktiskt singla slanten. Låt sedan en annan person singla en slant 100 gånger. Väntevärdet är 50% att slanten kommer att ändra värde från en singling till en annan. Men den person som hittade på sitt slumpmässiga utfall kommer med stor sannolikhet att växla mellan krona och klave i större utsträckning än så. Dessutom, ser man på den längsta sammanhållna serien med samma resultat, så kommer en riktigt randomisering skapa längre längsta serie än den påhittade i en överväldigande majoritet av fallen.

Intuitivt likställer människor slumpmässighet med förändring av utfall i högre grad än vad som är statistiskt försvarbart. Man har svårt att acceptera att slumpmässighet kan innebära att samma utfall upprepas.

Det är viktigt att känna till denna missuppfattning och att utgå ifrån den när man konstruerar svarsalternativ. Genom att medvetet bygga in samma position av svarsalternativ i grupp och låta något eller några svarsalternativ representeras i högre utsträckning skapar man en större sannolikhet att personer som inte vet eller inte är säkra på det rätta svarsalternativet svarar fel i högre utsträckning. Genom att överrepresentera något eller några svarsalternativ, såväl i rad som totalt för testet får man en högre reliabilitet i resultatet.

Det finns dock tillfällen då man tjänar på att införa slumpmässig ordning på frågor och svarsalternativ. Exempelvis när man lider av extrem tidsbrist är risken större att man som testkonstruktör misslyckas att upptäcka sin egen uppfattning av slumpmässighet och växlar för mycket mellan olika svarsalternativ. Det är dock en klar fördel att du slumpar svarsalternativen en gång och låter samtliga testande använda samma ordning.

Slumpmässig ordning är också att föredra när de testande gör samma test flera gånger. Anledningen är att testande lär sig saker av testet, speciellt om du ger omedelbar feedback på rätta svarsalternativ. Men du vill inte att de ska lära sig själva testet, det vill säga på vilken fråga de ska välja vilken svarsposition. Anledningen till att använda samma test flera gånger är att de testande ska lära sig den underliggande kunskapen. Därför är slumpmässig ordning på frågor och svarsalternativ att föredra, även i de fall då man använder sig av skiftande svårighetsgrad på frågorna.

Sammanfattningsvis bör man oftast bestämma ordningen på frågor och svarsalternativ utifrån grundläggande principer för testkonstruktion. Däremot, lider man av tidsbrist eller låter användarna testa sig flera gånger är det en fördel att lotta ordningen på frågor och svarsalternativ

Tidsbegränsning av digitala tester

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.

Testning och inlärning

När det handlar om testning och inlärning finns det huvudsakligen två inriktningar: traditionell och progressiv. Den traditionella synen på testning och inlärning är linjär. Först lär man sig kunskapen som sedan testas. Den progressiva synen på testning och inlärning är strukturell. Testning är inte bara någonting man gör efter att inlärningen har slutat, enkom för att testa kunskaperna. Testning i sig är ett värdefull verktyg för inlärning.

Jag förespråkar testning som inlärning.

Vad är testning? Kortfattat är testning simulering. Vi testar individer innan vi låter dem agera i verkligheten. Själva testet är en simulering av verkligheten för att pröva den testandes kunskaper och färdigheter.

Upprepning är all inlärnings moder. Genom att upprepa kunskap lär vi oss den. Dessvärre räcker det inte att besitta kunskap. Man måste även kunna hämta den från sin kunskapsbank när det behövs. Här kommer testning in.

Testning innebär att vi ställer frågor till den testande för att bedöma ifall hens responser är korrekta eller inte. Frågorna är sticken till de testande. Med frågorna ställer vi upp parametrar för de testande för att se om de kan hämta adekvata kunskaper och färdigheter för att besvara frågan. Därför innebär testning att man tränar den testande på att hämta korrekt kunskap vid rätt tillfälle.

Hur kan vi då praktiskt använda oss av detta i verkligheten?

Speciellt när vi arbetar med digital testning finns det ett intressant användningsområde. Anta att vi har en mängd kunskap inom ett område som vi vill testa hos en specifik grupp. Vi gör det vi kan för att representera denna kunskap med en uppsättning frågor. Kunskapsområdets omfattning är så stort och antalet frågor är så många att det inte är rimligt att ställa samtliga frågor till de testande.

Vi behöver dock inte ställa samtliga frågor till de testande. Har vi bara ett tillräckligt stort slumpmässigt urval av frågorna, eller ett manuellt urval som väl representerar det totala mängden frågor kommer den testandes procentuella resultat med en viss marginal väl representera motsvarande resultat för den totala kunskapsmängden.

Ovanstående resonemang är ingenting konstigt, utan enbart grundläggande statistik. Men det har en viktig implikation för digital testning. När man bygger ett digitalt test är ovanstående metod den vanligast förekommande. Man extraherar en total mängd av frågor för att så väl som möjligt täcka den totala kunskapsmängden som ska testas. Sedan testar man de testande med ett randomiserat eller manuellt urval av dessa frågor.

Utför man en testning har man skapat mjukvara och för området anpassade frågor. I och med detta har man på en och samma gång byggt en perfekt plattform för inlärning av samma kunskap.

Låter man de testande vid upprepade tillfällen göra testet skapar man en inlärningssituation. Inte bara lär sig de testande kunskapen genom upprepningen, utan även att applicera den i samband med frågor och eventuella situationer som frågorna kan måla upp. Genom att låta de testande att testa sig upprepade gånger lär de sig alltså även att hämta kunskapen de har lärt sig i rätt sammanhang. Dessutom finns det ytterligare positiva effekter av att de lär sig testsituationen och programvaran så att den innebär ett minimalt hinder för korrekt prestation vid själva testningen.

Här brukar de traditionella pedagogerna bryta in med att man inte vill att de testande ska lära sig testet, utan den underliggande kunskapen. Mitt svar på det är: Ja, naturligtvis är det så. Därför är det viktigt att formulera testfrågorna så att de adekvat återspeglar den underliggande kunskapen. Därför är det viktigt att vi låter våra skarpaste och mest ambitiösa pedagoger tackla uppgiften att skapa och upprätthålla relevanta testfrågor. Digitala tester är skalbara och kan nå ett i princip oändligt antal testande på ett sätt som en pedagog i ett klassrum aldrig kan göra.

Har man skapat en plattform för testning har man samtidigt skapat en plattform för lärande och givetvis bör man använda denna möjlighet för att de testande snabbare ska kunna lära sig erforderlig kunskap. Därför är det av yttersta vikt att vi har testkonstruktörer som kan skapa frågor som väl motsvarar den efterfrågade kunskapen.