Основы тестирования и тест-дизайнПроектирует стратегию тестирования изменения с явным приоритетом рисков: что проверять до релиза, что покрыть регрессией, а что не тестировать сейчас. Обосновывает выбор между исследовательским тестированием, автоматизацией и проверкой по чек-листу с учётом цены ошибки и частоты изменений.
Тестовая документация и дефектыПроводит ревью тестовой документации и находит конкретные пробелы: неописанный негативный сценарий, неоднозначный expected result или неучтённое бизнес-правило. Обосновывает, когда тест case избыточен и его стоит заменить поддерживаемым чек-листом либо автотестом.
Web, клиент–сервер и инструменты браузераАнализирует сложный web-дефект, воспроизводящийся только в конкретном браузере, сети или состоянии сессии; формирует гипотезы и проверяет их через HAR, throttling или логи. Обосновывает минимальный набор браузеров/устройств для тестирования по рискам продукта, а не «во всех версиях на всякий случай».
API-тестированиеПроектирует набор API-проверок для интеграции нескольких сервисов: контракт, версии, ошибки и повторные запросы. Обосновывает границу между API-, contract- и end-to-end-тестами для конкретного риска; определяет, какой сигнал позволит быстро локализовать поломку контракта.
SQL и проверка данныхПроектирует запрос или набор сверок для проверки миграции/сложной бизнес-логики, включая дубли, пропуски и нарушение связей. Обосновывает, когда проверка должна идти на уровне БД, API или UI, и какие ложные выводы даст каждый из вариантов.
Нефункциональное тестирование: производительность и безопасностьОбосновывает приоритет нефункциональных проверок для релиза по риску: какие сценарии нагрузки, авторизации или отказа критичны именно этому продукту. Сравнивает варианты защиты/проверки (например, rate limit, валидация на сервере, контроль прав) и объясняет, какой риск остаётся после выбранного решения.
Автоматизация, CI/CD и тестовые окруженияДля заданной фичи формирует слой автоматизации: какие проверки оставить unit/API/UI, как изолировать данные и какие сигналы позволят локализовать падение. Для заданного pipeline разделяет быстрые проверки и тяжёлые e2e так, чтобы сократить обратную связь без потери критичных рисков; устраняет системную причину flaky-теста, а не повышает timeout.