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