A new course in Advanced Machine Learning requires us to test prospective students to determine their readiness and understand what they need to prepare for the course. However, there is a dilemma: on one hand, we need to check their knowledge in Data Science, and on the other, we cannot conduct a full 4-hour exam.
To tackle this issue, we have set up a TestDev team right within the Data Science course development team (and it seems this is just the beginning). Here’s a list of 10 'pitfalls' encountered when creating tests for assessing knowledge. We hope that the world of online education will become a little better after this.
Pitfall 1: Not clearly defining the testing objectives
To effectively define the objectives and create a test that reflects them, we must answer several questions during the planning phase:
- What exactly are we testing?
- In what environment will the testing take place and what mechanics will be used? What limitations exist in this environment? This point will also help to understand the technical requirements for the device used for testing, as well as for the content (if the test is taken on phones, images should be readable even on small screens, there should be an option to enlarge them, etc.).
- How long will the testing take? We need to consider the conditions under which the user will take the test. Is it possible that the user will need to interrupt the testing process and continue later?
- Will there be feedback? How do we formulate and deliver it? What is needed to obtain feedback? Is there a time gap between completing the test and receiving feedback?
In our case, by answering these questions, we defined the following objectives for the test:
- The test must show whether prospective students are ready for the course, and if they possess sufficient knowledge and skills.
- The test should provide us with material for feedback, indicating the topic where students made mistakes, allowing them to enhance their knowledge. We will explain how to construct it further.
Pitfall 2: Not creating a specification for the expert — the test compiler
A tesztfeladatok összeállításához elengedhetetlen, hogy bevonjunk egy szakértőt abban a területen, amelynek tudását tesztáljuk. Azért a szakértőnek meg kell kapnia a megfelelő műszaki leírást, amely tartalmazza a teszt témáit, a tesztelt tudásokat/skill-eket és azok szintjét.
A szakértő nem fog ilyen műszaki leírást készíteni magának, hiszen az ő feladata a feladatok kitalálása, nem a teszt struktúrája. Főleg, hogy eddig még kevés ember foglalkozik szakmai tesztek kidolgozásával, még a tanítási folyamat során sem. Erre külön szakirányban oktatnak — pszichometria.
Ha gyorsan szeretnél megismerkedni a pszichometriával, Oroszországban van minden érdeklődő számára. A mélyebb tanulmányokhoz az Oktatási Intézetben van és doktori program.
A műszaki leírás készítésekor részletes leírást gyűjtünk össze a tesztről a szakértő számára (még jobb, ha vele együtt): a feladatok témái, a feladatok típusa, azok mennyisége.
Hogyan válasszuk ki a feladatok típusát: miután meghatároztuk a témákat, eldöntjük, hogy mely feladatokkal lehet ezt a legjobban ellenőrizni? A klasszikus lehetőségek: nyílt végű feladat, többválasztós vagy egyválasztós feladat, megfeleltetés, stb. (ne felejtsük el a tesztelés környezetének technikai korlátait!). A feladatok típusa miután meghatározásra és leírásra került, készen áll a műszaki leírás a szakértő számára. Ezt a dokumentumot teszt specifikációnak is nevezhetjük.
Buktatók 3: Nem bevonni a szakértőt a teszt kidolgozásába
A szakértő teszt kidolgozásába való bevonásakor rendkívül fontos, hogy ne csupán a "munkamennyiséget" határozzuk meg számára, hanem bevonjuk őt magába a fejlesztési folyamatba.
Hogyan tegyük a szakértővel való munkát a lehető leghatékonyabbá:
- Előre felkészíteni őt és időt szánni a tesztfejlesztés tudományáról, pszichometriáról való beszélgetésre.
- A szakértő figyelmét a valid és megbízható értékelési eszköz létrehozására összpontosítani, nem pedig kérdések listájára.
- Elmagyarázni, hogy a munkája magában foglalja az előkészítési szakaszt, nem csupán a feladatok fejlesztését.
Néhány szakértő (a személyiségük miatt) ezt úgy értelmezheti, mint saját munkájuk ellenőrzését, és nekik azt magyarázzuk el, hogy még ha kiváló feladatokat is készítenek, ezek egyszerűen nem illeszkedhetnek a tesztelés konkrét céljaihoz.
Ahhoz, hogy a folyamat gyorsan zajlódjon, egy szakértővel elkészítjük a tudás és készségek lefedettségi táblázatát, amely a vizsga specifikációjának része. Ez a táblázat lehetővé teszi számunkra, hogy pontosan kidolgozzuk a kérdéseket, és meghatározzuk, mit fogunk mérni. Minden egyes esetben ez kicsit eltérő módon is megfogalmazható. A mi feladatunk: ellenőrizni, hogy az adott személy mennyire tájékozott a korábbi, alapvető kurzusok tudása és készségei terén, hogy megértsük, mennyire van felkészülve az új kurzusra.
Csapda 4: Azt gondolni, hogy a szakértő "jobban tudja"
Jobban ismeri a tantárgyat. De nem mindig magyaráz világosan. Nagyon fontos ellenőrizni a feladatok megfogalmazását. Írjunk érthető utasításokat, például: "Válassza az 1 helyes választ". A szakértők 90%-a úgy készíti a kérdéseket, ahogy neki magának érthető. És ez rendben van. De mielőtt a tesztet átadnánk annak, aki elvégzi, mindent ellenőrizni és rendezni kell, hogy azok, akik a tesztet végzik, pontosan értsék, mi van a kérdésben, és ne vétsenek hibát csupán amiatt, mert félreértelmezték a feladat szövegét.
A kettős értelmezés elkerülése érdekében "kognitív laborokat" tartunk. Megkérjük a célcsoport tagjait, hogy végezzék el a tesztet, miközben hangosan kifejtik, mit gondolnak, és ezt részletesen rögzítjük. A "kognitív laborokban" könnyen észlelhetők a zavaros kérdések, a rossz megfogalmazások, és elsődleges visszajelzést kaphatunk a teszt eredményeiről.
Csapda 5: Figyelmen kívül hagyni a teszt végrehajtásához szükséges időt
sarcasm mode: on
Természetesen a mi tesztünk a legjobb, mindenki álma, hogy elvégezze! Igen, négy órán át.
sarcasm mode: off
Ha van egy listánk arról, hogy mit lehet ellenőrizni, a legfontosabb, hogy ezt ne tegyük (első pillantásra furcsának tűnik, nem igaz?). Kíméletlenül vágnunk kell, kiemelve a szakértővel a kulcsfontosságú tudásokat és készségeket (igaz, hogy egyes készségeket is tesztelni lehet). Megvizsgáljuk a feladatok típusát, és megbecsüljük a várható elvégzési időt: ha még mindig túllépjük a racionális határokat — vágjunk!
A terjedelem csökkentése érdekében próbálkozhatunk azzal is, hogy egy feladattal két készséget ellenőrzünk (óvatosan). Ebben az esetben nehéz megérteni, miért hibázott valaki, de ha helyesen végrehajtja, akkor mindkét készség figyelembe vehető. Fontos biztosítani, hogy ezek a két készség egy tudásterülethez tartozzon.
Csapda 6: Nem átgondolni a pontozási rendszer kialakítását
Gyakran, amikor tesztértékelést készítünk, klasszikus pontozási rendszert használunk, például 1 pont az egyszerű feladatokért és 2 pont a nehezekért. De ez nem univerzális. Egyszerűen az összesített pontszám a tesztelés végén nem sokat mond nekünk: nem tudjuk, mely feladatokért kaptuk ezeket a pontokat, és csak a helyes feladatok számát tudjuk meghatározni. Pontos megértésre van szükségünk arról, hogy a tesztelők pontosan milyen készségeket mutatnak be. Ezenkívül szeretnénk visszajelzést adni nekik arról, hogy mely témákat kell még dolgozniuk.
Hiszen olyan tesztet végzünk, amely az embereket a program folytatására készültekre és nem készültekre osztja, néhányuknak javasolni fogjuk, hogy készüljenek fel a kurzusra ingyenes képzés keretében. Fontos számunkra, hogy csak azok kerüljenek ebbe a csoportba, akiknek tényleg szükségük van rá, és akik készen állnak erre.
A mi helyzetünkben: a teszt fejlesztői munkacsoporton belül meghatározzuk, hogy mely csoportokat kell kiemelnünk (például felkészült, részben felkészült), és létrehozunk egy táblázatot ezen csoportok jellemzőivel, megadva, hogy mely készségek és tudások relevánsak a felkészült csoport számára. Így lehet kialakítani a hasonló tesztek feladatainak "nehézségét".
Hiba 7: Csak automatikusan értékelni az eredményeket
Természetesen az értékelésnek a lehető legobjektívebbnek kell lennie, ezért a diákok egyes anyagait automatikusan, "kulcsok" alapján értékeljük — a helyes válaszokkal összehasonlítva. Még ha nincs is speciális tesztelési rendszer, számos ingyenes megoldás létezik. Ha pedig van elképzelés a szkriptek írásának alapelveiről, a Google űrlapokkal és az eredmények táblázatokba történő importálásával bármit meg lehet valósítani. Ha a feladatok egy részét szakértők ellenőrzik, akkor meg kell fontolnunk a szakértőknek az válaszok átadását, anélkül, hogy információt adunk a vizsgázókról. És gondolkoznunk kell azon, hogyan integrálhatjuk a szakértők ellenőrzésének eredményeit a végső értékelésbe.
Kezdetben azt terveztük, hogy néhány nyitott feladatot készítünk kód alapján, ahol a szakértők előre meghatározott kritériumok szerint értékelik a megoldásokat, és még egy rendszert is készítettünk, amely exportálja a teszt résztvevőinek egyes válaszait egy külön táblázatba a szakértőknek, majd importálja az eredményeket egy értékelési táblázatba. Azonban a célcsoport képviselőivel, a termékmenedzserrel és az oktatási tervezővel folytatott megbeszélések után úgy ítéltük meg, hogy a technikai interjú az azonnali szakértői visszajelzéssel és a kód, valamint egyes kérdések megbeszélésével sokkal hatékonyabb és hasznosabb lesz a résztvevők számára.
Most a szakértő ellenőrzi a teszt teljesítményét, pontosítva néhány kérdést. Ehhez elkészítettünk egy kérdéslistát, valamint értékelési kritériumokat a technikai interjúhoz. A technikai interjú előtt a szakértő megkapja a teszt résztvevő válaszainak térképét, hogy választhasson olyan kérdéseket, amelyeket érdemes feltenni.
Hiba 8: Nem magyarázni a tesztelési eredményeket
A visszajelzés bemutatása a résztvevőknek egy külön kérdés. Nemcsak a teszteredményt kell közölni, hanem meg is kell érteni a teszt eredményeit.
Ezek lehetnek:
- Azok a feladatok, amelyekben a résztvevő hibázott, de helyesen végezte el őket.
- Azok a témák, amelyekben a résztvevő hibázott.
- A résztvevő rangsora a vizsgázók között.
- A résztvevő szintjének leírása, például a szakemberek szintleírása alapján (a munkaköri leírások szerint).
A tesztünk pilótaindításakor azok számára, akik jelentkezni kívántak a programra, a teszteredményekkel együtt megmutattuk a listát azokról a témákról, amelyeken érdemes lenne javítani. De ez persze nem az ideális megoldás, folyamatosan fejlődni fogunk és javítjuk a visszajelzést.
Hiba 9: Nem beszélni a tesztről a fejlesztőkkel
Talán a legkényesebb hibák, amelyekre különösen kellemetlen rálépni - a teszt, a leírás és a számítási skála „ahogy van” állapotban elküldése a fejlesztőknek.
Mi az, ami valóban megvitatásra szorul:
- A kérdések megjelenése, struktúrája, a grafikák elhelyezése, hogyan néz ki a helyes válasz kiválasztása.
- Hogyan számolják a pontot (ha szükséges), nincsenek-e további feltételek.
- Hogyan alakul a visszajelzés, honnan szerezhetők be a szövegek, nincsenek-e automatikusan kialakuló blokkok.
- Milyen kiegészítő információt kell összegyűjteni, és mikor (ugyanazok a kapcsolattartók).
A félreértések elkerülése érdekében arra kérjük fejlesztőinket, hogy kódoljanak 2 vagy 3 különböző kérdést, hogy megnézhessük, hogyan néznek ki a teszt programozása előtt.
Görbe 10: Azonnal a produkcióba helyezés tesztelés nélkül
Háromszor, srácok, a tesztet három különböző embernek kell ellenőriznie, de jobb, ha mindegyik legalább háromszor átnézi. Ez az igazság vérrel, verejtékkel és a kód sorain keresztül született.
A tesztünket három szereplő ellenőrzi:
- A termékmenedzser — ellenőrzi a teszt működését, megjelenését és mechanikáját.
- A teszt fejlesztője — ellenőrzi a feladatok szövegét, sorrendjét, a teszt kezelésének formáját, a feladat típusait, helyes válaszokat, olvashatóságot és a grafika normális megjelenését.
- A feladatok szerzője (szakértő) — a szakmai szempontból ellenőrzi a teszt helyességét.
Gyakorlati példa: csak a harmadik áttanulmányozás során a feladatok szerzője vette észre, hogy egy feladat a régi megfogalmazásban maradt. Az összes korábbi feladatot is aktívan módosították. De amikor a tesztet kódolták, másképp nézett ki, mint ahogy eredetileg elképzelték. Nagy valószínűséggel valamit módosítani kell. Ezt figyelembe kell venni.
Result
Óvatosan megkerülve ezeket a "görbéket", létrehoztunk egy speciális , hogy ellenőrizzük a felvételizők tudását. Bárki tesztelheti, míg előkészítjük a következő anyagot, amelyben elmondjuk, mi történt a bot belsejében, és hogyan alakult ez azután.
Szerezzen keresett szakmát a nulláról vagy fejlessze készségeit és bérét online kurzusokkal a SkillFactory-n:
- (12 hét)
- (20 hét)
- (20 hét)
- (12 hónap)
További kurzusok
- (12 hónap)
- (14 hét)
- (5 hét)
- (18 hónap)
- (6 hónap)
- (12 hónap)
- (8 hónap)
- (9 hónap)
- (12 hónap)
- (18 hónap)
- (18 hónap)
- (12 hónap)
- (9 hónap)
- (7 hónap)
Forrás: habr.com
