Цифровая трансформация образования является одним из приоритетных направлений государственной политики Российской Федерации. «Стратегическое направление в области цифровой трансформации отрасли науки и высшего образования до 2030 года» в качестве целевых ориентиров определяет достижение «цифровой зрелости образовательных организаций, внедрение сквозных цифровых технологий, включая технологии искусственного интеллекта, и формирование цифровых экосистем, обеспечивающих индивидуализацию образовательных траекторий» [4]. Реализация данных ориентиров невозможна без пересмотра подходов к контрольно-оценочной деятельности, которая в условиях цифровой среды приобретает новые формы и требования.

В полной мере это относится к обучению программированию в общеобразовательной школе. В настоящее время программирование является не только содержательным ядром предмета «Информатика», но и фактически обязательным компонентом итоговой аттестации: значительная часть заданий единого государственного экзамена требует от выпускников написания программного кода. При этом объём учебного времени, отводимого на освоение алгоритмизации и программирования, остается ограниченным, а существующие методические и инструментальные средства не позволяют в полной мере обеспечить индивидуальное сопровождение каждого ученика. Как следствие, мотивированные школьники вынуждены осваивать программирование преимущественно за рамками школы — в системе дополнительного образования, с репетиторами или самостоятельно [1].

Одной из ключевых причин сложившейся ситуации является дефицит инструментов формирующего оценивания, адаптированных к специфике программирования как учебной дисциплины. Формирующее оценивание, ориентированное на диагностику затруднений и содержательную обратную связь в процессе обучения, признается необходимым условием становления алгоритмического и критического мышления. Однако в массовой школьной практике его реализация сталкивается с объективным ограничением: ручная проверка каждой учебной программы учителем трудоемка и не может быть оперативной, а существующие автоматизированные средства (автотесты, оценочные модули сред разработки) ограничиваются бинарным вердиктом «верно/неверно» и не обеспечивают педагогически значимой обратной связи.

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

Понятие «формирующее оценивание» вошло в педагогическую теорию и практику во второй половине XX века. Впервые оно было введено М. Скривеном в 1967 году, а в 1968 году Б. Блум использовал его в контексте концепции «обучения для овладения мастерством» [2]. В отличие от итогового (суммативного) оценивания, фиксирующего результат на момент завершения изучения темы или курса, формирующее оценивание направлено на «диагностику затруднений и содержательную обратную связь в процессе обучения» [2]. Ключевая характеристика формирующего оценивания — его ориентация не на контроль, а на развитие. Как отмечает М.А. Пинская, «оценивание для обучения» — это «процесс поиска и интерпретации данных, которые ученики и их учителя используют для того, чтобы решить, как далеко ученики уже продвинулись в своей учебе, куда им необходимо продвинуться и как сделать это наилучшим образом» [3]. Таким образом, в центре оказывается не констатация уровня подготовки, а совместное движение учителя и ученика к запланированным образовательным результатам.

Л.Л. Босова, Н.Н. Самылкина и А.Ю. Босова, рассматривая применение формирующего оценивания в школьном курсе информатики, подчёркивают, что его сущность заключается в том, чтобы «понять, как происходит усвоение учебного материала обучающимся, на каком уровне учащийся усваивает этот материал, какие образовательные стратегии подходят для освоения конкретного материала наилучшим образом, какая адресная поддержка необходима каждому конкретному учащемуся и как правильно ее оказать» [2]. Данное определение фиксирует несколько принципиально важных для настоящего исследования положений. Во-первых, формирующее оценивание всегда индивидуализировано. Оно предполагает учёт не только актуального уровня знаний, но и темпа, способов восприятия информации, типичных затруднений конкретного ученика. Во-вторых, оно требует оперативной обратной связи. Решение о коррекции должно приниматься «здесь и сейчас», пока учебная ситуация сохраняет свою актуальность. Отсроченная обратная связь (например, проверка работы через день) теряет значительную долю своего формирующего потенциала. В-третьих, формирующее оценивание неразрывно связано с критериальным подходом. Критерии оценивания должны быть заранее известны и понятны ученику, а сам процесс оценивания — прозрачен [2].

Применительно к обучению программированию перечисленные характеристики приобретают особую специфику. Программирование как учебная дисциплина сочетает в себе формализованное знание (синтаксис языка, структуры данных, алгоритмические конструкции) и творческую деятельность по поиску решения. Ошибка в коде может быть вызвана как незнанием правил записи операторов, так и неверно выстроенной логикой, непониманием условия задачи или неспособностью декомпозировать её на подзадачи. В этом контексте обратная связь при проверке программного кода должна решать несколько задач: указывать на синтаксическую ошибку и объяснять правило её устранения; выявлять логическую ошибку и подводить ученика к пересмотру алгоритма; предлагать более оптимальный способ решения (если уместно); мотивировать к доработке и повторной отправке решения. Однако в массовой школьной практике реализация такой многомерной обратной связи силами одного учителя крайне затруднительна. Полноценный анализ каждой ученической программы требует от учителя значительных временных затрат, что в условиях дефицита учебных часов и наполняемости классов делает регулярное применение формирующего подхода физически невозможным.

В практике обучения программированию существует целый класс инструментов, автоматизирующих проверку кода, однако их функциональные возможности лишь частично соответствуют заявленным педагогическим требованиям. Они ориентированы преимущественно на бинарную оценку: программа прошла тесты — «зачтено», не прошла — «ошибка». При этом ученик не получает ни объяснения причин, ни указаний на то, в каком направлении следует двигаться. Как следствие, образовательный потенциал ошибки остаётся нераскрытым, а мотивация к исправлению — низкой.

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

Первая группа — олимпиадные и соревновательные платформы (Codeforces, Timus, Яндекс.Контест и аналоги). Данные системы ориентированы на проведение состязаний и объективную верификацию решений. Проверка осуществляется путем прогона программы на наборе тестов, после чего участнику сообщается вердикт: «принято», «неправильный ответ», «превышение времени», «ошибка компиляции» и т. п. Такой формат обеспечивает высокую скорость и объективность, однако полностью лишён педагогической составляющей. Обратная связь здесь не объясняет причин ошибки, не указывает на конкретный фрагмент кода, требующий исправления, и не предлагает путей решения. Инструменты данного класса реализуют суммативную, а не формирующую модель оценивания и не могут быть напрямую использованы в общеобразовательной школе без существенной адаптации.

Вторая группа — модули автоматической проверки, встраиваемые в системы управления обучением (LMS). Наиболее распространенным примером является плагин Virtual Programming Lab (VPL) для Moodle. Данное решение позволяет выполнять код непосредственно в браузере, проводить тестирование, проверять на заимствования и вести журнал оценок. VPL даёт преподавателю значительную свободу в настройке критериев проверки, однако эта же гибкость оборачивается высоким порогом вхождения: для конфигурации тестов требуются навыки программирования и понимание архитектуры системы. Обратная связь, получаемая учеником, по-прежнему представляет собой результат прохождения тестов (успешно/неуспешно). Отдельные исследовательские разработки предлагают расширить функционал VPL за счет так называемых «негативных тест-кейсов», когда система идентифицирует типичные ошибочные решения и выдает соответствующее сообщение. Тем не менее, подобные модификации носят экспериментальный характер и не стали массовой практикой.

Третья группа — образовательные онлайн-платформы и массовые открытые курсы (MOOC). Stepik, Coursera, JavaRush и аналогичные среды используют автоматическую проверку кода как основной механизм контроля при большом потоке обучающихся. В большинстве случаев проверка сводится к сравнению вывода программы с эталонным, что неизбежно порождает те же ограничения, что и в олимпиадных системах: вердикт есть — объяснения нет. Некоторые платформы делают шаги в сторону формирующего подхода: например, JavaRush содержит модуль «Анализ кода», который выявляет нарушения стиля оформления (code style) и даёт рекомендации по улучшению читаемости. Однако такие инструменты затрагивают лишь синтаксическую и стилистическую сторону, оставляя без внимания логические ошибки, оптимальные алгоритмы и смысловые искажения. Кроме того, ряд платформ практикует код-ревью силами опытных разработчиков, но это уже не автоматизированная, а экспертная проверка, которая не масштабируется на массовое школьное обучение.

Четвертая группа — новые инструменты, использующие методы искусственного интеллекта и статического анализа. В последние годы появились решения, способные не только исполнять код, но и анализировать его качество, безопасность, производительность, соответствие стандартам. Примером может служить платформа GitVerse от Сбера, запущенная в конце 2024 года и включающая AI-ассистента GigaCode, а также инструмент GigaView, оценивающий код по девяти критериям. Данные средства ориентированы в первую очередь на корпоративную разработку и профессиональные команды; их адаптация под образовательные задачи, особенно под уровень общеобразовательной школы, требует отдельной проработки. Педагогический сценарий использования, понятные школьнику формулировки обратной связи и интеграция с учебным процессом в существующих решениях отсутствуют.

Как видим, с одной стороны, существуют разнообразные автоматизированные средства проверки программного кода, различающиеся по сложности, среде применения и степени интеллектуальности; с другой стороны, ни одно из них не реализует модель формирующего оценивания в том объёме, который требуется для системного использования в школьном обучении программированию. Данный вывод определяет необходимость перехода от анализа существующих решений к проектированию специализированного инструментария, ориентированного на задачи формирующего оценивания в общеобразовательной школе.

По результатам анализа существующих систем автоматизированной проверки кода, нами были выделены три группы требований к инструментарию формирующего оценивания: требования к содержанию обратной связи, требования к интерфейсу и среде взаимодействия, а также требования к условиям внедрения в образовательный процесс.

Требования к обратной связи. Главным отличием формирующего оценивания от суммативного является характер сообщения, которое получает ученик. Вместо констатации факта («верно», «неверно», «тест пройден») система должна обеспечивать содержательную, диагностическую и развивающую обратную связь. Это предполагает: указание на конкретную строку или фрагмент кода, содержащий ошибку; объяснение причины ошибки (синтаксическая, логическая, алгоритмическая); классификацию ошибки по типу и степени критичности; наличие подсказки, наводящего вопроса или отсылки к теоретическому материалу; возможность демонстрации корректного решения или альтернативного подхода; вариативность обратной связи в зависимости от уровня подготовки учащегося (например, развёрнутое объяснение для начинающих и краткий указатель для более опытных).

Требования к интерфейсу и среде взаимодействия. Условия массовой школы накладывают жесткие ограничения на программную реализацию. Система не должна требовать от пользователя установки сложного программного обеспечения, настройки окружения или изучения дополнительных интерфейсов. Оптимальным каналом взаимодействия представляются веб-среды или мессенджеры, уже интегрированные в повседневную коммуникацию школьников и учителей. К данной группе требований относятся: кроссплатформенность и доступность с любого устройства (компьютер, планшет, смартфон); отсутствие необходимости в развёртывании собственной серверной инфраструктуры образовательной организацией; минимальное время отклика (режим реального времени или близкий к нему); понятный, не перегруженный техническим жаргоном интерфейс.

Требования к организации учебного процесса. Внедрение любого цифрового инструмента в школьную практику невозможно без учёта позиции учителя. Система автоматизированного формирующего оценивания не должна восприниматься педагогом как средство, заменяющее его профессиональные компетенции. Напротив, её целесообразно рассматривать как инструмент, принимающий на себя рутинную, трудоёмкую часть работы и тем самым высвобождающий время учителя для содержательного взаимодействия с учениками. Из этого следуют дополнительные требования: настраиваемость критериев проверки учителем без необходимости программирования; наличие понятной аналитики по классу в целом и каждому ученику в отдельности; методическое сопровождение, включающее готовые библиотеки задач и примеры использования.

Сформулированные требования задают вектор поиска конкретных технологических решений. Ключевым ограничением существующих систем, как уже было обозначено выше, является не столько сама возможность автоматической проверки кода, сколько отсутствие педагогически содержательной обратной связи. Снятие этого ограничения сегодня становится принципиально достижимым благодаря развитию методов искусственного интеллекта, в частности обработки естественного языка и анализа семантики программного кода. Современные языковые модели способны не только верифицировать решение, но и интерпретировать намерения программиста, локализовать ошибку и генерировать объяснения, адаптированные под уровень пользователя.

Другим перспективным направлением является выбор среды взаимодействия. Традиционные LMS и веб-интерфейсы требуют от ученика дополнительных действий по авторизации, навигации, ожиданию ответа. Альтернативой выступают мессенджеры — цифровые среды, уже интегрированные в повседневную коммуникацию школьников. Telegram, VK Мессенджер и аналогичные платформы предоставляют знакомый интерфейс, низкий порог входа, поддержку различных устройств и возможность асинхронного взаимодействия. Бот-интерфейс в таком окружении воспринимается учащимися не как ещё одна учебная система, а как естественный канал получения оперативной помощи.

Считаем, что наиболее перспективной представляется разработка специализированного инструмента формирующего оценивания на базе чат-бота, использующего методы искусственного интеллекта для анализа кода и генерации обратной связи. Подобное решение способно в полной мере реализовать выделенные требования: обеспечить содержательный фидбек, быть доступным с любых устройств без установки, легко встраиваться в существующий учебный процесс и не требовать от учителя дополнительной технической подготовки. В рамках дальнейшего исследования предполагается разработка и апробация такого прототипа применительно к школьному курсу программирования.

В заключении отметим, обучение программированию в современной школе сталкивается с устойчивым противоречием: необходимость формирующего оценивания декларируется, но инструментально не обеспечивается. Существующие системы автоматической проверки кода реализуют преимущественно суммативную модель контроля и не дают содержательной обратной связи, а ручная проверка учителем не масштабируется в условиях массового обучения. Выход из сложившейся ситуации лежит в разработке специализированных средств, например чат-бота, ориентированного на задачи автоматизированного формирующего оценивания в школьном курсе программирования и отвечающего трем ключевым требованиям: педагогическая полнота обратной связи, доступность интерфейса и интегрируемость в образовательный процесс.

Литература:
1. Барышева И. В., Козлов О. А., Малкина Е. В., Шестакова Н. В. Проблемы программирования в рамках школьного образования // Вестник Нижегородского университета им. Н. И. Лобачевского. Серия: Социальные науки. 2023. №3 (71). URL: https://cyberleninka.ru/article/n/problemy-programmirovaniya-v-ramkah-shkolnogo-obrazovaniya (дата обращения: 03.02.2026).
2. Босова Л. Л., Самылкина Н. Н., Босова А. Ю. Формирующее оценивание образовательных результатов обучающихся по информатике в основной школе. Информатика в школе. 2024;(2):4-16. URL: https://doi.org/10.32517/2221-1993-2024-23-2-4-16 (дата обращения: 07.02.2026).
3. Пинская М.А. Формирующее оценивание: оценивание в классе: учеб. пособие / М.А. Пинская. – М.: Логос, 2010. – 264 с. URL: https://gymnasium69.gosuslugi.ru/netcat_files/175/2862/formiruyushhee_oczenivaniya_uspeshnye_praktiki.pdf (дата обращения: 07.02.2026).
4. Распоряжение Правительства Российской Федерации от 5 июля 2025 г. № 1805-р «О стратегическом направлении в области цифровой трансформации отрасли науки и высшего образования до 2030 г.» // Официальный интернет-портал правовой информации. URL: https://www.garant.ru/products/ipo/prime/doc/412194202/ (дата обращения: 03.02.2026).