Как тестируешь новую фичу

Мой подход к тестированию новой фичи

Тестирование новой функциональности — это комплексный процесс, который я выстраиваю как многоуровневую стратегию, сочетающую исследовательское тестирование с формальными проверками. Вот ключевые этапы.

1. Погружение в контекст и анализ требований

Перед написанием первого теста я глубоко анализирую задачу.

• Изучаю документацию: ТЗ, пользовательские истории, макеты, API-спецификации.
• Уточняю детали с командой: Провожу мини-встречу с аналитиком/продукт-менеджером и разработчиком, чтобы понять цель фичи, целевую аудиторию и ожидаемое поведение. Задаю уточняющие вопросы: "Что должно произойти, если...?".
• Определяю область тестирования: Что входит в фичу, а что нет. Какие смежные модули могут быть затронуты (регрессионное воздействие).

# Пример: Формирую сценарии на основе истории
Как: Пользователь корзины
Я хочу: Применить промокод
Чтобы: Получить скидку на заказ

Сценарий: Успешное применение валидного промокода
Дано: У меня в корзине есть товары на сумму > 1000 руб.
И: Я ввожу валидный промокод "SUMMER10"
Когда: Я нажимаю "Применить промокод"
Тогда: К заказу применяется скидка 10%
И: Итоговая сумма пересчитывается

2. Проектирование тестов: Многоуровневый подход

Я проектирую тесты, покрывающие все уровни пирамиды тестирования.

• Unit-уровень (совместно с разработчиком): Убеждаюсь, что ключевая бизнес-логика покрыта модульными тестами. Иногда ревьюю их.
• Интеграционное/API-тестирование: Для backend-фич или сложной логики это основа. Тестирую endpoints на валидные/невалидные данные, граничные условия, ошибки.

# Пример pytest для API-теста (псевдокод)
import requests

def test_apply_valid_promocode():
    url = "/api/cart/apply-promo"
    headers = {"Authorization": "Bearer <token>"}
    payload = {"promocode": "SUMMER10", "cart_id": "123"}
    
    response = requests.post(url, json=payload, headers=headers)
    
    assert response.status_code == 200
    assert response.json()["discount"] == 10
    assert "final_sum" in response.json()

• UI-тестирование: Проверяю пользовательский интерф ейс на соответствие макетам, удобство использования, доступность. Ключевой принцип: автоматизирую только стабильные, критические сценарии (например, happy path), основную же массу проверок выполняю вручную и exploratory-манером.

3. Выполнение тестирования: Итеративный цикл

Это основная фаза, где я совмещаю разные техники.

1. Smoke-тестирование: Сначала проверяю, что фича вообще собирается, деплоится и открывается без критических ошибок.
2. Детальное тестирование по чек-листу: Проверяю все запланированные позитивные и негативные сценарии.
3. Исследовательское тестирование (Exploratory Testing): Выделяю отдельный, ничем не ограниченный таймбокс (например, 60-90 минут), где действую как любознательный пользователь или даже "злоумышленник". Цель — найти неочевидные дефекты.

    *   **Техники**: Проверка граничных значений (Boundary Value Analysis), эквивалентных разделений (Equivalence Partitioning), состояния (State Transition), совместимости (кросс-браузерность, разные разрешения).

1. Проверка смежных областей (Impact Analysis/Regression): Тестирую интеграцию фичи с другими модулями системы, чтобы не сломать существующий функционал.

4. Нефункциональные аспекты и завершение

Новая фича должна быть не только рабочей, но и надежной.

• Производительность: Влияет ли новая логика на время ответа? Провожу базовые нагрузочные проверки (например, через JMeter для API).
• Безопасность: Проверяю базовые уязвимости — инъекции, отсутствие авторизации, манипуляцию данными (если фича связана с данными пользователя).
• Документирование и отчетность: Все найденные баги заношу в трекер с четкими шагами воспроизведения, логами и скриншотами. Подготавливаю итоговый отчет для стейкхолдеров: что было протестировано, какие риски покрыты, рекомендации к выпуску.

Ключевые принципы, которых я придерживаюсь

• Тестирование — это не только поиск багов, а оценка качества. Я оцениваю, решает ли фича задачу пользователя.
• Раннее вовлечение (Shift-Left): Чем раньше я включусь в обсуждение, тем больше потенциальных проблем будет устранено на этапе проектирования.
• Четкие критерии приемки (Definition of Done): Фича не готова, пока не протестированы все сценарии, не проведен регресс и не выполнены нефункциональные проверки.
• Автоматизация с умом: Автоматизирую то, что дает максимальную отдачу (критические сценарии, саньити-чеки, API-контракты).

Таким образом, мой метод — это не просто последовательность действий, а гибкий, контекстно-зависимый процесс, нацеленный на минимизацию рисков и обеспечение ценности продукта для конечного пользователя.