Давно я не писал длинных постов. Думаю, настало время :-) Не знаю, проводилось ли подобное исследование раньше, но я решил провести его для себя. На собеседованиях (на ручного тестировщика) я задавал кандидатам вопрос: «Что вам интересно в тестировании и чем бы вы хотели заниматься?»

В 100% случаев ответ был один — автоматизацией тестирования. Да, я не преувеличиваю: ровно 100%, то есть все без исключения. Ни разу я не услышал ничего другого.

Лучший среди худших ответов звучал так: «Сейчас я понимаю, что мне есть куда расти, но в будущем хотел бы заниматься… автотестированием».

Так отвечают не только джуны, вчера прочитавшие первые статьи про виды тестирования, «белый» и «черный ящик», но и кандидаты с 3–5 годами реального опыта. К последним, естественно, возникает встречный вопрос: «А что мешало заняться этим четыре года назад?»

Но самое печальное вот что: из 100% кандидатов, мечтающих об автоматизации, 97-98% никогда не писали ни строчки кода.

Почему это грустно? Складывается впечатление, что карьера QA-инженера жестко ограничена двумя ролями:

• Ручной тестировщик — для многих синоним «новичка, вкатившегося в IT».
• Автоматизатор — якобы «опытный тестировщик, прошедший огонь и воду в мануальном тестировании и волшебным образом освоивший программирование».

Теперь — мое субъективное мнение.

Почему переход из ручного тестирования в автоматизацию — чаще миф, чем реальность? 1. Работа определяет роль Если вас наняли для ручного тестирования, значит, от вас ждут именно этого. Даже если продукт растет, объем ручных проверок обычно увеличивается, и вы попадаете в замкнутый круг.

2. Обучение с нуля — титанический труд Научить человека программировать, если он никогда этого не делал, — сложно. Нужен горящий идеей наставник и не менее мотивированный ученик. Даже в идеальных условиях процесс требует огромных временных затрат: многочасовые демо, объяснение основ, погружение в используемые фреймворки. У меня был успешный опыт такого обучения, но, оглядываясь назад, понимаю, насколько это было трудно. Таких энтузиастов — и среди учителей, и среди учеников — днем с огнем не сыщешь.

3. Автотестирование ≠ просто «писать тесты» Это еще и разработка инструментов, автоматизация процессов и многое другое. По сути — полноценная разработка.

4. Ну и наконец - вам просто может это не понравиться Писать код — не так просто, как рисуют в рекламных постах. Уже есть десятки статей на том же Хабре про боли разработки - это рутина, часы отладки, постоянное умственное напряжение, недовольство своим кодом спустя неделю… А если добавить костыли в продукте, из-за которых E2E-тесты превращаются в ад, — может возникнуть стойкое отвращение к профессии.

Вернусь к теме ограниченности развития. QA — это не только тестирование. В обеспечении качества огромное количество направлений, где не хватает экспертов:

• инцидент/проблем менеджемент,
• мониторинги,
• релизные-процессы,
• оптимизация рабочих процессов.

Всё это влияет на качество продукта не меньше, а иногда и больше, чем автотесты. Просто об этом мало говорят.

Кто-то возразит: «Инцидент-менеджмент — это поддержка, мониторинги — SRE, релизы — релиз-менеджеры(или SDM)». Но, во-первых, то же самое можно сказать и про автотестирование — для этого есть разработчики, которые уже обладают соответствующими навыками. А во-вторых, как я уже писал ранее, тестирование — это лишь малая часть QA. Хороший QA-инженер — специалист широкого профиля, отвечающий за качество на всех этапах жизненного цикла продукта: от идеи до поддержки и обратной связи от пользователей.

Вместо вывода Я ни в коем случае не принижаю автоматизацию — это важная часть QA. Но хотелось бы видеть в специалистах более широкий кругозор.

Если вы никогда не писали код — возможно, вам это и не нужно? Посмотрите, где вы можете принести больше пользы - и это может быть отнюдь не код.