Перед записью на новый курс Machine Learning Advanced мы тестируем будущих студентов, чтобы определить уровень их готовности и понять, что именно им необходимо предложить для подготовки к курсу. Но возникает дилемма: с одной стороны, мы должны проверить знания по Data Science, с другой — мы не можем устроить полноценный 4-х часовой экзамен.
Для решения такой задачи мы развернули штаб по TestDev прямо в команде разработки курсов по Data Science (и, похоже, это только начало). Представляем вам список 10 «граблей», на которые наступают при разработке тестов для оценки знаний. Надеемся, что мир онлайн-обучения станет после этого чуть лучше.
Грабли 1: Не определить четко цели тестирования
Чтобы грамотно определить цели и составить тест, который будет их учитывать, на этапе планирования мы должны ответить себе на несколько вопросов:
- Что мы собственно проверяем?
- В какой среде будет проходить тестирование и какие механики используются? Какие в этой среде есть ограничения. Этот же пункт позволит понять технические требования к устройству, на котором будет проходить тестирование, а ещё — к содержанию (если тест проходят с телефонов, картинки должны читаться даже на маленьком экране, должна быть возможность их увеличить и т.п.).
- Сколько времени будет проходить тестирование? Нужно продумать, в каких условиях пользователь будет проходить тест. Может ли возникнуть ситуация, что ему нужно будет прервать процесс тестирования, а затем снова продолжить?
- Будет ли обратная связь? Как формируем и доставляем ее? Что нужно для получения? Есть ли временной зазор между выполнением теста и обратной связью?
В нашем случае, ответив на эти вопросы, мы определили для теста такой список целей:
- Тест должен показать, готовы ли будущие студенты к прохождению курса, хватит ли им знаний и навыков.
- Тест должен дать нам материал для обратной связи, указать тему, в которой студенты допустили ошибку, чтобы они смогли подтянуть свои знания. Как его составить — рассказываем далее.
Грабли 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 задание осталось в старом варианте формулировки. Все предыдущие тоже активно правили. Но когда тест закодили, выглядел он иначе, чем изначально представляли. С большой вероятностью что-то придется править. Это нужно учитывать.
Итог
Аккуратно обойдя все эти «грабли», мы создали специального , для проверки знаний абитуриентов. Любой желающий может потестить его, пока мы готовим следующий материал, в котором расскажем, что происходило внутри бота, и во что это все трансформировалось потом.
Получить востребованную профессию с нуля или Level Up по навыкам и зарплате, можно пройдя онлайн-курсы SkillFactory:
- (12 недель)
- (20 недель)
- (20 недель)
- (12 месяцев)
Eще курсы
- (12 месяцев)
- (14 недель)
- (5 недель)
- (18 месяцев)
- (6 месяцев)
- (12 месяцев)
- (8 месяцев)
- (9 месяцев)
- (12 месяцев)
- (18 месяцев)
- (18 месяцев)
- (12 месяцев)
- (9 месяцев)
- (7 месяцев)
Источник: habr.com