Enne uuele masinõppe kursusele registreerumist testime tulevasi õpilasi, et teha kindlaks nende valmisoleku tase ja mõista, mida nad kursuseks valmistumiseks täpselt pakkuma peavad. Kuid tekib dilemma: ühelt poolt peame andmeteaduses teadmisi proovile panema, teisalt ei saa me korraldada täisväärtuslikku 4-tunnist eksamit.
Selle probleemi lahendamiseks oleme juurutanud TestDevi peakorteri otse andmeteaduse kursuse arendusmeeskonnas (ja tundub, et see on alles algus). Esitame teile nimekirja 10 lõksust, mis teadmiste hindamiseks mõeldud testide koostamisel kokku puutuvad. Loodetavasti muutub veebipõhise õppe maailm pärast seda pisut paremaks.
Rake 1: testimise eesmärkide selgelt määratlemata jätmine
Eesmärkide õigeks määratlemiseks ja neid arvesse võtva testi loomiseks peame planeerimisetapis vastama mitmele küsimusele:
- Mida me tegelikult kontrollime?
- Millises keskkonnas testimine toimub ja millist mehaanikat kasutatakse? Millised on selle keskkonna piirangud? See sama punkt võimaldab teil mõista tehnilisi nõudeid seadmele, millega testimine toimub, ja ka sisule (kui test on tehtud telefonidest, peaksid pildid olema loetavad ka väikesel ekraanil, peaks neid on võimalik suurendada jne).
- Kui kaua testimine aega võtab? Peate mõtlema, millistel tingimustel kasutaja testi sooritab. Kas võib tekkida olukord, kus ta peab testimisprotsessi katkestama ja seejärel uuesti jätkama?
- Kas tagasisidet tuleb? Kuidas me seda moodustame ja tarnime? Mida on vaja saada? Kas testi täitmise ja tagasiside vahel on ajavahe?
Meie puhul määratlesime pärast nendele küsimustele vastamist testi jaoks järgmise eesmärkide loendi:
- Test peaks näitama, kas tulevased üliõpilased on valmis kursust läbima ning kas neil on piisavalt teadmisi ja oskusi.
- Test peaks andma meile tagasisideks materjali, näitama teema, milles õpilased eksisid, et nad saaksid oma teadmisi täiendada. Allpool räägime teile, kuidas seda koostada.
Reha 2: eksperdi testi koostaja tehniliste kirjelduste koostamata jätmine
Testiobjektide koostamiseks on väga oluline kaasata selle valdkonna ekspert, milles teadmisi kontrollitakse. Ja eksperdi jaoks on omakorda vaja pädevat tehnilist kirjeldust (kirjeldust), mis sisaldab testi teemasid, testitavaid teadmisi/oskusi ja nende taset.
Ekspert ei tee selliseid tehnilisi kirjeldusi enda jaoks, sest tema ülesanne on välja mõelda ülesanded, mitte testi ülesehitus. Pealegi töötavad vähesed testid professionaalselt välja isegi õpetamise käigus. Seda õpetatakse eraldi erialal – psühhomeetria.
Kui soovite psühhomeetriaga kiiresti tutvuda, siis Venemaal on see olemas kõigile huvilistele. Põhjalikumaks uurimiseks on Haridusinstituudil ja aspirantuur.
Tehniliste kirjelduste koostamisel kogume eksperdile (või parem, koos temaga) testi üksikasjaliku kirjelduse: ülesannete teemad, ülesannete tüübid, nende arv.
Kuidas valida ülesannete tüüpi: kui teemad on otsustatud, otsustame, millised ülesanded suudavad seda kõige paremini testida? Klassikalised valikud: avatud ülesanne, valik- või ühe valikuga ülesanne, sobitamine jne (ärge unustage testimiskeskkonna tehnilisi piiranguid!). Peale tööülesannete liigi määramist ja täpsustamist on meil eksperdi jaoks valmis tehniline kirjeldus. Võite seda nimetada testi spetsifikatsiooniks.
Rake 3: Ei kaasata testi arendusse eksperti
Eksperdi testiarendusse sukeldumisel on väga oluline mitte lihtsalt näidata talle “töö ulatust”, vaid kaasata ta arendusprotsessi endasse.
Kuidas muuta koostöö eksperdiga võimalikult tõhusaks:
- Seadistage see eelnevalt ja veetke aega testide arendamise teadusest ja psühhomeetriast rääkides.
- Suuna hindaja tähelepanu kehtiva ja usaldusväärse hindamisvahendi, mitte küsimuste loendi loomisele.
- Selgitage, et tema töö hõlmab ettevalmistavat etappi, mitte ainult ülesannete enda väljatöötamist.
Mõned eksperdid (oma olemuse tõttu) võivad seda tajuda oma töö proovikivina ja me selgitame neile, et isegi kui loome suurepäraseid ülesandeid, ei pruugi need konkreetsete testimise eesmärkidega lihtsalt sobida.
Protsessi kiireks kulgemiseks koostame koos eksperdiga teemade katvuse (teadmiste ja oskuste) tabeli, mis on osa testi spetsifikatsioonist. Just see tabel võimaldab meil küsimusi täpselt välja töötada ja määrata, mida me mõõdame. Igal konkreetsel juhul saab selle koostada veidi erinevalt. Meie ülesanne on kontrollida, kui hästi inimene saab aru eelmiste, põhikursuste teadmistest ja oskustest, et mõista, kui valmis ta on uuel kursusel õppima.
Reha 4: Arvates, et ekspert "teab kõige paremini"
Tunneb teemat paremini. Kuid see ei seleta alati selgelt. Väga oluline on kontrollida ülesannete sõnastust. Kirjutage selged juhised, näiteks „Valige 1 õige valik”. 90% juhtudest koostavad eksperdid küsimused nii, et nad ise aru saavad. Ja see on okei. Aga enne testi sooritajatele üleandmist tuleb kõik üle kontrollida ja läbi kammida, et testi sooritajad saaksid täpselt aru, mida neilt nõutakse ega teeks vigu lihtsalt seetõttu, et võivad ülesande teksti valesti tõlgendada.
Ülesannete kahekordse tõlgendamise vältimiseks viime läbi "kognitiivseid laboreid". Palume sihtrühma inimestel testi sooritada, öeldes kõva häälega välja oma arvamuse ja salvestades selle üksikasjalikult. "Kognitiivsetes laborites" saate "püüda" ebaselgeid küsimusi, halba sõnastust ja saada testile esimest tagasisidet.
Rake 5: Ignoreeri testi täitmise aega
sarkasmirežiim: sees
Muidugi on meie test parim, kõik unistavad selle läbimisest! Jah, kõik 4 tundi.
sarkasmirežiim: väljas
Kui on nimekiri kõigest, mida saab kontrollida, siis peamine on seda mitte teha (esmapilgul kõlab see imelikult, kas pole?). Peate halastamatult lõikama, selgitades välja võtmeteadmised ja -oskused koos eksperdiga (jah, mitmeid oskusi saab testis ka testida). Vaatame ülesannete tüüpe ja hindame eesmärgi täitmise aega: kui kõik on ikka rohkem kui mõistlikud piirid, siis kärpime!
Helitugevuse vähendamiseks võid proovida (ettevaatlikult) testida ka kahte oskust ühes ülesandes. Sel juhul on raske aru saada, miks inimene eksis, kuid õigesti tehes saab arvestada mõlema oskusega. Oluline on veenduda, et need 2 oskust vastavad samale teadmiste valdkonnale.
Reha 6: Ei mõtle läbi punktisüsteemi
Tihti kasutavad nad hindamistestide koostamisel klassikalist punktisüsteemi, näiteks kergete ülesannete eest 1 punkt ja raskete eest 2 punkti. Kuid see pole universaalne. Ainuüksi testitulemuste põhjal saadud punktide summa ei ütle meile palju: me ei tea, milliste ülesannete eest need punktid saadi ja saame määrata vaid õigete ülesannete arvu. Peame täpselt aru saama, milliseid oskusi testijad näitavad. Lisaks soovime neile anda tagasisidet, millised teemad vajavad täiustamist.
Teeme ju testi, mis jagab inimesed nendeks, kes on valmis programmi läbima ja kes ei ole valmis, mõnel soovitame kursuseks valmistuda tasuta koolituse kaudu. Meie jaoks on oluline, et sellesse rühma kuuluksid ainult need, kes seda tõesti vajavad ja kes on selleks valmis.
Mida me oma olukorras teeme: määrame testi koostajate töörühmas kindlaks, millised inimrühmad tuleb tuvastada (näiteks õppimisvalmis, osaliselt valmis) ja moodustame selliste rühmade tunnuste tabeli, mis näitab, millised oskused ja teadmised on õppimisvalmis koolituse rühma jaoks asjakohane. Nii saate selliste testide jaoks ülesannete "raskused" sõnastada.
Rake 7: hinda tulemusi ainult automaatselt
Loomulikult peaks hindamine olema võimalikult objektiivne, nii et osa õppematerjale hinnatakse automaatselt, “võtmete järgi” – võrreldes õigete vastustega. Isegi kui spetsiaalset testimissüsteemi pole, on tasuta lahendusi küllaga. Ja kui mõistate skriptide kirjutamise põhimõtteid, saate Google'i vormide ja tabelites tulemustega teha, mida soovite. Kui mõnda ülesannet kontrollivad eksperdid, siis peame mõtlema ekspertidele vastuste edastamisele, ilma et testi sooritajaid puudutaks. Ja mõelge, kuidas integreerida eksperttestide tulemused lõpphinnangusse.
Tahtsime algselt teha mitu koodiga avatud ülesannet, kus eksperdid hindavad lahendusi eelnevalt vormistatud kriteeriumide alusel ja koostasime isegi süsteemi, mis ekspordib testis osalejate individuaalsed vastused spetsiaalsesse ekspertide tabelisse ja impordib seejärel saadud tulemused tabel hindamisarvutustega. Kuid pärast arutamist sihtrühma esindajate, tootejuhi ja haridusdisaineriga, tundsime, et tehnilise intervjuu läbiviimine, kus oleks kiire ekspertide tagasiside ja koodide ning üksikute küsimuste arutamine, oleks palju tõhusam ja kasulikum ka osalejatele endile. .
Nüüd kontrollib ekspert testi täitmist, täpsustades mõningaid küsimusi. Selleks oleme koostanud tehnilise intervjuu küsimuste ja hindamiskriteeriumide juhendi. Enne tehnilist vestlust saab eksamineerija kaardi testi sooritaja vastustest, mis aitab tal esitada küsimusi.
Rake 8: Ärge selgitage testi tulemusi
Omaette teema on osalejatele tagasiside andmine. Peame mitte ainult teavitama testi tulemustest, vaid andma ka arusaamise testi tulemustest.
Need võivad olla:
- Ülesanded, milles osaleja tegi vea ja mille ta täitis õigesti.
- Teemad, milles osaleja tegi vigu.
- Tema paremusjärjestus eksami sooritajate seas.
- Osaleja taseme kirjeldus vastavalt näiteks spetsialisti taseme kirjeldusele (vabade töökohtade kirjelduse alusel).
Meie testi pilootkäivitamise ajal näitasime programmis registreeruda soovijatele koos tulemustega nimekirja teemadest, mida oli vaja täiustada. Kuid see pole kindlasti ideaalne, me täiustame ja anname paremat tagasisidet.
Rake 9: Ärge arutlege testi arendajatega
Vahest kõige teravam reha, mille otsa on eriti ebameeldiv astuda, on testi, kirjelduse ja hindamisskaala saatmine arendajatele “nagu on”.
Mida täpselt tuleb arutada:
- Küsimuste välimus, ülesehitus, graafika asukoht, milline näeb välja õige vastuse valik.
- Kuidas skoori arvutatakse (vajadusel), kas on mingeid lisatingimusi.
- Kuidas tekib tagasiside, kust saab tekste, kas on olemas täiendavaid automaatselt genereeritud plokke.
- Millist lisainfot on vaja koguda ja mis hetkel (samad kontaktid).
Arusaamatuste vältimiseks palume oma arendajatel kodeerida 2 või 3 erinevat küsimust, et nad saaksid enne testi enda kodeerimist näha, kuidas need välja näevad.
Rake 10: ilma testimiseta laadige otse tootmisse
3 korda, poisid, testi peaksid kontrollima 3 korda erinevad inimesed või veel parem, igaüks 3 korda See tõde saadi vere, higi ja pikslite koodiridade abil.
Meie test kontrollib järgmist kolmikut:
- Toode – kontrollib testi jõudlust, välimust, mehaanikat.
- Testi arendaja - kontrollib ülesannete teksti, nende järjekorda, testiga töötamise vormi, ülesannete tüüpe, õigeid vastuseid, loetavust ja graafika tavapärast vaatamist.
- Ülesannete autor (ekspert) kontrollib testi täpsust eksperdi positsioonilt.
Näide praktikast: alles kolmandal sõidul nägi ülesannete autor, et 1 ülesanne jäi sõnastuse vanasse versiooni. Aktiivselt valitsesid ka kõik eelmised. Kuid kui test oli kodeeritud, nägi see välja teistsugune, kui algselt ette kujutati. Suure tõenäosusega tuleb midagi parandada. Seda tuleb arvestada.
Summaarne
Kõigist neist “rehast” ettevaatlikult mööda minnes lõime spetsiaalse , et testida kandideerijate teadmisi. Igaüks saab seda testida, kui valmistame ette järgmist materjali, milles räägime teile, mis robotis juhtus ja milleks see kõik hiljem muutus.
SkillFactory veebikursustel osaledes võite omandada nõutud elukutse nullist või Level Up tasemel oskuste ja palga osas:
- (12 nädalat)
- (20 nädalat)
- (20 nädalat)
- (12 kuud)
Rohkem kursusi
- (12 kuud)
- (14 nädalat)
- (5 nädalat)
- (18 kuud)
- (6 kuud)
- (12 kuud)
- (8 kuud)
- (9 kuud)
- (12 kuud)
- (18 kuud)
- (18 kuud)
- (12 kuud)
- (9 kuud)
- (7 kuud)
Allikas: www.habr.com