Voordat we ons inschrijven voor de nieuwe Machine Learning Advanced-cursus, testen we potentiële studenten om hun gereedheidsniveau te bepalen en te begrijpen wat ze precies moeten bieden om zich voor te bereiden op de cursus. Maar er ontstaat een dilemma: aan de ene kant moeten we de kennis in Data Science testen, aan de andere kant kunnen we geen volwaardig examen van 4 uur regelen.
Om dit probleem op te lossen, hebben we een TestDev-hoofdkantoor geïmplementeerd in het Data Science-cursusontwikkelingsteam (en het lijkt erop dat dit nog maar het begin is). We presenteren u een lijst met 10 valkuilen die u tegenkomt bij het ontwikkelen van tests om kennis te beoordelen. Hopelijk zal de wereld van online leren hierna een beetje beter zijn.
Rake 1: Het niet duidelijk definiëren van testdoelen
Om doelen correct te definiëren en een test te maken waarmee hiermee rekening wordt gehouden, moeten we in de planningsfase verschillende vragen beantwoorden:
- Wat controleren we eigenlijk?
- In welke omgeving zal het testen plaatsvinden en welke mechanismen worden gebruikt? Wat zijn de beperkingen in deze omgeving? Ditzelfde punt zal u in staat stellen de technische vereisten te begrijpen voor het apparaat waarop de tests zullen worden uitgevoerd, en ook voor de inhoud (als de test vanaf telefoons wordt genomen, moeten de afbeeldingen zelfs op een klein scherm leesbaar zijn, het zou moeten zijn mogelijk zijn om ze te vergroten, enz.).
- Hoe lang duurt het testen? U moet nadenken over de omstandigheden waaronder de gebruiker de test zal afleggen. Kan er een situatie ontstaan waarin hij het testproces moet onderbreken en vervolgens opnieuw moet doorgaan?
- Zal er feedback zijn? Hoe vormen en leveren we het? Wat moet je ontvangen? Is er een tijdsverschil tussen de uitvoering van de test en de feedback?
In ons geval hebben we, nadat we deze vragen hadden beantwoord, de volgende lijst met doelen voor de test gedefinieerd:
- Uit de toets moet blijken of toekomstige studenten klaar zijn om de cursus te volgen en of ze over voldoende kennis en vaardigheden beschikken.
- De toets moet ons materiaal voor feedback opleveren, aangeven op welk onderwerp leerlingen een fout hebben gemaakt, zodat ze hun kennis kunnen verbeteren. Hoe je het samenstelt, vertellen we je hieronder.
Rake 2: Het niet opstellen van technische specificaties voor de deskundige testschrijver
Voor het samenstellen van toetsitems is het van groot belang om een deskundige te betrekken op het terrein waarop kennis wordt getoetst. En voor een expert heb je op zijn beurt een competente technische specificatie (beschrijving) nodig, waarin de onderwerpen van de test, de kennis/vaardigheden die worden getest en het niveau ervan zijn opgenomen.
Een expert zal dergelijke technische specificaties niet voor zichzelf opstellen, omdat het zijn taak is om taken te bedenken, niet de structuur van de test. Bovendien ontwikkelen maar weinig mensen professioneel tests, zelfs niet tijdens het lesgeven. Dit wordt onderwezen in een aparte specialiteit: psychometrie.
Als je snel kennis wilt maken met psychometrie, dan is dat in Rusland het geval voor alle geïnteresseerden. Voor meer diepgaande studie heeft het Institute of Education en graduateschool.
Bij het opstellen van de technische specificaties verzamelen we een gedetailleerde beschrijving van de test voor de expert (of beter, samen met hem): onderwerpen van taken, soort taken, hun aantal.
Hoe het soort taken kiezen: nadat we de onderwerpen hebben bepaald, beslissen we welke taken dit het beste kunnen testen? Klassieke opties: taak met open einde, taak met meerdere of enkele keuze, matching, etc. (vergeet de technische beperkingen van de testomgeving niet!). Na het bepalen en specificeren van het soort werkzaamheden hebben wij een kant-en-klare technische specificatie voor de expert. Je kunt het een testspecificatie noemen.
Rake 3: Geen expert betrekken bij testontwikkeling
Bij het onderdompelen van een expert in testontwikkeling is het erg belangrijk om hem niet alleen de “werkomvang” aan te geven, maar hem ook te betrekken bij het ontwikkelingsproces zelf.
Zo maak je de samenwerking met een expert zo effectief mogelijk:
- Zet het van tevoren op en besteed wat tijd aan het praten over de wetenschap van testontwikkeling en psychometrie.
- Richt de aandacht van de beoordelaar op het creëren van een valide en betrouwbaar beoordelingsinstrument, niet op een lijst met vragen.
- Leg uit dat zijn werk een voorbereidende fase omvat, en niet alleen de ontwikkeling van de taken zelf.
Sommige experts kunnen dit (vanwege hun aard) beschouwen als een test van hun eigen werk, en we leggen hen uit dat zelfs als we uitstekende taken creëren, deze eenvoudigweg niet passen bij de specifieke testdoelen.
Om het proces snel te laten verlopen, stellen wij samen met de expert een tabel met onderwerpdekking (kennis en vaardigheden) op, die deel uitmaakt van de testspecificatie. Dankzij deze tabel kunnen we de vragen nauwkeurig uitwerken en bepalen wat we gaan meten. In elk specifiek geval kan het net iets anders worden samengesteld. Het is onze taak om te controleren hoe goed iemand de kennis en vaardigheden van eerdere basiscursussen begrijpt, om te begrijpen hoe klaar hij is om in een nieuwe cursus te studeren.
Rake 4: Denken dat de expert ‘het het beste weet’
Kent het onderwerp beter. Maar het wordt niet altijd duidelijk uitgelegd. Het is erg belangrijk om de formulering van de opdrachten te controleren. Schrijf duidelijke instructies, bijvoorbeeld: ‘Kies 1 juiste optie.’ In 90% van de gevallen bereiden experts vragen voor op een manier die zij zelf begrijpen. En dat is oké. Maar voordat de test wordt overhandigd aan degenen die hem willen afleggen, moet alles worden gecontroleerd en uitgekamd, zodat de mensen die de test afleggen precies begrijpen wat er van hen wordt verlangd en geen fouten maken alleen maar omdat ze de tekst van de taak verkeerd kunnen interpreteren.
Om dubbele interpretatie van taken te voorkomen, voeren we ‘cognitieve laboratoria’ uit. We vragen mensen uit de doelgroep om de test te doen, waarbij we hardop zeggen wat ze ervan vinden en dit tot in detail vastleggen. Bij ‘cognitieve laboratoria’ kun je onduidelijke vragen en slechte bewoordingen ‘vangen’ en de eerste feedback op de test krijgen.
Rake 5: Negeer de uitvoeringstijd van de test
sarcasmemodus: aan
Onze test is natuurlijk de beste, iedereen droomt ervan om deze te halen! Ja, alle 4 uur.
sarcasmemodus: uit
Als er een lijst is met alles wat kan worden gecontroleerd, is het belangrijkste om dit niet te doen (op het eerste gezicht klinkt het vreemd, nietwaar?). Je moet meedogenloos knippen en samen met een expert de belangrijkste kennis en vaardigheden identificeren (ja, een aantal vaardigheden kan ook worden getest in de test). We kijken naar het soort taken en schatten de beoogde voltooiingstijd in: als alles nog steeds boven redelijke grenzen ligt, snijden we deze!
Om het volume te verminderen, kun je ook proberen twee vaardigheden (voorzichtig) in één taak te testen. In dit geval is het moeilijk te begrijpen waarom de persoon een fout heeft gemaakt, maar als het correct wordt gedaan, kan met beide vaardigheden rekening worden gehouden. Het is belangrijk om ervoor te zorgen dat deze 2 vaardigheden overeenkomen met hetzelfde kennisgebied.
Rake 6: Niet nadenken over het scoresysteem
Bij het samenstellen van beoordelingstoetsen gebruiken ze vaak het klassieke scoresysteem, bijvoorbeeld 1 punt voor gemakkelijke taken en 2 punten voor moeilijke taken. Maar het is niet universeel. Alleen de som van de punten op basis van de testresultaten zal ons niet veel vertellen: we weten niet voor welke taken deze punten zijn ontvangen en we kunnen alleen het aantal correcte taken bepalen. We moeten precies begrijpen welke vaardigheden de kandidaten laten zien. Daarnaast willen we hen feedback geven over welke onderwerpen verbeterd moeten worden.
We doen tenslotte een test die mensen zal verdelen in degenen die er klaar voor zijn en degenen die er nog niet klaar voor zijn om het programma te voltooien; we zullen sommigen adviseren om zich voor te bereiden op de cursus door middel van gratis training. Voor ons is het belangrijk dat deze groep alleen bestaat uit degenen die het echt nodig hebben en er klaar voor zijn.
Wat wij in onze situatie doen: we bepalen binnen de werkgroep van testontwikkelaars welke groepen mensen geïdentificeerd moeten worden (bijvoorbeeld leerklaar, deels klaar) en stellen een tabel op met kenmerken van zulke groepen, waarin wordt aangegeven welke vaardigheden en kennis zal relevant zijn voor de groep klaar-om-te-leren-trainingen. Op deze manier kun je de “moeilijkheidsgraad” van taken voor dergelijke tests formuleren.
Rake 7: Evalueer de resultaten alleen automatisch
Uiteraard moet de beoordeling zo objectief mogelijk zijn, dus een deel van de leerstof van de leerling wordt automatisch beoordeeld, “aan de hand van sleutels” – vergeleken met de juiste antwoorden. Zelfs als er geen speciaal testsysteem is, zijn er voldoende gratis oplossingen. En als u de principes van het schrijven van scripts begrijpt, kunt u doen wat u wilt met Google-formulieren en resultaten in tabellen. Als sommige taken door experts worden gecontroleerd, moeten we erover nadenken om antwoorden aan de experts te geven, zonder informatie over de testpersonen. En denk na over hoe je de uitkomsten van experttesten kunt integreren in de eindbeoordeling.
We wilden aanvankelijk verschillende taken met een open einde maken met code, waarbij experts oplossingen evalueren op basis van vooraf opgestelde criteria. We hebben zelfs een systeem voorbereid dat individuele antwoorden van testdeelnemers exporteert naar een speciale tabel voor experts, en vervolgens de resultaten importeert in een tabel met beoordelingsberekeningen. Maar na overleg met vertegenwoordigers van de doelgroep, productmanager en onderwijsontwerper waren we van mening dat het houden van een technisch interview met onmiddellijke feedback van experts en het bespreken van de code, evenals individuele kwesties, veel effectiever en nuttiger zou zijn voor de deelnemers zelf. .
Nu verifieert de expert de voltooiing van de test en verduidelijkt enkele vragen. Om dit te doen, hebben we een gids met vragen en beoordelingscriteria voor een technisch interview opgesteld. Vóór het technische interview ontvangt de examinator een kaart met de antwoorden van de testpersoon, zodat hij de vragen kan selecteren die hij wil stellen.
Hark 8: Verklaar de testresultaten niet
Het geven van feedback aan deelnemers is een vak apart. We moeten niet alleen informeren over de testscore, maar ook inzicht geven in de testresultaten.
Het kan:
- Taken waarbij de deelnemer een fout heeft gemaakt en die hij correct heeft uitgevoerd.
- Onderwerpen waarin de deelnemer fouten heeft gemaakt.
- Zijn rangschikking onder degenen die het examen afleggen.
- Beschrijving van het niveau van de deelnemer, conform bijvoorbeeld de beschrijving van het specialistische niveau (op basis van de omschrijving van vacatures).
Tijdens de pilotlancering van onze test hebben we aan degenen die zich wilden inschrijven voor het programma, samen met de resultaten, een lijst met onderwerpen laten zien die verbeterd moesten worden. Maar ideaal is dit zeker niet, wij gaan verbeteren en betere feedback geven.
Rake 9: Bespreek de test niet met ontwikkelaars
Misschien wel de scherpste hark, die vooral onaangenaam is om op te stappen, is om de test, beschrijving en scoreschaal “as is” naar de ontwikkelaars te sturen.
Wat moet er precies besproken worden:
- Het uiterlijk van de vragen, de structuur, de positie van de afbeeldingen, hoe de keuze van het juiste antwoord eruit ziet.
- Hoe wordt de score berekend (indien nodig), zijn er aanvullende voorwaarden?
- Hoe wordt feedback gegenereerd, waar kun je teksten krijgen, zijn er extra automatisch gegenereerde blokken.
- Welke aanvullende informatie moet u verzamelen en op welk moment (dezelfde contacten).
Om misverstanden te voorkomen, vragen we onze ontwikkelaars om 2 of 3 verschillende vragen te coderen, zodat ze kunnen zien hoe ze eruit zien voordat ze de test zelf coderen.
Rake 10: Zonder testen direct uploaden naar productie
Drie keer, jongens, de test zou drie keer door verschillende mensen moeten worden gecontroleerd, of beter nog, elk drie keer. Deze waarheid werd verkregen met bloed, zweet en pixels van regels code.
Onze test controleert het volgende trio:
- Product - controleert de test op prestaties, uiterlijk, mechanica.
- Testontwikkelaar - controleert de tekst van de taken, hun volgorde, de manier waarop met de test wordt gewerkt, soorten taken, correcte antwoorden, leesbaarheid en normale weergave van afbeeldingen.
- De auteur van de taken (expert) controleert de test op betrouwbaarheid vanuit een expertpositie.
Een voorbeeld uit de praktijk: pas bij de derde run zag de auteur van de taken dat 1 taak in de oude versie van de formulering bleef. Alle voorgaande regeerden ook actief. Maar toen de test werd gecodeerd, zag deze er anders uit dan aanvankelijk gedacht. De kans is groot dat er iets gecorrigeerd moet worden. Hiermee moet rekening worden gehouden.
Totaal
Door al deze “harken” zorgvuldig te omzeilen, hebben we een special gemaakt , om de kennis van aanvragers te testen. Iedereen kan het testen terwijl we het volgende materiaal voorbereiden, waarin we je zullen vertellen wat er in de bot is gebeurd en waar het later allemaal in is veranderd.
U kunt een gewild beroep helemaal opnieuw opbouwen of een hoger niveau bereiken in termen van vaardigheden en salaris door de online cursussen van SkillFactory te volgen:
- (12 weken)
- (20 weken)
- (20 weken)
- (12 maanden)
Meer cursussen
- (12 maanden)
- (14 weken)
- (5 weken)
- (18 maanden)
- (6 maanden)
- (12 maanden)
- (8 maanden)
- (9 maanden)
- (12 maanden)
- (18 maanden)
- (18 maanden)
- (12 maanden)
- (9 maanden)
- (7 maanden)
Bron: www.habr.com