Разберемся почему так вышло:

1. Формальный опыт, а не инженерный. Пять лет в мануальном тестировании - это не всегда пять лет развития. Многие QA просто повторяют сценарии и работают в рамках UI-кейсов. Без анализа архитектуры, запросов и логов навык остаётся на уровне «пользователь с чеклистом».

2. Нет перехода от “чек-листа” к “системе”. Она умеет тестировать REST и SOAP, но не понимает, что за ними стоит: какой сервис отвечает, что такое код ответа, где искать источник бага. Отсутствие системного мышления и связи между слоями продукта (frontend–backend–инфраструктура) делает любое «смотреть логи» бессмысленным ритуалом.

3. Отсутствие менторства и инженерной среды. Когда рядом нет технарей, которые объясняют «почему работает именно так», QA остаётся в изоляции. Документация не помогает, потому что без контекста это просто набор инструкций. Ей нужен не курс, а человек, который покажет причинно-следственные связи и даст базу через реальные кейсы.

💡 Итог: человек не глуп, просто его траектория пошла по пользовательскому пути, а не инженерному. Исправляется не за день, но вполне реально, если начать с логики API, структуры ответов и разборов логов по конкретным сценариям.