Voordat ons vir die nuwe Masjienleer Gevorderde-kursus inskryf, toets ons voornemende studente om hul vlak van gereedheid te bepaal en te verstaan wat hulle presies moet aanbied om vir die kursus voor te berei. Maar 'n dilemma ontstaan: aan die een kant moet ons kennis in Data Science toets, aan die ander kant kan ons nie 'n volwaardige 4-uur eksamen reël nie.
Om hierdie probleem op te los, het ons 'n TestDev-hoofkwartier reg in die Data Science-kursusontwikkelingspan ontplooi (en dit lyk of dit net die begin is). Ons bied aan jou 'n lys van 10 slaggate wat teëgekom word wanneer toetse ontwikkel word om kennis te assesseer. Hopelik sal die wêreld van aanlynleer hierna 'n bietjie beter wees.
Rake 1: Versuim om toetsdoelwitte duidelik te definieer
Om doelwitte korrek te definieer en 'n toets te skep wat dit in ag sal neem, moet ons in die beplanningstadium verskeie vrae beantwoord:
- Wat kontroleer ons nou eintlik?
- In watter omgewing sal die toetsing plaasvind en watter meganika word gebruik? Wat is die beperkings in hierdie omgewing? Hierdie selfde punt sal jou toelaat om die tegniese vereistes te verstaan vir die toestel waarop die toets uitgevoer sal word, en ook vir die inhoud (as die toets van fone geneem word, moet die prente selfs op 'n klein skerm leesbaar wees, dit moet moontlik wees om hulle te vergroot, ens.).
- Hoe lank sal die toetsing neem? Jy moet dink oor die voorwaardes waaronder die gebruiker die toets sal aflê. Kan daar 'n situasie wees waar hy die toetsproses moet onderbreek en dan weer moet voortgaan?
- Sal daar terugvoer wees? Hoe vorm en lewer ons dit? Wat moet jy ontvang? Is daar 'n tydsvertraging tussen toetsuitvoering en terugvoer?
In ons geval, nadat ons hierdie vrae beantwoord het, het ons die volgende lys doelwitte vir die toets gedefinieer:
- Die toets moet wys of toekomstige studente gereed is om die kursus te neem en of hulle genoeg kennis en vaardighede het.
- Die toets moet vir ons materiaal vir terugvoer gee, die onderwerp aandui waarin studente 'n fout gemaak het, sodat hulle hul kennis kan verbeter. Ons sal jou hieronder vertel hoe om dit saam te stel.
Rake 2: Versuim om tegniese spesifikasies vir die kundige toetsskrywer op te stel
Om toetsitems saam te stel, is dit baie belangrik om 'n deskundige te betrek in die veld waarin kennis getoets word. En vir 'n kenner het jy op sy beurt 'n bekwame tegniese spesifikasie (beskrywing) nodig wat die onderwerpe van die toets, die kennis/vaardighede wat getoets word en hul vlak insluit.
’n Kenner sal nie sulke tegniese spesifikasies vir homself doen nie, want sy werk is om met take vorendag te kom, nie die struktuur van die toets nie. Boonop ontwikkel min mense toetse professioneel, selfs in die proses van onderrig. Dit word in 'n aparte spesialiteit geleer - psigometrie.
As jy vinnig wil kennis maak met psigometrie, dan is daar in Rusland vir almal wat belangstel. Vir meer in-diepte studie het die Instituut vir Onderwys en nagraadse skool.
By die voorbereiding van die tegniese spesifikasies, versamel ons 'n gedetailleerde beskrywing van die toets vir die deskundige (of beter, saam met hom): onderwerpe van take, tipe take, hul aantal.
Hoe om die tipe take te kies: nadat ons oor die onderwerpe besluit het, besluit ons watter take dit die beste kan toets? Klassieke opsies: oop-einde taak, meervoudige of enkelkeuse taak, passing, ens. (moenie vergeet van die tegniese beperkings van die toetsomgewing nie!). Nadat ons die tipe take bepaal en gespesifiseer het, het ons 'n gereedgemaakte tegniese spesifikasie vir die deskundige. Jy kan dit 'n toetsspesifikasie noem.
Rake 3: Nie 'n deskundige by toetsontwikkeling betrek nie
Wanneer 'n kenner in toetsontwikkeling onderdompel word, is dit baie belangrik om nie net vir hom die "omvang van werk" aan te dui nie, maar om hom by die ontwikkelingsprosedure self te betrek.
Hoe om die werk met 'n kundige so effektief moontlik te maak:
- Stel dit vooraf op en spandeer tyd om oor die wetenskap van toetsontwikkeling en psigometrie te praat.
- Fokus die evalueerder se aandag op die skep van 'n geldige en betroubare assesseringsinstrument, nie 'n lys vrae nie.
- Verduidelik dat sy werk 'n voorbereidende stadium insluit, nie net die ontwikkeling van die take self nie.
Sommige kundiges (weens hul aard) mag dit as 'n toets van hul eie werk beskou, en ons verduidelik aan hulle dat selfs al skep ons uitstekende take, dit dalk eenvoudig nie by die spesifieke toetsdoelwitte pas nie.
Om die proses vinnig te laat verloop, berei ons 'n tabel van onderwerpdekking (kennis en vaardighede) saam met die deskundige op, wat deel is van die toetsspesifikasie. Dit is hierdie tabel wat ons in staat stel om die vrae akkuraat uit te werk en te bepaal wat ons sal meet. In elke spesifieke geval kan dit effens anders saamgestel word. Ons taak is om te kyk hoe goed 'n persoon die kennis en vaardighede van vorige, basiese kursusse verstaan om te verstaan hoe gereed hy is om in 'n nuwe kursus te studeer.
Rake 4: Dink dat die kenner "die beste weet"
Ken die onderwerp beter. Maar dit verduidelik nie altyd duidelik nie. Dit is baie belangrik om die bewoording van die opdragte na te gaan. Skryf duidelike instruksies, byvoorbeeld, "Kies 1 korrekte opsie." In 90% van gevalle berei kenners vrae voor op 'n manier wat hulle self verstaan. En dis oukei. Maar voor die oorhandiging van die toets aan diegene wat dit gaan aflê, moet alles nagegaan en gefynkam word sodat die mense wat die toets aflê presies verstaan wat van hulle vereis word en nie foute maak net omdat hulle die teks van die taak verkeerd kan interpreteer nie.
Om dubbele interpretasie van take te vermy, voer ons "kognitiewe laboratoriums." Ons vra mense uit die teikengehoor om die toets af te lê, hardop te sê wat hulle dink en dit in detail op te teken. By "kognitiewe laboratoriums" kan jy onduidelike vrae, slegte bewoording "vang" en die eerste terugvoer oor die toets kry.
Rake 5: Ignoreer toetsuitvoeringstyd
sarkasmemodus: aan
Natuurlik is ons toets die beste, almal droom daarvan om dit te slaag! Ja, al 4 ure.
sarkasmemodus: af
As daar 'n lys is van alles wat nagegaan kan word, is die belangrikste ding om dit nie te doen nie (met die eerste oogopslag klink dit vreemd, nie waar nie?). Jy moet genadeloos sny, sleutelkennis en -vaardighede identifiseer met 'n deskundige (ja, 'n aantal vaardighede kan ook in die toets getoets word). Ons kyk na die tipe take en skat die teikenvoltooiingstyd: as alles nog meer as redelike perke is, sny ons dit!
Om die volume te verminder, kan jy ook probeer om twee vaardighede in een taak (noukeurig) te toets. In hierdie geval is dit moeilik om te verstaan hoekom die persoon 'n fout gemaak het, maar as dit reg gedoen word, kan albei vaardighede in ag geneem word. Dit is belangrik om seker te maak dat hierdie 2 vaardighede ooreenstem met dieselfde area van kennis.
Hark 6: Dink nie deur die puntestelsel nie
Dikwels, wanneer hulle assesseringstoetse saamstel, gebruik hulle die klassieke puntestelsel, byvoorbeeld 1 punt vir maklike take en 2 punte vir moeilike take. Maar dit is nie universeel nie. Net die som van punte gebaseer op die toetsresultate sal ons nie veel sê nie: ons weet nie vir watter take hierdie punte ontvang is nie en ons kan net die aantal korrekte take bepaal. Ons moet presies verstaan watter vaardighede toetsafnemers demonstreer. Boonop wil ons vir hulle terugvoer gee oor watter onderwerpe verbeter moet word.
Ons doen immers 'n toets wat mense sal verdeel in diegene wat gereed is en diegene wat nie gereed is om die program te voltooi nie; ons sal sommige aanraai om deur gratis opleiding vir die kursus voor te berei. Dit is vir ons belangrik dat hierdie groep net diegene insluit wat dit regtig nodig het en wat gereed is daarvoor.
Wat ons in ons situasie doen: ons bepaal binne die werkgroep van toetsontwikkelaars watter groepe mense geïdentifiseer moet word (byvoorbeeld gereed om te leer, gedeeltelik gereed) en vorm 'n tabel van kenmerke van sulke groepe, wat aandui watter vaardighede en kennis sal relevant wees vir die groep gereed om te leer opleiding. Op hierdie manier kan jy die “moeilikheid” van take vir sulke toetse formuleer.
Hark 7: Evalueer slegs resultate outomaties
Natuurlik moet assessering so objektief as moontlik wees, so sommige van die studentemateriaal word outomaties geassesseer, "deur sleutels" - in vergelyking met die korrekte antwoorde. Selfs al is daar geen spesiale toetsstelsel nie, is daar baie gratis oplossings. En as jy die beginsels van die skryf van skrifte verstaan, kan jy doen wat jy wil met Google-vorms en resultate in tabelle. As sommige van die take deur kundiges nagegaan word, moet ons daaraan dink om antwoorde aan die kundiges te lewer, sonder inligting oor die toetsafnemers. En dink aan hoe om die resultate van deskundige toetsing in die finale assessering te integreer.
Ons wou aanvanklik verskeie oop-einde take met kode maak, waar kundiges oplossings evalueer op grond van vooraf gevormde kriteria, en ons het selfs 'n stelsel voorberei wat individuele antwoorde van toetsdeelnemers na 'n spesiale tafel vir kundiges uitvoer, en dan die resultate invoer in 'n tabel met assesseringsberekeninge. Maar nadat ons met verteenwoordigers van die teikengehoor, produkbestuurder en opvoedkundige ontwerper bespreek het, het ons gevoel dat die voer van 'n tegniese onderhoud met onmiddellike deskundige terugvoer en bespreking van die kode, sowel as individuele kwessies, baie meer effektief en nuttig vir die deelnemers self sou wees .
Nou verifieer die deskundige die voltooiing van die toets en verduidelik sommige vrae. Om dit te doen, het ons 'n gids van vrae en assesseringskriteria vir 'n tegniese onderhoud voorberei. Voor die tegniese onderhoud ontvang die eksaminator 'n kaart van die toetsling se antwoorde om hom te help om vrae te kies om te vra.
Hark 8: Moenie toetsresultate verduidelik nie
Die verskaffing van terugvoer aan deelnemers is 'n aparte kwessie. Ons moet nie net oor die toetstelling inlig nie, maar ook 'n begrip van die toetsresultate gee.
Dit kan wees:
- Take waarin die deelnemer 'n fout gemaak het en wat hy korrek voltooi het.
- Onderwerpe waarin die deelnemer foute gemaak het.
- Sy posisie onder diegene wat die eksamen aflê.
- Beskrywing van die deelnemer se vlak, in ooreenstemming, byvoorbeeld, met die beskrywing van die spesialisvlak (gebaseer op die beskrywing van vakatures).
Tydens die loodsbekendstelling van ons toets het ons aan diegene wat vir die program wou inskryf, saam met die resultate, 'n lys van onderwerpe gewys wat verbeter moes word. Maar dit is beslis nie ideaal nie, ons sal verbeter en beter terugvoer gee.
Rake 9: Moenie die toets met ontwikkelaars bespreek nie
Miskien is die skerpste hark, wat veral onaangenaam is om op te trap, om die toets, beskrywing en tellingskaal “soos dit is” aan die ontwikkelaars te stuur.
Wat presies bespreek moet word:
- Die voorkoms van die vrae, die struktuur, die posisie van die grafika, hoe die keuse van die korrekte antwoord lyk.
- Hoe word die telling bereken (indien nodig), is daar enige bykomende voorwaardes.
- Hoe word terugvoer gegenereer, waar om tekste te kry, is daar addisionele outomaties gegenereerde blokke.
- Watter bykomende inligting moet jy insamel en op watter punt (dieselfde kontakte).
Om misverstande te voorkom, vra ons ons ontwikkelaars om 2 of 3 verskillende vrae te kodeer sodat hulle kan sien hoe dit lyk voordat hulle die toets self kodeer.
Rake 10: Sonder om te toets, laai direk op na produksie
3 keer, ouens, die toets moet 3 keer deur verskillende mense nagegaan word, of nog beter, 3 keer elk. Hierdie waarheid is verkry met bloed, sweet en pixels van reëls kode.
Ons toets kontroleer die volgende drie:
- Produk - kontroleer die toets vir prestasie, voorkoms, meganika.
- Toetsontwikkelaar - kontroleer die teks van die take, hul volgorde, vorm van werk met die toets, tipe take, korrekte antwoorde, leesbaarheid en normale besigtiging van grafika.
- Die outeur van die take (deskundige) kontroleer die toets vir getrouheid vanuit 'n deskundige posisie.
'n Voorbeeld uit die praktyk: eers met die derde lopie het die skrywer van die take gesien dat 1 taak in die ou weergawe van die bewoording oorbly. Al die voriges het ook aktief regeer. Maar toe die toets gekodeer is, het dit anders gelyk as wat oorspronklik gedink is. Dit is hoogs waarskynlik dat iets reggestel sal moet word. Dit moet in ag geneem word.
Totale
Om al hierdie "hark" versigtig te omseil, het ons 'n spesiale geskep , om die kennis van aansoekers te toets. Enigeen kan dit toets terwyl ons besig is om die volgende materiaal voor te berei, waarin ons jou sal vertel wat binne die bot gebeur het, en wat dit alles later verander het.
Jy kan 'n gesogte beroep van nuuts af kry of Level Up in terme van vaardighede en salaris deur SkillFactory aanlyn kursusse te neem:
- (12 weke)
- (20 weke)
- (20 weke)
- (12 maande)
Meer kursusse
- (12 maande)
- (14 weke)
- (5 weke)
- (18 maande)
- (6 maande)
- (12 maande)
- (8 maande)
- (9 maande)
- (12 maande)
- (18 maande)
- (18 maande)
- (12 maande)
- (9 maande)
- (7 maande)
Bron: will.com