Før vi melder oss på det nye Machine Learning Advanced-kurset, tester vi potensielle studenter for å bestemme deres beredskapsnivå og forstå nøyaktig hva de trenger å tilby for å forberede seg til kurset. Men et dilemma oppstår: på den ene siden må vi teste kunnskap i Data Science, på den andre kan vi ikke arrangere en fullverdig 4-timers eksamen.
For å løse dette problemet har vi distribuert et TestDev-hovedkvarter rett i Data Science-kursutviklingsteamet (og det ser ut til at dette bare er begynnelsen). Vi presenterer for deg en liste over 10 fallgruver du møter når du utvikler tester for å vurdere kunnskap. Forhåpentligvis vil verden av nettbasert læring bli litt bedre etter dette.
Rake 1: Ikke klart å definere testmål
For å definere mål riktig og lage en test som vil ta hensyn til dem, må vi på planleggingsstadiet svare på flere spørsmål:
- Hva sjekker vi egentlig?
- Hvilket miljø skal testingen foregå i og hvilken mekanikk brukes? Hva er begrensningene i dette miljøet? Dette samme punktet vil tillate deg å forstå de tekniske kravene til enheten som testingen skal utføres på, og også for innholdet (hvis testen er tatt fra telefoner, bør bildene være lesbare selv på en liten skjerm, den skal være mulig å forstørre dem osv.).
- Hvor lang tid vil testen ta? Du må tenke på forholdene som brukeren vil ta testen under. Kan det være en situasjon der han må avbryte testprosessen og deretter fortsette igjen?
- Kommer det tilbakemeldinger? Hvordan former og leverer vi den? Hva trenger du å motta? Er det en tidsforsinkelse mellom testutførelse og tilbakemelding?
I vårt tilfelle, etter å ha svart på disse spørsmålene, definerte vi følgende liste over mål for testen:
- Testen skal vise om fremtidige studenter er klare for å ta kurset og om de har nok kunnskap og ferdigheter.
- Testen skal gi oss stoff for tilbakemelding, angi temaet der elevene gjorde feil, slik at de kan forbedre kunnskapene sine. Vi forteller deg hvordan du komponerer den nedenfor.
Rake 2: Unnlatelse av å utarbeide tekniske spesifikasjoner for eksperttestskriveren
For å komponere testelementer er det svært viktig å involvere en ekspert på feltet kunnskap testes. Og for en ekspert trenger du på sin side en kompetent teknisk spesifikasjon (beskrivelse), som inkluderer testens emner, kunnskapen/ferdighetene som testes og nivået deres.
En ekspert vil ikke gjøre slike tekniske spesifikasjoner for seg selv, fordi jobben hans er å komme med oppgaver, ikke strukturen til testen. Dessuten er det få som utvikler tester profesjonelt, selv i undervisningsprosessen. Dette undervises i en egen spesialitet - psykometri.
Hvis du raskt vil bli kjent med psykometri, så er det i Russland for alle interesserte. For mer fordypning har Utdanningsinstituttet og forskerskole.
Når vi utarbeider de tekniske spesifikasjonene, samler vi en detaljert beskrivelse av testen for eksperten (eller bedre, sammen med ham): emner for oppgaver, type oppgaver, deres nummer.
Hvordan velge type oppgaver: etter å ha bestemt oss for temaene, bestemmer vi hvilke oppgaver som best kan teste dette? Klassiske alternativer: åpen oppgave, fler- eller enkeltvalgsoppgave, matching osv. (ikke glem de tekniske begrensningene til testmiljøet!). Etter å ha bestemt og spesifisert type oppgaver har vi en ferdig teknisk spesifikasjon for eksperten. Du kan kalle det en testspesifikasjon.
Rake 3: Ikke involverer en ekspert i testutvikling
Når du fordyper en ekspert i testutvikling, er det veldig viktig ikke bare å indikere for ham "arbeidets omfang", men å involvere ham i selve utviklingsprosedyren.
Hvordan gjøre arbeidet med en ekspert så effektivt som mulig:
- Sett det opp på forhånd og bruk litt tid på å snakke om vitenskapen om testutvikling og psykometri.
- Fokuser evaluatorens oppmerksomhet på å lage et gyldig og pålitelig vurderingsverktøy, ikke en liste med spørsmål.
- Forklar at arbeidet hans inkluderer en forberedende fase, ikke bare utviklingen av selve oppgavene.
Noen eksperter (på grunn av sin natur) kan oppfatte dette som en test av sitt eget arbeid, og vi forklarer dem at selv om vi lager utmerkede oppgaver, kan de rett og slett ikke passe de spesifikke testmålene.
For å få prosessen til å gå raskt utarbeider vi en tabell over emnedekning (kunnskap og ferdigheter) med eksperten, som er en del av testspesifikasjonen. Det er denne tabellen som lar oss regne ut spørsmålene nøyaktig og bestemme hva vi skal måle. I hvert enkelt tilfelle kan det kompileres litt annerledes. Vår oppgave er å sjekke hvor godt en person forstår kunnskapen og ferdighetene til tidligere grunnkurs for å forstå hvor klar han er til å studere i et nytt kurs.
Rake 4: Tenker at eksperten "vet best"
Kan faget bedre. Men det forklarer ikke alltid klart. Det er svært viktig å sjekke ordlyden i oppgavene. Skriv klare instruksjoner, for eksempel "Velg ett riktig alternativ." I 1 % av tilfellene forbereder eksperter spørsmål på en måte de selv forstår. Og det er greit. Men før du overleverer testen til de som skal ta den, må alt kontrolleres og finkjemmes slik at personene som tar testen forstår nøyaktig hva som kreves av dem og ikke gjør feil bare fordi de kan feiltolke teksten i oppgaven.
For å unngå dobbelttolkning av oppgaver, gjennomfører vi «kognitive laboratorier». Vi ber folk fra målgruppen om å ta testen, si høyt hva de synes og registrerer det i detalj. På "kognitive laboratorier" kan du "fange" uklare spørsmål, dårlige formuleringer og få den første tilbakemeldingen på testen.
Rake 5: Ignorer testgjennomføringstiden
sarkasmemodus: på
Selvfølgelig er testen vår den beste, alle drømmer om å bestå den! Ja, alle 4 timene.
sarkasmemodus: av
Når det er en liste over alt som kan sjekkes, er det viktigste å ikke gjøre det (ved første øyekast høres det rart ut, ikke sant?). Du må nådeløst kutte, identifisere nøkkelkunnskaper og ferdigheter med en ekspert (ja, en rekke ferdigheter kan også testes i testen). Vi ser på typen oppgaver og anslår målfullføringstiden: hvis alt fortsatt er mer enn rimelige grenser, kutter vi det!
For å redusere volumet kan du også prøve (nøye) å teste to ferdigheter i en oppgave. I dette tilfellet er det vanskelig å forstå hvorfor personen gjorde en feil, men hvis det gjøres riktig, kan begge ferdighetene tas i betraktning. Det er viktig å sørge for at disse to ferdighetene tilsvarer samme kunnskapsområde.
Rake 6: Tenker ikke gjennom scoringssystemet
Når de sammenstiller vurderingstester, bruker de ofte det klassiske poengsystemet, for eksempel 1 poeng for enkle oppgaver og 2 poeng for vanskelige. Men det er ikke universelt. Bare summen av poeng basert på testresultatene vil ikke fortelle oss mye: vi vet ikke for hvilke oppgaver disse poengene ble mottatt, og vi kan bare bestemme antall riktige oppgaver. Vi må forstå nøyaktig hvilke ferdigheter testtakere viser. I tillegg ønsker vi å gi dem tilbakemelding på hvilke temaer som må forbedres.
Vi gjør tross alt en test som vil dele opp folk i de som er klare og de som ikke er klare til å fullføre programmet; vi vil råde noen til å forberede seg til kurset gjennom gratis opplæring. Det er viktig for oss at denne gruppen kun inkluderer de som virkelig trenger det og som er klare for det.
Hva vi gjør i vår situasjon: vi bestemmer i arbeidsgruppen av testutviklere hvilke grupper av mennesker som må identifiseres (for eksempel klare til å lære, delvis klare) og danner en tabell over egenskaper for slike grupper, som indikerer hvilke ferdigheter og kunnskaper vil være aktuelt for gruppen av lærevillige treninger. På denne måten kan du formulere "vanskeligheten" til oppgaver for slike tester.
Rake 7: Evaluer kun resultater automatisk
Selvsagt skal vurderingen være så objektiv som mulig, så noe av studentmateriellet vurderes automatisk, "ved nøkler" - sammenlignet med de riktige svarene. Selv om det ikke er noe spesielt testsystem, finnes det nok av gratisløsninger. Og hvis du forstår prinsippene for å skrive skript, kan du gjøre hva du vil med Google-skjemaer og resultater i tabeller. Hvis noen av oppgavene kontrolleres av eksperter, så må vi tenke på å levere svar til ekspertene, uten informasjon om testtakerne. Og tenk på hvordan du kan integrere resultatene av eksperttesting i den endelige vurderingen.
Vi ønsket i utgangspunktet å lage flere åpne oppgaver med kode, der eksperter vurderer løsninger basert på forhåndsutformede kriterier, og vi utarbeidet til og med et system som eksporterer individuelle svar fra testdeltakere til en spesiell tabell for eksperter, og deretter importerer resultatene inn i en tabell med vurderingsberegninger. Men etter å ha diskutert med representanter for målgruppen, produktsjef og pedagogisk designer, følte vi at å gjennomføre et teknisk intervju med umiddelbar eksperttilbakemelding og diskusjon av koden, så vel som individuelle problemstillinger, ville være mye mer effektivt og nyttig for deltakerne selv .
Nå verifiserer eksperten fullføringen av testen, og avklarer noen spørsmål. For å gjøre dette har vi utarbeidet en guide med spørsmål og vurderingskriterier for et teknisk intervju. Før det tekniske intervjuet mottar sensoren et kart over testpersonens svar for å hjelpe ham med å velge spørsmål å stille.
Rake 8: Ikke forklar testresultatene
Å gi tilbakemelding til deltakerne er en egen sak. Vi må ikke bare informere om testresultatet, men også gi en forståelse av testresultatene.
Disse kan være:
- Oppgaver der deltakeren gjorde en feil og som han fullførte riktig.
- Emner der deltakeren gjorde feil.
- Hans rangering blant de som tar eksamen.
- Beskrivelse av deltakerens nivå, i samsvar med for eksempel beskrivelsen av spesialistnivået (basert på beskrivelsen av ledige stillinger).
Under pilotlanseringen av testen vår viste vi til de som ønsket å melde seg på programmet, sammen med resultatene, en liste over emner som måtte forbedres. Men dette er absolutt ikke ideelt, vi vil forbedre oss og gi bedre tilbakemeldinger.
Rake 9: Ikke diskuter testen med utviklere
Den kanskje skarpeste raken, som er spesielt ubehagelig å tråkke på, er å sende test-, beskrivelses- og poengskalaen til utviklerne "som den er".
Hva skal egentlig diskuteres:
- Utseendet til spørsmålene, strukturen, plasseringen av grafikken, hvordan valget av riktig svar ser ut.
- Hvordan beregnes poengsummen (om nødvendig), er det noen tilleggsbetingelser.
- Hvordan genereres tilbakemeldinger, hvor man kan hente tekster, er det flere automatisk genererte blokker.
- Hvilken tilleggsinformasjon trenger du å samle inn og på hvilket tidspunkt (samme kontakter).
For å unngå misforståelser ber vi utviklerne våre om å kode 2 eller 3 forskjellige spørsmål slik at de kan se hvordan de ser ut før de koder selve testen.
Rake 10: Uten testing, last opp direkte til produksjonen
3 ganger, folkens, testen bør sjekkes 3 ganger av forskjellige personer, eller enda bedre, 3 ganger hver. Denne sannheten ble oppnådd med blod, svette og piksler med kodelinjer.
Testen vår sjekker følgende trio:
- Produkt - sjekker testen for ytelse, utseende, mekanikk.
- Testutvikler - sjekker teksten til oppgavene, rekkefølgen deres, arbeidsformen med testen, typer oppgaver, riktige svar, lesbarhet og normal visning av grafikk.
- Forfatteren av oppgavene (ekspert) kontrollerer testen for troskap fra en ekspertstilling.
Et eksempel fra praksis: først på den tredje kjøringen så forfatteren av oppgavene at 1 oppgave forble i den gamle versjonen av ordlyden. Alle de forrige styrte også aktivt. Men da testen ble kodet, så den annerledes ut enn først antatt. Det er høyst sannsynlig at noe må rettes opp. Dette må tas i betraktning.
Total
Ved å omgå alle disse "rakene" skapte vi en spesiell , for å teste kunnskapen til søkere. Hvem som helst kan teste det mens vi forbereder det neste materialet, der vi vil fortelle deg hva som skjedde inne i boten, og hva det hele forvandlet seg til senere.
Du kan få et ettertraktet yrke fra bunnen av eller Level Up når det gjelder ferdigheter og lønn ved å ta SkillFactory nettkurs:
- (12 uker)
- (20 uker)
- (20 uker)
- (12 måneder)
Flere kurs
- (12 måneder)
- (14 uker)
- (5 uker)
- (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