08.02.2008

Когда ботинки не жмут – проверяем СДО на удобство

Я рассматриваю и изучаю разные СДО очень часто. Но у меня взгляд уже привычный, сразу смотрю туда, где чащего возникают проблемы. А при выборе первой и, возможно, единственной СДО к ней нужно внимательно присмотреться. Это особенно трудно сделать, когда к вам приезжает специалист от разработчиков и, зачастую, за час встречи рассказывают столько всего, что в одной голове просто не может уложиться.

На первый взгляд, все СДО одновременно и очень разные и очень похожие. Функционал уже не сильно меняется, много сходства между самыми разными по стоимости системами. Но, в конечном счете, эту систему нужно будет использовать каждый день. И вам, как оргазаторам обучения, и слушателям. Поэтому систему нужно проверить на реальных действиях. Нужна демо-версия и спокойная обстановка. И еще нужен сценарий тестирования.

Вот в этом моменте мы сразу думаем – а как его составить? Его можно и нужно взять из методики обучения, где описано, как слушатель и тьютор должны работать, что обучение было эффективным. (Тут сразу становится ясно, что методику нужно составить до того, как речь пойдет о выборе технологий. Иначе получается, что не технологии поддерживают методику и процесс передачи знаний, а методика и процесс построенны на основе этих самых технологий).

Как может выглядеть сценарий?


Административные и общие задачи:

  • Вход (все просто и понятно?)
  • Находим нужный курс (Быстро? Найти удалось?)
  • Измнение профиля курса (понятно как и что можно изменить?)
  • Отправка сообщения
  • Проверка входящих
  • Смотрим оценки
  • Ищем что-то в справке к системе (найти удалось?)

Работа с содержанием курса:

  • Найдете определенную часть учебного материала, главу 4 или тему А.
  • Найдите информацию, которая требуется для выполнения задания
  • Выполните переход от одной части курса к другой
  • Напишите сообщение и ответ на другое сообщение в форуме курса
  • Попробуйте что-то написать в блог и/или wiki (если это предусмотрено)
  • Организуйте синхронный диалог в чате
  • Попробуйте посмотреть видео, flash-анимацию, послушать аудио
  • Просмотрите календарь, попробуйте посмотреть отдельные мероприятия, распечатать их
  • Попробуйте изменить что-то в календаре

Естественно, чтобы проводить такие сценарии, в систему нужно будет что-то загрузить, но это, как правило, делаят разработчики, так как демо вход в пустую систему – бесполезное занятие. Лучше всего сценарий сделать по ролям. И стоит пригласить к тестированию системы нескольких людей, чтобы было больше мнений.

Самое главное – система должна быть такая, чтобы вы не заметили, что вы ее использовала. Она не должна вызывать чувств. Она должна быть поддержкой вопроса более эмоционального – обучения!

4 коммент.:

Alexander Ryabinin комментирует...

... Я бы так же добавил "тестироваие тестирования", так как это 30-50% качества LMS.

Очень важно то, и вы отметили в своем посте, что тестирвание должно происходить по ролям и желательно разными людьми.

Так вот сценарий у каждой роли свой, и начать нужно от простого "Создатель курса - создает курс", "Студент - открывает курс" и т.д. то есть то, что должна уметь каждая LMS, так вот даже на этом этапе порой всплэвают различные баги и неудобности.

Журкин Игорь комментирует...

Эмм, немного непонятно, а как блоги, календари, и прочее описанное в тестировании, относятся к содержанию курса? К слову сказать, наверное, самое главное тестирование должно быть направленно на взломоустойчивость, поскольку наиболее привлекательным свойством СДО является по общему мнению - беспристрастность контроля знаний.

Елена Тихомирова комментирует...

Блоги, календари и прочие инструменты относятся к содержанию курса - там содержится важная учебная информация. Электронный учебник - это не весь курс, а толко его теоретическая часть.

Про тестирование на взломоустойчивость - это важно, но для администратора. Если при выборе системы ориентироваться только на этот параметр, то система может оказаться крайне не удобной для конечного пользователя.

Anton комментирует...

Интересная тема - "тестирование на взломоустойчивость". Давайте определимся с терминами и целями. Наша конечная цель - обучение людей. Удобное, быстрое, относительно дешевое и приносящее удовольствие всем участвующим :) Обязательным критерием хорошего учебного процесса должна являться, как совершенно справедливо отметил Игорь, беспристрастность контроля знаний. Но это - всего лишь обязательное, само собой разумеещееся требование, точно так же, как покупая новый автомобиль, вы разумно предполагаете, что бензобак, скорей всего не дырявый и машина заведется. Недурно это проверить, но это, очевидно не сама цель выбора машины. Главное, чтобы она удовольствие доставляла и не ломалась. А вот это уже - действительно критерий выбора.
Теперь по поводу взломов. На мой взгляд, под безопансотью должно продразумеваться, что обычный, неумудренный опытом в CS (Computer science, не Counter Strike :) ) студент/преподаватель не должен никакими своими неадекватьными действиями повредить системе или процессу контроля знаний. Иными словами - система должна адекватно реагировать на неадекватные действия. Все.
Что касается прям-таки "взломов", могу сказать следующее. Я видел много систем "изнутри". Видел всем известный Blackboard, WebCT, имел удовольствие участвовать в создании еще нескольких подобных. Мог ответственно заявить, что обладая необходимыми познаниями, эти коммерчески успешные продукты могут быть "взломаны", но есть одно но... Если студент в состоянии подменять cookies и генерировать правильные ID (с учетом временных меток) сессий других пользователей, написать корректную SQL-инъекцию и изменить БД, то...может мы не тому его учим? :)