Тести в Moodle без списування: 12 налаштувань

Повністю унеможливити списування під час дистанційного тестування технічними засобами не можна. Сам Moodle прямо попереджає: браузерні обмеження не є «непробивними», а посилення контролю майже завжди створює додаткові незручності для студентів. Тому практична мета інша — зробити недозволену допомогу складнішою, менш передбачуваною і менш вигідною, не перетворюючи тест на перевірку витривалості до технічних бар’єрів.

Це особливо важливо після введення в дію Закону України «Про академічну доброчесність» № 4742-IX: заклади мають вибудовувати внутрішню систему забезпечення доброчесності, а МОН серед її елементів називає використання програмних засобів для виявлення ознак порушень. Але сама наявність Moodle, пароля або прокторингу ще не робить оцінювання доброчесним. Потрібна комбінація методики, налаштувань і зрозумілих правил.

Нижче — шість рівнів захисту, які варто розглядати як систему. Починати доцільно не з найдорожчого інструмента, а з банку питань і логіки самого тесту.

12 налаштувань, які варто перевірити перед контрольним тестом

Це не «рецепт», у якому треба одночасно ввімкнути всі 12 пунктів. Наприклад, Sequential navigation може бути недоречною для тесту, де студент має право переглядати й уточнювати відповіді, а IP-фільтр — для дистанційного складання з домашніх мереж. Таблиця потрібна як контрольний список: кожне налаштування має бути свідомо ввімкнене або свідомо залишене вимкненим відповідно до сценарію оцінювання.

Зміст

1. Рівень 1. Банк питань
2. Рівень 2. Налаштування самого тесту
3. Рівень 3. Показ результатів
4. Рівень 4. Обмеження доступу
5. Рівень 5. Safe Exam Browser
6. Рівень 6. Прокторинг
7. Після сесії: що перевірити перед наступним тестуванням
8. Чого не роблять налаштування
9. FAQ

Рівень 1. Банк питань

Найсильніше налаштування проти обміну готовими відповідями — не «заборонити Alt+Tab», а зробити так, щоб студенти бачили різні набори питань.

У Moodle питання зберігаються в Question bank і можуть бути розподілені за категоріями. Під час створення тесту викладач може додати не конкретне питання, а випадкове питання з вибраної категорії. Офіційна документація Moodle уточнює: якщо в тесті кілька випадкових позицій, система не повинна показувати те саме питання двічі в межах однієї спроби; що більший банк, то вища ймовірність, що студенти отримають різні набори. Деталі описані в Building Quiz.

Практично банк краще будувати не як одну папку зі «100 питаннями з дисципліни», а як структуру за темами та складністю, наприклад:

• тема 1 — базове розуміння;
• тема 1 — застосування;
• тема 2 — базове розуміння;
• тема 2 — застосування;
• інтеграційні питання за кількома темами.

Тоді тест можна збирати за шаблоном: два випадкові питання з першої категорії, два — з другої, одне — з інтеграційної тощо. Студенти отримують співставні за структурою варіанти, але не однаковий набір.

Окремо Moodle дозволяє перемішувати порядок питань у тесті. Для питань із кількома варіантами відповіді можна також перемішувати самі варіанти, якщо тип питання це підтримує. Це не захищає від фотографування екрана чи передачі змісту питання, але знижує користь від повідомлення «у питанні № 7 правильна відповідь — B».

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

Практичний мінімум: якщо всі студенти отримують ті самі 20 питань у тому самому порядку, додавання прокторингу не усуває головну конструктивну слабкість тесту.

Рівень 2. Налаштування самого тесту

Другий рівень — параметри активності Quiz. У актуальній документації Moodle є кілька налаштувань, які прямо впливають на можливість обмінюватися відповідями.

1. Вікно відкриття і закриття

Задайте Open the quiz і Close the quiz, якщо тест має проходити в конкретний період. Якщо час не визначено, Moodle за замовчуванням не обмежує доступ до тесту календарним вікном.

Для різних груп або окремих студентів можна використовувати Group overrides і User overrides. Це важливо, коли є індивідуальні умови проходження або різні потоки складають тест у різний час.

2. Ліміт часу

Time limit обмежує тривалість конкретної спроби. Коли час спливає, активна спроба за типової конфігурації автоматично надсилається з уже введеними відповідями.

Ліміт часу зменшує можливість довго шукати кожну відповідь у сторонніх джерелах, але надто жорсткий таймер починає вимірювати швидкість роботи замість знань. Не варто механічно задавати однакову кількість секунд на кожне питання: розрахункова задача, коротке визначення й аналіз кейсу потребують різного часу.

Перед сесією тест варто пройти в ролі тестового студента й перевірити реальну тривалість, а для передбачених винятків застосувати user/group overrides.

3. Кількість спроб

Для підсумкового контролю часто достатньо однієї спроби. Але це не універсальне правило. Для тренувального тесту кілька спроб можуть бути методично виправданими: Moodle сам описує повторні спроби як спосіб перетворити тест на навчальну активність.

Якщо спроб кілька, перевірте налаштування Each attempt builds on the last. Коли воно ввімкнене, наступна спроба може продовжувати попередню з тими самими питаннями; якщо потрібен новий варіант, це налаштування має відповідати обраній моделі тестування.

4. Послідовна навігація

У Navigation method можна обрати Sequential замість Free. Тоді студент проходить питання по черзі й не може повернутися до попереднього або перескочити вперед.

Це зменшує можливість швидко переглянути весь тест, розподілити питання між кількома людьми й потім повернутися до відповідей. Водночас послідовна навігація підвищує ціну випадкової помилки: студент не може виправити відповідь після того, як згадав потрібний факт пізніше. Тому її варто використовувати лише там, де це відповідає логіці оцінювання.

5. Перемішування

У редакторі тесту можна ввімкнути Shuffle, щоб змінювати порядок питань. Для відповідних типів питань окремо налаштовується перемішування варіантів відповіді.

Найкращий ефект дає комбінація трьох речей: випадкова вибірка з категорій, перемішування питань і перемішування варіантів. Одна лише зміна порядку не допоможе, якщо весь потік отримує той самий набір.

Рівень 3. Показ результатів

Одна з найчастіших помилок — правильно налаштувати тест, але віддати банк відповідей першій групі одразу після завершення.

У Moodle блок Review options визначає, що студент бачить:

• під час спроби;
• відразу після її завершення;
• пізніше, поки тест ще відкритий;
• після закриття тесту.

Окремо контролюються відповідь студента, правильність, оцінка, специфічний і загальний feedback та Right answer — правильна відповідь. Moodle визначає «Immediately after the attempt» як перші дві хвилини після завершення спроби, а «Later, while the quiz is still open» — період після цього до закриття тесту.

Якщо кілька потоків проходять однаковий або частково спільний банк у різний час, не показуйте правильні відповіді, поки останній потік не завершив тестування. Інакше технічно захищений тест перетворюється на джерело готових відповідей.

Це не означає, що feedback треба приховувати назавжди. Для навчальної цінності тесту корисно повернути пояснення після завершення всього контрольного вікна. Головне — розвести в часі оцінювання та навчальний розбір.

Для тестів із великою ставкою варто окремо перевіряти Review options перед кожною сесією, а не покладатися на старий шаблон курсу.

Рівень 4. Обмеження доступу

Коли тест проходить у визначеній аудиторії або для окремого потоку, Moodle дозволяє додати технічні обмеження на початок спроби.

Пароль до тесту

Поле Require password дозволяє вимагати пароль перед запуском. Це корисно, коли викладач оголошує код безпосередньо перед початком контрольної роботи в аудиторії або на синхронній зустрічі.

Пароль не є механізмом ідентифікації: його можна передати іншій людині. Його завдання — обмежити момент і коло доступу, а не довести, хто саме сидить за пристроєм.

IP-обмеження

Require network address дозволяє обмежити спроби певними IP-адресами або підмережами, зокрема CIDR-діапазоном. Moodle прямо наводить це як сценарій для контрольованого тестування, де доступ має бути лише з визначеної аудиторії або мережі.

IP-фільтр доречний у комп’ютерному класі з прогнозованою мережевою схемою. Для домашнього тестування він часто непридатний: адреси можуть змінюватися, студенти можуть користуватися мобільними мережами, NAT або іншою інфраструктурою.

Різні потоки

Для потоків із різним часом початку краще використовувати Group overrides, а не створювати кілька майже однакових копій тесту. Так простіше підтримувати єдину структуру, але задавати різні часові вікна, ліміти, кількість спроб або паролі.

Затримка між спробами

Якщо повторні спроби дозволені, Moodle має Enforced delay between attempts. Це корисно для навчальних тестів: студент не може нескінченно перезапускати тест за кілька хвилин, збираючи правильні відповіді методом перебору.

Для підсумкового оцінювання логічніше спочатку вирішити, чи повторна спроба взагалі потрібна, а вже потім налаштовувати затримку.

Рівень 5. Safe Exam Browser

Safe Exam Browser (SEB) — спеціалізований браузер для контрольованого середовища. Moodle має вбудовану інтеграцію з ним у налаштуваннях Quiz: можна вимагати використання SEB, конфігурувати його вручну, застосувати шаблон або завантажити власну конфігурацію.

За документацією Moodle, SEB може працювати у повноекранному режимі, прибирати звичайну вебнавігацію, блокувати частину комбінацій клавіш і копіювання/вставлення, обмежувати перехід на сторонні сайти, водночас дозволяючи явно визначені ресурси чи застосунки. Докладніше — у Quiz settings та на офіційному сайті Safe Exam Browser.

SEB корисний, коли потрібно обмежити використання цього самого пристрою, на якому студент проходить тест. Але він не створює фізичного контролю над середовищем: другий телефон, інший комп’ютер або допомога людини поруч залишаються поза межами звичайного lockdown-браузера.

Підтримувані пристрої

Поточна офіційна лінійка SEB має релізи для Windows, macOS та iOS/iPadOS. Отже, твердження «SEB не працює на планшетах» некоректне: iPad підтримуються. Водночас у переліку актуальних клієнтів немає окремих релізів для Linux та Android.

Це означає, що перед обов’язковим використанням SEB треба зробити технічне опитування пристроїв студентів і запропонувати сценарій для тих, чия платформа не підтримується. Інакше контроль доброчесності перетвориться на бар’єр доступу до оцінювання.

Що перевірити перед сесією

Не вводьте SEB одразу на підсумковому іспиті. Спочатку проведіть короткий пробний тест із тією самою конфігурацією. Перевірте:

1. запуск конфігурації на підтримуваних ОС;
2. автентифікацію в Moodle;
3. відкриття потрібних вкладених ресурсів;
4. роботу формул, аудіо, відео та файлів, якщо вони є в питаннях;
5. коректне завершення SEB;
6. процедуру дій, якщо пристрій студента не запускає середовище.

SEB має сенс тоді, коли його обмеження відповідають моделі іспиту. Для звичайного низькоставкового тесту він може бути надлишковим.

Рівень 6. Прокторинг

Прокторинг додає до технічного середовища спостереження за процесом складання. Це може бути живий нагляд, запис відео, контроль екрана або комбінація механізмів конкретної системи.

Використовувати прокторинг варто не «за замовчуванням», а там, де ризик підміни особи або сторонньої допомоги справді виправдовує додаткову складність. Для короткого поточного тесту з невеликою вагою прокторинг часто створює більше адміністративного навантаження, ніж користі. Для високоставкового іспиту потреба може бути вищою.

Що вирішити до підключення

До вибору сервісу заклад має відповісти щонайменше на такі питання:

• які саме дані система збирає;
• чи ведеться відео-, аудіо- або запис екрана;
• де зберігаються записи;
• хто має до них доступ;
• як довго вони зберігаються;
• як студент дізнається про правила до початку оцінювання;
• що відбувається при технічному збої;
• чи є альтернативний сценарій, якщо пристрій або умови студента несумісні з вимогами.

Відео, аудіо, зображення документа чи інші дані, за якими можна ідентифікувати людину, потребують належного режиму обробки й захисту. Базову рамку задає Закон України «Про захист персональних даних». Цей матеріал не замінює юридичної оцінки конкретного сервісу або сценарію прокторингу.

Прокторинг не замінює дизайн тесту

Якщо у всього потоку однакові питання, правильні відповіді відкриваються одразу, а завдання перевіряють лише відтворення фактів, камера не усуває ці слабкі місця. Прокторинг — верхній рівень системи, а не заміна банку питань, таймінгу та методики.

Після сесії: що перевірити перед наступним тестуванням

Контент-план передбачав тут кейс реальної сесії. Щоб не вигадувати досвід і цифри, практичніше використати цей блок як шаблон післясесійного аналізу.

Після завершення тестування зберіть факти, які можна перевірити в Moodle та в технічних журналах:

1. Які питання виявилися проблемними. Перевірте завдання з аномально низьким або високим відсотком правильних відповідей і скарги на двозначні формулювання.
2. Чи спрацювали часові обмеження. Подивіться, чи не був таймер надмірним для значної частини групи.
3. Чи були технічні збої. Відокремлюйте проблеми доступу, браузера, мережі й сервера від припущень про порушення.
4. Чи відкривалися результати раніше, ніж планувалося. Особливо важливо для кількох потоків.
5. Чи були винятки через user/group overrides. Переконайтеся, що вони не залишилися активними для майбутніх тестів.
6. Чи достатній банк питань. Якщо студенти регулярно отримують майже однакові набори, збільшуйте категорії або змінюйте схему вибірки.
7. Які дані треба зберегти. Якщо є підозра на порушення, не робіть висновок лише з одного технічного сигналу. Журнали Moodle фіксують дії, але не намір. Для цього в серії передбачено окремий матеріал про логи Moodle як доказову базу.

Такий розбір має завершуватися конкретною зміною конфігурації або методики, а не лише фразою «на наступній сесії посилимо контроль».

Чого не роблять налаштування

Навіть максимально жорстка конфігурація Moodle не вирішує проблему завдань, відповідь на які легко знайти або передати.

Якщо питання перевіряє лише пам’ять — «назвіть визначення», «вкажіть рік», «оберіть формулу» — зовнішня підказка часто дає готову відповідь. Якщо ж потрібно застосувати правило до нової ситуації, порівняти два підходи, пояснити помилку в розрахунку або обґрунтувати вибір, проста передача відповіді стає менш корисною.

Тому технічні обмеження варто поєднувати з перепроєктуванням оцінювання:

• більше завдань на застосування, а не відтворення;
• параметризовані задачі, де змінюються вихідні дані;
• коротке обґрунтування відповіді там, де це доречно;
• персоналізовані або контекстні сценарії;
• усний захист чи вибіркова співбесіда для робіт із високою вагою;
• аналіз чернеток та історії виконання, якщо формат завдання це дозволяє.

Мета — не створити атмосферу тотального контролю, а побудувати оцінювання, в якому самостійна підготовка стає раціональнішою стратегією, ніж пошук способу обійти систему.

Якщо заклад лише починає системно налаштовувати доброчесність, дивіться також хаб про технічну реалізацію академічної доброчесності.

FAQ

Чи потрібен прокторинг для звичайного заліку?

Не обов’язково. Спочатку оцініть вагу тесту, ризик підміни особи, розмір групи й те, чи можна зменшити ризик за допомогою банку питань, випадкової вибірки, таймінгу та належного показу результатів. Для багатьох поточних тестів цього достатньо. Прокторинг логічніше залишати для сценаріїв, де додатковий контроль пропорційний значущості оцінювання.

Чи законно записувати екран або відео студента?

Універсальної відповіді для будь-якого сценарію немає. Якщо система збирає дані, за якими можна ідентифікувати людину, треба визначити мету й порядок обробки, доступ, строк зберігання, захист і належне інформування. Конкретну модель прокторингу варто перевіряти з фахівцем із захисту персональних даних або юристом до запуску, а не після першої скарги.

Чи працює Safe Exam Browser на всіх пристроях?

Ні. В актуальній офіційній лінійці є клієнти для Windows, macOS та iOS/iPadOS. Окремих актуальних клієнтів для Linux і Android у списку релізів немає. Якщо SEB є обов’язковим, заклад має перевірити парк пристроїв студентів і передбачити альтернативу.

Чи достатньо встановити ліміт часу?

Ні. Таймер зменшує час на пошук зовнішніх відповідей, але не заважає двом студентам отримати однакові питання чи передати готовий набір після завершення. Він працює краще разом із банком питань, випадковою вибіркою, перемішуванням і правильно налаштованими Review options.

Чи варто забороняти повернення до попередніх питань?

Послідовна навігація може ускладнити координацію між студентами, але водночас забирає можливість виправити відповідь. Використовуйте її не як автоматичне «антисписування», а коли такий формат відповідає дизайну тесту.

Яке налаштування дає найбільший ефект?

Якщо вибирати одну стартову дію — якісний банк питань із випадковою вибіркою за категоріями. Далі додавайте перемішування, продуманий таймінг і контроль показу правильних відповідей. SEB та прокторинг мають сенс уже після того, як базова конструкція тесту не створює очевидних шляхів для обміну відповідями.

Налаштування Moodle під сесію

Для високоставкового тестування конфігурацію краще перевіряти не в день іспиту, а заздалегідь: банк питань, шаблони Quiz, групові винятки, Safe Exam Browser, пробний запуск і сценарії технічного збою.

Якщо потрібне налаштування або аудит середовища, дивіться послугу впровадження Moodle.

---

Джерела

• Закон України «Про академічну доброчесність» № 4742-IX
• Закон України «Про захист персональних даних» № 2297-VI

© BI-Systems. Передрук і поширення матеріалу дозволено за умови збереження авторства та активного посилання на оригінальну публікацію.