Обзор оценки

Поздравляем с завершением Модуля 1: Основы тестирования ПО. Эта оценка проверяет понимание всех тем уроков 1.1-1.29.

Оценка состоит из трёх частей:

ЧастьФорматВопросыВремя
Часть 1Quiz с множественным выбором10 вопросов10 минут
Часть 2Вопросы по сценариям3 сценария15 минут
Часть 3Практическое упражнение1 упражнение20 минут

Как использовать эту оценку

Перед началом:

  • Просмотрите свои записи по Модулю 1
  • Не используйте справочные материалы для quiz (Часть 1)
  • Для Частей 2 и 3 можно обращаться к предыдущим урокам

Шкала оценки:

  • Часть 1: 10 баллов (1 за правильный ответ)
  • Часть 2: 15 баллов (5 за сценарий)
  • Часть 3: 15 баллов (рубрика предоставлена)
  • Всего: 40 баллов
  • Проходной балл: 28/40 (70%)

Охваченные темы

  1. Основы тестирования
  2. Мышление тестировщика
  3. SDLC и тестирование
  4. STLC
  5. Уровни тестирования
  6. Типы тестирования
  7. Критерии входа и выхода
  8. Метрики и KPI
  9. Матрица трассировки требований
  10. Улучшение процессов (TMMi и TPI Next)
  11. Регулируемые отрасли
  12. Стандарты (IEEE 829 и ISO 29119)
  13. Тестовая стратегия

Часть 1: Quiz с множественным выбором

Вопросы quiz находятся в метаданных этого урока (10 вопросов). Пройдите quiz перед тем, как приступать к Частям 2 и 3.

Часть 2: Вопросы по сценариям

Сценарий A: QA-вызов в стартапе

Контекст: Вас только наняли единственным QA-инженером в финтех-стартап. Мобильное банковское приложение, 100K пользователей, 20 разработчиков, нет других тестировщиков, деплой дважды в неделю. В прошлом месяце три критических бага попали в продакшн: ошибка расчёта платежей, уязвимость безопасности в логине, проблема отображения на Android.

Вопросы (5 баллов):

  1. Какая фаза STLC выглядит наиболее слабой? Обоснуйте. (2 балла)
  2. Какие 3 метрики вы начнёте отслеживать немедленно и почему? (3 балла)
Решение

1. Наиболее слабая фаза: проектирование тестов и выполнение тестов. Разнообразие ушедших в продакшн дефектов (логика расчётов, безопасность, платформо-специфичное отображение) указывает на недостаточное покрытие тестами. Вторично: анализ требований/планирование.

2. Defect Escape Rate (напрямую измеряет проблему), покрытие тестами по уровню риска (выявляет пробелы), процент успешных деплоев (метрика для руководства).

Сценарий B: Пробел в RTM

Контекст: Команда готовится к регуляторному аудиту. 200 требований, 180 с тест-кейсами (20 без), 50 осиротевших тест-кейсов, 15 отложенных требований без тестов.

Вопросы (5 баллов):

  1. Рассчитайте процент покрытия требований. (1 балл)
  2. Какие три типа пробелов и какой риск у каждого? (2 балла)
  3. Что рекомендуете перед аудитом? (2 балла)
Решение

1. 180/200 = 90% (консервативно) или (185-5)/185 = 97.3% (только активные)

2. Требования без тестов (регуляторный риск), осиротевшие тест-кейсы (риск расползания скоупа), отложенные требования без документации (риск отслеживания).

3. Связать 20 требований, проверить 50 осиротевших тестов, формально задокументировать 15 отложенных, подготовить сводный отчёт RTM.

Сценарий C: Решение об улучшении процесса

Контекст: 300 человек в компании, 5 команд с разными подходами, нет организационной политики, планы по ISO 27001, бюджет $50K/год.

Вопросы (5 баллов):

  1. TMMi или TPI Next? Почему? (2 балла)
  2. Какие первые 3 действия по улучшению? (3 балла)
Решение

1. TPI Next: гибкость для неоднородных команд, ограниченный бюджет, быстрые победы, совместимость с ISO 27001.

2. Создать организационную политику тестирования, стандартизировать отчётность между командами, установить единый процесс управления дефектами.

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

Создайте схему тест-плана

Сценарий: Платформа онлайн-обучения: web-приложение, регистрация, курсы, уроки, квизы, сертификаты, оплата через Stripe, 50K студентов, Next.js + Go + PostgreSQL + AWS, 25 разработчиков, 5 тестировщиков, двухнедельные релизы, необходимо соответствие GDPR.

Задание: Создайте схему, включающую: скоуп, оценку рисков, подход к тестированию, критерии входа/выхода, ключевые метрики, распределение ресурсов.

Рубрика (15 баллов):

КритерийБаллыОписание
Чёткость скоупа3Ясный скоуп с обоснованием
Качество оценки рисков3Реалистичные оценки с аргументацией
Полнота подхода3Охватывает все релевантные типы тестирования
Критерии входа/выхода2Измеримые и реалистичные
Релевантность метрик2Привязаны к целям качества
Распределение ресурсов2Практичное использование команды
Подсказка

Оплата = наивысший риск. Квизы должны быть точными (влияют на сертификацию). Сертификаты должны быть надёжными. Учтите GDPR. С 5 тестировщиками и двухнедельными релизами автоматизируйте регрессию.

Решение

Скоуп: В скоупе: все потоки студентов, оплата, API testing, кросс-браузерное, производительность, безопасность, GDPR, доступность. Вне скоупа: админ-панель создания курсов, аналитика.

Риски: Оплата (Критический/Средний), квизы (Высокий/Средний), сертификаты (Высокий/Низкий), уроки (Высокий/Низкий), регистрация (Средний/Низкий), прогресс (Средний/Средний).

Подход: Unit testing (разработчики, 80% покрытия), API-автоматизация, E2E с Playwright (критические пути), ручное исследовательское каждый спринт, производительность с k6, безопасность с OWASP ZAP. Автоматизация: 70% регрессии за 6 месяцев.

Критерии: Вход: интеграционное тестирование завершено, билд в staging, данные подготовлены. Выход: 95% выполнение, 0 Critical, <3 High, поток оплаты 100%.

Метрики: DRE >90%, Defect Escape Rate <5%, автоматизация 70%, дефекты оплаты = 0.

Ресурсы: Тестировщик 1: автоматизация + оплата. Тестировщик 2: автоматизация квизов. Тестировщик 3: ручное для новых фич. Тестировщик 4: кросс-браузерное + GDPR. Тестировщик 5: производительность + безопасность.

Что дальше

Если вы набрали 28+ из 40, вы готовы к Модулю 2: Уровни и типы тестирования. Если набрали меньше 28, пересмотрите темы, где потеряли баллы. Нет ничего плохого в повторении — цель в прочном понимании, а не в скорости.

Модуль 2 будет строиться непосредственно на концепциях Модуля 1, углубляясь в уровни тестирования (модульное, интеграционное, системное, приёмочное) и типы (функциональное, нефункциональное, структурное, регрессионное). Фундамент, заложенный здесь, значительно облегчит Модуль 2.