ProHoster > Blogg > Administration > Att vÀlja rÀtt vÀg: 10 kritiska misstag vid utveckling av kunskapstest

Att vÀlja rÀtt vÀg: 10 kritiska misstag vid utveckling av kunskapstest

Att vÀlja rÀtt vÀg: 10 kritiska misstag vid utveckling av kunskapstest
Innan vi registrerar nya studenter pÄ kursen Machine Learning Advanced testar vi dem för att avgöra deras beredskapsnivÄ och förstÄ vad de behöver för att förbereda sig för kursen. Men dilemman uppstÄr: Ä ena sidan mÄste vi kontrollera kunskaper i Data Science, Ä andra sidan kan vi inte genomföra ett fullstÀndigt 4-timmars prov.

För att lösa detta problem har vi inrÀttat ett TestDev-team direkt i vÄr kursutvecklingsgrupp för Data Science (och det verkar som om detta bara Àr början). Vi presenterar en lista över 10 'fÀllor' som man kan falla i vid utvecklingen av tester för att utvÀrdera kunskaper. Vi hoppas att vÀrlden av onlineutbildning blir lite bÀttre efter detta.

FÀlla 1: Att inte tydligt definiera testmÄlen

För att korrekt definiera mÄlen och skapa ett test som tar hÀnsyn till dem, mÄste vi pÄ planeringsstadiet stÀlla oss sjÀlva nÄgra frÄgor:

  1. Vad Àr det vi egentligen testar? 
  2. I vilken miljö kommer testningen att Àga rum och vilka mekanismer anvÀnds? Vilka begrÀnsningar finns i denna miljö? Denna punkt hjÀlper oss ocksÄ att förstÄ de tekniska kraven för den enhet dÀr testningen kommer att genomföras, och Àven för innehÄllet (om testet görs via telefoner, mÄste bilderna kunna lÀsas Àven pÄ smÄ skÀrmar, det mÄste finnas möjlighet att förstora dem, etc.).
  3. Hur lÄng tid kommer testningen att ta? Vi mÄste tÀnka pÄ under vilka förhÄllanden anvÀndaren kommer att genomföra testet. Kan det uppstÄ en situation dÀr de behöver avbryta testningsprocessen och sedan fortsÀtta igen?
  4. Kommer det att finnas nÄgon Äterkoppling? Hur formar vi och levererar den? Vad behövs för att fÄ den? Finns det en tidsfördröjning mellan genomförandet av testet och Äterkopplingen?

I vÄrt fall, efter att ha svarat pÄ dessa frÄgor, definierade vi följande mÄl för testet:

  1. Testet ska visa om framtida studenter Àr redo att genomföra kursen och om de har tillrÀckliga kunskaper och fÀrdigheter.
  2. Testet ska ge oss material för feedback, ange vilket Àmne dÀr studenterna gjorde misstag, sÄ att de kan förbÀttra sina kunskaper. Hur man skapar det, kommer vi att berÀtta vidare.

FÀlla 2: Att inte skapa en kravspecifikation för experten - testutvecklaren

För att skapa testuppgifter Àr det mycket viktigt att involvera en expert inom det omrÄde vars kunskaper prövas. För experten krÀvs ocksÄ en vÀlformulerad kravspecifikation som inkluderar testets Àmnen, de kunskaper/fÀrdigheter som ska bedömas och deras nivÄ.

En expert kommer inte sjĂ€lv att skapa en sĂ„dan kravspecifikation, eftersom hans arbete handlar om att skapa uppgifter och inte om testets struktur. Än sĂ„ lĂ€nge utvecklar inte mĂ„nga professionellt tester, Ă€ven inom undervisningen. Detta lĂ€rs ut pĂ„ en sĂ€rskild utbildning — psykometri.

Om du vill fÄ en snabb introduktion till psykometri, sÄ finns det i Ryssland en sommarakademi för alla intresserade. För att fördjupa sig ytterligare finns det en masterutbildning och forskarutbildning.

NÀr vi förbereder kravspecifikationen samlar vi en detaljerad beskrivning av testet för experten (eller Ànnu bÀttre, tillsammans med honom): Àmnen för uppgifterna, typ av uppgifter, antal.

Hur man vÀljer typ av uppgifter: nÀr man bestÀmt sig för Àmnen, funderar man pÄ vilka uppgifter som bÀst kan pröva dessa. Klassiska alternativ inkluderar: uppgift med öppet svar, uppgift med flervalsalternativ, överensstÀmmelse, m.m. (glöm inte de tekniska begrÀnsningarna för miljön dÀr testningen genomförs!). Efter att ha bestÀmt och formulerat typ av uppgifter har vi en fÀrdig kravspecifikation för experten. Man kan kalla det testets specifikation.

FĂ€lla 3: Att inte involvera experten i utvecklingen av testet

NÀr man involverar experten i utvecklingen av testet Àr det mycket viktigt att inte bara ange "arbetsomfÄnget" för honom, utan att inkludera honom i sjÀlva utvecklingsprocessen.

Hur man fÄr arbetet med experten att bli sÄ effektivt som möjligt:

  • Förbereda honom i förvĂ€g och spendera en viss tid pĂ„ att berĂ€tta om vetenskapen bakom testutveckling och psykometri.
  • Fokusera expertens uppmĂ€rksamhet pĂ„ att skapa ett giltigt och pĂ„litligt bedömningsverktyg, och inte en lista med frĂ„gor.
  • Förklara att hans arbete inkluderar ett förberedande steg, inte bara utvecklingen av sjĂ€lva uppgifterna.

Vissa experter (pÄ grund av sin karaktÀr) kan uppfatta detta som en granskning av sitt eget arbete, och till dem förklarar vi att Àven om de skapar utmÀrkta uppgifter, kanske de helt enkelt inte passar för de specifika testmÄlen.

För att processen ska gÄ snabbt förbereder vi med en expert en tÀckningstabell av Àmnen (kunskaper och fÀrdigheter), som Àr en del av testets specifikation. Denna tabell gör det möjligt att noggrant arbeta igenom frÄgorna och identifiera vad vi ska mÀta. I varje enskilt fall kan den utformas nÄgot annorlunda. VÄrt mÄl Àr att kontrollera hur vÀl en person behÀrskar kunskaperna och fÀrdigheterna frÄn tidigare grundkurser för att förstÄ hur beredd han eller hon Àr för utbildningen i den nya kursen.

FÀlla 4: Att tro att experten "vet bÀttre"

KÀnner Àmnet bÀttre. Men förklarar inte alltid tydligt. Det Àr mycket viktigt att kontrollera formuleringarna av uppgifterna. Att skriva tydliga instruktioner, till exempel "VÀlj 1 korrekt alternativ". I 90% av fallen förbereder experterna frÄgor sÄ som de sjÀlva förstÄr dem. Och det Àr helt okej. Men innan testet överlÀmnas till dem som ska göra det, mÄste allt kontrolleras och justeras sÄ att de personer som genomför testet exakt förstÄr vad som krÀvs av dem, utan att göra misstag pÄ grund av missförstÄnd av uppgiftstexten.

För att undvika dubbeltydigheter i uppgifterna genomför vi "kognitiva labb". Vi ber personer frÄn mÄlgruppen att genomföra testet medan de sÀger högt vad de tÀnker, och vi dokumenterar detta noggrant. PÄ "kognitiva labb" kan man "fÄnga" otydliga frÄgor, dÄliga formuleringar och fÄ tidig Äterkoppling pÄ testet.

FÀlla 5: Att inte ta hÀnsyn till tiden som behövs för att genomföra testet

sarcasm mode: on
SjÀlvklart Àr vÄrt test det bÀsta, alla drömmer om att genomföra det! Ja, hela 4 timmar.
sarcasm mode: off

NÀr det finns en lista över allt som kan kontrolleras, Àr det viktigaste att faktiskt inte göra det (det lÄter konstigt vid första anblicken, eller hur?). Det Àr viktigt att skarpt prioritera, tillsammans med experten, nyckelkunskaper och fÀrdigheter (ja, ett antal fÀrdigheter kan ocksÄ kontrolleras i testet). Vi ser pÄ typ av uppgifter och uppskattar den avsedda tiden för genomförande: om det fortfarande ligger över rimliga grÀnser - skÀr ner!

För att minska volymen kan man ocksÄ försöka (försiktigt) att kontrollera tvÄ fÀrdigheter med en uppgift. I sÄ fall Àr det svÄrt att förstÄ varför en person gjorde ett misstag, men om det görs korrekt kan bÄda fÀrdigheterna beaktas. Det Àr viktigt att sÀkerstÀlla att dessa tvÄ fÀrdigheter hör till samma kunskapsomrÄde.

FÀlla 6: Att inte tÀnka ut ett poÀngsystem

NÀr man skapar bedömningstester anvÀnds ofta ett klassiskt poÀngsystem, till exempel 1 poÀng för lÀtta uppgifter och 2 poÀng för svÄra. Men detta Àr inte universellt. Enbart summan av poÀngen i slutet av testet ger oss inte mycket information: vi vet inte vilka uppgifter poÀngen kommer ifrÄn och kan bara avgöra antalet korrekta uppgifter. Vi behöver en klar förstÄelse av vilka specifika fÀrdigheter testdeltagarna visar. Dessutom vill vi ge dem feedback om vilka Àmnen de behöver förbÀttra.

Vi gör ett test som ska separera de som Àr redo och de som inte Àr redo för programmet; vissa av dem kommer vi att rekommendera att förbereda sig med gratis utbildning. Det Àr viktigt för oss att endast de som verkligen behöver detta och Àr förberedda hamnar i denna grupp.

Vad vi gör i vÄr situation: vi bestÀmmer inom arbetsgruppen för testutvecklarna vilka grupper av mÀnniskor vi behöver sÀrskilja (till exempel de redo för lÀrande, delvis redo) och formar en tabell med karakteristika för dessa grupper, dÀr vi anger vilka fÀrdigheter och kunskaper som Àr relevanta för gruppen som Àr redo för lÀrande. SÄ kan vi formulera "svÄrighetsgraden" för uppgifterna i liknande tester.

FÀlla 7: Att utvÀrdera resultaten enbart automatiskt

SjĂ€lvklart mĂ„ste bedömningen vara sĂ„ objektiv som möjligt, dĂ€rför utvĂ€rderas en del av studenternas material automatiskt, "efter nycklar" — genom att jĂ€mföra med de rĂ€tta svaren. Även om det inte finns nĂ„got speciellt testsystem, finns det massor av gratislösningar. Och om man har förstĂ„else för principerna för att skriva skript, kan man göra vad som helst med Google-formulĂ€r och resultaten i tabeller. Om en del av uppgifterna bedöms av experter, mĂ„ste vi tĂ€nka pĂ„ hur vi ska skicka svaren till experterna, utan information om den som lĂ€mnar in. Och tĂ€nka pĂ„ hur resultaten av expertbedömningen ska integreras i den slutgiltiga bedömningen.

Vi ville ursprungligen göra flera öppna uppgifter med kod, dÀr experterna bedömer lösningar utifrÄn fördefinierade kriterier, och vi förberedde till och med ett system som exporterar enskilda deltagaransvar till en speciell tabell för experterna och sedan importerar resultaten till en tabell med bedömningsberÀkning. Men efter diskussion med representanter frÄn mÄlgruppen, produktchefen och pedagogisk designer, ansÄg vi att genomföra tekniska intervjuer med omedelbar feedback frÄn experten och diskussion av koden, samt specifika frÄgor skulle vara mycket mer effektivt och anvÀndbart för deltagarna sjÀlva.

Nu verifierar experten att testet har genomförts och klargör vissa frÄgor. För detta har vi förberett en guide för frÄgor och bedömningskriterier för den tekniska intervjun. Innan den tekniska intervjun fÄr experten en karta över deltagarens svar, för att vÀlja de frÄgor som Àr vÀrt att stÀlla.

Fallgrop 8: Att inte förklara testresultaten

Att ge feedback till deltagarna Àr en separat frÄga. Vi mÄste inte bara informera om testpoÀngen, utan ocksÄ ge en förstÄelse för testresultaten.
Det kan vara: 

  • Uppgifter som deltagaren gjorde fel i, men som den ocksĂ„ klarade.
  • Ämnen dĂ€r deltagaren gjorde misstag.
  • Hans bedömning bland de som klarade testet.
  • Beskrivning av deltagarens nivĂ„, i enlighet med till exempel beskrivningen av specialistnivĂ„er (baserat pĂ„ arbetsbeskrivningar).

Vid den pilotstarten av vÄrt test, visade vi dem som ville ansöka till programmet, tillsammans med resultaten, en lista över Àmnen som behöver förbÀttras. Men det Àr sjÀlvklart inte idealiskt, vi kommer att förbÀttra oss och göra tillbaka informationen bÀttre.

Fallgrop 9: Att inte diskutera testet med utvecklarna

Kanske de mest akuta fallgroparna, som det Àr sÀrskilt obehagligt att falla i - att skicka testet, beskrivningen och poÀngberÀkningen till utvecklarna som det Àr.
Vad som behöver diskuteras:

  • Utseendet pĂ„ frĂ„gorna, strukturen, placeringen av grafik, hur det ser ut nĂ€r det gĂ€ller att vĂ€lja rĂ€tt svar.
  • Hur poĂ€ngen berĂ€knas (om det behövs), om det finns nĂ„gra ytterligare villkor.
  • Hur feedbacken utformas, var texterna kommer ifrĂ„n, om det finns nĂ„gra automatiskt genererade block.
  • Vilken ytterligare information behöver du samla in och nĂ€r (samma kontakter)?

För att undvika missförstÄnd ber vi vÄra utvecklare att koda 2 eller 3 olika frÄgor sÄ att vi kan se hur de ser ut innan programmeringen av sjÀlva testet.

Fallgrop 10: Att ladda upp direkt till produktion utan att testa.

Tre gĂ„nger, killar, tester mĂ„ste kontrolleras tre gĂ„nger av olika personer, eller Ă€nnu bĂ€ttre — varje person tre gĂ„nger. Denna sanning har förvĂ€rvats med blod, svett och pixlar av kodrader.

Vi har ett test som kontrollerar detta trio:

  1. ProduktĂ€garen — kontrollerar testet för funktionalitet, utseende och mekanik.
  2. Testutvecklaren — kontrollerar texten i uppgifterna, deras ordning, arbetsform med testet, uppgiftstyper, korrekta svar, lĂ€sbarhet och normal visning av grafik.
  3. Uppgiftsförfattaren (experten) — kontrollerar testet för korrekthet ur expertperspektiv.

Exempel frÄn praktiken: först vid tredje körningen sÄg uppgiftsförfattaren att en uppgift hade blivit kvar i den gamla formuleringen. Alla tidigare korrigeringar hade ocksÄ gjorts aktivt. Men nÀr testet kodades sÄg det annorlunda ut Àn vad man ursprungligen hade förestÀllt sig. Det Àr med hög sannolikhet att nÄgot mÄste korrigeras. Detta mÄste beaktas.

Resultat

Genom att försiktigt undvika alla dessa "fallgropar" skapade vi en speciell bot i Telegram, för att kontrollera kunskaperna hos studenter. Alla intresserade kan testa den medan vi förbereder nÀsta material, dÀr vi kommer att berÀtta vad som hÀnde inuti boten och hur detta sedan transformerades.

Att vÀlja rÀtt vÀg: 10 kritiska misstag vid utveckling av kunskapstest
Att skaffa en eftertraktad yrkesroll frÄn grunden eller nivÄ upp sina fÀrdigheter och lön kan göras genom att gÄ online-kurser pÄ SkillFactory:

Fler kurser

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster