Чем дольше я работаю в сфере IT, тем сильнее ощущаю, насколько направление QA недооценено и зачастую недооценено вполне оправданно. Да, можно делать важный вид, придумывать себе заслуги в духе: «настроил процессы», «контролировал качество продукта», «собрал метрики SDLC» и многое другое. Но за этой ширмой очень часто нет реального инженерного содержания. Сплошь и рядом встречаются QA-лиды, которые руководят командой на проекте, но при этом не знают даже стека, на котором написан их собственный продукт. Сеньоры-тестировщики продолжают мучить бедный «черный ящик», даже не пытаясь заглянуть под капот и понять, как система вообще работает. Инженеры с опытом 5+ лет гордо указывают в разделе «достижения» что-то вроде: «сократил время регресса за счет категоризации тест-кейсов». Серьезно? Это - результат пятилетнего пути? Когда задаёшь чуть более сложный вопрос, чем «что такое REST» (и то этот вопрос иногда вызывает ступор), в ответ зачастую слышишь лишь неуверенное: «что-то такое слышал(а), но не сталкивался(лась)». Как можно тестировать микросервисную архитектуру, ни разу не столкнувшись с gRPC, Kafka, синхронными и асинхронными паттернами взаимодействия? Теперь немного про автоматизаторов. Почему-то многие уверены, что их задача - просто писать автотесты, и этим всё заканчивается. Зачем они это делают? Как устроена система, которую они проверяют? Как лучше воздействовать на неё, чтобы выявить фундаментальные проблемы? Эти вопросы, как им кажется, «не про них». Они пишут код, они серьёзные люди, они - разработчики. Итог закономерен: автоматизатор пишет автотесты для проверки микросервисной архитектуры, не имея ни малейшего представления о том, как она устроена. Подобных примеров - множество. И всё это укрепляет мнение разработчиков и менеджеров, что QA - это только про тестирование, а люди этой профессии на большее не способны. Из-за этого настоящим инженерам - тем, кто действительно глубоко понимает предметную область и обладает технической компетенцией, приходится пробиваться через стену непонимания. Им доверяют меньше, не допускают к инфраструктуре и коду, смотрят с подозрением на технические предложения и замечания. К счастью, такие инженеры обычно достаточно упёртые и мотивированные, чтобы всё равно двигать профессию вперёд. Именно они дают надежду, что область обеспечения качества однажды выйдет на заслуженный уровень и перестанет ассоциироваться исключительно с тестированием. Зачем этот пост? Не для того, чтобы пожаловаться. А чтобы донести простую мысль: что-то нужно менять. Если вы узнали себя хотя бы в одной из описанных ситуаций - это повод серьёзно задуматься. Возможно, пришло время изменить вектор развития или даже сменить сферу деятельности. Нам жизненно важно переломить критическую массу в пользу зрелого, глубокого, инженерного QA, которое будет цениться и, что немаловажно, достойно оплачиваться. P.S. Почему возник этот пост? Проанализировав собеседования за последний год, я заметил, что не встретил ни одного инженера по обеспечению качества - только тестировщиков. Со стажем 3, 5, 7 и даже 10 лет. Возможно, это лишь частный случай, но он весьма показателен.