Обзор оценки по Модулю 2
Поздравляем с достижением последнего урока Модуля 2. Эта комплексная оценка проверяет ваше понимание всех тем, рассмотренных в 35 уроках модуля.
Оценка состоит из трёх частей:
- Вопросы на знания — 10 вопросов quiz в метаданных (ответьте на них до чтения)
- Вопросы по сценариям — Классификация и применение концепций к реальным ситуациям
- Практическое упражнение — Создание стратегии тестирования для нового проекта
Система оценки
- Часть 1 (Quiz): 10 вопросов × 3 балла = 30 баллов
- Часть 2 (Сценарии): 5 сценариев × 6 баллов = 30 баллов
- Часть 3 (Упражнение): 40 баллов
- Итого: 100 баллов. Проходной балл: 70
Покрываемые темы
| Область | Уроки | Ключевые концепции |
|---|---|---|
| Уровни тестирования | 2.1-2.6 | Модульное, интеграционное, системное, E2E, UAT, пирамида |
| Функциональные типы | 2.7-2.10 | Smoke, sanity, регрессионное, ретестирование |
| Нефункциональное | 2.11-2.25 | Производительность, безопасность, юзабилити, доступность, совместимость, надёжность |
| Методы тестирования | 2.26-2.28 | Белый ящик, чёрный ящик, серый ящик |
| Статическое vs. Динамическое | 2.29-2.31 | Ревью, инспекции, статический анализ |
| Исследовательские подходы | 2.32-2.34 | Исследовательское, ad hoc, monkey-тестирование, SBTM |
Часть 2: Вопросы по сценариям
Сценарий 1: Ваша команда только что задеплоила хотфикс безопасности в продакшн, изменяющий поток аутентификации. У вас 30 минут до закрытия окна деплоя.
Какие типы тестирования нужно провести и почему?
Сценарий 2: Медицинское приложение хранит записи пациентов, обрабатывает страховые случаи и генерирует отчёты. Подчиняется требованиям HIPAA. Новая версия добавляет управление рецептами.
Перечислите все типы тестирования по приоритету.
Сценарий 3: SonarQube показывает для PR: 0 багов, 0 уязвимостей, 3 минорных code smell, 45% покрытия нового кода. Quality Gate требует 80%.
Можно ли мержить PR? Какие действия предпринять?
Сценарий 4: Мобильное банковское приложение получает жалобы на «случайные краши», которые QA не может воспроизвести скриптовыми тест-кейсами.
Какие подходы к тестированию вы бы рекомендовали?
Сценарий 5: Ваша компания строит новую e-commerce платформу с нуля. Когда в SDLC должен начаться каждый тип тестирования?
Решение — Сценарий 1
**Smoke-тестирование** (5-10 мин), затем **целевое тестирование безопасности** исправленной уязвимости (10-15 мин), затем **целевая регрессия** функций аутентификации (10-15 мин). Времени на полную регрессию нет.Решение — Сценарий 2
**Критичное:** Функциональное, безопасность (HIPAA), регрессионное, интеграционное. **Высокий приоритет:** Производительность, доступность, совместимость, юзабилити. **Средний:** Восстановление, исследовательское, статическое. **Также:** UAT с медицинскими специалистами.Решение — Сценарий 3
PR не мержить — Quality Gate не пройден. Разработчик должен написать больше тестов, не снижать порог. Исследовать, почему покрытие низкое.Решение — Сценарий 4
Monkey-тестирование с Android Monkey, исследовательское тестирование с SBTM (фокус на быстрой навигации и условиях сети), тестирование совместимости на конкретных устройствах из логов крашей, анализ логов крашей, профилирование памяти.Решение — Сценарий 5
Требования: статическое (ревью). Проектирование: ревью архитектуры. Реализация: юнит-тесты, статический анализ, ревью кода. Интеграция: API-тестирование. Системное: функциональное, регрессионное, исследовательское. Нефункциональное: производительность, безопасность, доступность. Пре-релиз: UAT, E2E. Пост-релиз: smoke, мониторинг.Часть 3: Практическое упражнение — Стратегия тестирования
Вы — QA Lead новой платформы онлайн-обучения: управление пользователями, каталог курсов, видеоплеер, движок квизов, система платежей, уведомления, админ-панель и мобильные приложения.
Создайте стратегию: А (10б): Уровни тестирования и распределение усилий. Б (10б): Матрица типов тестирования по функциям. В (10б): План статического vs. динамического тестирования с инструментами. Г (10б): План исследовательского тестирования с 3 чартерами и управлением SBTM.
Решение упражнения
Часть А: Подход testing trophy (акцент на интеграции). Unit 25%, Интеграция 35%, Системное 25%, E2E 10%, UAT 5%.
Часть Б: Платежи и видео требуют критического уровня безопасности/производительности. Все функции нуждаются в высоком уровне функционального тестирования. Мобильные приложения требуют критической совместимости и юзабилити.
Часть В: Статическое: ревью требований, ревью архитектуры, SonarQube в CI, ревью кода. Динамическое: Jest/pytest для юнит, Postman для API, Playwright для веба, k6 для нагрузки, OWASP ZAP для безопасности.
Часть Г: Чартеры: видеоплеер при деградированной сети, поток платежей и возвратов с граничными случаями, движок квизов под давлением времени. Сессии SBTM по 90 минут, дебриф в течение часа, 2-3 сессии на спринт по высокорисковым областям.
Что дальше
Поздравляем с завершением Модуля 2. Теперь у вас есть всестороннее понимание уровней, типов и методов тестирования.
Модуль 3: Техники проектирования тестов берёт техники чёрного ящика из Урока 2.27 и исследует их глубоко: эквивалентное разбиение, анализ граничных значений, таблицы решений, тестирование переходов состояний, попарное тестирование и многое другое.