Прогулянка граблями: 10 критичних помилок розробки тесту для перевірки знань

Прогулянка граблями: 10 критичних помилок розробки тесту для перевірки знань
Перед записом на новий курс Machine Learning Advanced ми тестуємо майбутніх студентів, щоб визначити рівень їхньої готовності та зрозуміти, що саме їм необхідно запропонувати для підготовки до курсу. Але виникає дилема: з одного боку, ми повинні перевірити знання з Data Science, з іншого — ми не можемо влаштувати повноцінний 4-х годинний іспит.

Для вирішення такого завдання ми розгорнули штаб по TestDev прямо в команді розробки курсів з Data Science (і, схоже, це лише початок). Подаємо вам список 10 «граблів», на які наступають при розробці тестів для оцінки знань. Сподіваємося, що світ онлайн-навчання стане після цього трохи кращим.

Граблі 1: Не визначити чітко цілі тестування

Щоб грамотно визначити цілі та скласти тест, який їх враховуватиме, на етапі планування ми маємо відповісти собі на кілька запитань:

  1. Що ми власне перевіряємо? 
  2. У якому середовищі проходитиме тестування та які механіки використовуються? Які у цьому середовищі є обмеження. Цей же пункт дозволить зрозуміти технічні вимоги до пристрою, на якому проходитиме тестування, а ще до змісту (якщо тест проходять з телефонів, картинки повинні читатися навіть на маленькому екрані, повинна бути можливість їх збільшити і т.п.).
  3. Скільки часу проходитиме тестування? Потрібно продумати, в яких умовах користувач проходитиме тест. Чи може виникнути ситуація, що йому потрібно буде перервати тестування, а потім знову продовжити?
  4. Чи буде зворотний зв'язок? Як формуємо та доставляємо її? Що потрібне для отримання? Чи є часовий зазор між виконанням тесту та зворотним зв'язком?

У нашому випадку, відповівши на ці запитання, ми визначили для тесту такий перелік цілей:

  1. Тест має показати, чи готові майбутні студенти до проходження курсу, чи вистачить їм знань та навичок.
  2. Тест повинен дати нам матеріал для зворотного зв'язку, вказати тему, в якій студенти припустилися помилки, щоб вони змогли підтягнути свої знання. Як його скласти – розповідаємо далі.

Граблі 2: Не скласти ТЗ для експерта - упорядника тесту

Для складання завдань тесту дуже важливо залучати експерта у тій галузі, знання у якій перевіряються. А для експерта в свою чергу потрібне грамотне ТЗ (опис), що включає теми тесту, знання / навички, що перевіряються, і їх рівень.

Експерт таке ТЗ сам для себе не робитиме, адже його робота — придумати завдання, а не структуру тесту. Тим більше, поки що мало хто розробляє тести професійно, навіть у процесі викладання. Цьому навчають на окремій спеціальності – психометрика.

Якщо вам хочеться швидко познайомитися із психометрикою, то в Росії є літня школа для всіх, хто цікавиться. Для більш поглибленого вивчення в Інституті освіти є магістратура та аспірантура.

Готуючи ТЗ, ми збираємо докладний опис тесту для експерта (а краще разом з ним): теми завдань, тип завдань, їх кількість.

Як вибрати тип завдань: визначившись із темами, вирішуємо, якими завданнями це можна перевірити найкраще? Класичні варіанти: завдання з відкритою відповіддю, завдання з множинним або єдиним вибором, відповідності, ін. (не забуваємо про технічні обмеження середовища, в якому проводиться тестування!). Після визначення та прописування типу завдань у нас є готове ТЗ для експерта. Можна назвати його специфікацією тесту.

Граблі 3: Не залучити експерта до розробки тесту

При зануренні експерта у розробку тесту, дуже важливо не просто позначити йому «обсяг робіт», а залучити його до процедури розробки.

Як зробити так, щоб робота з експертом була максимально ефективною:

  • Заздалегідь налаштувати його і витратити якийсь час на розповідь про науку розробки тестів, психометріку.
  • Сфокусувати увагу експерта на створенні валідного та надійного інструменту оцінки, а не списку питань.
  • Пояснити, що у його роботу включається підготовчий етап, як розробка самих завдань.

Деякі експерти (в силу свого характеру) можуть сприймати це як перевірку власної роботи, і ми пояснюємо, що навіть при створенні відмінних завдань вони просто можуть не підійти під конкретні цілі тестування.

Щоб процес пройшов швидко, ми готуємо з експертом таблицю покриття тем (знань та навичок), яка є частиною специфікації тесту. Саме ця таблиця дозволяє точно опрацювати питання, визначити, що ми вимірюватимемо. У кожному даному випадку вона може бути складена трохи по-різному. Наше завдання: перевірити, наскільки людина добре орієнтується у знаннях та навичках попередніх, базових курсів, щоб зрозуміти, наскільки вона готова до навчання на новому курсі.

Граблі 4: Думати, що експерт знає краще

Знає предмет краще. Але не завжди зрозуміло пояснює. Дуже важливо перевірити формулювання завдань. Написати зрозумілі інструкції, наприклад, "Виберіть 1 правильний варіант". У 90% експерти готують питання так, як їм зрозуміло. І це нормально. Але перед передачею тесту тим, хто його проходитиме, потрібно все перевірити і зачесати, щоб люди, які проходять тест, точно зрозуміли, що від них потрібно, і не припустилися помилок лише тому, що могли неправильно витлумачити текст завдання.

Щоб уникнути подвійного тлумачення завдань ми проводимо «когнітивні лабораторії». Ми просимо людей із ЦА пройти тест, промовляючи вголос, що вони думають і докладно це фіксуємо. На «когнітивних лабораторіях» можна «зловити» незрозумілі питання, погані формулювання, отримати перший зворотний зв'язок тесту.

Граблі 5: Не враховувати час виконання тесту

sarcasm mode: on
Звичайно ж, наш тест найкращий, усі мріють його пройти! Так, усі 4 години.
sarcasm mode: off

Коли є список усього, що можна перевірити, головне — цього не робити (на перший погляд дивно звучить, чи не так?). Потрібно безжально різати, виділяючи з експертом ключові знання та навички (так, ряд навичок теж можна перевірити у тесті). Дивимося на тип завдань і прикидаємо цільовий час виконання: якщо все ще більше розумних меж - ріжемо!

Для скорочення обсягу можна також спробувати (акуратно) перевірити одним завданням дві навички. У цьому випадку складно зрозуміти, чому людина помилилася, але при правильному виконанні можна врахувати обидва навички. Важливо переконатися, що ці 2 навички відповідають одній галузі знань.

Граблі 6: Не продумати систему виставлення балів

Часто при складанні оціночних тестів використовують класичну систему оцінювання в балах, наприклад, 1 бал за легкі завдання та 2 бали за складні. Але вона не є універсальною. Просто сума балів за підсумками тестування нам мало що скаже: ми не знаємо, за які завдання отримано ці бали і можемо визначити лише кількість вірних завдань. Нам потрібне точне розуміння, які саме навички демонструють учасники тестування. Крім того, ми хочемо дати їм фідбек, які теми потрібно доопрацювати.

Адже ми робимо тест, який ділитиме людей на готових та неготових до проходження програми, деяким ми радимо підготуватися до курсу на безкоштовному навчанні. Нам важливо, щоб у цю групу потрапили лише ті, кому це справді потрібно і хто до цього готовий.

Що робимо в нашій ситуації: визначаємося всередині робочої групи розробників тесту, які групи людей потрібно виділити (наприклад, готові до навчання, частково готові) та формуємо таблицю характеристик таких груп, із зазначенням того, які навички та знання будуть актуальні для групи готових до навчання навчання. Так можна формувати «важкість» завдань для таких тестів.

Граблі 7: Оцінювати результати лише автоматично

Звісно, ​​оцінювання має бути максимально об'єктивним, тому частина матеріалів студентів оцінюється автоматично, «за ключами» — порівнюючи з вірними відповідями. Навіть якщо немає спеціальної системи тестування, є безліч безкоштовних рішень. А якщо є розуміння принципів написання скриптів, то з гугл-формами та результатами в таблицях можна робити будь-що. Якщо частину завдань перевіряють експерти, то нам необхідно продумати доставку експертам відповідей, без інформації про тих, хто здає. І подумати, як інтегрувати результати перевірки експертів у підсумкове оцінювання.

Ми спочатку хотіли зробити кілька відкритих завдань із кодом, коли експерти оцінюють рішення за заздалегідь сформованими критеріями, і навіть підготували систему, яка експортує окремі відповіді учасників тестування до спеціальної таблиці для експертів, а потім імпортує результати до таблиці з розрахунком оцінювання. Але після обговорення з представниками ЦА, продакт-менеджером та педагогічним дизайнером, ми вважали, що провести технічне інтерв'ю з миттєвим фідбеком експерта та обговоренням коду, а також окремих питань буде набагато ефективнішим та кориснішим для самих учасників.

Наразі експерт верифікує проходження тесту, уточнюючи деякі питання. Для цього ми підготували гайд питань, критерії оцінювання технічного інтерв'ю. Перед технічним інтерв'ю експерт одержує карту відповідей учасника тестування, щоб вибрати питання, які варто поставити.

Граблі 8: Не пояснювати результати тестування

Подання зворотного зв'язку учасникам – окреме питання. Нам необхідно не тільки поінформувати про тестовий бал, а й дати розуміння результатів тесту.
Це можуть бути: 

  • Завдання, у яких учасник помилився, які виконав правильно.
  • Теми, в яких учасник припустився помилок.
  • Його рейтинг серед тих, хто складає іспит.
  • Опис рівня учасника відповідно, наприклад, з описом рівня фахівців (на основі опису вакансій).

При пілотному запуску нашого тесту тим, хто хотів вступити на програму, разом з результатами, ми показували список тем, які потрібно підтягнути. Але це звичайно не ідеал, ми будемо вдосконалюватися і робити зворотній зв'язок краще.

Граблі 9: Не обговорювати тест із розробниками

Мабуть, найгостріші граблі, наступати на які особливо неприємно — відправити розробникам тест, опис та шкалу підрахунку у стані «як є».
Що саме потребує обговорення:

  • Зовнішній вигляд питань, структура, положення графіки, як виглядає вибір правильної відповіді.
  • Як вважається бал (якщо потрібний), чи немає додаткових умов.
  • Як формується зворотний зв'язок, де брати тексти, чи немає додатково блоків, що формуються автоматично.
  • Яку додаткову інформацію вам необхідно збирати і в якийсь момент (ті ж контакти).

Щоб уникнути непорозуміння, ми просимо наших розробників закодувати 2 або 3 різні питання, щоб можна було глянути, як вони виглядають перед програмуванням самого тесту.

Граблі 10: Не тестуючи заливати відразу в продакшн

3 рази, хлопці, перевіряти тест повинні 3 рази різні люди, а краще — кожен по 3. Ця істина здобута кров'ю, потім пікселями рядками коду.

У нас тест перевіряє таке тріо:

  1. Продакт – перевіряє тест на працездатність, зовнішній вигляд, механіки.
  2. Розробник тесту – перевіряє текст завдань, їх порядок, форму роботи з тестом, типи завдань, вірних відповідей, читабельність та нормальний перегляд графіки.
  3. Автор завдань (експерт) – перевіряє тест на вірність із експертної позиції.

Приклад із практики: тільки втретє прогону автор завдань побачив, що 1 завдання залишилося у старому варіанті формулювання. Усі попередні теж активно правили. Але коли тест закодували, він виглядав інакше, ніж спочатку представляли. З великою ймовірністю щось доведеться правити. Це потрібно враховувати.

Підсумок

Акуратно обійшовши всі ці граблі, ми створили спеціального бота в Telegramдля перевірки знань абітурієнтів. Будь-який бажаючий може потішити його, поки ми готуємо наступний матеріал, в якому розповімо, що відбувалося всередині бота, і що це все трансформувалося потім.

Прогулянка граблями: 10 критичних помилок розробки тесту для перевірки знань
Здобути затребувану професію з нуля або Level Up за навичками та зарплатою, можна пройшовши онлайн-курси SkillFactory:

Ще курси

Джерело: habr.com

Додати коментар або відгук