l_konstantin
/
TestingWebApp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
19 Commits
2 Branches
0 Tags
2.4 MiB
Tree: 4801ea9f19
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '4801ea9f19'
${ noResults }
TestingWebApp/docs/revision_task/sprint-01-testing.md

4.8 KiB
Raw Blame History

Спринт 1 — тестирование (версионирование)

Актуальный ведённый журнал (авто + ручные шаги, ответы ОК/не ОК): TESTING_JOURNAL.md — этот файл остаётся как подробный черновик сценариев.

Ниже: автоматизировано / проверено при разработке и ручная приёмка — дублирует структуру; статусы переносите в TESTING_JOURNAL.md.

Окружение: зафиксировать ветку/коммит, URL стенда, тестовые учётки (роль автора, роль сотрудника).

1. Автоматизировано и self-check (разработка)

Отмечайте [ ] → [x] по мере выполнения.

1.1 Автотесты и статический анализ

  • Unit-тесты правила «0 попыток — правка на месте без новой версии»
  • Unit-тесты: после появления попытки — сохранение создаёт новую версию, старая неактивна
  • Тест: попытка хранит version_id совпадающий с версией, по которой проходили
  • Integration/API: нельзя «потерять» цепочку при смене активной версии
  • Линтеры/CI зелёные на MR спринта 1

1.2 Смоук вручную (быстрый) перед передачей

  • Создать тест, несколько раз сохранить до назначения/прохождения — версия одна
  • Назначить, пройти тест, снова изменить тест — новая версия, старая в истории
  • Список тестов у сотрудника без дублей цепочки
  • Смена активной версии: новые прохождения идут по новой активной; старая попытка в разборе по старой версии

2. Ручная приёмка (я / заказчик)

Сценарии для прогона в «боевом» темпе, без доступа к коду.

2.1 Автор: жизненный цикл без попыток

  • Создать тест, изменить вопросы/порог — всё в одной версии, номер версии ожидаемо стабилен
  • Убедиться, что в UI явно видно, что тест ещё «ни разу не проходили» (если предусмотрено ТЗ/UX)

2.2 Сотрудник + первая попытка

  • Назначить тест, пройти его полностью
  • Как автор изменить вопрос/варианты, сохранить — появляется новая версия; старая доступна в истории

2.3 Корректность данных

  • Открыть разбор/результат старой попытки: формулировки вопросов и правильные ответы соответствуют той версии, с которой проходили
  • Новое назначение/новое прохождение — по актуальной активной версии

2.4 Управление версиями

  • История версий отображается полностью и понятно (номера, даты при наличии)
  • Переключение активной версии на предыдущую: списки обновляются; новая попытка идёт по выбранной версии
  • Деактивация теста: цепочка не светится сотруднику; данные на месте, старые результаты открываются (если доступ по ролям предусмотрен)

2.5 Визуальная согласованность

  • Экраны редактора и списков визуально согласованы с остальным internal web (отступы, шрифты, кнопки, таблицы, ошибки) — без отклонения от принятого дизайна

2.6 Негатив

  • Попытка не может «сломать» цепочку (ошибки пользователю понятны)

Итог приёмки спринта 1: дата __________, подпись/комментарий _________________________