Mugavus: 10 kriitilist testi arenduse viga teadmiste kontrollimiseks

Mugavus: 10 kriitilist testi arenduse viga teadmiste kontrollimiseks
Enne uuele Machine Learning Advanced kursusele registreerimist testime tulevasi tudengeid, et määrata nende ettevalmistuse tase ja mõista, mida neile kursuse ettevalmistamiseks pakkuda. Kuid tekib dilemma: ühelt poolt peame kontrollima andmeteaduse teadmisi, teiselt poolt ei saa me korraldada täielikku 4 tunni eksamit.

Selle ülesande lahendamiseks oleme loonud TestDev tiimi otse andmeteaduse kursuste arendamise meeskonnas (ja tundub, et see on alles algus). Tutvustame teile nimekirja 10 „gpadest”, kuhu astutakse testide väljatöötamisel teadmiste hindamiseks. Loodame, et see muudab online-õppe maailma natuke paremaks.

Graple 1: Testimise eesmärkide täpsustamata jätmine

Kuidas selgelt määrata eesmärke ja koostada test, mis neid arvesse võtab, peame planeerimise etapis endale mitmele küsimusele vastama:

  1. Mida me tõeliselt kontrollime? 
  2. Millises keskkonnas testi läbi viiakse ja milliseid mehhanisme kasutatakse? Millised on selle keskkonna piirangud? See punkt aitab mõista ka seadme tehnilisi nõudeid, millega testimist läbi viiakse, ning sisu nõudeid (nt kui testitakse telefonide kaudu, peavad pildid olema loetavad isegi väikese ekraani peal ja neid tuleb võimaldada suurendada jne).
  3. Kui kaua testimine kestab? Tuleb läbi mõelda, millistes tingimustes kasutaja testi läbib. Kas on võimalik, et tal tuleb testimise protsess katkestada ja pärast seda jätkata?
  4. Kas tagasiside antakse? Kuidas seda kujundatakse ja edastatakse? Mida on selle saamiseks vaja? Kas testi sooritamise ja tagasiside vahel on ajavahe?

Meie juhul vastates nendele küsimustele määratlesime testi jaoks järgmised eesmärgid:

  1. Test peab näitama, kas tulevased üliõpilased on kursuse läbimiseks valmis ja kas neil on piisavalt teadmisi ja oskusi.
  2. Test peaks olema meile tagasiside allikaks, näidates teemat, milles üliõpilased on eksinud, et nad saaksid oma teadmisi täiendada. Kuidas seda koostada — räägime edasi.

Vale 2: Ei koostata eksperdi jaoks TÕ-d — testi koostaja jaoks

Testi ülesannete koostamisel on väga oluline kaasata ekspert antud valdkonnas, mille teadmisi testitakse. Eksperdile on vajalik ka arusaadav TÕ (kirjeldus), mis hõlmab testi teemasid, testitavaid teadmisi/oskusi ja nende taset.

Ekspert ei tee sellist TÕ-d endale ise, kuna tema töö on ülesannete väljamõtlemine, mitte testi struktuuri loomine. Eriti kuna vähe inimesi arendab professionaalselt teste, isegi õppetöös. Sellega õpetatakse eraldi erialal — psühhomeetrikas.

Kui soovite kiiresti psühhomeetrikaga tutvuda, siis Venemaal on suvekool kõigile huvilistele. Süvitsi minekuks on Hariduste instituudis magistrikraad ja doktorikraad.

TÕ koostamisel kogume eksperdi jaoks üksikasjaliku testi kirjelduse (ja veel parem, koos temaga): ülesannete teemad, ülesannete tüüp ja nende arv.

Kuidas valida ülesannete tüüpi: otsustades teemade üle, milliseid ülesandeid on kõige parem kontrollida? Klassikalised variandid: avatud vastustega ülesanne, mitme- või ühekordse valiku ülesanne, vastavused jne. (ärme unusta tehnilisi piiranguid keskkonnas, kus testimist viiakse läbi!). Pärast ülesannete tüübi määratlemist ja fikseerimist on meil valmis spetsifikatsioon eksperdile.

Kamm 3: Ära kaasata eksperti testi arendamisse

Eksperdi kaasamisel testi arendamisse on väga oluline mitte lihtsalt määratleda talle "töömaht", vaid kaasata ta ise arendusprotsessi.

Kuidas tagada, et töö ekspertidega oleks võimalikult tõhus:

  • Ettenähtavalt seadistada tema ja kulutada natuke aega testi arendamise teaduse, psühhomeetria tutvustamiseks.
  • Keskenduda eksperdi tähelepanu kehtiva ja usaldusväärse hindamisvahendi loomisele, mitte küsimuste loendi koostamisele.
  • Selgitada, et tema töö sisaldab ettevalmistusfaasi, mitte ainult ülesannete väljatöötamist.

Mõned eksperdid (oma olemuse tõttu) võivad seda tajuda kui oma töö kontrollimist, ja neile selgitame, et isegi suurepäraste ülesannete koostamisel võivad need lihtsalt mitte sobida konkreetsete testimise eesmärkidega.

Kuna protsess kulgeb kiiresti, koostame ekspertidega teemade katvuse tabeli (teadmiste ja oskuste), mis on osa testi spetsifikatsioonist. Just see tabel võimaldab täpselt töötada küsimustega ja määratleda, mida me mõõdame. Igas konkreetses juhus võib see olla koostatud veidi erinevalt. Meie ülesanne on kontrollida, kui hästi inimene orienteerub varasemate, põhikursuste teadmistest ja oskustest, et mõista, kui valmis ta on uue kursuse õppimiseks.

Kivi 4: Arvata, et ekspert «teab paremini»

Teema on hästi selge. Kuid mitte alati on selgelt seletatud. On väga oluline kontrollida ülesannete sõnastust. Kirjutada arusaadavad juhised, näiteks: „Valige 1 õige variant.” 90% ekspertidest koostavad küsimusi nii, nagu nad ise mõistavad. Ja see on normaalne. Kuid enne testi andmist neile, kes seda läbivad, tuleb kõik üle vaadata ja korrigeerida, et inimesed, kes testi läbivad, saaksid kindlalt aru, mida neilt nõutakse, ja ei teeks vigu vaid seetõttu, et nad võivad ülesande teksti valesti tõlgendada.

Kaksikkäsituste vältimiseks viime läbi „kognitiivseid laboratooriume”. Palume sihtrühma inimestel test läbida, rääkides valjusti sellest, mida nad mõtlevad, ja fikseerime selle detailselt. „Kognitiivsetes laboratooriumides” saab „püüdma” arusaamatud küsimused, halvad sõnastused ja esimese tagasiside testi kohta.

Pettumus 5: Ei arvesse võtta testi sooritamise aega

iroonia režiim: sisse
Muidugi on meie test parim, kõik unistavad sellest läbi minna! Jah, täpselt 4 tundi.
iroonia režiim: välja

Kui on olemas loetelu kõigest, mida võiks kontrollida, siis peamine on seda mitte teha (esmapilgul kõlab see kummalisena, eks?). Tuleb halastamatult kärpida, tuues välja koos ekspertidega olulised teadmised ja oskused (jah, mitmeid oskusi saab ka testis kontrollida). Vaatame ülesannete tüüpe ja arvutame sihtajaga täitmist: kui aeg ületab mõistlikud piirid — kärpige!

Koguse vähendamiseks võib proovida (õrnalt) ühe ülesande kaudu kontrollida kahte oskust. Sel juhul on keeruline mõista, miks inimene eksis, kuid õigesti sooritades saab arvesse võtta mõlemaid oskusi. On oluline veenduda, et need 2 oskust kuuluvad ühte teadmiste valdkonda.

Pettus 6: Punktisüsteemi väljatöötamise ignoreerimine

Tihti, kui koostame hindamiskatseid, kasutame klassikalist hindamissüsteemi punktide jagamisel, näiteks 1 punkt kergete ülesannete eest ja 2 punkti keerukamate ülesannete eest. Kuid see ei ole universaalne. Lihtsalt punktide summa testimise tulemuste põhjal ei ütle meile palju: me ei tea, milliste ülesannete eest need punktid on saadud ja saame määrata vaid korrektsete ülesannete arvu. Meil on vajalik täpne arusaam, milliseid konkreetseid oskusi testi osalejad demonstreerivad. Lisaks soovime anda neile tagasisidet, milliseid teemasid tuleks rohkem arendada.

Kuna teeme testi, mis jagab inimesi valmis ja mittevalmis programmiga edasi minema, on mõnel inimesel soovitus valmistuda tasuta koolituseks. Meie jaoks on oluline, et sellesse rühma kuuluksid ainult need, kellele see tõeliselt vajalik on ja kes on valmis.

Mida me selles olukorras teeme: määratleme testiarendajate töörühmas, milliseid inimesi on vaja eristada (näiteks need, kes on õppimiseks valmis, osaliselt valmis) ja vormime nende gruppide omaduste tabeli, märkides ära, millised oskused ja teadmised on aktuaalsed õppimisvalmis gruppide jaoks. Nii saab moodustada selliste testide ülesannete "keerukuse".

Küsimused 7: Hindame tulemusi ainult automaatselt

Muidugi peab hindamine olema võimalikult objektiivne, seega hinnatakse osa üliõpilaste materjalidest automaatselt, "võtmete" alusel - võrreldes võimalike õigete vastustega. Isegi kui pole spetsiaalset testimissüsteemi, leidub palju tasuta lahendusi. Ja kui on arusaam skriptide kirjutamise printsiipidest, siis Google'i vormide ja tabelite tulemuste abil saab teha mida iganes. Kui osa ülesandeid hindavad eksperdid, peame hoolikalt läbima, kuidas toimetada ekspertidele vastuseid, ilma teabeta neile, kes vastasid. Ja mõtlema, kuidas integreerida ekspertide kontrolli tulemused lõpphindamisse.

Me algasime teha mitmeid avatud ülesandeid koodiga, kui eksperdid hindavad lahendusi eelnevalt kindlaksmääratud kriteeriumide alusel, ja isegi valmistasime ette süsteemi, mis eksportib testimise osalejate eraldi vastused spetsiaalsesse tabelisse ekspertidele ning siis impordib tulemused hindamistabelisse. Kuid pärast arutelusid sihtrühma esindajate, tootjajuhiga ja õpikujundajaga leidsime, et tehnilise intervjuu läbi viimine koos eksperdi kohese tagasisidega ja koodi ning individuaalsete küsimuste arutamine oleks palju tõhusam ja kasulikum osalejatele endile.

Nüüd kinnitab ekspert testi edukust, täpsustades teatud küsimusi. Selleks oleme koostanud küsimuste juhendi ja hindamiskriteeriumid tehniliseks intervjueerimiseks. Enne tehnilist intervjuud saab ekspert osaleja vastuste kaardi, et valida välja küsimused, mida küsida.

Kübarad 8: Testitulemusi mitte seletada

Tagasiside andmine osalejatele on eraldi teema. Me peame mitte ainult teavitama testide tulemustest, vaid ka selgitama nende tulemuste sisu.
Need võivad olla: 

  • Ülesanded, kus osaleja eksis, kuid need, mida ta õigesti sooritas.
  • Teemad, mille osas osaleja tegi vigu.
  • Tema reiting eksamit sooritanute seas.
  • Osaleja taseme kirjeldus, vastavalt näiteks spetsialistide taseme kirjeldusele (tuginedes töökuulutustele).

Meie testi pilotprojekti käigus näitasime programmiga liituda soovijatele koos tulemustega ka nimekirja teemadest, mida tuleks täiustada. Kuid see pole muidugi ideaalne, me püüame pidevalt täiustuda ja tagasisidet paremaks muuta.

Pettumuse põhjused 9: Testi mitte arutada arendajatega.

Võib-olla on need kõige teravamad pettumuse põhjused, millele jalgade alla astumine on eriti ebameeldiv — saata arendajatele test, kirjeldus ja hindamiskaala seisundis «nagu on».
Mis vajab arutelu:

  • Küsimuste välimus, struktuur, graafika paigutus, kuidas näeb välja õige vastuse valik.
  • Kuidas punktide arvutamine käib (kui see on vajalik), kas ei ole täiendavaid tingimusi.
  • Kuidas tagasisidet kujundatakse, kust võtta tekste, ega ole lisaks automaatselt genereeritud blokke.
  • Milliseid lisainformatsioone peate koguma ja millal (samad kontaktid).

Arusaamatuste vältimiseks palume meie arendajatel kodeerida 2 või 3 erinevat küsimust, et saaksime enne testi programmeerimist näha, kuidas need välja näevad.

Kähmlus 10: Testimata, otse tootmisse laadimine.

Kolm korda, poisid, test peab olema kolme erineva inimese poolt kontrollitud, veel parem — igaühe poolt kolm korda. See tõde on välja teenitud vere, higi ja koodi pikslitega.

Meie test kontrollib sellist triaadi:

  1. Tootjad — kontrollivad testi funktsionaalsust, välimust ja mehhanisme.
  2. Testi arendaja — kontrollib ülesannete tekste, nende järjekorda, tööviisi, ülesannete tüüpe, õigeid vastuseid, loetavust ja graafika normaalset vaatamist.
  3. Ülesannete autor (ekspert) — kontrollib testi õigsust eksperdi seisukohalt.

Näide praktikaalalt: alles kolmandal korral, kui autor ülesandeid jooksutas, märkas ta, et 1 ülesanne jäi vana sõnastuse varianti. Kõiki eelnevaid muudeti aktiivselt. Kuid kui test kodeeriti, tundus see teisiti, kui alguses ette kujutati. Suure tõenäosusega peab midagi muutma. Seda tuleb arvesse võtta.

Kokkuvõte

Kavalalt vältides kõiki neid „langeb”, lõime me eraldi Telegrami boti, et kontrollida sisseastujate teadmisi. Igaüks, kes soovib, saab seda testida, kui me valmistame ette järgmist materjali, milles räägime, mis toimus boti sees ja kuidas see kõik hiljem teisteks muutus.

Mugavus: 10 kriitilist testi arenduse viga teadmiste kontrollimiseks
Saada endale nõutav amet nullist või Level Up oskustes ja palgas, läbides SkillFactory veebikursuseid:

Rohkem kursusi

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster