Обзор оценки

Поздравляем с достижением последнего урока Модуля 4. Эта оценка проверяет понимание всех тем тестовой документации.

Система оценки

  • Часть 1 (Quiz): 10 вопросов x 3 балла = 30 баллов
  • Часть 2 (Сценарии): 5 сценариев x 6 баллов = 30 баллов
  • Часть 3 (Упражнение): 40 баллов
  • Итого: 100 баллов. Проходной балл: 70

Покрываемые темы

ОбластьУрокиКлючевые концепции
Стратегия и планирование4.1-4.2Тест-стратегия, IEEE 829
Проектирование тест-кейсов4.3-4.5Написание, позитивные/негативные/граничные, тестовые данные
Управление дефектами4.6-4.10Баг-репорты, серьёзность/приоритет, жизненный цикл, Jira
Отчётность4.11-4.13Выполнение, покрытие, примечания к релизу
Процесс4.14-4.16Triage, чек-листы vs кейсы, agile-документация
Продвинутые4.17-4.19Итоговые отчёты, RTM, шаблоны и стандарты

Часть 2: Сценарные вопросы

Сценарий 1: Вы приходите в компанию единственным QA. Документации тестирования нет. B2B SaaS с 50 корпоративными клиентами. Какие документы создаёте первыми?

Сценарий 2: Баг-репорты команды возвращаются с «Cannot Reproduce». Цикл исправления вырос с 2 до 7 дней.

Сценарий 3: CTO просит рекомендацию go/no-go. 88% pass rate (цель 95%), 2 открытых major бага, дедлайн завтра.

Сценарий 4: Регулируемый клиент в здравоохранении требует полную прослеживаемость. Команда использует agile без формальных тест-планов.

Сценарий 5: 200 тест-кейсов для фичи, которая меняется каждый спринт. Поддержка съедает 40% времени QA.

Решения

1. Порядок: Шаблон баг-репорта → чек-лист критических фич → стратегия на 1 страницу → шаблон спринтовых заметок → шаблон итогового отчёта.

2. Корневая причина: плохие баг-репорты. Решение: шаблон с обязательными полями, обучение, peer review 2 недели.

3. No-Go. 88% ниже цели. Предложить: исправить major, перезапустить проваленные, пересмотренный timeline.

4. Гибрид: Agile-спринты + RTM в Jira+Xray + «прослеживаемость проверена» в DoD.

5. Конвертировать в чек-листы для стабильных областей, автоматизировать happy paths, использовать acceptance criteria как спецификации, удалить устаревшие тест-кейсы.

Часть 3: Практическое упражнение

QA Lead для приложения такси с 8 фичами. Создать: стратегию на 1 страницу, 5 тест-кейсов бронирования, баг-репорт отмены, RTM с 6 требованиями.

Решение упражнения

Стратегия: На основе рисков. Критичное: платежи + GPS. Инструменты: Playwright, Appium, k6. Окружения: Dev, QA, Staging.

Тест-кейсы: 1. Бронирование валидной поездки. 2. Запланированная поездка. 3. Негативный: одна точка отправления/назначения. 4. Негативный: нет доступных водителей. 5. Граничный: максимальная дистанция 100км.

Баг-репорт: Заголовок: «С пассажира списана плата за отмену при отмене в бесплатном окне». S1/P1. Чёткие шаги, ожидаемый vs фактический.

RTM: Критический пробел: GPS-трекинг без тест-кейсов. Частичные пробелы: верификация водителя, политика отмены.

Что дальше

Поздравляем с завершением Модуля 4. Модуль 5: Тестирование веб-приложений переходит от документации к практическому тестированию.