Выбор языка для автотестов.
Автор: Ксения Райковская, QA Automation Lead в Plata

Сегодня хочу затронуть тему, которая почти всегда вызывает споры. Вопросы по ней часто задают на собеседованиях, мнения на этот счёт - диаметрально противоположные, и правильного ответа нет.

Всё, что написано ниже - моё личное мнение, во многом совпадающее с мнением Alex Pshe и ряда других источников, которые я читала и смотрела.

Способы выбора языка автотестов:

1. По языку backend.
Часто используемая стратегия. Позволяет переиспользовать модели, классы работы с базой, API-контракты. Обычно тесты фронта в таком случае тоже пишут на этом языке, особенно если он достаточно универсален.

2. По языку фронта.
Когда в фокусе UI-часть, в игру вступают JS/TS. Плюсы: можно задействовать фронтов, больше специалистов с таким стеком, сами языки проще. В таком случае и бэк часто тестируется на этом же языке.

3. Разные языки для тестов фронта и бэка.
Иногда UI и API тестируются разными людьми или даже командами. Тогда каждый пишет на «своём» языке. Это рабочий вариант, но если QA-команда одна - жизнь усложняется, падает переиспользуемость, возрастают усилия на поддержку.

4. Язык, не используемый в разработке.
Моё любимое. Исторически сложилось - взяли QA, который писал, скажем, на Python - продолжаем писать на Python, хотя бэк на Go. Бывает, что тесты начинали писать разработчики, выбрали «удобный» фреймворк, который не имеет никакого отношения к тому на чём написан проект, а теперь нанимают QA для поддержки. Ещё причина - рынок - Python и Java QA найти проще и дешевле, чем C# или Go. Иногда уже есть свой фреймворк и обучение в компании - на всех проектах используется один язык - проще перевести людей между проектами и масштабировать best practice и подходы.

5. Низкоуровневые или визуальные инструменты (Katalon, TestComplete и т.п.)
Часто - от руководства. Иногда - это способ перевести ручников в автотестирование. Слышала на собесе историю, где купили дорогущий Katalon «инструмент простой, тестировщики справятся».

Что выбрать?
Универсального ответа нет. Мне ближе первый подход. Но всё зависит от ситуации. Иногда четвёртый - лучшее, что можно придумать, когда нет доступа к коду, когда нужно снизить косты, и повысить ROI.

А что говорить на собеседовании?

Первое - задать встречные вопросы:
• Что уже используется?
• На чём написаны бэк и фронт, есть ли вообще доступ у тестировщиков к коду?
• Планируется ли автоматизация мобилки?
• Что первично - UI или backend?
• Насколько часто меняется код?
• Сколько человек в QA-команде или планируется?

Если всё только начинается - уточни, какой функционал будет покрываться в первую очередь. Если бэк стабилен - его тестировать дешевле и быстрее.

Если стек проекта редкий и проект не очень большой, лучше не настаивать на языке бэка. Можно честно сказать: «у меня есть экспертиза в таких-то стеках. Учитывая, что ваш язык редкий, я бы выбрала <X> - это ускорит запуск и упростит найм».