Før tilmelding til det nye kursus i Machine Learning Advanced, tester vi de kommende studerende for at bestemme deres beredskabsniveau og forstå, hvad de specifikt har brug for for at forberede sig til kurset. Men der opstår en dilemma: På den ene side skal vi teste viden om Data Science, på den anden side kan vi ikke gennemføre en fuld 4 timers prøve.
For at løse en sådan opgave har vi oprettet et TestDev-team direkte i udviklingsteamet for kurser i Data Science (og det ser ud til, at dette kun er begyndelsen). Her er en liste over 10 'kløfter', som man kan falde i, når man udvikler tests til vurdering af viden. Vi håber, at verden for online uddannelse vil blive lidt bedre efter dette.
Kløft 1: At ikke definere testens mål klart
For at kunne definere målene korrekt og sammensætte en test, der tager hensyn til dem, skal vi i planlægningsfasen besvare flere spørgsmål:
- Hvad er det, vi faktisk tester?
- I hvilket miljø vil testen finde sted, og hvilke mekanikker anvendes? Hvilke begrænsninger findes der i dette miljø? Denne punkt vil også give os indblik i de tekniske krav til den enhed, som testen skal udføres på, samt til indholdet (hvis testen udføres på telefoner, skal billederne kunne læses selv på en lille skærm, og der skal være mulighed for at zoome ind osv.).
- Hvor lang tid vil testen tage? Vi skal overveje, under hvilke forhold brugeren vil gennemføre testen. Kan der opstå situationer, hvor det er nødvendigt at afbryde testen og derefter fortsætte?
- Vil der være feedback? Hvordan former og leverer vi den? Hvad skal der til for at modtage den? Er der en tidsforsinkelse mellem testens afslutning og feedbacken?
I vores tilfælde, ved at besvare disse spørgsmål, har vi defineret følgende mål for testen:
- Testen skal vise, om de kommende studerende er klar til at tage kurset, og om de har tilstrækkelig viden og færdigheder.
- Testen skal give os materiale til feedback og angive emnet, hvor studerende har lavet fejl, så de kan forbedre deres viden. Hvordan man sammensætter den, fortæller vi videre om.
Kløft 2: At ikke udarbejde en kravspecifikation til eksperten - testforfatteren
For creating test assignments, it is very important to involve an expert in the field being assessed. For the expert, a well-formulated specification (description) is needed, which includes the test topics, the knowledge/skills being assessed, and their level.
An expert will not create such a specification for themselves, as their job is to come up with assignments, not the test structure. Especially since not many are professionally developing tests yet, even while teaching. This is taught in a separate specialty—psychometrics.
If you want to quickly familiarize yourself with psychometrics, there is a for all interested. For deeper study, the Institute of Education offers a and postgraduate studies.
When preparing the specification, we gather a detailed description of the test for the expert (preferably together with them): topics of the assignments, types of assignments, and their quantity.
How to choose the type of assignments: once we have determined the topics, we decide which assignments can best assess them? Classic options include: open-ended assignments, multiple-choice or single-choice assignments, matching tasks, etc. (don’t forget about the technical limitations of the environment where the testing takes place!). After determining and formalizing the types of assignments, we have a ready specification for the expert. We can call it the test specification.
Pitfall 3: Not involving an expert in the test development
When immersing an expert in the test development, it is very important not just to indicate the 'scope of work' but to involve them in the development process itself.
How to make working with the expert as effective as possible:
- Pre-adjust their mindset and spend some time discussing the science of test development and psychometrics.
- Focus the expert’s attention on creating a valid and reliable assessment tool, rather than just a list of questions.
- Explain that their work includes a preparatory stage, not just the development of the assignments themselves.
Some experts (due to their nature) may perceive this as a check of their own work, and we clarify to them that even while creating excellent assignments, they may simply not fit specific testing goals.
For the process to go smoothly, we prepare a coverage table of topics (knowledge and skills) with an expert, which is part of the test specification. This table allows us to accurately formulate questions and determine what we will measure. It can be slightly different in each specific case. Our task is to check how well a person understands the knowledge and skills from previous, foundational courses to understand how ready they are for training in a new course.
Pitfall 4: Assuming that the expert "knows better"
Knows the subject better. But does not always explain clearly. It is very important to check the wording of the assignments. Write clear instructions, for example, "Select 1 correct option." In 90% of cases, experts prepare questions in a way that makes sense to them. And that’s fine. But before handing over the test to those who will take it, everything should be checked and polished so that the test-takers clearly understand what is required of them and do not make mistakes just because they might misinterpret the wording of the assignment.
To avoid double interpretation of tasks, we conduct "cognitive laboratories." We ask people from the target audience to take the test, verbalizing their thoughts aloud while we thoroughly document this. In the "cognitive laboratories," one can "catch" unclear questions, poor wordings, and gain initial feedback on the test.
Pitfall 5: Not considering the time to complete the test
sarcasm mode: on
Of course, our test is the best, everyone dreams of taking it! Yes, all 4 hours.
sarcasm mode: off
When there is a list of everything that can be checked, the main thing is not to do all of it (sounds strange at first glance, doesn't it?). One must ruthlessly cut down, highlighting key knowledge and skills with the expert (yes, some skills can also be tested). We look at the type of tasks and estimate the target time for completion: if it’s still exceeding reasonable limits—cut it down!
To reduce the volume, one can also try (carefully) to check two skills with one task. In this case, it is difficult to understand why a person made a mistake, but if done correctly, both skills can be accounted for. It is important to ensure that these two skills correspond to one area of knowledge.
Pitfall 6: Not thinking through the scoring system
Når man laver vurderingstest, bruger man ofte et klassisk pointsystem, for eksempel 1 point for lette opgaver og 2 point for svære. Men det er ikke universelt. Summen af point fra testen fortæller os ikke meget: vi ved ikke, hvilke opgaver der er givet disse point, og vi kan kun afgøre antallet af korrekte opgaver. Vi har brug for en præcis forståelse af, hvilke specifikke færdigheder testdeltagerne demonstrerer. Derudover ønsker vi at give dem feedback om, hvilke emner der skal arbejdes videre med.
For vi laver en test, der vil dele folk op i dem, der er klar til programmet, og dem, der ikke er klar. Til nogle vil vi anbefale at forberede sig med gratis undervisning. Det er vigtigt for os, at kun de personer, der virkelig har brug for det, og som er klar, kommer med i denne gruppe.
Hvad gør vi i vores situation: vi beslutter inden for udviklerteamet for testen, hvilke grupper af mennesker der skal skelnes (for eksempel dem, der er klar til undervisning, og dem der delvist er klar) og vi laver en oversigt over karakteristika for disse grupper, med angivelse af hvilke færdigheder og viden der vil være relevante for den gruppe, der er klar til undervisning. På denne måde kan vi udforme "sværhedsgraden" af opgaverne for sådanne tests.
Grube 7: At vurdere resultater kun automatisk
Selvfølgelig skal vurderingen være så objektiv som muligt, derfor vurderes en del af de studerendes materiale automatisk, "efter nøgler" - ved at sammenligne med de rigtige svar. Selv hvis der ikke er et specialiseret testsystem, er der masser af gratis løsninger. Og hvis man forstår principperne for skriptoprettelse, kan man med Google-formularer og resultater i regneark gøre hvad som helst. Hvis en del af opgaverne vurderes af eksperter, er det nødvendigt at tænke over, hvordan man sender svarene til eksperterne uden information om de testede. Og overveje, hvordan man integrerer resultatet af eksperternes vurdering i den endelige bedømmelse.
Vi ønskede oprindeligt at lave et par åbne opgaver med kode, hvor eksperter vurderer løsninger ud fra forudfastsatte kriterier, og vi havde endda forberedt et system, der eksporterer individuelle svar fra deltagerne i testningen til en særlig tabel for eksperterne, og derefter importerer resultaterne til en tabel med vurderingsberegning. Men efter diskussioner med repræsentanter for målgruppen, produktchefen og læringsdesigneren, mente vi, at det ville være langt mere effektivt og nyttigt for deltagerne at gennemføre et teknisk interview med øjeblikkelig feedback fra eksperten og diskussion om koden samt enkelte spørgsmål.
Nu verificerer eksperten testens gennemførelse ved at præcisere nogle spørgsmål. Til dette har vi forberedt en guide med spørgsmål og vurderingskriterier til det tekniske interview. Før det tekniske interview får eksperten en kortlægning af deltagerens svar, så de kan vælge de spørgsmål, der er relevante at stille.
Fælde 8: Ikke at forklare testresultaterne
Præsentationen af feedback til deltagerne er et særskilt spørgsmål. Vi har brug for ikke kun at informere om testresultatet, men også at give forståelse for resultaterne af testen.
Dette kan være:
- Opgaver, som deltageren fejlede i, samt dem, de løste korrekt.
- Emner, hvor deltageren lavede fejl.
- Deres rang blandt eksamensdeltagerne.
- En beskrivelse af deltagerens niveau, i henhold til beskrivelsen af specialistniveauer (baseret på jobbeskrivelser).
Ved pilotafviklingen af vores test, viste vi dem, der ønskede at tilmelde sig programmet, en liste over emner, der skulle forbedres sammen med resultaterne. Men dette er naturligvis ikke ideelt, vi vil forbedre os og gøre feedbacken bedre.
Fælde 9: Ikke at diskutere testen med udviklerne
Måske de mest kritiske fælder, det er særligt ubehageligt at træde i — at sende testen, beskrivelsen og vurderingsskalaen til udviklerne i 'som det er'-stand.
Hvad specifikt skal diskuteres:
- Udseendet af spørgsmålene, strukturen, grafikplaceringen, hvordan det korrekte svar præsenteres.
- Hvordan pointene tælles (hvis nødvendigt), er der nogle yderligere betingelser.
- Hvordan feedbacken dannes, hvor teksterne kommer fra, om der er automatisk genererede blokke.
- Hvilke yderligere oplysninger skal du indsamle, og hvornår (de samme kontakter).
For at undgå misforståelser beder vi vores udviklere om at kode 2 eller 3 forskellige spørgsmål, så vi kan se, hvordan de ser ud, før selve testen programmeres.
Fælde 10: Uden at teste, går direkte i produktion.
Tre gange, folkens, testen skal kontrolleres tre gange af forskellige personer, eller bedre - hver især tre gange. Denne sandhed er opnået med blod, sved og pixels af kodelinjer.
Vi tester sådan et trio:
- Produktet - kontrollerer testen for funktionalitet, udseende, mekanik.
- Testudvikleren - tjekker tekstene til opgaverne, deres rækkefølge, hvordan man arbejder med testen, opgavetyper, korrekte svar, læsbarhed og normal visning af grafikken.
- Opgaveforfatteren (ekspert) - kontrollerer testen for rigtighed fra et ekspertperspektiv.
Eksempel fra praksis: først efter den tredje gennemgang så opgaveforfatteren, at 1 opgave var forblevet i den gamle formulering. Alle tidligere blev også aktivt ændret. Men når testen blev kodet, så den anderledes ud end de oprindeligt forestillede. Der vil med stor sandsynlighed være noget, der skal rettes. Det er vigtigt at tage højde for.
Resultat
Forsigtigt undgående alle disse "fælder" har vi skabt en speciel , til at teste viden hos ansøgere. Enhver, der ønsker det, kan teste den, mens vi forbereder det næste materiale, hvor vi fortæller om, hvad der skete inden i botten, og hvordan det hele blev transformeret senere.
Få en eftertragtet profession fra bunden eller opgradér dine færdigheder og løn ved at tage onlinekurser hos SkillFactory:
- (12 uger)
- (20 uger)
- (20 uger)
- (12 måneder)
Flere kurser
- (12 måneder)
- (14 uger)
- (5 uger)
- (18 måneder)
- (6 måneder)
- (12 måneder)
- (8 måneder)
- (9 måneder)
- (12 måneder)
- (18 måneder)
- (18 måneder)
- (12 måneder)
- (9 måneder)
- (7 måneder)
Kilde: habr.com
