От вебинаров до биллинга: что нужно тестировать в EdTech на самом деле

Если вы руководите EdTech‑продуктом, статья даст вам понимание, что и как обязательно нужно тестировать, на каких этапах и какие вопросы задавать своему QA (внутреннему или внешнему). 90% материала посвящено российскому рынку и реалиям, 10% – интересным кейсам от Coursera, Duolingo и других международных компаний.

В среднестатистической российской онлайн‑школе «всё хорошо с QA» выглядит так: регресс зелёный, баги в Jira закрыты, тестировщик подтвердил готовность релиза. Накатывается новая фича – скажем, новый формат вебинара или групповой проверки домашек. И вот в 19:55 в чате поддержки появляется первое сообщение: «У меня не открывается урок». Через минуту – уже 12 таких сообщений, через пять минут – 200. К 20:15 вебинар так и не запустился: на платформе по‑прежнему белый экран. Начинается суматоха: методист тегает продакта, продакт – CTO, CTO – разработчика, разработчик – тестировщика. Все в панике, но финансовые и репутационные потери уже не исправить.

Мы много лет помогаем компаниям из мира цифровых образовательных технологий выстраивать QA и не раз сталкивались с историями разного уровня фатальности. Почти всегда проблема не в конкретных тестировщиках, а в самой системе. Дело в том, что EdTech тестируют как обычное веб‑приложение, не учитывая сложность продукта, специфическую нагрузку, особое поведение пользователей и серьезность последствий ошибок. Если бы об этом писали в учебниках для джунов, мы бы не разгребали ситуации, где школа на 10 тысяч активных учеников живёт без автотестов, а единственный QA – методист, который тестирует как может в свободное от основной работы время (невыдуманные истории из практики коллег, увы).

Чем EdTech отличается от «просто веба» с точки зрения тестирования?

Когда говоришь собственникам: «У вас не просто сайт с курсами, видео и оплатой», – они всегда смотрят с легким недоумением, искренне не понимая, зачем выделять отдельный QA‑подход для EdTech. Но на это есть 5 веских причин.

1. Нагрузка в EdTech неравномерная. У обычного интернет‑магазина пиковые часы – это, условно, вечер и выходные, с предсказуемым ростом в дни акций. У EdTech пик приходится на конкретные даты и время. К примеру, 19:00 МСК, понедельник, старт вебинара – на платформе одновременно оказываются 8 000 пользователей. К 19:01 их уже 11 000, к 19:03 – 14 000, и треть из них видит сообщение «Ой, что‑то пошло не так». Это не просто высокая нагрузка, а резкий удар. Если вы не тестируете систему именно так – с пиковыми всплесками и стремительным нарастанием числа пользователей, – вы не проверяете нагрузку по‑настоящему.
2. Особенная аудитория c нестандартным поведением, к тому же, довольно часто далёкая от IT. В большинстве школ это: родители школьников (нервничают); сами школьники (легко отвлекаются); взрослые, проходящие переквалификацию (стесняются обращаться в поддержку и просто уходят). Любая ошибка здесь – не просто запись в системе отслеживания багов, а фраза «Всё тупит, я не буду здесь заниматься». Конверсия в обучение – критически важная метрика, и страдает она не из‑за громких сбоев, а из‑за банальных проблем с юзабилити. Поэтому тестировать пользовательский интерфейс в современных образовательных технологиях нужно обязательно.
3. EdTech‑продукт – это целая экосистема: лендинг, личные кабинеты ученика и родителя, кабинеты методиста и преподавателя, админ‑панель, CRM, биллинг, интеграции с эквайрингом, мессенджерами и видеоплатформой, мобильное приложение, иногда desktop‑плеер для скачанных уроков или даже отдельный класс с интерактивной доской. Всё это должно работать без сбоев. Стандартное функциональное тестирование веб‑приложения здесь не поможет, так как у вас не одно приложение, а сложная взаимосвязанная система.
4. Контент – это часть продукта. В обычном SaaS пользователь сам вводит данные, и QA их не затрагивает. В EdTech контент – это база: видео, тексты, тесты, интерактивные задания и тренажёры. Каждый новый курс – это новый набор данных, который должен корректно отображаться, воспроизводиться и оцениваться. Когда методисты сообщают: «Мы загрузили 12 модулей нового курса», – для QA это сигнал к регрессионному тестированию. Например, в одном из модулей может оказаться видео с нестандартной кодировкой, которое не загрузится на старом Android‑планшете.
5. Цена ошибки в EdTech измеряется не деньгами. В финтехе ошибка грозит потерей средств клиента и комплаенс‑рисками, а в EdTech – пропущенным уроком перед ЕГЭ. Деньги можно вернуть, но упущенное занятие за две недели до экзамена (и доверие к вам) – нет. Поэтому критичность дефектов нужно оценивать в категориях обучения, а не просто в функциональности.

Раз уж заговорили о критичности – забудьте про разделение «бизнес-критичный, не критичный, минорный». В тестировании EdTech-решений мы обычно настаиваем на трёх осях: критичность для обучения (срывает ли это занятие?), массовость (один пользователь или 30%?), обратимость (можем ли мы откатить эффект?).

На пересечении этих осей легко договариваться с разработкой о приоритетах. «У нас P1, всё критично» – это разговор ни о чём. «Это срывает занятие у 30% активной аудитории и при этом необратимо» – уже конкретная проблема.

7 контуров качества EdTech платформ

Когда речь идет о тестировании образовательных сервисов, многие представляют себе регресс, проверку форм и пару нагрузочных тестов перед запуском. На практике этого недостаточно. Пользователям всё равно, где произошел сбой – если они решат, что продукт сырой, то уйдут к конкурентам. Чтобы этого не случилось, нужно внедрить зрелую стратегия тестирования, которая покроет 7 контуров качества.

Контур №1. Видео и стриминг: главный источник критических сбоев в EdTech 

Видео – это сердце большинства EdTech проектов. Записанные уроки, живые вебинары, гибридные форматы. И если видеоматериалы недоступны, то бизнес стоит. Вот распространённые ошибки.

Тестируют видео не на тех файлах. Команда QA проверяет плеер на стенде – с «эталонным» видеофайлом, который, разумеется, воспроизводится без проблем. Но в прод курсы загружают методисты и тренеры: файлы отличаются кодеками, частотой кадров и структурой. Эту вариативность часто не учитывают. Решение простое, хоть и трудоемкое: создать тестовую библиотеку из 30–50 реальных файлов из продакшена  – из разных эпох и от всех подрядчиков. Каждый релиз плеера или транскодера нужно прогонять через всю библиотеку.

Игнорируют реалии российского рынка. С 2022 года стриминг в РФ работает в особых условиях: часть международных контент‑провайдеров недоступна или функционирует нестабильно. Многие пользователи в регионах пользуются 3G – например, у условного «Б‑оператора» скорость в лучшем случае достигает 2 Мбит/с. Если тестировать только на офисном гигабитном соединении, картина будет нереалистичной. Обязательно проводите throttling‑тесты – искусственно ограничивайте полосу пропускания. Проверьте три сценария: «плохой 3G», «средний 4G» и «хороший Wi‑Fi». Так вы поймёте, как работает адаптивный битрейт, что показывает плеер при падении скорости и корректно ли возобновляется воспроизведение.

Не проверяют длительные сценарии. Урок может длиться 45 минут, вебинар – 90 минут или даже два часа. Часто тестировщик убеждается, что видео запускается, и считает задачу выполненной. Но важно оставлять стрим на длительное время. Например, у одного из клиентов мы обнаружили проблему: через 57 минут просмотра в Safari звук рассинхронизировался с картинкой на 2–3 секунды – из‑за этого пользователь не понимал, что говорит лектор.

Совет для CTO: попросите QA-команду показать вам матрицу «устройство × браузер × сеть × длительность» для видео. Если у них нет такой матрицы или она содержит меньше 15 комбинаций – у вас нет тестирования видео. У вас есть надежда (или вера?), что оно работает.

Контур №2. Тестирование производительности: выдержит ли платформа реальный учебный процесс

Большинство EdTech компаний к которым мы приходим, уже имеют какой‑никакой опыт нагрузочного тестирования – обычно это разовый прогон в JMeter перед крупным запуском. Но такой подход редко отражает реальную картину работы продукта. Почему?

Профиль нагрузки EdTech‑платформы специфичен, и его нужно тщательно проектировать. Мы выделяем четыре типа всплесков – каждый требует отдельного тестирования.

Сценарий должен повторять реальное поведение пользователей. Например: «4 000 пользователей заходят в личный кабинет, нажимают кнопку „Войти в вебинар“, переходят на страницу плеера, плеер устанавливает WebSocket‑коннект, открывается чат, начинается видеопоток, а через 12 минут 800 человек одновременно открывают вкладку с заданием». Создать такой тест непросто – это кропотливая, методичная работа.

Отдельно стоит упомянуть chaos‑тестирование. В классическом варианте оно подразумевает намеренный вывод из строя отдельных частей инфраструктуры, чтобы проверить устойчивость системы. В EdTech я предпочитаю более мягкий подход – так называемые деградационные тесты.

Что будет, если контент‑провайдер отключится в ключевой момент? Или если эквайринг начнёт тормозить и задерживать платежи – скажем, обработка вместо привычных 2 секунд займет целых 8? А если сервис рассылок выйдет из строя и не отправит пользователям уведомления о начале вебинара?

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

Контур №3. Платежи, доступы и возвраты: самая чувствительная зона EdTech

Разберём одну из самых проблемных областей – биллинг в EdTech. Он должен синхронно выполнять три задачи: принять оплату, выдать доступ, уведомить пользователя. Сбой на любом этапе ведёт к финансовым потерям или некорректным списаниям.

Вот ключевые сценарии для регрессионного тестирования:

• Двойная оплата. Пользователь случайно нажимает «Оплатить» дважды и получает два списания. Хотя кейс кажется надуманным, по статистике на такие операции приходится 0,3–1,5% всех оплат в любой школе. Важно проверить, возвращает ли система деньги автоматически и отображается ли эта операция в интерфейсе администратора.

• Оплата с задержкой. Эквайринг работает медленно, пользователь решает, что платёж не прошёл, и повторяет попытку – в итоге средства списываются  несколько раз.

• Промокод плюс рассрочка. Любимая комбинация, которую все забывают тестировать. Особенно если рассрочка через банк-партнёра. В нашей практике был случай,  когда промокод 50% применялся к каждому платежу рассрочки отдельно, и человек платил половину суммы дважды по графику. Это вызвало серьезные проблемы в бухгалтерии.

• Возврат за частично оплаченный курс. Если ученик прошёл 3 из 10 модулей и запросил возврат, нужно убедиться, что сумма соответствует оферте, а запись о возврате есть в CRM и 1С.

• Подписочная модель и отмены. Если у вас подписка на доступ к контенту – что происходит при отмене? Доступ блокируется сразу или после завершения оплаченного периода? Что происходит с контентом, скачанным через мобильное приложение? 

• Разные способы оплаты (СБП, карты, остатки Apple Pay в РФ и др.) имеют свои нюансы – коды ошибок, поведение при таймауте, комиссии. Для каждого канала нужен отдельный набор тестов.

Если биллинг покрыт автотестами меньше чем на 90%, то вы серьезно рискуете. В EdTech автоматизация не опция, а необходимость: ручной прогон занимает около 16 часов, требует тестовых карт и согласования с эквайрингом. Проводить его перед каждым релизом практически нереально.

Контур №4. Мобильные приложения: большая часть аудитории учится со смартфонов

Доля мобильного трафика в российских EdTech-продуктах варьируется от 50 до 80% в зависимости от ниши. Школьные платформы — мобилки 65–75%. Платформы для взрослых (профессиональное обучение) — 50–60%. Подготовка к ЕГЭ — почти 80% мобилки в вечерние часы. И при этом регулярно видим команды, где приложение тестируется «по остаточному принципу» — после того как закончили с вебом.

Что специфично для EdTech приложений в России?

Разнообразие устройств заметно шире, чем в Европе. Там достаточно протестировать приложение на паре флагманских iPhone и трёх моделях Android, а у нас приходится учитывать старые Honor и Xiaomi, бюджетные Realme, а также российские планшеты на нестандартных сборках Android (например, поставленные в школы по госконтракту). Многие из этих устройств работают на прошлогодних версиях ОС без последних обновлений сервисов Google – и это тоже влияет на работу приложения. Если не тестировать на матрице хотя бы из 12–15 реальных устройств (от премиальных до бюджетных), часть пользователей будет сталкиваться с ошибками. Они вряд ли обратятся в поддержку – скорее просто уйдут или оставят негативный отзыв, что в перспективе снизит приток клиентов. 

RuStore и альтернативные сторы. Некоторая часть аудитории не может скачать приложение из Google Play и использует RuStore, AppGallery или устанавливает APK‑файл напрямую. Версия для RuStore порой отличается от Play‑версии – например, может не поддерживать Firebase push‑уведомления и использовать собственные аналоги. Поэтому важно тестировать каждую сборку отдельно, включая сценарий прямой установки APK: там могут быть особенности с разрешениями и поведением приложения.

Офлайн-режим. Если платформа позволяет скачивать уроки для офлайн‑просмотра, то нужен отдельный блок тестирования. Сценарий «скачал — сеть пропала — продолжаю смотреть — сеть вернулась — прогресс синхронизировался» имеет множество вариантов развития – и любой из них может дать сбой без систематической проверки. Например, бывает так: пользователь скачал урок, школа отозвала доступ из‑за неуплаты, но видео продолжает воспроизводиться с устройства. Мы сталкивались с таким багом в трёх школах – в одной он оставался нерешенным два года.

Push-уведомления. В EdTech это конверсионный инструмент: «Ваш урок через 15 минут», «Не забудьте сдать домашку», «Преподаватель проверил работу». Если уведомления не доходят, то снижается удержание аудитории. Тестировать их непросто: нужны реальные устройства и сертификаты APNS/FCM, а также проверка на сотнях уведомлений за раз. Особенно важно тестировать на разных брендах – Huawei, Xiaomi и Samsung по‑разному управляют фоновыми процессами, из‑за чего уведомления могут не приходить, если система принудительно выгрузила приложение.

Контур №5. ПДн, права доступа и безопасность: базовый минимум для EdTech 

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

• Корректность работы согласий на обработку персональных данных (ПДн). Важно убедиться, что чек‑боксы при регистрации настроены правильно (обязательные или необязательные), а информация корректно записывается в базу данных и передается родителю ученика.
• Реализацию права на удаление данных. Может ли пользователь или родитель запросить удаление информации? Что именно удаляется, а что сохраняется по закону – например, данные в логах биллинга должны оставаться.
• Следует подтвердить локализацию серверов. Хотя это инфраструктурный вопрос, QA‑команда должна в рамках регрессионного тестирования убедиться, что все чувствительные данные обрабатываются на серверах в РФ.
• Контроль доступов внутри платформы. Например, может ли преподаватель курса А получить доступ к данным ученика из курса B, к которому не имеет отношения? Тест на «горизонтальную эскалацию прав» обязателен: он выявляет риски несанкционированного доступа.
• Важно проверить безопасность для неавторизованных пользователей. Может ли гость по прямой ссылке открыть чужой урок, профиль или переписку в чате? Такие уязвимости нередко встречаются – хотя их редко ищут целенаправленно.

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

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

Контур №6. Интерфейс глазами ученика, а не разработчика

В EdTech почти не тестируют одну очень важную вещь – «обучаемость» интерфейса, то есть его способность помочь ученику получить нужные знания. Это зона на стыке QA, UX‑исследований и педдизайна. 

Вот сценарии, которые мы обычно просим команду протестировать вживую, на реальных представителях ЦА.

• Первая сессия нового ученика. Зарегистрировался, оплатил, зашёл – может ли он за 5 минут найти своё первое занятие и начать учиться? Сколько раз перешёл по интерфейсу впустую? Где запнулся?
• Возврат после паузы. Если ученик не заходил на платформу две недели, система должна помочь ему сориентироваться – подсказать, на чём он остановился. 
• Сдача домашки. Сколько шагов требуется, видно ли, что работа отправлена, приходит ли подтверждение? 
• Запрос помощи. Ученик не понял тему – как он может задать вопрос преподавателю, методисту, поддержке? Сколько кликов до результата?
• Сценарий «родитель проверяет ребёнка». Может ли родитель за две минуты увидеть прогресс, посещения, оценки?

Маленькая ремарка. Юзабилити-тестирование на сотрудниках школы – это самообман. Они знают продукт, помнят, куда нажимать, и не споткнутся там, где реальный человек. Найдите 5–7 представителей целевой аудитории, попросите их выполнить ваши сценарии вслух и запишите. Это даст вам данных больше, чем три месяца внутренних обсуждений.

О том, как проводить юзабилити-тестирование, находить реальные барьеры и превращать пользовательский опыт в конкурентное преимущество, мы подробно рассказали в отдельном материале. Ссылку на статью оставим в конце. 

Контур №7. Контент как часть продукта: почему его тоже нужно тестировать 

Контент в EdTech – часть продукта, а его публикация равнозначна релизу. С точки зрения управления качеством каждый новый курс должен проходить приемочное регрессионное тестирование перед запуском.

Что оно должно включать:

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

В половине школ, с которыми мы начинали работать, такого тестирования не было. Методисты сами собирали курс, сами его проверяли – и сразу запускали в прод. В результате первая когорта учеников обнаруживала 20–30 проблем, которые приходилось устранять уже «на живых людях». Это не самый профессиональный подход. При этом исправить ситуацию несложно: достаточно разработать чёткий чек‑лист и выделить ответственного, который будет прогонять его перед публикацией каждого курса.

Что должно быть в зрелой QA-стратегии EdTech-платформы?

Соберем теперь все вышесказанное в чек-лист для CTO или CEO. Если вы можете уверенно поставить галочку напротив каждого пункта – поздравляем, у вас есть система. Если нет – вы нашли точки роста.

На уровне процессов

• Описана матрица критичности дефектов с осями «обучение/массовость/обратимость».
• Есть документированная стратегия тестирования с прописанными контурами (видео, нагрузка, биллинг, мобилка, безопасность, юзабилити, контент).
• Каждый релиз проходит регрессию по чек-листу всех 7 контуров.
• Перед публикацией каждого нового курса проходит приемочный регресс контента.
• Команда QA участвует в продуктовых обсуждениях ещё до того, как начинают писать технические спецификации.

На уровне инструментов

• Автотесты для биллинга – обязательны, особенно для критических сценариев. 
• Автотесты на основные пользовательские пути (вход, начало урока, сдача домашки).
• Нагрузочные тесты должны учитывать реальный профиль нагрузки – а не просто «1000 пользователей на главной». 
• Для мобильного тестирования нужна матрица из минимум 12–15 моделей устройств. 
• Регулярные throttling-прогоны на медленных сетях.
• Тестовая библиотека видео из реального продакшена.

На уровне команды

• В команде есть специалист или группа, отвечающая за автоматизацию тестирования. 
• В команде есть человек, отвечающий за нагрузочное тестирование (либо это умеет основной QA).
• QA-команда умеет тестировать мобильные приложения, а не только веб и отдает приоритет тестированию той платформы, которая популярна среди вашей аудитории.
• Есть процесс юзабилити-исследований с реальными учениками – минимум раз в квартал.

Собственная команда или аутсорс: что выбрать EdTech-компании?

Мы бы соврали, если бы сказали, что аутсорс – всегда лучший вариант. Это не так. У in‑house‑команды есть весомые преимущества: глубокое понимание контекста, постоянная связь с разработчиками, накопленные знания о продукте и единая корпоративная культура. Если в разработке задействовано более 200 человек, а продукт уже стабилен, то собственная QA‑команда – логичный выбор. Мы не затрагиваем экономический аспект: в 2026 году он заметно изменился, и мы сами часть административных процессов ради экономии отдали на аутсорс профессионалам. Но это тема для отдельной статьи.

При этом, в EdTech есть ряд ситуаций, где аутсорс работает реально лучше.

Ситуация 1. Быстрый рост школы при нехватке QA‑специалистов. Типичная картина: 30 разработчиков и всего 2 тестировщика, которые не справляются с нагрузкой. Нанять ещё 5 человек – это 2–3 месяца на поиск и адаптацию плюс риск, что не все приживутся. Аутсорс решает проблему за 1–2 недели – не как постоянное решение, а как временная мера, пока формируется своя команда.

Ситуация 2. Нужны редкие компетенции. Нагрузочное тестирование. Безопасность. Автоматизация мобилки. Каждая из этих компетенций требует одного-двух узкоспециализированных спецов. Содержать в штате трёх инженеров под три направления, если они нужны не на 100% времени – дорого. Аутсорс под конкретное направление обходится в разы дешевле.

Ситуация 3. Пиковая нагрузка на тестирование. Перед началом учебного года, запуском нового курса или редизайном объем тестирования возрастает в 3–5 раз на 1–2 месяца. In‑house‑команда в такие периоды перегружена, а потом простаивает. Аутсорс позволяет гибко масштабировать ресурсы под текущие задачи. 

Ситуация 4. Нужен взгляд со стороны. Когда команда долго работает с продуктом, она может не замечать очевидных проблем. Внешний QA‑специалист подходит к тестированию непредвзято и выявляет то, что для внутренних сотрудников стало «нормой». Это особенно важно при аудите процессов и подготовке к масштабированию.

Ситуация 5. Юзабилити-исследования. Тестировать продукт на своих сотрудниках – мы уже договорились – самообман. Аутсорсер, у которого собран реальный пул респондентов из ЦА, делает это в разы быстрее и качественнее, чем внутренняя команда, которая каждый раз заново ищет учеников.

Идеальная конфигурация для крупной EdTech-школы – это, как правило, гибрид. 1–2 инхаус-QA в каждой продуктовой команде, которые знают свой контекст, плюс внешний партнер на нагрузку, мобильную автоматизацию, юзабилити и пиковые работы.

Какие вопросы задать потенциальному QA-подрядчику?

Если вы решили рассматривать аутсорс тестирования – вот вопросы, по ответам на которые сразу станет понятно: перед вами серьёзная компания и надёжный партнёр или вам продают джунов в красивой обертке.

1. Покажите 2–3 реальных кейса с EdTech-продуктами или платформами с похожим профилем нагрузки. Без названий, под NDA – нормально, но цифры и подходы должны быть.
2. Какой у вас типовой подход к нагрузочному тестированию EdTech? Какие инструменты используете? Какие профили проектируете?
3. На скольких реальных устройствах вы можете тестировать мобильное приложение прямо сейчас, без закупки?
4. Есть ли у вас опыт работы с российскими платежными системами (СБП, конкретные банки-эквайеры)?
5. Как вы строите коммуникацию с инхаус-командой? Используете ли наши инструменты (Jira/Slack/Telegram) или у вас «всё своё»?
6. Какие гарантии вы даёте по срокам и качеству? Есть ли SLA?
7. Что произойдёт, если ваш ключевой инженер на нашем проекте уволится?
8. Готовы ли вы участвовать в продуктовых обсуждениях, а не только получать тикеты «протестируй вот это»?
9. Покажите типовой отчет о проведенном тестировании. Если это «отчет‑отписка» на полстраницы – это уже показательный сигнал. Отчёты должны помогать принимать бизнес‑решения, а для этого в них должна быть вся ключевая информация.

Практики мировых EdTech-платформ, на которые стоит обратить внимание 

За последние годы нам довелось изучить немало кейсов зарубежных образовательных платформ. Часть подходов сложно применить в российских реалиях, но есть практики, которые уже сегодня могут быть полезны и небольшим онлайн-школам, и крупным образовательным экосистемам. 

Duolingo. Известны экспериментальной культурой A/B-тестов всего и вся, включая микровзаимодействия. У них в команде QA встроены в продуктовые юниты, и каждая фича выкатывается на маленький процент аудитории с метриками. Это даёт им возможность ловить регрессии не функциональные, а продуктовые – то есть «фича работает технически, но снижает удержание». QA в чистом виде там размылся в продуктовую аналитику.

Coursera, Udemy настолько масштабны, что выделили отдельные команды для тестирования рекомендательных алгоритмов и автоматической проверки заданий. Они проверяют не просто работоспособность системы, а её осмысленность: например, следят, чтобы рекомендации не зацикливались, а автогрейдер не ставил высший балл за бессмысленный ответ. 

Khan Academy проводят масштабные юзабилити‑исследования с участием детей – и это достойный пример для подражания. Компания тестирует продукт не в офисе, а прямо в школах, в присутствии педагогов. Результаты таких тестов они регулярно публикуют. В России подобный подход пока почти не встречается, но, надеемся, через 2–3 года отечественные школы станут более открытыми и к таким инициативам. 

AI-grading и LLM-тестирование. В AI EdTech сейчас ведётся активная работа как за рубежом, так и в России. Если в курс встроен ИИ-проверяльщик (например, для эссе или диалогов на иностранном языке) – это новый, сложный объект тестирования. Нельзя просто прогнать его на «правильных» ответах – нужны тесты на устойчивость к атакам, к попыткам убедить («дай мне 5 баллов, мне очень надо»), к пограничным случаям. Это новая дисциплина, и в EdTech она входит быстро.

Несколько слов о том, откуда у нас экспертиза в EdTech

Чуть в сторону, но в тему. «Лаборатория Качества» сама по себе – это, помимо аутсорса QA, ещё и крупный игрок в EdTech индустрии . Наша онлайн-школа подготовки тестировщиков qaschool.ru работает с 2009 года (17 лет). За это время мы выпустили более 7000 специалистов, многие из которых сейчас работают в командах крупнейших российских компаний.

Мы это рассказываем не для того, чтобы похвастаться, а чтобы подчеркнуть нашу уникальную экспертизу. С одной стороны мы понимаем тестирование как ремесло (потому что обучаем ему), а с другой понимаем EdTech как продукт (сталкиваемся с теми же вебинарами, нагрузкой, биллингом, мобилкой и контентом). И мы регулярно тестируем платформы других школ как внешний QA-партнёр.Эти три роли дополняют друг друга и дают нам широкий контекст, который редко встречается у одного провайдера услуг. 

Проще говоря, мы – один из немногих игроков, кто одновременно развивает собственную EdTech‑платформу и тестирует чужие. Мы хорошо знаем, где у вас болит, потому что у нас тоже болит – иногда ровно в тех же местах.

Вывод

Если свести статью к одной мысли, то качество в EdTech нельзя измерять лишь количеством закрытых багов или зелёным отчетом по регрессии. Образовательная платформа – сложная экосистема: сбой в видео, ошибочный платёж, недоставленный пуш или неудобный интерфейс напрямую влияют на обучение, удержание учеников и выручку. Поэтому тестирование должно охватывать все ключевые аспекты: видео, нагрузку, биллинг, мобильные приложения, безопасность, пользовательский опыт и контент.

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

Если хотите оценить текущее состояние качества на своей платформе, обсудить процессы тестирования или получить независимый взгляд со стороны, обращайтесь в «Лабораторию Качества». Мы много лет работаем с образовательными продуктами, понимаем специфику отрасли – и не только как QA‑партнёр, но и как компания, развивающая собственные EdTech‑проекты.

1. Как россияне оплачивают обучение в 2025 году // Т-Бизнес секреты URL: https://secrets.tbank.ru/trendy/issledovanie-oplat-v-onlajn-obuchenii/ (дата обращения: 02.06.2026). ↩︎