Тестирование бота

Цель: получить полное и достоверное представление о том, как бот-ментор @AINanoMentorBot работает «в полях», собрать реальные данные для улучшения UX и обнаружить критические, мажорные и минорные дефекты до запуска в прод.

Общие сведения
1.1 Количество тестировщиков: ровно 20 человек с разными Telegram-аккаунтами (у каждого уникальный tgUserID).

1.2 Тип тестирования: exploratory + script-based.

1.3 Период тестирования: 3 полных календарных дня с момента получения доступа.

1.4 Канал: только интерфейс Telegram-бота (web, desktop, iOS, Android – на усмотрение участников).

1.5 Версия ПО, которую тестируем: релиз «Beta-2» от <дата билда>.
Покрываемые требования (обязательный минимум)
Каждый тестировщик должен «закрыть» хотя бы один пункт в каждой группе. В сумме все 25 функциональных требований (FR) и 2 нефункциональных (NFR) из предоставленных документов должны иметь подтверждённое прохождение (или найденную ошибку).• FR.COMMAND.001–007

• FR.MENTOR.004, 006, 007, 012

• Весь образовательный контент (course.json, уроки 1-25)

• NFR.COMMAND.001, NFR.COMMAND.002 (стойкость к ошибкам и корректная работа FSM)
Тестовые сценарии (выполняются всеми или распределяются по людям – см. план покрытия)
3.1 Happy-path: новый пользователь запускает /start, выбирает режим minimal, последовательно проходит 20 уроков, отвечает на контрольные вопросы (правильно и неправильно), просматривает статистику /stats.
3.2 Happy-path-2: новый пользователь запускает /start, выбирает accelerated, три раза использует «Уже знаю», один раз отвечает неверно, смотрит объяснение, переходит «Следующий урок →».
3.3 Проверка команд: в свободном порядке проверяются /help, /lesson без активного урока, повторный /start, /stats до и после 5 уроков.
3.4 Callback-валидация: ручная отправка callback-id c неподдерживаемым префиксом («foo_bar») – бот не падает, возвращает понятное сообщение.
3.5 Ошибка пользователя: ввод свободного текста вместо кнопки, когда бот ждёт кнопку.
3.6 Устойчивость к обрыву: закрыть Telegram на 10 мин, вернуться – состояние сохранено.
3.7 Кросс-платформенность: минимум 3 пользователя с Android, 3 – с iOS, 2 – с Desktop, 2 – с Web (остальные по желанию).
3.8 Производительность: измерить время между отправкой любой команды и получением ответа (10 замеров на каждого). Цель < 2 сек, фиксируем фактическое.
3.9 WOW-эффект: после прохода не меньше чем 10 уроков вызвать /stats, убедиться, что статистика персонализирована (есть рекомендации).
3.10 ROV-механики: убедиться, что после 5-го урока появляются уточняющие контекст-вопросы (≈30 % вероятности).
3.11 Ошибка сервера: искусственно вызвать 429 (частым спамом /stats) – бот отвечает graceful, ошибка логируется.
Формат отчёта (это «acceptance criteria» – за них платим)

4.1 Одна таблица .xlsx или GoogleSheets.
Обязательные столбцы:
• TesterName
• tgUserID
• Device & OS (пример: iPhone 13 / iOS 17.5)
• Сценарии, выполненные (номера)
• Кол-во уроков пройдено / пропущено / неверных ответов
• Ошибки (Yes/No)
• LinkToArtifacts (папка tester_<tgUserID>)

4.2 Журнал дефектов (в той же книге, отдельный лист «Bugs»):
• BugID (формат BUG-xxx)
• Summary
• Severity (Blocker / Critical / Major / Minor / Trivial)
• Steps to Reproduce (шаг 1 …)
• Expected Result
• Actual Result
• tgUserID репортёра
• Attach (скрин / видео) – ссылка на файл в облаке
4.3 Покрытие требований (лист «Coverage»): матрица «Требование × Tester», отметка Pass / Fail / N/A.
4.4 Итоговый executive summary (один абзац ≤ 200 сл.): общее впечатление, самые критичные проблемы, совет по next-steps.

Требования к артефактам
• Скриншоты: PNG, с тайм-стампом в имени, ключевой шаг перед ошибкой и после.
• Все файлы складываются в облачную папку QA_<ваша_команда>, внутри подпапки per user. Ссылку приложить в отчёте.

Критерии приёмки и оплаты
Оплачивается только при одновременном выполнении следующих пунктов:
A. В отчёте присутствуют ровно 20 уникальных tgUserID.
B. Матрица покрытия показывает 100 % покрытие FR и NFR; для каждого Fail приложён баг-репорт.
C. Не менее 1 Critical-баг или письменное подтверждение, что Critical-багов не выявлено (и почему).
D. Все артефакты доступны, открываются без запроса доступа, соответствуют ссылкам.
E. Executive summary передано отдельным документом (txt или md) и не превышает 200 слов. Не выполнен хотя бы один пункт – отчёт возвращается на доработку без оплаты.
Коммуникации и поддержка
• Все вопросы – в общий чат «QA × MentorBot» (Telegram группа – будет указана).
• Обновления билда во время теста не планируются. Если случится hot-fix, Head of QA проинформирует в чате и приложит change-log.
Сроки сдачи
• Дедлайн загрузки финального отчёта – 23:59 MSK последнего дня теста.
• Проверка и фидбэк заказчика – до +2 рабочих дней.