Innan vi anmäler oss till den nya Machine Learning Advanced-kursen testar vi blivande studenter för att fastställa deras beredskapsnivå och förstå exakt vad de behöver erbjuda för att förbereda sig för kursen. Men ett dilemma uppstår: å ena sidan måste vi testa kunskaper i Data Science, å andra sidan kan vi inte ordna en fullfjädrad 4-timmars tentamen.
För att lösa det här problemet har vi distribuerat ett TestDev-huvudkontor i Data Science-kursutvecklingsteamet (och det ser ut som att detta bara är början). Vi presenterar för dig en lista med 10 fallgropar som man stöter på när man utvecklar tester för att bedöma kunskap. Förhoppningsvis kommer världen av onlinelärande att bli lite bättre efter detta.
Rake 1: Misslyckas med att tydligt definiera testmål
För att korrekt definiera mål och skapa ett test som tar hänsyn till dem måste vi i planeringsstadiet svara på flera frågor:
- Vad kollar vi egentligen?
- Vilken miljö kommer testningen att ske i och vilken mekanik används? Vilka är begränsningarna i den här miljön? Samma punkt gör att du kan förstå de tekniska kraven för enheten på vilken testet kommer att utföras, och även för innehållet (om testet är taget från telefoner, bör bilderna vara läsbara även på en liten skärm, det bör vara möjligt att förstora dem etc.).
- Hur lång tid tar testet? Du måste tänka på under vilka förutsättningar användaren kommer att göra testet. Kan det finnas en situation där han behöver avbryta testprocessen och sedan fortsätta igen?
- Kommer det återkoppling? Hur formar och levererar vi det? Vad behöver du få? Finns det en tidsförskjutning mellan testkörning och feedback?
I vårt fall, efter att ha besvarat dessa frågor, definierade vi följande lista med mål för testet:
- Testet ska visa om framtida studenter är redo att gå kursen och om de har tillräckliga kunskaper och färdigheter.
- Testet ska ge oss material för feedback, ange ämnet där eleverna gjorde ett misstag, så att de kan förbättra sina kunskaper. Vi berättar hur du komponerar den nedan.
Rake 2: Misslyckande med att upprätta tekniska specifikationer för den sakkunnige testskribenten
För att komponera testobjekt är det mycket viktigt att involvera en expert inom det område där kunskapen prövas. Och för en expert behöver du i sin tur en kompetent teknisk specifikation (beskrivning), som inkluderar testets ämnen, kunskaperna/färdigheterna som testas och deras nivå.
En expert kommer inte att göra sådana tekniska specifikationer för sig själv, eftersom hans jobb är att komma på uppgifter, inte strukturen för testet. Dessutom är det få som utvecklar tester professionellt, även under undervisningsprocessen. Detta lärs ut i en separat specialitet - psykometri.
Om du snabbt vill bekanta dig med psykometri, så finns det i Ryssland för alla intresserade. För mer fördjupad studie har Utbildningsinstitutet och forskarskola.
När vi förbereder de tekniska specifikationerna samlar vi in en detaljerad beskrivning av testet för experten (eller bättre, tillsammans med honom): ämnen för uppgifter, typ av uppgifter, deras antal.
Hur man väljer typ av uppgifter: efter att ha bestämt oss för ämnena bestämmer vi vilka uppgifter som bäst kan testa detta? Klassiska alternativ: öppen uppgift, flervals- eller envalsuppgift, matchning, etc. (glöm inte testmiljöns tekniska begränsningar!). Efter att ha fastställt och specificerat typen av uppgifter har vi en färdig teknisk specifikation för experten. Du kan kalla det en testspecifikation.
Rake 3: Inte involvera en expert i testutveckling
När du fördjupar en expert i testutveckling är det mycket viktigt att inte bara indikera för honom "arbetets omfattning", utan att involvera honom i själva utvecklingsförfarandet.
Hur man gör arbetet med en expert så effektivt som möjligt:
- Ställ in det i förväg och ägna lite tid åt att prata om vetenskapen om testutveckling och psykometri.
- Fokusera utvärderarens uppmärksamhet på att skapa ett giltigt och tillförlitligt bedömningsverktyg, inte en lista med frågor.
- Förklara att hans arbete inkluderar ett förberedande stadium, inte bara utvecklingen av själva uppgifterna.
Vissa experter (på grund av sin natur) kan uppfatta detta som ett test av sitt eget arbete, och vi förklarar för dem att även om vi skapar utmärkta uppgifter, kanske de helt enkelt inte passar de specifika testmålen.
För att processen ska gå snabbt utarbetar vi en tabell över ämnestäckning (kunskaper och färdigheter) med experten, vilket är en del av testspecifikationen. Det är denna tabell som gör att vi kan räkna ut frågorna och bestämma vad vi ska mäta. I varje enskilt fall kan det sammanställas något annorlunda. Vår uppgift är att kontrollera hur väl en person förstår kunskaperna och färdigheterna i tidigare, grundkurser för att förstå hur redo hen är att läsa i en ny kurs.
Rake 4: Tror att experten "vet bäst"
Kan ämnet bättre. Men det förklarar inte alltid tydligt. Det är mycket viktigt att kontrollera ordalydelsen i uppdragen. Skriv tydliga instruktioner, till exempel "Välj 1 rätt alternativ." I 90 % av fallen förbereder experter frågor på ett sätt som de själva förstår. Och det är okej. Men innan man lämnar över provet till de som ska göra det måste allt kontrolleras och kammas så att de som tar provet förstår exakt vad som krävs av dem och inte gör fel bara för att de kan misstolka uppgiftens text.
För att undvika dubbeltolkning av uppgifter genomför vi "kognitiva laboratorier." Vi ber personer från målgruppen att göra testet, säga högt vad de tycker och spela in det i detalj. På "kognitiva laboratorier" kan du "fånga" oklara frågor, dåliga formuleringar och få den första feedbacken på testet.
Rake 5: Ignorera testkörningstiden
sarkasmläge: på
Naturligtvis är vårt test det bästa, alla drömmer om att klara det! Ja, alla 4 timmarna.
sarkasmläge: av
När det finns en lista över allt som kan kontrolleras är det viktigaste att inte göra det (vid första anblicken låter det konstigt, eller hur?). Du måste hänsynslöst skära, identifiera nyckelkunskaper och färdigheter med en expert (ja, ett antal färdigheter kan också testas i testet). Vi tittar på typen av uppgifter och uppskattar måltiden för slutförande: om allt fortfarande är mer än rimliga gränser, skär vi ner det!
För att minska volymen kan du också prova att (noggrannt) testa två färdigheter i en uppgift. I det här fallet är det svårt att förstå varför personen gjorde ett misstag, men om det görs på rätt sätt kan båda färdigheterna beaktas. Det är viktigt att se till att dessa 2 färdigheter motsvarar samma kunskapsområde.
Rake 6: Tänker inte igenom poängsystemet
När de sammanställer bedömningsprov använder de ofta det klassiska poängsystemet, till exempel 1 poäng för enkla uppgifter och 2 poäng för svåra. Men det är inte universellt. Bara summan av poäng baserat på testresultaten kommer inte att säga oss mycket: vi vet inte för vilka uppgifter dessa poäng erhölls och vi kan bara fastställa antalet korrekta uppgifter. Vi måste förstå exakt vilka färdigheter testtagare visar. Dessutom vill vi ge dem feedback på vilka ämnen som behöver förbättras.
Vi gör trots allt ett test som kommer att dela in personer i de som är redo och de som inte är redo att slutföra programmet, vi kommer att råda några att förbereda sig för kursen genom gratis utbildning. Det är viktigt för oss att denna grupp bara omfattar de som verkligen behöver det och som är redo för det.
Vad vi gör i vår situation: vi bestämmer inom arbetsgruppen av testutvecklare vilka grupper av människor som behöver identifieras (till exempel redo att lära, delvis redo) och bildar en tabell över egenskaper hos sådana grupper, som anger vilka färdigheter och kunskaper kommer att vara relevant för gruppen av redo att lära utbildning. På så sätt kan du formulera "svårigheten" för uppgifter för sådana test.
Rake 7: Utvärdera endast resultat automatiskt
Självklart ska bedömningen vara så objektiv som möjligt, så en del av elevmaterialet bedöms automatiskt, "med nycklar" - jämfört med de rätta svaren. Även om det inte finns något speciellt testsystem så finns det gott om gratislösningar. Och om du förstår principerna för att skriva manus kan du göra vad du vill med Googles formulär och resultat i tabeller. Om några av uppgifterna kontrolleras av experter måste vi tänka på att leverera svar till experterna, utan information om testpersonerna. Och fundera på hur du integrerar resultaten från experttester i den slutliga bedömningen.
Vi ville från början göra flera öppna uppgifter med kod, där experter utvärderar lösningar utifrån förutformade kriterier, och vi har till och med förberett ett system som exporterar individuella svar från testdeltagare till en speciell tabell för experter, och sedan importerar resultaten till en tabell med bedömningsberäkningar. Men efter att ha diskuterat med representanter för målgruppen, produktchef och pedagogisk designer, kände vi att det skulle vara mycket mer effektivt och användbart för deltagarna själva att genomföra en teknisk intervju med omedelbar expertfeedback och diskussion om koden, såväl som enskilda frågor. .
Nu verifierar experten slutförandet av testet och klargör några frågor. För att göra detta har vi utarbetat en guide med frågor och bedömningskriterier för en teknisk intervju. Innan den tekniska intervjun får examinatorn en karta över testtagarens svar för att hjälpa honom välja frågor att ställa.
Rake 8: Förklara inte testresultat
Att ge feedback till deltagarna är en separat fråga. Vi behöver inte bara informera om testresultatet, utan också ge en förståelse för testresultaten.
Det kan vara:
- Uppgifter där deltagaren gjort ett misstag och som han genomfört korrekt.
- Ämnen där deltagaren gjort misstag.
- Hans ranking bland de som tar provet.
- Beskrivning av deltagarens nivå, i enlighet med till exempel beskrivningen av specialistnivån (baserat på beskrivningen av lediga tjänster).
Under pilotlanseringen av vårt test visade vi, för de som ville anmäla sig till programmet, tillsammans med resultaten en lista över ämnen som behövde förbättras. Men det här är verkligen inte idealiskt, vi kommer att förbättra och ge bättre feedback.
Rake 9: Diskutera inte testet med utvecklare
Den kanske vassaste raken, som är särskilt obehaglig att trampa på, är att skicka test-, beskrivnings- och poängskalan till utvecklarna "i befintligt skick".
Vad exakt behöver diskuteras:
- Frågornas utseende, strukturen, grafikens placering, hur valet av rätt svar ser ut.
- Hur beräknas poängen (om det behövs), finns det några ytterligare villkor.
- Hur genereras feedback, var man kan hämta texter, finns det ytterligare automatiskt genererade block.
- Vilken ytterligare information behöver du samla in och vid vilken tidpunkt (samma kontakter).
För att undvika missförstånd ber vi våra utvecklare att koda 2 eller 3 olika frågor så att de kan se hur de ser ut innan de kodar själva testet.
Rake 10: Utan att testa, ladda upp direkt till produktionen
3 gånger, killar, testet bör kontrolleras 3 gånger av olika personer, eller ännu bättre, 3 gånger vardera. Denna sanning erhölls med blod, svett och pixlar av kodrader.
Vårt test kontrollerar följande trio:
- Produkt - kontrollerar testet för prestanda, utseende, mekanik.
- Testutvecklare - kontrollerar uppgifternas text, deras ordning, arbetsform med testet, typer av uppgifter, korrekta svar, läsbarhet och normal visning av grafik.
- Uppgifternas författare (expert) kontrollerar trohetsprovet från en expertposition.
Ett exempel från praktiken: först vid den tredje körningen såg författaren av uppgifterna att 1 uppgift fanns kvar i den gamla versionen av formuleringen. Alla de tidigare styrde också aktivt. Men när testet kodades såg det annorlunda ut än man först tänkt sig. Det är mycket troligt att något måste rättas till. Detta måste beaktas.
Totalt
Genom att försiktigt kringgå alla dessa "rake" skapade vi en special , för att testa de sökandes kunskaper. Vem som helst kan testa det medan vi förbereder nästa material, där vi kommer att berätta vad som hände inuti boten och vad det förvandlades till senare.
Du kan få ett eftertraktat yrke från grunden eller Level Up när det gäller kompetens och lön genom att ta SkillFactory onlinekurser:
- (12 veckor)
- (20 veckor)
- (20 veckor)
- (12 månader)
Fler kurser
- (12 månader)
- (14 veckor)
- (5 veckor)
- (18 månader)
- (6 månader)
- (12 månader)
- (8 månader)
- (9 månader)
- (12 månader)
- (18 månader)
- (18 månader)
- (12 månader)
- (9 månader)
- (7 månader)
Källa: will.com