Выбор языка для автотестов.
Автор: Ксения Райковская, 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> - это ускорит запуск и упростит найм».
Автор: Ксения Райковская, 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> - это ускорит запуск и упростит найм».
❤5🔥3👍2
📕 Необходимые навыки тестировщика, которыми вы уже обладаете - для будущих и начинающих тестировщиков, и тех, кто хочет начать карьеру в IT
На открытом уроке 15 июля в 20:00 мск мы погрузимся в тонкости мышления QA-инженера и его роли в IT-команде:
📗 На вебинаре разберём:
1. Какими базовыми навыками тестирования вы уже обладаете;
2. Различные пути входа в QA с нуля;
📘 В результате разберетесь в тонкостях тестирования и простроите собственный путь входа в IT.
👉 Регистрация и подробности о курсе QA Engineer. Basic: https://vk.cc/cNyusx
Все участники открытого урока получат скидку на курс "QA Engineer. Basic" и Памятку по всем методам тестирования
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFH3SrYG
На открытом уроке 15 июля в 20:00 мск мы погрузимся в тонкости мышления QA-инженера и его роли в IT-команде:
📗 На вебинаре разберём:
1. Какими базовыми навыками тестирования вы уже обладаете;
2. Различные пути входа в QA с нуля;
📘 В результате разберетесь в тонкостях тестирования и простроите собственный путь входа в IT.
👉 Регистрация и подробности о курсе QA Engineer. Basic: https://vk.cc/cNyusx
Все участники открытого урока получат скидку на курс "QA Engineer. Basic" и Памятку по всем методам тестирования
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2W5zFH3SrYG
❤3
Мобильное тестирование: разбираемся с эмуляторами и тестовыми фермами
Наша свежий материал в помощь мобильному тестировщику, в котором мы разбираемся с инструментами для мобильного тестирования — эмуляторами/симуляторами/мобильными фермами и смотрим, что есть на рынке на данный момент.
Читать на testengineer.ru
Наша свежий материал в помощь мобильному тестировщику, в котором мы разбираемся с инструментами для мобильного тестирования — эмуляторами/симуляторами/мобильными фермами и смотрим, что есть на рынке на данный момент.
Читать на testengineer.ru