Как поступишь, если на проекте много тестов и мало времени

Стратегия при большом объёме тестов и ограниченном времени

Это практически универсальная ситуация в реальных проектах. За 10+ лет разработки я выработал несколько проверенных стратегий, которые позволяют обеспечить качество при ограниченных ресурсах.

Шаг 1: Оценка и приоритизация (15-30 минут)

Определить критичность функций

• Critical (P0): функции, без которых приложение не работает
  • Авторизация, главный flow, платежи, database операции
  • Тестируем в 100% случаев
• High (P1): важные функции, влияющие на UX
  • Поиск, фильтры, сортировка
  • Тестируем если есть время
• Medium/Low: все остальное
  • Тестируем в последнюю очередь

Анализ тестового набора

• Сколько тестов есть? 100, 1000, 10000?
• Какой процент покрывают критичные функции?
• Есть ли дублирующиеся тесты?
• Есть ли obsolete (устаревшие) тесты?

Шаг 2: Оптимизация существующих тестов

Удалить ненужные тесты

• Устаревшие тесты на удаленные функции
• Дублирующиеся проверки (если 5 тестов проверяют одно и то же)
• Слишком детализированные тесты (можно объединить)
• Экономия 20-30% времени часто возможна

Оптимизировать существующие тесты

• Объединить несколько простых тестов в один (если независимые)
• Пример: вместо 3 отдельных тестов на валидацию email, паролья, имени — один комплексный
• Убрать redundant assertions

Параллелизация

• Запускать тесты параллельно, а не последовательно
• Если тесты независимы — это может сэкономить 50-70% времени
• Инструменты: pytest-xdist, parallel execution в TestNG

Шаг 3: Умная стратегия выполнения

Risk-based тестирование

1. Определить области высокого риска:
   • Много менялось кода в этом модуле
   • Много найдено багов здесь раньше
   • Критичные бизнес-процессы
2. Fokus на высокорисковые области
3. Для низкорисковых областей: выборочное тестирование

Smoke + Regression flow

• Smoke (10-15 минут): проверяем, что приложение вообще работает
  • Может ли открыться, залогиниться, выполнить основное действие?
• Регрессия (30-60 минут): автоматизированные тесты на критичные функции
• Детальное тестирование: только если smoke и regression прошли

Exploratory тестирование вместо scripted

• Вместо выполнения всех 500 тест-кейсов:
  • Потратить 1-2 часа на свободное исследование приложения
  • Часто находим больше багов, чем по сценариям
  • Более интеллектуальное использование времени

Шаг 4: Автоматизация и инструменты

Максимально использовать автоматизацию

• Запустить все автоматические тесты, пока ты спишь/отдыхаешь
• Вручную тестировать только UI/UX, которые не автоматизируются
• Ratio: 70% автотесты, 30% ручные

Continuous тестирование

• Запускать автотесты после каждого commit
• Не ждать end of sprint для регрессионного тестирования
• Быстро catch баги

Использовать AI-powered инструменты

• Automatic test generation tools (Testim, Applitools)
• Генерируют тесты автоматически
• Экономия 30-50% времени на написание тестов

Шаг 5: Коммуникация с командой

Честно сообщить о ограничениях

• "Я могу протестировать эти 5 критичных функций, но на остальное не хватит времени"
• Указать риски: какие области не протестированы?
• Предложить: можно ли сдвинуть сроки, добавить людей, снизить требования?

Negotiation с Product Owner / Manager

• Показать, что нужно:
  • Либо больше времени
  • Либо меньше функций
  • Либо больше QA инженеров
  • Либо ниже качество (риск)

Шаг 6: Умные техники тестирования

Boundary Value Analysis

• Тестировать не все значения, а граничные
• Вместо тестирования 100 чисел — тестируем 5 граничных
• Экономия: 90% времени, находим 80% багов

Equivalence Partitioning

• Разделить входные данные на классы
• Тестировать по одному представителю каждого класса
• Пример: возраст — дети (1-17), взрослые (18-65), пенсионеры (65+)
• Тестируем по одному из каждой группы, а не всё диапазон

Pair Testing

• Работать в парах (2 QA)
• Один выполняет тесты, второй заполняет результаты, замечает что-то
• Находим больше bagов при том же времени

Мой типичный план при нехватке времени:

За 2 часа до дедлайна:

1. Smoke тестирование (15 минут) ✓
2. Запустить все автотесты (параллельно, пока я работаю)
3. Тестировать вручную 5 критичных потоков (45 минут)
4. Exploratory тестирование последний критичный модуль (30 минут)
5. Составить bug report: найденные проблемы + области без тестирования

Результат:

• Сдаю продукт с известным качеством -明ко указываю риски
• Не претендую на идеальное качество, но на приемлемое

Правило 80/20 (Pareto Principle)

• 80% багов находятся в 20% кода (самые критичные части)
• Сфокусировать усилия на этих 20%
• Вместо тестирования всего — тестируем умно

Когда это реально критично:

Если нет времени даже на минимум:

1. Автотесты: запустить все, что есть
2. Smoke testing: может ли нормально использовать?
3. Критичные баги: нет крахов, потери данных, security issues?
4. Честный отчет: "протестировал в ограниченном объеме, вот риски"

Инструменты, которые помогают:

• pytest-xdist — параллельный запуск тестов
• Allure Reports — красивые отчеты о результатах
• Test management tools — приоритизация и трекинг
• CI/CD pipeline — автоматический запуск после commit
• AI-powered tools — автогенерация тестов

Главное сообщение:

Не нужно стремиться к идеальному покрытию всё по списку. Нужна умная стратегия:

• Приоритизация
• Автоматизация
• Параллелизация
• Честная оценка рисков

Профессиональный QA знает, как находить максимум багов с минимум ресурсов.