
Здравствуйте. Я не айтишник — я учитель истории с более чем десятилетним стажем. Но информационные технологии всегда были моей страстью и надёжным инструментом в работе.
В этой статье я хочу рассказать о собственном опыте внедрения системы тестирования в школьной практике. Моя программа предельно проста — она написана на Python в духе unix-way: делает одну вещь, но делает её хорошо. Опытные разработчики вряд ли увидят в ней что-то новое, но цель текста — показать, как принципы системного администрирования и инженерного мышления могут помочь в решении педагогических задач.
Проблемы классической системы
За годы преподавания я постоянно сталкивался с одной и той же проблемой — как объективно оценить знания всех учеников при ограниченном времени.
Если урок истории проходит раз в неделю, по нормам нужно поставить минимум три оценки за триместр. На практике это означает: пять человек у доски — и урок закончен.
Я пробовал разные подходы: выборочный опрос, случайные вопросы по параграфу — три минуты на ученика, чтобы понять, читал ли он текст. Это ускоряло процесс, но не решало главного: системность и объективность оставались недостижимыми.
Эра нейросетей
С появлением нейросетей домашние задания потеряли смысл. Ученик за минуту получает готовый текст, а у меня уходит три часа на его проверку. Более того, честные ученики оказываются в проигрыше: их работы слабее, потому что они написаны собственными силами.
Рефераты тоже не спасают. Чтобы написать хороший реферат, нужно уметь работать с книгами, а не просто компилировать тексты из интернета. Нейросети здесь бесполезны, но школьники — тоже. Проверка одного реферата занимает у меня до шести часов.
Однако в этом есть и надежда: машина пока не умеет мыслить исторически, а значит, у нас, учителей, остаётся пространство для настоящего обучения.
Поиски решения
Ученики изобретательны и находят способ обмануть любую систему.
Когда я пробовал тесты с трафаретом, оценки внезапно стали слишком хорошими — оказалось, кто-то сфотографировал шаблон с ключами. С интерактивной доской было не лучше: солнечные «зайчики» и кашель служили сигналами подсказки.
Тогда я решил: пусть всё будет просто. Минимум интерфейсов, максимум контроля. И вернулся к идее классического тестирования — но на своих условиях.
Тестирование и мой опыт monkey-кодинга
Как-то у меня появилось два свободных окна между уроками. За это время я написал небольшой скрипт на Python — не больше 80 строк. Использовал библиотеку questionary.
Формат теста оказался прост и удобен:
Вопрос|Правильный ответ|Неправильный|Неправильный|...
Программа случайным образом перемешивает варианты, но сохраняет правильный ответ в первом поле. Я предусмотрел и выбор количества вопросов: если указано больше, чем есть в базе, программа просто берёт максимум.
Таким образом, из базы в 200 вопросов каждый ученик получает всего 5 случайных. Пример исходников доступен в открытом репозитории:
Всё распространяется под MIT-лицензией — пусть пользуются те, кому нужно.
Кто пойдёт к доске?
Проблема №1 — максимизировать количество проверенных учеников.
Пять случайных вопросов и три минуты на прохождение оказались оптимальным сочетанием.
Так я могу проверить половину класса за урок. При этом я избегаю работы с персональными данными — логи и конфигурации лежат в .gitignore.
Следующий вопрос: кто идёт отвечать?
Если желающих нет — задержка, если много — шум. Решение оказалось неожиданным: я просто использую randomus.ru для выбора ученика. А чтобы не возиться с мышью, применяю плагин Vimium — теперь всё решают клавиши, и процесс идёт в духе Unix: быстро, минималистично и без кликов.
Bash в помощь
Когда-то я был убеждённым пользователем Windows и писал собственные утилиты для обработки данных. Но Linux научил меня простоте.
grep — и я вижу оценки нужного ученика:
grep "Иванов" log_all.txt
cat — и все логи за неделю объединены в один файл:
cat *.txt > log_all.txt
Хочу объединить все тесты в общий банк? Тоже не проблема:
cat * > ultimate.txt
Да, команда примитивна, но философия верна: делай меньше, но делай лучше. Именно этот подход позволяет мне работать быстрее и сосредоточиться на сути — на обучении, а не на бумажной рутине.
Что дальше?
Экзюпери сказал: «Книга закончена не тогда, когда нечего добавить, а когда нечего убрать».
Моя система развивается именно по этому принципу.
Недавно я добавил возможность подключаться к школьному компьютеру по SSH с телефона. С внешней клавиатурой телефон превращается в полноценный терминал, и я могу работать удалённо.
Также я реализовал списки классов, чтобы ученик не вводил фамилию вручную. В Windows-версии эта функция пока не активна — впереди оптимизация.
Мой проект прост, но он живой. Он растёт, потому что отвечает реальной потребности: сделать оценивание объективным, а работу учителя — эффективной.
Да, кто-то посмеётся над «учителем-скриптером». Но я считаю, что инновации начинаются не в лабораториях, а там, где человек пытается облегчить себе жизнь, не изменяя сути своего дела.
Заключение
Мой проект — это попытка объединить педагогический опыт и инженерное мышление. Он делает процесс проверки знаний прозрачным, быстрым и честным.
Учитель получает инструмент анализа, а ученик — простое и понятное испытание. Машина берёт на себя рутину, освобождая время для настоящего обучения.
Я не стремлюсь заменить педагога машиной. Я лишь хочу, чтобы она помогала сохранять человечность в профессии, где бумага и формальности часто вытесняют живое знание.