Moodle після оновлення: що перевірити перед запуском

Вступ

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

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

Тому після оновлення Moodle варто провести приймальну перевірку до того, як повернути всіх користувачів у звичайний режим. Її завдання — відповісти на просте запитання: чи може заклад безпечно продовжувати навчальний процес на оновленій платформі.

Якщо оновлення ще не виконане, спочатку скористайтеся інструкцією «Оновлення Moodle 4.5 до 5.2».

Зміст

Пріоритет 1. Вхід користувачів
Пріоритет 2. Курси й контент
Пріоритет 3. Оцінки й завдання
Пріоритет 4. Сповіщення й пошта
Пріоритет 5. Мобільний застосунок
Технічна перевірка без занурення в адміністрування
План на перший тиждень
FAQ

Пріоритет 1. Вхід користувачів

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

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

студент;
викладач;
адміністратор або менеджер.

Якщо заклад використовує кілька способів автентифікації — наприклад, локальні облікові записи, LDAP, OAuth або корпоративний SSO, — перевірте кожен із них окремо. Moodle 5.2 має оновлений інтерфейс входу та MFA, але для вже налаштованих сайтів чинні параметри не повинні автоматично змінюватися лише через оновлення. Загальний огляд змін версії доступний у MoodleDocs.

Особливо уважно перевіряйте вхід, якщо під час міграції змінювалися плагіни автентифікації або заклад раніше використовував компоненти, вилучені з ядра Moodle 5.0, зокрема CAS чи MNet.

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

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

Пріоритет 2. Курси й контент

Далі перевірте сам навчальний контент. Не потрібно вручну переглядати кожну сторінку кожного курсу. Ефективніше вибрати репрезентативну вибірку.

До неї варто включити:

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

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

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

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

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

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

Пріоритет 3. Оцінки й завдання

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

Виберіть кілька курсів і пройдіть повний сценарій:

студент відкриває завдання;
бачить правильний термін здачі;
надсилає тестову роботу;
викладач бачить подання;
викладач виставляє оцінку й залишає зворотний зв’язок;
студент бачить результат;
оцінка коректно відображається в журналі.

Так само варто вибірково перевірити тести, особливо якщо вони використовуються для контрольних або екзаменів.

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

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

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

Пріоритет 4. Сповіщення й пошта

Після успішної перевірки основних навчальних сценаріїв протестуйте комунікації.

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

Практично достатньо перевірити кілька типових подій:

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

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

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

Пріоритет 5. Мобільний застосунок

Мобільний застосунок легко пропустити, якщо команда проводить міграцію з комп’ютерів. Але для частини студентів телефон може бути основним способом роботи з Moodle.

Після оновлення перевірте щонайменше:

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

Особливо важлива така перевірка для сайтів із SSO або іншою нестандартною автентифікацією. Офіційний посібник Moodle App окремо описує особливості мобільного входу для зовнішніх способів автентифікації.

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

Технічна перевірка

Після міграції потрібна загальна технічна приймальна перевірка.

Команда, відповідальна за платформу, має підтвердити, що:

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

Цей блок не вимагає, щоб керівник або викладач аналізував системні журнали самостійно. Його задача — отримати від відповідального адміністратора підтвердження стану, а не фразу «сайт відкривається, отже все добре».

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

План на перший тиждень

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

На перший тиждень варто визначити простий режим супроводу.

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

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

Щоденний короткий огляд. Відповідальна команда переглядає нові звернення та стан платформи й відстежує, чи не з’являється повторюваний патерн.

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

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

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

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

FAQ

Скільки тримати бекап після оновлення?

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

Коли повертати всіх користувачів?

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

Чи потрібно перевіряти всі курси?

Зазвичай ні. Практичніше сформувати репрезентативну вибірку з різних типів курсів і окремо перевірити ті, що критичні найближчим часом або активно використовують сторонні компоненти. Якщо виявлено системну проблему, вибірку потрібно розширити.

Хто має проводити перевірку?

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

Чи потрібно тестувати мобільний застосунок, якщо сайт у браузері працює?

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

Що вважати критичною проблемою?

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

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