Før vi tilmelder os det nye Machine Learning Advanced-kursus, tester vi potentielle studerende for at bestemme deres parathedsniveau og forstå, hvad de præcist skal tilbyde for at forberede sig til kurset. Men et dilemma opstår: På den ene side skal vi teste viden i Data Science, på den anden side kan vi ikke arrangere en fuldgyldig 4-timers eksamen.
For at løse dette problem har vi implementeret et TestDev-hovedkvarter lige i Data Science kursusudviklingsteamet (og det ser ud til, at dette kun er begyndelsen). Vi præsenterer dig for en liste over 10 faldgruber, du støder på, når du udvikler tests til at vurdere viden. Forhåbentlig vil verden af online læring blive lidt bedre efter dette.
Rake 1: Manglende klart definere testmål
For at definere mål korrekt og oprette en test, der tager hensyn til dem, skal vi på planlægningsstadiet besvare flere spørgsmål:
- Hvad tjekker vi egentlig?
- Hvilket miljø vil testen finde sted i, og hvilken mekanik bruges? Hvad er begrænsningerne i dette miljø? Dette samme punkt vil give dig mulighed for at forstå de tekniske krav til den enhed, som testen skal udføres på, og også for indholdet (hvis testen er taget fra telefoner, skal billederne være læsbare selv på en lille skærm, det skal være muligt at forstørre dem osv.).
- Hvor lang tid tager testen? Du skal tænke over de betingelser, som brugeren vil tage testen under. Kan der være en situation, hvor han er nødt til at afbryde testprocessen og derefter fortsætte igen?
- Kommer der feedback? Hvordan former og leverer vi det? Hvad skal du modtage? Er der en tidsforskydning mellem testudførelse og feedback?
I vores tilfælde, efter at have besvaret disse spørgsmål, definerede vi følgende liste over mål for testen:
- Testen skal vise, om fremtidige studerende er klar til at tage kurset, og om de har tilstrækkelig viden og færdigheder.
- Testen skal give os materiale til feedback, angive det emne, hvor eleverne lavede en fejl, så de kan forbedre deres viden. Vi fortæller dig, hvordan du komponerer det nedenfor.
Rake 2: Manglende udarbejdelse af tekniske specifikationer for den ekspert testskribent
For at sammensætte testemner er det meget vigtigt at inddrage en ekspert inden for det område, hvor viden testes. Og for en ekspert har du til gengæld brug for en kompetent teknisk specifikation (beskrivelse), som omfatter testens emner, den viden/de færdigheder, der testes, og deres niveau.
En ekspert vil ikke lave sådanne tekniske specifikationer for sig selv, fordi hans job er at komme med opgaver, ikke strukturen af testen. Desuden er det de færreste, der udvikler tests professionelt, selv under undervisningen. Dette undervises i et særskilt speciale - psykometri.
Hvis du hurtigt vil stifte bekendtskab med psykometri, så er der i Rusland for alle interesserede. For mere dybdegående undersøgelse har Uddannelsesinstituttet og efterskole.
Når vi udarbejder de tekniske specifikationer, indsamler vi en detaljeret beskrivelse af testen til eksperten (eller bedre sammen med ham): emner for opgaver, type opgaver, deres antal.
Hvordan vælger man opgavetypen: Efter at have besluttet emnerne, beslutter vi, hvilke opgaver der bedst kan teste dette? Klassiske muligheder: åben opgave, flervalgsopgave eller enkeltvalgsopgave, matchning osv. (glem ikke testmiljøets tekniske begrænsninger!). Efter fastlæggelse og specificering af opgavetypen har vi en færdig teknisk specifikation til eksperten. Du kan kalde det en testspecifikation.
Rake 3: Ikke involvering af en ekspert i testudvikling
Når du fordyber en ekspert i testudvikling, er det meget vigtigt ikke blot at angive for ham "arbejdets omfang", men at involvere ham i selve udviklingsproceduren.
Sådan gør du arbejdet med en ekspert så effektivt som muligt:
- Sæt det op på forhånd, og brug lidt tid på at tale om videnskaben om testudvikling og psykometri.
- Fokuser evaluatorens opmærksomhed på at skabe et gyldigt og pålideligt vurderingsværktøj, ikke en liste med spørgsmål.
- Forklar, at hans arbejde omfatter en forberedende fase, ikke kun udviklingen af selve opgaverne.
Nogle eksperter kan (på grund af deres natur) opfatte dette som en test af deres eget arbejde, og vi forklarer dem, at selvom vi laver fremragende opgaver, kan de simpelthen ikke passe til de specifikke testmål.
For at få processen til at gå hurtigt, udarbejder vi en tabel over emnedækning (viden og færdigheder) med eksperten, som er en del af testspecifikationen. Det er denne tabel, der giver os mulighed for præcist at udarbejde spørgsmålene og bestemme, hvad vi vil måle. I hvert enkelt tilfælde kan det sammensættes lidt forskelligt. Vores opgave er at kontrollere, hvor godt en person forstår viden og færdigheder fra tidligere grundkurser for at forstå, hvor klar han er til at studere i et nyt kursus.
Rake 4: Tænker, at eksperten "ved bedst"
Kender emnet bedre. Men det forklarer ikke altid klart. Det er meget vigtigt at tjekke opgavernes ordlyd. Skriv klare instruktioner, for eksempel "Vælg 1 korrekt mulighed." I 90 % af tilfældene forbereder eksperter spørgsmål på en måde, som de selv forstår. Og det er okay. Men før man overdrager testen til dem, der skal tage den, skal alt tjekkes og kæmmes, så de personer, der tager testen, forstår præcis, hvad der kræves af dem og ikke laver fejl, bare fordi de måske misfortolker opgavens tekst.
For at undgå dobbelttolkning af opgaver udfører vi "kognitive laboratorier." Vi beder folk fra målgruppen om at tage testen, sige højt, hvad de synes, og optage det i detaljer. På "kognitive laboratorier" kan du "fange" uklare spørgsmål, dårlige formuleringer og få den første feedback på testen.
Rake 5: Ignorer testudførelsestiden
sarkasmetilstand: tændt
Selvfølgelig er vores test den bedste, alle drømmer om at bestå den! Ja, alle 4 timer.
sarkasmetilstand: slukket
Når der er en liste over alt, der kan kontrolleres, er det vigtigste ikke at gøre det (ved første øjekast lyder det mærkeligt, gør det ikke?). Du skal skåneløst skære, identificere nøgleviden og færdigheder med en ekspert (ja, en række færdigheder kan også testes i testen). Vi ser på typen af opgaver og estimerer den ønskede færdiggørelsestid: Hvis alt stadig er mere end rimelige grænser, skærer vi det!
For at reducere lydstyrken kan du også prøve (omhyggeligt) at teste to færdigheder i én opgave. I dette tilfælde er det svært at forstå, hvorfor personen lavede en fejl, men hvis det gøres korrekt, kan begge færdigheder tages i betragtning. Det er vigtigt at sikre sig, at disse 2 færdigheder svarer til det samme vidensområde.
Rake 6: Tænker ikke pointsystemet igennem
Ofte bruger de, når de udarbejder vurderingstests, det klassiske pointsystem, for eksempel 1 point for lette opgaver og 2 point for svære. Men det er ikke universelt. Bare summen af point baseret på testresultaterne vil ikke fortælle os meget: vi ved ikke, for hvilke opgaver disse point blev modtaget, og vi kan kun bestemme antallet af korrekte opgaver. Vi er nødt til at forstå præcis, hvilke færdigheder testpersoner demonstrerer. Derudover vil vi give dem feedback på, hvilke emner der skal forbedres.
Når alt kommer til alt, laver vi en test, der vil dele folk op i dem, der er klar og dem, der ikke er klar til at gennemføre programmet; vi vil råde nogle til at forberede sig til kurset gennem gratis træning. Det er vigtigt for os, at denne gruppe kun omfatter dem, der virkelig har brug for det, og som er klar til det.
Hvad vi gør i vores situation: vi bestemmer inden for arbejdsgruppen af testudviklere, hvilke grupper af mennesker der skal identificeres (for eksempel klar til at lære, delvis klar) og danner en tabel over karakteristika for sådanne grupper, der angiver hvilke færdigheder og viden vil være relevant for gruppen af lærevillige uddannelser. På denne måde kan du formulere "sværhedsgraden" af opgaver til sådanne tests.
Rake 7: Evaluer kun resultater automatisk
Naturligvis skal bedømmelsen være så objektiv som muligt, så nogle af elevmaterialerne vurderes automatisk "ved nøgler" - sammenlignet med de rigtige svar. Selvom der ikke er noget særligt testsystem, er der masser af gratis løsninger. Og hvis du forstår principperne for at skrive scripts, så kan du gøre, hvad du vil med Google-formularer og resultater i tabeller. Hvis nogle af opgaverne bliver tjekket af eksperter, så skal vi tænke på at levere svar til eksperterne, uden information om testdeltagerne. Og tænk på, hvordan du integrerer resultaterne af eksperttests i den endelige vurdering.
Vi ønskede i første omgang at lave flere åbne opgaver med kode, hvor eksperter vurderer løsninger efter foruddefinerede kriterier, og vi har endda udarbejdet et system, der eksporterer individuelle svar fra testdeltagere til en speciel tabel for eksperter, og derefter importerer resultaterne ind i en tabel med vurderingsberegninger. Men efter at have diskuteret med repræsentanter for målgruppen, produktchef og pædagogisk designer, følte vi, at det ville være meget mere effektivt og nyttigt for deltagerne selv at gennemføre et teknisk interview med øjeblikkelig ekspertfeedback og diskussion af koden, såvel som individuelle spørgsmål. .
Nu verificerer eksperten færdiggørelsen af testen og afklarer nogle spørgsmål. For at gøre dette har vi udarbejdet en guide med spørgsmål og vurderingskriterier til en teknisk samtale. Inden den tekniske samtale modtager eksaminator et kort over testpersonens svar for at hjælpe ham med at udvælge spørgsmål, der skal stilles.
Rake 8: Forklar ikke testresultater
At give feedback til deltagerne er et særskilt spørgsmål. Vi skal ikke kun informere om testresultatet, men også give en forståelse af testresultaterne.
Det kan være:
- Opgaver, hvor deltageren lavede en fejl, og som han udførte korrekt.
- Emner, hvor deltageren begik fejl.
- Hans placering blandt dem, der tager eksamen.
- Beskrivelse af deltagerens niveau, i overensstemmelse med for eksempel beskrivelsen af specialistniveauet (baseret på beskrivelsen af ledige stillinger).
Under pilotlanceringen af vores test viste vi til dem, der ønskede at tilmelde sig programmet, sammen med resultaterne en liste over emner, der skulle forbedres. Men dette er bestemt ikke ideelt, vi vil forbedre og give bedre feedback.
Rake 9: Diskuter ikke testen med udviklere
Den måske skarpeste rake, som er særligt ubehagelig at træde på, er at sende test-, beskrivelses- og scoringsskalaen til udviklerne "som den er".
Hvad der præcist skal diskuteres:
- Spørgsmålenes udseende, strukturen, grafikkens placering, hvordan valget af det rigtige svar ser ud.
- Hvordan beregnes scoren (hvis nødvendigt), er der yderligere betingelser.
- Hvordan genereres feedback, hvor kan man hente tekster, er der yderligere automatisk genererede blokke.
- Hvilke yderligere oplysninger skal du indsamle og på hvilket tidspunkt (samme kontakter).
For at undgå misforståelser beder vi vores udviklere om at kode 2 eller 3 forskellige spørgsmål, så de kan se, hvordan de ser ud, inden de koder selve testen.
Rake 10: Uden test, upload direkte til produktion
3 gange, gutter, testen skulle kontrolleres 3 gange af forskellige personer, eller endnu bedre, 3 gange hver. Denne sandhed blev opnået med blod, sved og pixels af kodelinjer.
Vores test tjekker følgende trio:
- Produkt - kontrollerer testen for ydeevne, udseende, mekanik.
- Testudvikler - tjekker opgavernes tekst, deres rækkefølge, arbejdsform med testen, opgavetyper, korrekte svar, læsbarhed og normal visning af grafik.
- Opgavernes forfatter (ekspert) kontrollerer testen for troskab fra en ekspertposition.
Et eksempel fra praksis: først ved tredje kørsel så opgaveforfatteren, at 1 opgave var tilbage i den gamle version af formuleringen. Alle de foregående regerede også aktivt. Men da testen blev kodet, så den anderledes ud end oprindeligt forestillet. Det er højst sandsynligt, at noget skal rettes. Dette skal tages i betragtning.
Total
Forsigtigt omgå alle disse "rake", skabte vi en speciel , for at teste ansøgernes viden. Enhver kan teste det, mens vi forbereder det næste materiale, hvor vi vil fortælle dig, hvad der skete inde i botten, og hvad det hele forvandlede sig til senere.
Du kan få et efterspurgt erhverv fra bunden eller Level Up med hensyn til kompetencer og løn ved at tage SkillFactory online kurser:
- (12 uger)
- (20 uger)
- (20 uger)
- (12 måneder)
Flere kurser
- (12 måneder)
- (14 uger)
- (5 uger)
- (18 måneder)
- (6 måneder)
- (12 måneder)
- (8 måneder)
- (9 måneder)
- (12 måneder)
- (18 måneder)
- (18 måneder)
- (12 måneder)
- (9 måneder)
- (7 måneder)
Kilde: www.habr.com