Voordat we studenten inschrijven voor de nieuwe cursus Machine Learning Advanced, testen we hen om hun vaardigheidsniveau vast te stellen en te begrijpen wat we hen moeten aanbieden ter voorbereiding op de cursus. Maar er ontstaat een dilemma: aan de ene kant moeten we kennis van Data Science beoordelen, aan de andere kant kunnen we geen uitgebreide vier uur durende examen organiseren.
Om dit probleem op te lossen, hebben we een TestDev-team opgezet binnen het team dat verantwoordelijk is voor de ontwikkeling van cursussen Data Science (en het lijkt erop dat dit nog maar het begin is). Hier is een lijst van 10 āhobbelsā waarop men kan stuiten bij het ontwikkelen van tests voor kennisbeoordeling. We hopen dat de wereld van online onderwijs hierdoor een beetje beter wordt.
Hobbel 1: Geen duidelijke doelen voor de testbepaling vaststellen
Om de doelen goed vast te stellen en een test samen te stellen die deze gebruikt, moeten we ons tijdens de planningsfase een aantal vragen stellen:
- Wat controleren we precies?Ā
- In welke omgeving zal de test plaatsvinden en welke mechanismen worden gebruikt? Wat zijn de beperkingen in deze omgeving? Dit punt helpt ons ook de technische vereisten voor het apparaat waarop de test zal plaatsvinden vast te stellen, evenals de inhoud (als de test op telefoons wordt afgenomen, moeten de afbeeldingen ook op een klein scherm leesbaar zijn, moet er een mogelijkheid zijn om ze te vergroten, enzovoort).
- Hoeveel tijd zal de test in beslag nemen? We moeten nadenken over de omstandigheden waaronder de gebruiker de test zal afleggen. Kan er een situatie ontstaan waarin hij het testproces moet onderbreken en later moet voortzetten?
- Zal er feedback zijn? Hoe wordt deze geformuleerd en geleverd? Wat is er voor nodig om feedback te ontvangen? Is er een tijdsverschil tussen het voltooien van de test en de feedback?
In ons geval hebben we, door deze vragen te beantwoorden, voor de test de volgende doelen vastgesteld:
- De test moet aantonen of de studenten klaar zijn voor de cursus en of ze over voldoende kennis en vaardigheden beschikken.
- De test moet ons materiaal voor feedback geven, de onderwerpen aanwijzen waarin studenten fouten hebben gemaakt, zodat ze hun kennis kunnen verbeteren. Hoe we dit opstellen, komt hierna aan bod.
Hobbel 2: Geen specificatie opstellen voor de expert - testontwikkelaar
Voor het opstellen van testopdrachten is het zeer belangrijk om een expert in het betreffende vakgebied te betrekken, wiens kennis wordt getoetst. En voor de expert is een goed opgesteld technisch verslag (beschrijving) nodig, waarin de onderwerpen van de test, de te toetsen kennis/vaardigheden en hun niveau zijn opgenomen.
Een expert zal zo'n technisch verslag niet zelf opstellen, omdat zijn taak is om opdrachten te verzinnen, en niet om de structuur van de test te bepalen. Bovendien ontwikkelt nog maar weinig mensen professioneel tests, zelfs niet in het onderwijs. Dit wordt onderwezen in een aparte specialisatie - psychometrie.
Als je snel wilt kennismaken met psychometrie, dan is er in Rusland voor iedereen die geĆÆnteresseerd is. Voor een diepgaandere studie zijn er aan het Instituut voor Onderwijs en promotietrainingen.
Bij het opstellen van het technisch verslag verzamelen we een gedetailleerde beschrijving van de test voor de expert (nog beter samen met hem): onderwerpen van de opdrachten, type opdrachten, aantal opdrachten.
Hoe kies je het type opdrachten: nadat we de onderwerpen hebben bepaald, stellen we vast welke opdrachten het beste kunnen worden gebruikt om dit te verifiƫren? Klassieke opties: open vraag, meerkeuze vraag, bijpassingen, etc. (vergeet de technische beperkingen van de omgeving waarin de test wordt afgenomen niet!). Na het bepalen en beschrijven van het type opdrachten hebben we een klaar technisch verslag voor de expert. We kunnen het de testspecificatie noemen.
Valstrik 3: Betrek de expert niet bij de ontwikkeling van de test
Bij het betrekken van de expert bij de ontwikkeling van de test is het zeer belangrijk om niet alleen de 'werkomvang' aan te geven, maar hem ook in het ontwikkelingproces zelf te betrekken.
Hoe ervoor te zorgen dat het werk met de expert zo efficiƫnt mogelijk is:
- Stel hem van tevoren in en besteed enige tijd aan uitleg over de wetenschap van testontwikkeling, psychometrie.
- Concentreer de aandacht van de expert op het creƫren van een valide en betrouwbaar beoordelingsinstrument, en niet op een lijst met vragen.
- Leg uit dat zijn werk ook een voorbereidende fase omvat, niet alleen de ontwikkeling van de opdrachten zelf.
Sommige experts (vanwege hun karakter) kunnen dit zien als een controle van hun eigen werk, en aan hen leggen we uit dat zelfs bij het creƫren van uitstekende opdrachten, deze eenvoudigweg niet passend kunnen zijn voor de specifieke doelstellingen van de test.
Om het proces snel te laten verlopen, bereiden we samen met een expert een dekkingstabel voor die kennis en vaardigheden bevat, welke deel uitmaakt van de testspecificatie. Deze tabel maakt het mogelijk om de vragen nauwkeurig uit te werken en te bepalen wat we zullen meten. In elk specifiek geval kan deze enigszins anders worden samengesteld. Onze taak is om te controleren hoe goed iemand vertrouwd is met de kennis en vaardigheden van eerdere, basis cursussen, zodat we kunnen begrijpen hoe voorbereid hij of zij is op de nieuwe cursus.
Val 4: Denken dat de expert 'beter weet'
Kent het onderwerp beter. Maar legt niet altijd duidelijk uit. Het is heel belangrijk om de formuleringen van opdrachten te verifiĆ«ren. Schrijf duidelijke instructies, zoals 'Kies 1 juiste optie'. In 90% van de gevallen stellen experts vragen op een manier die voor hen zelf begrijpelijk is. En dat is prima. Maar voordat de test aan degenen die hem gaan afleggen wordt overgegeven, moet alles worden gecontroleerd en gecorrigeerd, zodat de mensen die de test afleggen precies begrijpen wat van hen wordt verwacht, en geen fouten maken omdat ze de tekst van de opdracht verkeerd hebben geĆÆnterpreteerd.
Om dubbelzinnigheid in de opdrachten te voorkomen, houden we 'cognitieve laboratoria'. We vragen mensen uit de doelgroep om de test te maken, terwijl ze hardop uitspreken wat ze denken, en we documenteren dit gedetailleerd. In de 'cognitieve laboratoria' kunnen onduidelijke vragen en slechte formuleringen worden ontdekt, en we krijgen een eerste terugkoppeling over de test.
Val 5: Geen rekening houden met de tijd voor het afleggen van de test
sarcasm mode: aan
Natuurlijk is onze test de beste, iedereen droomt ervan deze te doen! Ja, allemaal 4 uur.
sarcasm mode: uit
Wanneer er een lijst is van alles wat gecontroleerd kan worden, is het belangrijkste ā dit niet te doen (dat klinkt op het eerste gezicht vreemd, toch?). We moeten genadeloos snijden en samen met een expert de sleutelkennis en -vaardigheden benadrukken (ja, een aantal vaardigheden kan ook in de test worden gecontroleerd). We kijken naar het type opdrachten en schatten de verwachte tijd om ze uit te voeren: als het allemaal nog steeds binnen redelijke grenzen ligt ā snijden!
Om de omvang te verkleinen, kan je ook proberen (voorzichtig) met Ć©Ć©n opdracht twee vaardigheden te controleren. In dit geval is het moeilijk te begrijpen waarom iemand fout zat, maar bij een correcte uitvoering kunnen beide vaardigheden worden meegewogen. Het is belangrijk om ervoor te zorgen dat deze 2 vaardigheden binnen hetzelfde kennisgebied vallen.
Val 6: Niet nadenken over het punten systeem
Bij het opstellen van evaluatietests wordt vaak het klassieke beoordelingssysteem in punten gebruikt, bijvoorbeeld 1 punt voor gemakkelijke vragen en 2 punten voor moeilijke vragen. Maar dit systeem is niet universeel. Gewoon de som van de punten na de test zegt ons weinig: we weten niet voor welke vragen deze punten zijn toegekend en kunnen alleen het aantal correcte antwoorden bepalen. We hebben een duidelijk begrip nodig van welke specifieke vaardigheden de deelnemers aan de test demonstreren. Bovendien willen we hen feedback geven over welke onderwerpen ze nog moeten verbeteren.
We maken immers een test die mensen zal indelen in degenen die klaar zijn en degenen die niet klaar zijn voor het programma; sommigen zullen we adviseren om zich voor te bereiden op de cursus via gratis onderwijs. Het is belangrijk voor ons dat alleen degenen die dit echt nodig hebben en er klaar voor zijn in deze groep worden opgenomen.
Wat we in onze situatie doen: we bepalen binnen de werkgroep van testontwikkelaars welke groepen mensen we moeten onderscheiden (bijvoorbeeld klaar voor opleiding, gedeeltelijk klaar) en we stellen een tabel op met kenmerken van dergelijke groepen, waarbij we aangeven welke vaardigheden en kennis relevant zijn voor de groep die klaar is voor opleiding. Op deze manier kunnen we de 'moeilijkheid' van de opdrachten voor dergelijke tests vormgeven.
Fallacy 7: Resultaten alleen automatisch beoordelen
Natuurlijk moet beoordeling zo objectief mogelijk zijn, daarom worden bepaalde materialen van studenten automatisch beoordeeld, 'op basis van antwoorden' ā door te vergelijken met de juiste antwoorden. Zelfs als er geen speciaal testsysteem is, zijn er talloze gratis oplossingen. En als men de principes van scriptschrijven begrijpt, kan men met Google Forms en resultaten in tabellen van alles doen. Als bepaalde opdrachten door experts worden beoordeeld, moeten we nadenken over het bezorgen van antwoorden aan experts, zonder informatie over de kandidaten. En over hoe we de resultaten van de expertbeoordelingen kunnen integreren in de uiteindelijke beoordeling.
We initially wanted to create several open tasks with code, where experts evaluate solutions based on pre-defined criteria, and even prepared a system that exports individual responses from test participants into a special table for experts, and then imports the results into a scoring table. However, after discussions with representatives of the target audience, the product manager, and the instructional designer, we concluded that conducting a technical interview with instant expert feedback and code discussion, as well as specific questions, would be much more effective and beneficial for the participants themselves.
Now the expert verifies the completion of the test by clarifying some questions. For this, we have prepared a guide of questions and evaluation criteria for the technical interview. Before the technical interview, the expert receives a response map of the test participant to select the questions to ask.
Pitfall 8: Not explaining test results
Providing feedback to participants is a separate issue. We need not only to inform about the test score but also to give an understanding of the test results.
Dit kunnen zijn:Ā
- Tasks where the participant made mistakes, but also tasks completed correctly.
- Topics where the participant made errors.
- His rating among those taking the exam.
- Description of the participant's level, according to, for example, the level description of specialists (based on job descriptions).
During the pilot launch of our test, to those wanting to enter the program, we showed, along with the results, a list of topics to review. But this is of course not ideal; we will improve and enhance feedback.
Pitfall 9: Not discussing the test with developers
Perhaps the most sensitive pitfalls, which are especially unpleasant to encounter ā sending the test, description, and scoring scale to developers in the 'as is' state.
What exactly needs to be discussed:
- The appearance of questions, structure, placement of graphics, how the correct answer looks.
- How the score is calculated (if needed), whether there are any additional conditions.
- How feedback is formed, where to source texts, whether there are any additional blocks formed automatically.
- What additional information you need to gather and at what moment (the same contacts).
Om misverstanden te voorkomen, vragen we onze ontwikkelaars om 2 of 3 verschillende vragen te coderen, zodat we kunnen zien hoe ze eruitzien voordat we de test zelf programmeren.
Valstrik 10: Geen testen voordat je direct in productie gaat
Drie keer, jongens, de test moet drie keer door verschillende mensen worden gecontroleerd, of nog beter ā elke persoon drie keer. Deze waarheid is verkregen door bloed, zweet en pixels van het codeerwerk.
Onze test controleert zo'n trio:
- Product ā controleert de test op functionaliteit, uitstraling en mechanica.
- Testontwikkelaar ā controleert de tekst van de opdrachten, hun volgorde, de werking van de test, de types opdrachten, de juiste antwoorden, leesbaarheid en een normale weergave van de grafiek.
- Opdrachtgever (expert) ā controleert de test op juistheid vanuit een deskundig perspectief.
Een praktijkvoorbeeld: pas bij de derde run merkte de opdrachtgever dat 1 opdracht in de oude formulering was blijven staan. Alle eerdere versies waren ook actief aangepast. Maar toen de test was gecodeerd, zag hij er anders uit dan aanvankelijk werd gedacht. Waarschijnlijk moet er iets worden aangepast. Dit moet in overweging worden genomen.
Conclusie
Nauwkeurig alle deze "valstrikken" omzeilend, hebben we een speciale , gemaakt voor de kenniscontrole van de kandidaten. Iedereen die wil, kan het testen terwijl we het volgende materiaal voorbereiden, waarin we uitleggen wat er binnen de bot gebeurde en hoe dit later is veranderd.
Verkrijg een gewilde beroepskwalificatie vanaf nul of level up je vaardigheden en salaris door 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: habr.com
