Category: Тестирование

17
Окт
2021

Запрос GET в Postman срабатывает через раз, когда переменным в Environment присваиваются Динамические переменные

Тестирую API https://petstore.swagger.io
У меня два метода:
POST создает Юзера. Вот этот https://petstore.swagger.io/#/user/createUser
В body запроса:
{
"id": {{$randomInt}},
"username": "{{usr}}",

12
Окт
2021

Avito PaaS Meetup #1

На митапе специалисты Авито расскажут о разработке, доставке и эксплуатации сервисов, а также об автоматическом тестировании.
— Читать дальше «Avito PaaS Meetup #1»

08
Окт
2021

Конференция HighLoad++ 2021

Крупнейшая в Европе IT-конференция для разработчиков высоконагруженных систем. В программе более 130 докладов, персональные консультации и полезные знакомства.
— Читать дальше «Конференция HighLoad++ 2021»

06
Окт
2021

Повторяющиеся слова в тексте на Python

Есть вот такая задача: Напишите программу, которая считывает текст из файла (в файле может быть больше одной строки) и выводит самое частое слово в этом тексте и через пробел то, сколько раз оно встретилось. Если таких слов несколько, выве…

06
Окт
2021

Как создать очередь из взаимосвязанных REST API запросов?

Имеется два независимых друг от друга REST API, для взаимосвязи которых используется/разрабатывается промежуточный сервис, который с определённым интервалом взаимодействует с ними обеими. Стоит отметить, что оба API недоступны для изменени…

01
Окт
2021

Какое из 8 направлений IT-стажировки вам подходит? Тест от Tproger и Kaspersky

Шуточный тест, чтобы определить, какое направление стажировки SafeBoard может вам подойти. Просто выбирайте решения, которые вам ближе всего.
— Читать дальше «Какое из 8 направлений IT-стажировки вам подходит? Тест от Tproger и Kaspersky»

15
Сен
2021

Курсы Skillbox по программированию за 0 рублей

Skillbox открыл бесплатный доступ к курсам по программированию на 7 дней. Можно выбрать среди направлений: введение в программирование, веб-вёрстка, тестирование, Python, 1С и Go-разработка.
— Читать дальше «Курсы Skillbox по программированию за 0 рубл…

15
Сен
2021

Набор на стажировку в Dell Technologies

Dell Technologies приглашает студентов дневного отделения технических вузов Санкт-Петербурга на оплачиваемую стажировку. На выбор есть 5 направлений: программирование на Java, C++ или Python, тестирование ПО, DevOps и администрирование.
— Читать дальше…

14
Сен
2021

🛠 Осваиваем инструменты QA-инженера или как ручному тестировщику работать с REST API

Изучишь REST API – останешься в Стране Чудес, и я покажу тебе, насколько глубоко уходит кроличья нора и как удобнее всего в нее нырнуть.

Пусть за спиной остался не один баг-репорт, написан не один ручной тест и пройден не один регресс, но почему все еще кажется, будто мир тестирования так и не открыл свои тайны? Ответ прост: пора двигаться дальше. Ведь баги возникают не просто так, и веб-браузер – это не картинка на экране.

Общение между сервером и клиентом, краткое определение REST API

Большинство веб-приложений в современном мире работают на клиент-серверной архитектуре. Основной ее смысл в том, что сетевая нагрузка распределена между поставщиком (сервер) и потребителем (клиент). Общение между ними осуществляется через сетевые протоколы, но для любого общения нужны правила, и тут мы как раз подходим к REST API.

Схема клиент-серверной архитектуры.
Схема клиент-серверной архитектуры.

REST (Representational State Transfer) – это набор правил взаимодействия компонентов распределенного приложения, которые включают в себя следующие требования (ограничения):

  • отделять в архитектуре клиент от сервера;
  • в период между запросами клиента никакая информация о его состоянии не должна храниться на сервере;
  • необходима возможность кэширования ответов сервера;
  • необходимо единообразие интерфейса для возможности независимого развития каждого сервера;
  • необходимо предоставлять возможность добавления слоев между клиентом и сервером для лучшей масштабируемости и безопасности.

Почему большинство веб-приложений используют REST?

Если REST API – набор способов, подчиняющихся определенным правилам, то зачем большинство web-приложений используют такое сочетание?

  • Правила порождают порядок и единообразие. Это облегчает работу с кодом, а также его чтение.
  • Сервисы становятся масштабируемыми, что дает возможность сделать приложение отказоустойчивым и более безопасным.
  • Появляется возможность более легкого исправления ошибок и внесения изменений.
  • Прозрачность связей между компонентами также упрощает чтение и работу с кодом.

Перечислять можно долго, но основной смысл в том, что такой подход упрощает работу и систематизирует код.

Определяем где ошибка, классификация кодов HTTP

Хватит общих слов. Пора переходить к практике: нужно открыть devtools браузера (нажать клавишу F12) и перейти во вкладку Network (можно настроить фильтр на показ XHR, так будет удобнее).

Скриншот браузера с открытой панелью devtools.
Скриншот браузера с открытой панелью devtools.

Колонка статуса показывает статус выполнения запроса, прошел ли он успешно, или была допущена ошибка. Если кратко, то статусы можно для простоты сортировать следующим образом:

1xx Информационные сообщения. Например, 102 – идет обработка запроса.
2xx Успешное сообщение.
3xx Была проведена переадресация, т.е. запрашиваемая информация больше не находится по этому адресу и запрос полетел по другому адресу.
4xx Ошибка на стороне клиента. Т.е. нужно изменить запрос или его заголовки, например.
5xx Ошибка на стороне сервера. Можно открыть логи (если есть возможность) и поискать ошибку.

Допустим, был интересен определенный запрос, потому что именно его меняли в нужном релизе, или его статус указывает на ошибку. Чтобы посмотреть информацию по запросу, нужно дважды щелкнуть (уверена, что знаете, но проговорить нужно):

Скриншот браузера с открытой devtools.
Скриншот браузера с открытой devtools.

Основная информация, которую можно посмотреть по запросу, начиная работать с REST – это первые три вкладки:

  • Headers – заголовки и основная информация.
  • Preview – посмотреть тело запроса.
  • Response – посмотреть тело ответа.

Остальные вкладки можно рассмотреть как-нибудь потом.

На первой вкладке содержится общая информация по данному запросу, а также header, которые в нем используются (дополнительная информация к запросу, передаваемая между сервером и клиентом).

В общей информацией указан метод, который используется в запросе (в данном случае GET). Основные используемые методы (о других можно дополнительно почитать здесь).

GET Получение данных. Например, чтобы загрузить статью на странице.
POST Создание сущности.Например при создании нового пользователя.
PUT Обновление сущности. Например изменение пароля или логина у уже существующего пользователя или заголовка статьи.
DELETE Удаление сущности. Например удаление статьи, пользователя или теста. Иногда вместо DELETE используется PUT с пустым телом запроса.

Еще нужно обратить внимание на такой заголовок как Content-Type. Он отображает в каком формате передаются данные в запросе: json, xml или text.

Инструменты тестировщика для работы с REST

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

Первый инструмент, который не требует никакой дополнительной установки – это devtools используемого браузера. Достаточно нажать F12 и начать отслеживать, какие запросы летят и нет ли ошибок, которые нужно задокументировать в баг.

Второй инструмент, который всегда под рукой у пользователя Unix/Linux – это curl (в Windows нужно будет его специально установить). Чтобы посмотреть информацию по этой утилите, достаточно набрать следующую команду в терминале:

        man curl
# или
curl --help

    

Для начала можно попробовать отправить GET-запрос и получить ответ:

        curl -i https://proglib.io/posts/fetch
    
Непонятные символы появились, потому что нет русификации консоли.
Непонятные символы появились, потому что нет русификации консоли.

Был повторен GET-запрос и получен ответ. Используя ключ -i, можно посмотреть дополнительную информацию. Дальше можно попробовать отправить POST-запрос, сразу же отправив header content-type:

        curl -i -X POST -d '' -H 'content-type: application/json' https://proglib.io/post/info
    
Консоль с вызванным curl.
Консоль с вызванным curl.

В нашем запросе -X POST показывает, что используется метод POST (по умолчанию отправляется метод GET), -d ‘’ – тело запроса (в данном случае пустое) и -H 'content-type: application/json' – заголовок, показывающий, что тип сообщений – json. В ответ пришел статус 400, значит тело запроса нужно менять.

Немного освоив curl, можно переходить к более высокоуровневому инструменту. В статье я рассмотрю Postman, но есть и другие варианты.

Postman – свободно распространяемая программа с платным контентом для взаимодействия в команде. Для работе в ней нужно зарегистрировать свою почту на официальном сайте и скачать десктопную версию (хотя можно работать и через браузер). Также для Postman есть официальная документация и обучающие видео.

Начнем с отправки того же самого GET-запроса, что и с помощью curl:

Скриншот программы Postman.
Скриншот программы Postman.

На картинке видно, что заголовки были заполнены автоматически. Ответ более читаемый, чем при запросе с помощью curl.

Теперь можно отправить POST-запрос, тело которого также будет пустым, и будет прописан указывающий тип запроса header:

Скриншот программы Postman.
Скриншот программы Postman.

Был получен такой же ответ с таким же статусом, как и при отправке запроса с помощью curl.

Postman умеет еще множество вещей: можно собирать запросы в коллекции, писать тесты на Java Script, осуществлять мониторинг определенных запросов, документировать их и т.д.

Выводы

Можно продолжать тестировать только клиентскую часть, раз за разом проводя тест-дизайн, пытаться отловить ошибку и не пытаясь проанализировать ее с точки зрения кода программы… Но разве этого достаточно? Разве не хочется заглянуть под картинку и увидеть, как все работает?

В статье описаны основы и показаны некоторые инструменты. Открытие консоли браузера – только первый шаг, который ведет к нагрузочному тестированию, автоматизации rest-test или пониманию, как все устроено. Однако дорогу осилит идущий, а в следующих публикациях мы разберем и более сложные темы. Удачи!

***

Если вы только начинаете осваивать профессию, стоит обратить внимание на Факультет ручного тестирования образовательной онлайн-платформы GeekBrains. Обучение длится всего 10 месяцев и включает теоретическую часть, практику с четырьмя проектами в портфолио и как бонус – диплом о профессиональной переподготовке с гарантированным трудоустройством. Программа обучения актуальна, а занятия ведут практикующие специалисты российских технологических компаний.

07
Сен
2021

Test Automation Hackathon

EPAM проведёт первый в СНГ онлайн-хакатон для автоматизаторов – Test Automation Hackathon. Это командное соревнование как для действующих автоматизаторов, так и для всех, кому интересна автоматизация тестирования.
— Читать дальше «Test Automation Hacka…

01
Сен
2021

Курс «Профессия разработчик»

За 15 месяцев новички разберутся в сфере разработки, выберут направление и прокачаются в нём, чтобы устроиться в компанию или открыть свой бизнес в IT.
— Читать дальше «Курс «Профессия разработчик»»

31
Авг
2021

«Свою первую работу по тестированию я нашел случайно»

Порог входа в сфере тестирования ПО довольно низок, но стать высококлассным инженером по Quality Assurance непросто: Вячеслав Зимин рассказал нашему корреспонденту о своем пути в профессию.

31
Авг
2021

🗣 «Свою первую работу по тестированию я нашел случайно»

Порог входа в сфере тестирования ПО довольно низок, но стать высококлассным инженером по Quality Assurance непросто: Вячеслав Зимин рассказал нашему корреспонденту о своем пути в профессию.

Где вы учились и как решились пойти в тестирование?

Я из города невест – Иваново. Получил высшее образование по специальности физика, а также дополнительный диплом учителя. Еще во время обучения в университете устроился работать преподавателем. Вел два предмета – физику и информатику. После окончания вуза остался там работать, хоть это и не совсем то, что мне было нужно: изначально я хотел связать жизнь с программированием, к тому же меня не устраивали условия работы и не хватало зарплаты.


Я начал все чаще смотреть в сторону IT и в свободное время занимался программированием, одновременно изучая вакансии, и однажды наткнулся на вакансию тестировщика. 11 лет назад еще не было такого количества курсов, поэтому тестирование я тоже изучал самостоятельно. Курсы проходил уже после трудоустройства.


Как вы нашли первую работу?

Первую работу по тестированию я нашел случайно. Будущая жена скинула мне вакансию тестировщика игр с городского форума. После нескольких дней многочасового самостоятельного обучения я решил попробовать. Не помню, спрашивали тогда мое резюме или нет, но точно давали тестовое задание. Мое заключалось в том, чтобы найти и оформить баги в игре, которая уже была выложена в соцсеть. Его выполнение стало переломным моментов в моей карьере. Оказалось, что мне интересно тестировать, интересно смотреть, правильно ли все работает и находить баги.

После того тестового меня приняли. Это казалось чем-то невероятным. Приятный офис в бизнес-центре, кофе и сама атмосфера была отличная. Так началась моя карьера в тестировании. Тогда конкурс на стартовую позицию был намного ниже чем сейчас и требования были не такими высокими.

В то время никакие сертификаты для трудоустройства не требовались. Даже когда я сам через несколько лет принимал людей на работу, мы рекомендовали литературу и выдавали тестовые задания во время собеседований. Это только последние несколько лет наличие сертификата стало для работодателя одним их критериев первоначального отбора, поскольку оно подтверждает серьезность намерений кандидата. Поскольку многие рассматривают тестирование как временную работу, чтобы войти в сферу IT, работодатели с каждым годом повышают планку.

Какие знания умения и навыки вам потребовались на позиции джуниора?

В первую компанию (как оказалось, это был стартап) только с общим представлением о профессии и с невероятным желанием работать в этой сфере. Может быть именно этот факт зацепил моего работодателя. В команде я был единственным тестировщиком, и все знания пришлось добывать самому. Отчасти мне помогла книга “tестирование dot com”. Еще я много общался с программистами, получал от них фидбек и смотрел, как сделать свою работу и процесс лучше и эффективнее. Каждый день читал форумы и статьи, чтобы понять все нюансы работы и выстроить правильный процесс тестирования.

Инструментов тестирования в компании тоже не было, все делали либо в чате, либо в документах Google. Я самостоятельно познакомился с Testlink (инструмент для хранения тест-кейсов), установил и начал в нем работать.

Легко ли вам было с начальной позиции перейти к уровню middle?

В этом стартапе я проработал примерно год. Потом у компании дела пошли хуже. Новых продуктов не было, а старые не приносили должного дохода, поэтому сократили почти всю команду и оставили только несколько сильных программистов. В это время открылась вакансия тестировщика в крупной компании Social Quantum, и я решил попробовать свои силы там. В этот раз предварительного тестового задания не было, и меня пригласили сразу на собеседование. Вернее, их было два. Сначала собеседование с hr, где спрашивали теорию, а потом пригласили в офис на второе собеседование. Тут уже были практические вопросы и задания, т.е. меня попросили оформить баг-репорт и написать тест-кейс.

С тестовыми заданиями я справился успешно, и меня пригласили опять же на позицию джуна. В компании тогда еще не было своего отдела тестирования, но была команда на аутсорсе и все тест-кейсы были уже в инструменте Testlink (с которым я так удачно познакомился на предыдущей работе). Именно в этой компании началось мое карьерное развитие.

Когда мы только развивали тестирование, то не пользовались какими-то сложными техническими инструментами. По мере развития самой команды и тестирования в компании мы постепенно расширяли и техническую экспертизу. Мы тестировали игры, и по сути не было какого-то адекватного API – пришлось выкручиваться и пробовать реализовать end-to-end-тесты. Было перепробовано много инструментов и один из них мне запомнился: я его долго пытался приноровить к специфике тестирования игр – это TestComplete. К сожалению, он нам не подошел, и мы решили остановиться на скрипте по распознаванию изображений Sikuli. Именно тогда мы и стали развивать автоматизацию в компании.

Что касается инструментов ручного тестирования, то в ходу у нас были вполне стандартные Charles и Android SDK. В ручном тестировании каких-то специальных инструментов мы не использовали. Была админка игры и прямые руки тестировщика.

В этой компании я проработал лет 5 или 6. Хотя у нас и не было четкой градации по должностям, но точно могу сказать, что вырос за тот год из джуна в миддл-позицию. Еще через год я прошел курс тест-аналитика и стал уже лидом небольшой команды. Еще через год мы с руководителем отдела решили сделать внутренние курсы по тестированию. У меня было достаточно опыта и педагогическое образование, к тому же я постоянно обучался, так что особых проблем с созданием первого собственного курса не было. Плюс за все эти годы работы тестировщиком мое желание преподавать никуда не делось. И это как раз была отличная возможность соединить два любимых занятия: преподавание и тестирование.

Легко ли со средних позиций перейти к уровню senior QA и что для этого нужно?

Все зависит от самого человека, от его желания, мотивации и стремления. У меня был случай, когда сотрудник за год упорной работы перешел из джуна на позицию синьора, но он выкладывался по полной. И конечно же дело тут не ограничивается только хард-скиллами. Для меня senior QA – это не только сильный технический специалист, но и самостоятельный сотрудник, который может сам решать проблемы, организовывать свое время, расставлять приоритеты в работе и так далее. Тот человек, которому дал сложную задачу, и он ее выполнит в оговоренное время. При этом ты не переживаешь, что что-то может пойти не так.

Если хочешь из мидла вырасти в сеньора, ты должен стараться показывать своему руководителю, что готов брать на себя задачи и можешь самостоятельно решать проблемы. Однако главное тут – не перегнуть палку с самостоятельностью и инициативностью.

Если инженер по QA уровня middle считает себя готовым к переходу в высшую лигу, как проверить, что он не ошибается?

В одной из компаний, где я работал, был очень хороший подход в этом плане. Давалась возможность попробовать себя на определенной позиции. Т.е. специалист сначала получал новые зоны ответственности на несколько месяцев, далее смотрели как он работает, выдавали подробный фидбек, и если все шло хорошо, его переводили на новую должность. Либо просто закрепляли те зоны ответственности, которые брали на себя. Такой подход хорошо себя показывал, так как позволяет посмотреть, успешно ли сотрудник справиться с новыми обязанностями.

Если такой возможности нет, я обычно смотрю на развитие тестировщика за время работы в компании – как он себя показывал. Оцениваю, может ли он потенциально потянуть новые обязанности и как эффективно будет их выполнять. При необходимости можно опросить команду, иногда они дают полезную информацию. И обязательно нужно обговорить со специалистом, что произойдет, если он не справится, чтобы в дальнейшем не было сложностей и неприятных неожиданностей. Лучше проработать план «Б», если человек не потянет новую нагрузку.

Как самому сотруднику проверить, что он не ошибается и готов к переходу?

Я считаю, что если специалист уверенно справляется с текущими обязанностями и чувствует, что ему стало скучно, это повод задуматься о дальнейшем росте. Узнать наверняка, точно ли ты готов к переходу или нет, можно выполнив задачи более высокого уровня. Это можно сделать в свободное время или на своем проекте, попросив о таких заданиях руководителя.

Что потребуется изучить и какие навыки наработать, чтобы выйти на уровень senior?

Для позиции senior QA надо разделять направления и специализации. Если мы говорим про мобильное тестирование, опытный специалист должен знать основную базу того, с чем он работает. Как минимум это особенности тестирования мобильных устройств и операционных систем. У него должен быть уверенный опыт с инструментами тестирования мобильных приложений. Он должен знать и разбираться в таких вещах как Android SDK и XCode. Кроме того, будет плюсом если он знает про работу с эмуляторами и имеет опыт в автоматизации. Хорошо знает тестирование API, его особенности, умеет работать с инструментами тестирования API и разбирается в клиент-серверной архитектуре. Для веб-тестирования сюда же можно включить API и клиент серверную архитектуру, хорошее знание протоколов и запросов, знание HTML, CSS, DevTools.

Перечислять можно очень долго. Основная сложность, на мой взгляд, в том, что у нас нет единого стандарта и многое зависит от специфики компании. Я видел ситуации, когда человек уходил синьором из одной компании и приходил на уровень ниже в другую, где были иные требования к синьорам. Думаю, единственное, что остается неизменным – это хорошая база.

Такой специалист должен идеально знать как составлять тест-кейсы, чек-листы, баг-репорты. Разбираться в терминологии тестирования, знать процессы тестирования и в целом процессы разработки ПО. Знать и уметь работать с основными инструментами (Bug Tracking System, Test Management System) и конечно иметь опыт в тестировании – обычно от 3 лет и выше. Также в некоторых компаниях синьор может выдавать фидбек младшим специалистам и быть для них наставником. В этом случае ему потребуется развивать и софт-скиллы.

Как лучше строить карьеру? Тут нет однозначного ответа. Каждый решает сам для себя. Кому-то комфортно расти в одной компании и никуда не уходить, а другим интересней работать в разных местах. По опыту скажу, что расти все-таки лучше в свободном плавании. В компании не всегда есть место для роста и это задерживает развитие кандидата. Кроме того, разные компании – это более обширный опыт.

Как у вас родилась идея создать собственное сообщество?

Именно из-за желания учить других в 2015 году я взялся за разработку внутренних курсов компании. Когда перешел в новую, там не было возможности проводить обучение сотрудников, тогда у меня родилась идея обучать тестированию всех.

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

Если в самом начале я был один и обучал самостоятельно, то сейчас есть целая команда опытных тестировщиков, которые помогают начинающим специалистам обучиться и устроиться на работу.


Какие инструменты вы чаще всего используете и почему?
Так как я уже перешел из тестирования в управление тестированием, взаимодействовать с инструментами приходится все меньше. Тем не менее, иногда приходится браться за старое. Не могу выделить какие-то отдельные инструменты, которые используются чаще всего, потому что это зависит от задач. Единственный инструмент, которым я чаще всего пользовался в работе – это TestRail, так как тестировщик всегда имеет дело с тест-кейсами.

Что в тестировании самое важное?

Думаю, в тестировании самое важное – это качество. Тестировщик всегда должен стремиться сделать продукт качественней и стабильней. Нужно смотреть на него шире: не только глазами тестировщика, но и глазами пользователя. Можно часами закапываться в мелкие и несущественные баги, но не видеть основных проблем.

Еще важно, чтобы каждому участнику команды нравилась его работа. Именно тогда команда становиться сильной и это значительно повышает качество тестирования.

***
Реклама
Если вы только задумались о карьере в Quality Assurance или ручные тесты вам уже не в диковинку, стоит обратить внимание на курс автоматизации тестирования на Python от образовательной онлайн-платформы GeekBrains. Практикующие специалисты помогут вам освоить основы профессии и техники тест-дизайна, а также научат писать автотесты на Python. Успешно завершившие курс студенты получат диплом о профессиональной переподготовке и добавят в портфолио 4 проекта, а площадка поможет им с трудоустройством.

31
Авг
2021

👨‍🔧️ Сколько зарабатывают тестировщики в России и в мире?

О тестировщиках стали говорить все чаще. Правда ли, что у специалистов по Quality Assurance низкая зарплата? Развеем мифы и рассмотрим советы по поиску работы в сфере QA и QC.

Пандемия способствовала расширению прав и свобод тестировщиков, ведь они могут работать на удаленке практически из любой точки мира. Однако, требования к специалистам увеличились, что не скажешь про уровень оплаты. Рассмотрим подробнее зарплаты и требования к QA и QC специалистам.

Заработная плата тестировщиков в России

В России зарплата тестировщика начинается от 20 000 рублей (да, да, скептики закидают меня помидорами, но таковы суровые рыночные реалии). Если верить данным сайта russia.trud.com, джуны получают 20 – 100 тысяч рублей в месяц, мидлы – в диапазоне 70 – 160 тысяч, а у сеньоров зарплата стартует от 100 тысяч рублей (некоторые зарабатывают в месяц и по 300 тысяч, кому как повезет).

По данным все того же russia.trud.com, средняя заработная плата тестировщика в России составляет 46 353 рубля в месяц. Это как средняя температура по больнице: если взять морг и инфекционное отделение, можно получить близкий к физиологической норме показатель.

Средний уровень зарплаты тестировщиков за год.
Средний уровень зарплаты тестировщиков за год.

Навыки специалиста напрямую влияют на уровень его заработной платы. Приведу минимальные требования работодателей.

Итак, если вы претендуете на позицию тестировщика, вам нужно:

  • Разбираться в локализации дефектов и уметь их заводить.
  • Знать техники тест-дизайна, тест-анализа и тестовой комбинаторики.
  • Иметь навык работы с баг-трекинговыми системами: Bugzilla, Jira, YouTrack, Redmine.
  • Уметь писать тест-кейсы и работать с их хранилищами.
  • Иметь навыки клиентского тестирования веб-приложений.

Посмотрим, сколько денег тестировщик может получить за свои знания, умения и навыки в различных областях России. Здесь мы снова имеем среднюю температуру по больнице, к тому же russia.trud.com берет средние показатели. Медианная зарплата дала бы нам более адекватную картину.


Города, в которых востребованы специалисты.
Города, в которых востребованы специалисты.
Отдельно стоит отметить навыки автоматизации, которые весьма востребованы. На рынке труда наблюдается дефицит специалистов нагрузочного и автоматизированного тестирования, что увеличивает размер их заработной платы в среднем на 20 – 25%.

Преимуществом перед конкурентами будет:

  • Умение разрабатывать скрипты нагрузочного тестирования.
  • Умение работать с драйверами и надстройками автоматизированного тестирования.
  • Наличие навыков работы с фрейморками автоматизированного тестирования (JUnit, TestNG и др.).
  • Умение работать с системами отчетности результатов автотестов.
Рейтинг зарплат смежных специалистов.
Рейтинг зарплат смежных специалистов.

Заработная плата тестировщиков в других странах

По данным dou.ua стажер QA будет получать в среднем $400, а минимальная оплата труда Senior QA Engineer оценивается в $2700 в месяц. Обратите внимание, что украинские товарищи не забыли о медианных показателях, за что им отдельное спасибо.


В Нью-Йорке годовой доход QA начинается от $50 000.


Работодатели в Сан-Франциско оценивают работу тестировщиков от $65 000 в год.


В Лондоне тестировщику готовы заплатить от £30 000 в год.


Тестировщикам в Мумбаи платят от 300 тысяч рупий в год.


Как оформить резюме, чтобы получить работу QA или QC с хорошим доходом?

Достаточный размер резюме составляет 1 – 1,5 страницы, на их чтение должно уходить не более двух минут.

Информацию следует подавать емко, описывая важные моменты:

  • Обязательно с разметкой: заголовки, списки с ключевыми моментами.
  • При описании результатов отталкиваетесь от структуры «какая ответственность возлагалась и достижения в этой области». Опишите важные релизы, какие фичи были выпущены, какой карьерный рост произошел.
  • Инструменты и опыт работы. Тестировщики мобильных приложений могут указать: Charles, Xcode, Android Studio, Fiddler. QA бэкенда используют Insomnia или Postman, либо что-то подобное. Обязательно указывайте те инструменты, с которыми был реальный опыт, а не просто теория и поверхностное знание.

Советы по прохождению интервью

Вы заинтересованы в работе настолько же, насколько компания заинтересована в хорошем сотруднике. Сохраняйте спокойствие, отвечайте на вопросы и задавайте свои. Шутки, позитивное настроение и коммуникабельность станут плюсом. Главное – не переборщить.

Как проходит процесс найма:

  • Вводное интервью. Рекрутер представляет компанию, говорит о коммуникации в команде, рассказывают об ожиданиях. Слушать это стоит внимательно, после потребуется задать вопросы (некоторые специалисты специально пропускают какие-то нюансы, проверяя кандидата).
  • Кандидату стоит рассказать о своем опыте, какими инструментами и методиками он пользовался ранее. Джуны могут говорить о курсах или личных проектах.
  • Получение и выполнение кейса. Тестовое задание отличается в зависимости от направления: мобильное тестирование, кроссфункциональное, бэкенд или др.
  • Вопросы от кандидата или инвертированное собеседование. На этом этапе происходит смена роли интервьюера, теперь претендент на вакансию может спросить про метод управления проектом (Scrum, Agile, Kanban), применяется ли CI/CD (Continuous integration & Continuous delivery), часто ли применяют автотесты, каким фреймовроком пользуются и почему… Подобные вопросы показывают заинтересованность кандидата.
  • В финале стоит озвучить зарплатные ожидания (минимум исходя из потребностей и максимум, согласно профессиональному и рыночному уровням), спросить про длительность испытательного срока и как оценивается его прохождение. Обратная связь от кандидата после собеседования помогает оставить положительное впечатление, даже если на данный момент специалист не подходит на вакантное место. Бывает так, что его могут пригласить сотрудничать через какое-то время.
В общении не стоит бояться рассказывать о своих неудачах на прошлом месте работы. Об этом можно и стоит говорить, но дополняя информацией о решении проблемы и сделанных выводах, которые помогут избежать повторения ситуации.

***

В зависимости от компании и специфики работы, может быть от одного до трех этапов собеседования. Тех, кто только хочет изучить данное направление, с тонкостями профессии Manual QA Engineer познакомят специалисты портала GeekBrains. Обучение длится всего 10 месяц и включает теоретическую часть, практику с четырьмя проектами в портфолио и как бонус – диплом о профессиональной переподготовке и гарантированное трудоустройство. Программа обучения актуальна, а занятия ведут практикующие специалисты российских технологических компаний.

30
Авг
2021

TestCon Moscow 2021

Международная конференция по тестированию и обеспечению качества ПО. 3 дня докладов и мастер-классов от ведущих мировых специалистов.
— Читать дальше «TestCon Moscow 2021»

25
Авг
2021

Курс «Специалист по тестированию на проникновение»

7 месяцев практических занятий, постоянная поддержка менторов-пентестеров, диплом о профессиональной переподготовке и международный сертификат HackerU.
— Читать дальше «Курс «Специалист по тестированию на проникновение»»

16
Авг
2021

🐧 Терминал для тестировщика: консольные команды Unix/Linux, которые нужно знать наизусть

С тобой сложно, но без тебя невозможно. Посвящается текстовой консоли, работе в командной строке и причинам, по которым эту премудрость стоит освоить начинающему инженеру по Quality Assurance.

Первые шаги: 40 основных команд

Мое знакомство с терминалом началось немного раньше чем путь в тестирование. Скорее всего с установки системы на спор, а потом как-то прижился Linux, и сейчас винда вызывает некоторое подвисание.

Толчок в развитии дала статья «40 основных команд» и книга Скотта Гараннемана «Linux/ Необходимый код и команды. Карманный справочник» (в магазинах доступно ее 2-е издание).


Нагугилшь команду, а перейти в нужную папку забудешь. Или перепутаешь направление dd (команда поблочного переноса данных) и все, здравствуй вечер переустановки системы и потеря данных. Справочники – это хорошо, но основы работы в командной строке Unix/Linux нужно знать наизусть.

У меня получился примерно такой список необходимых внутренних команд оболочки Bourne shell (командные процессоры sh, bash и т.д.) и внешних утилит. Вызываются они одинаково:

  • Навигация по каталогам и файлам: cd, ls, pwd.
  • Работа с файлами и каталогами: rm, mv, cp, mkdir, cat, more, grep, sort, touch, tail, head, less, find.
  • Повышение привилегий: su, sudo.
  • Управление правами: chmod, chown, chgrp.
  • Текстовые редакторы: vi, vim, nano.
  • Архивация и разархивирование: tar, unzip, zip.
  • Установка программ: apt, yum.
  • Информация о командах: man, опция -h (–help).
  • История ранее выполняемых команд: history.
  • Работа с сетью: curl, ping, nslookup, netstat, wget, telnet, ifconfig, ip, ss.
  • Информация о системе и процессах: top, du, df, ps.
  • Управление процессами: kill.

Конечно команд больше, но эти мне пригодились мне в самом начале пути. Расскажу подробнее о самых необходимых.

Совершенствуем чтение логов

Первое, для чего тестировщик откроет терминал и начнет в нем работать – это логи (от англ. logs – файлы журналов, обычно текстовые). Потому что об аргумент «у меня все работает» разбиваются все доводы и с таким трудом найденные шаги воспроизведения. Можно достать файл целиком с помощью WinSCP и приложить его к багу, но не факт, что его откроют (и хорошо еще, если правильно настроено порционирование логов и файл весит не так уж и много).

Начать можно с простого. Команда tail показывает окончание файла (аналогично команда head читает данные с начала), а если добавить ключ -n, то можно увидеть заданное количество строк:

        tail -n 300 console.log
    

С ключом -f команда будет показывать дозапись в файл в реальном времени:

        tail -f console.log
    

Команда tail помогает, если ошибка произошла только что и ее найти в последних строках, или она воспроизводится прямо сейчас. Если нужно просмотреть весь журнал и найти определенные события (строки по шаблону), можно воспользоваться командой grep:

        grep -i ‘error’ console.log
# где i - регистронезависимый поиск

    

В данном случае будут найдены все строки в которых есть строка ‘error’ без зависимости от регистра. У команды гораздо больше возможностей, чем я показала. Про grep можно писать отдельную статью. Вот вариант поиска классов, логи которых включены на уровне DEBUG и сортировка их с помощью утилиты sort (один из примеров, который понадобился в реальной работе):

        grep DEBUG console-main.log | grep -oP '[a-z\.]+\.[A-Z][a-zA-Z0-9]*' | sort | uniq -c
    

Третий способ чтения логов – команда less. Работа в ней схожа с работой в редакторе vim, но с возможностью только чтения и поиска по файлу:

        less console.log # откроет файл на просмотр.

# Для навигации можно и нужно пользоваться клавишами:
#	Shift+g - для перемещения в конец файла
#	Shift+f - для перехода в режим чтения дозаписи файла
#	/ + “text” - для поиска значения вниз от курсора
#	? + “text” - для поиска значений вверх от курсора
#	Q - выход

    

Для чтения логов можно пользоваться любым их этих трех способов, но самый удобный – less. Он упрощает работу с большими файлами журналов и отслеживание ошибки, например, по одному треду.

Спасаем показ: подключаемся к базе данных

Рано или поздно в жизни тестировщика наступает сдача проекта. Бессонные ночи, правки на прод за час до релиза, написание ПМИ и постоянный перетест. И вот уже почти конец, остался показ.

В тот раз показ проходил в виде испытаний пользователями. Сами пользователи проходили ПМИ в качестве обучения, параллельно принимая систему. Мы могли только отслеживать и фиксировать ошибки и подсказывать, если выходили сильные заминки.

В системе объект должен был двигаться по определенному жизненному циклу. Пользователь нажал кнопку, и ничего не произошло. Даже в логах не отобразилась никакая информация. Показ встал. Действовать нужно быстро, иначе не засчитывалась защита. Под рукой только терминал. Выход из такой ситуации достаточно прост:

        psql -h localhost -U <user>
#	где psql - утилита для работы с бд постгрес
#	     h - хост подключения к бд
#	     U - пользователь для подключения к бд

    

А дальше найти селектом нужный объект и посмотреть, был ли переход объекта. Оказалось, что кнопка не была нажата, и показ продолжился в штатном режиме.

Ошибка не на нашей стороне: связанность, курлы и интеграции

Тестирование интеграций – одна из самых интересных в сфере Quality Assurance. Поиск возможных ошибок всегда усложняется тем, что не понятно, на чьей они стороне, есть ли связанность и на тот ли тестовый стенд настроено каждое приложение.

Прежде чем перейти к собственно тестированию, я провожу проверку связности.

Начнем с проверки сетевой доступности сервиса, с которым вы интегрируетесь (действия производятся с машины, на которой поднят интегрирующийся сервис):

        ping <host>
    

Пинг проходит, значит на той стороне как минимум поднят стенд (противоположный результат ни о чем не говорит, поскольку пакеты ICMP может резать сетевой экран – прим. ред.). Теперь нужно проверить, открыты ли нужные порты:

        telnet <ip> <port>
# Например:
telnet checkip.dyndns.org 80

    

Если соединение открыто, остается последний шаг перед началом тестирования интеграции. С помощью утилиты curl проверить возможность представленного в спецификации запроса:

        
curl <host>| jq # jq для структурированного просмотра ответа, если используется формат json

    

Например:

        curl 'https://proglib.io/api/paging/live'| jq
    

Ответ 200, значит можно приступать к тестированию. Минимальные условия для проверки выполнены.

Перезагрузка приложений и изменение настроек

Рано или поздно возникает потребность временно изменить настройки на тестовом стенде, например, изменить максимальный размер загружаемых файлов или подправить ссылку интеграционного стенда. Не всегда есть рядом разработчик или девопс, который может помочь.

В проектах настройки лежат в файлах application.properties (конфигурация приложения может описываться в самых разных файлах и даже с использованием языков разметки – прим.ред.). Чтобы найти их и открыть файл, воспользоваться командой locate:

        locate application.properties
    
Команда locate проводит поиск в специальной базе данных (не стоит путать ее с сервером SQL), которая периодически обновляется через планировщик. Для немедленного обновления нужно запустить команду updatedb с администраторскими полномочиями (su, sudo).

После нахождения пути, по которому лежат настройки, их можно открыть в vim или в другом текстовом редакторе:

        vim <path>/application.properties

    

После изменения и сохранения :wq настроек, нужно перезагрузить приложение. Рестарт приложения в Linux обычно выполняется командой (если в нем реализована вся необходимая обвязка, иначе придется убивать процессы с помощью kill и запускать программу заново – прим. ред.):

        sudo systemctl restart <serviceName>.service
    

После рестарта лучше смотреть логи, поскольку изменение настроек может так критично повлиять на приложение, что оно не запустится. Также нужно посмотреть статус приложения спустя несколько минут после рестарта:

        sudo systemctl stаtus <serviceName>.service
    
Прим. ред.
Этот метод сработает, если в приложении реализована вся скриптовая обвязка, в противном случае воспользуйтесь командой ps.


Приложение должно быть запущено, иначе лучше вернуть старые настройки и заново его рестартовать.

Нужно ли это тестировщику?

Терминал – инструмент, позволяющий решать множество мелких проблем, не прибегая к помощи других людей и программ. Конечно, есть вероятность сломать с его помощью систему или стереть нужные файлы, можно попасть в глупое положение, можно снести все. Однако сделать это можно и не используя терминал, поэтому почему бы не попробовать?

Удачи в обучении!

13
Авг
2021

Test Automation Hiring Weeks от EPAM

Тест-автоматизаторы уровня Middle+ смогут попасть в команду EPAM, принять участие в крупных проектах и получить приветственный бонус от 100 до 150 тысяч рублей.
— Читать дальше «Test Automation Hiring Weeks от EPAM»

10
Авг
2021

Курсы Skillbox по программированию за 0 рублей

На 7 дней Skillbox открывает бесплатный доступ к курсам по вёрстке сайтов, разработке на Python, Go, 1C и тестированию приложений.
— Читать дальше «Курсы Skillbox по программированию за 0 рублей»

22
Июл
2021

Написание теста на nigthwatch api

Тест должен вытаскивать из кода страницы теги iframe.object и embed и проверять вложены ли они в див с определённым классом. Код приложил, в ходе теста он не может даже вытащить тег со страницы, кто может подсказать где моя ошибка? В тести…

20
Июл
2021

Flutter Global Summit’21

Спикеры из крупных мировых компаний поговорят о применении Flutter и Dart в разработке приложений, сайтов и игр. Рассмотрят кейсы, проведут панельные дискуссии, воркшопы и Q&A-сессии.
— Читать дальше «Flutter Global Summit’21»

19
Июл
2021

Какую Ci систему выбрать, чтобы развернуть автотесты на предприятии? [закрыт]

Основная цель задачи такова. Есть автотесты на моём рабочем пк есть написанные автотесты.
Необходима какая-то система или среда, помещённая на сервер в которой эти тесты смогут запускать другие тестировщики. Соответственно необходим послед…

05
Июл
2021

Вебинар «Selenium Tools на Python»

Расскажут про ограничения Selenium для тестирования веб-интерфейсов, на практике рассмотрят функционал Selenium Tools на Python и его использование.
— Читать дальше «Вебинар «Selenium Tools на Python»»

23
Июн
2021

Митап «Дальнейшее развитие рынка Web UI-автоматизации»

Инженеры и менторы Solvery расскажут о перспективах Java, JavaScript и Python, проведут анализ рынка вакансий и поделятся гайдами и лайфхаками.
— Читать дальше «Митап «Дальнейшее развитие рынка Web UI-автоматизации»»

17
Июн
2021

Project Hiring Week

EPAM набирает команду разработчиков, инженеров, тестировщиков и аналитиков для работы в проектах Выделенного Центра Разработки. Оффер через 48 часов и welcome-бонус в размере одного оклада.
— Читать дальше «Project Hiring Week»

15
Июн
2021

Курс «Python и инструменты машинного обучения»

Обучение работе с аналитическими инструментами в Python от Московского физико-технического института. 2 месяца практических онлайн-вебинаров и сертификат о повышении квалификации в финале.
— Читать дальше «Курс «Python и инструменты машинного обучения»…

15
Июн
2021

🐍 Python для автоматизации тестирования: создаем несложный REST-тест за 4 шага

Python для инженера по Quality Assurance – универсальный «швейцарский нож», которым легко воспользоваться. Рассказываем, как создать автотест за 4 простых шага.

Python в тестирование, сферы его применения
Автоматизированное тестирование давно стало обязательным в сфере IT. Предъявляемые к инструментам инженера по Quality Assurance (QA) требования все выше, а выбор средств все больше: сейчас для улучшения качества продукта можно использовать даже машинное обучение. Python можно назвать швейцарским ножом в сфере тестирования. Нужно написать UI-тесты? Используйте Python. Требуется сгенерировать большое количество данных? Снова Python. Хотите создать бота для тестирования WoT? Тоже Python. Удобнее всего писать на Python тесты REST API.

План REST-теста

Чтобы написать хороший REST-тест нужно сделать следующее:

  • сгенерировать данные;
  • положить их в базу данных;
  • отправить REST-запросы;
  • сверить результаты с ожидаемыми;
  • сгенерировать отчет по результатам.
Для каждого действия есть идеально подходящая библиотека Python.

1. Создание тестовых данных

Можно сгенерить рандомные данные или взять их из файла csv. Например, для создания нового пользователя нужно заполнить поле ФИО, дату рождения или возраст, почту и пароль (почта будет служить логином):

        import random
import string
import datetime
# генерация случайного числа
age1 = random.randrange(15))
# генерация числа случайного в промежутке от 1 до 100 с шагом 3
age2 = random.randrange(0, 101, 3))
# генерация числа с плавающей точкой в промежутке от 5.2 до 7.9
print(random.uniform(5.2, 7.9))
# генерация строки из 10 случайных символов
letters = string.ascii_letters
password = ''.join(random.choice(letters) for i in range(10))
# выбор случайного значения из list
name = random.choice(['Oliver', 'William', 'James'])
mail = name+'@'+random.choice(['mail.ru', 'gmail.com', 'ya.ru'])
# генерация случайной даты между двумя датами
start_date = datetime.date(1920, 1, 1)
end_date = datetime.date(2011, 2, 1)
time_between_dates = end_date - start_date
days_between_dates = time_between_dates.days
random_number_of_days = random.randrange(days_between_dates)
birthday = start_date + datetime.timedelta(days=random_number_of_days)
    

Те же самые данные можно получить из заранее подготовленного файла в формате csv:

        import csv
with open('user.csv') as csv_file:
   csv_reader = csv.reader(csv_file, delimiter=',')
   for row in csv_reader:
        age = row['age']
        # и так далее...
        name = row['name’]
    

2. Добавление тестовых данных в базу

Информацию можно добавить в базу данных, что будет быстрее использования REST-запросов: Python умеет работать как реляционными, так и нереляционными СУБД. Рассмотрим отрывок кода, в котором происходит подключение к БД и добавление нового пользователя. В примере используется PostgreSQL, потому что это один из наиболее распространенных вариантов.

        import psycopg2
import logging

# аргументы для подключения к БД
DB_ARGS = "dbname=test user=postgres password=test host=localhost port=5432"

# функция подключение к БД
def conDB(): 
    try: 
        conn = psycopg2.connect(DB_ARGS) 
    except: 
        logging.error("Unable to connect to the database.") 
        return None 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
    return cur

# функция добавления пользователя
def insertUser(cur, name, age, mail, password):
    cur.execute("INSERT INTO person(name, age, mail, password) VALUES(%s, %s, %s, %s)", (name, age, mail, password))
    

*Примечание: код будет работать, если локально поднята БД test, и в ней есть таблица user с колонками name, age, mail, pass.

Более подробная информация доступна на сайте.

3. Первые REST-запросы

Библиотек для работы с с REST-запросами существует великое множество. Мне больше всего нравятся aiohttp и requests. Для написания тестов удобнее requests. С помощью POST-запроса создадим нового пользователя и после этого GET-запросом проверим, что он действительно был добавлен.

        import requests
    
# тело запроса для создания нового пользователя
user = {"name": "Fred”, "age": 25,"mail":"[email protected]", "password": "134513"}
r = requests.post("http://localhost/users/", data=user)
# напечатать код запроса
print(r.status_code)
# GET запрос на получение пользователя по id
url = "http://localhost/users/” + str(r.json()['id'])
r = requests.get("http://localhost/users/”, data=user)
print(r.text)
    

*Примечание: код будет работать, если локально поднят сервис, принимающий запросы POST и GET на создание пользователя и получение информации о нем.

4. Использование библиотеки PyTest

Приведенный выше код еще не является полноценным тестом. Если оставить его в таком виде, то будет сложно поддерживать. Для систематизации, а также для улучшения качества можно использовать библиотеку pyTest.

PyTest – это удобный инструмент, который автоматически находит написанные тесты, запускает тесты и пишет отчеты с результатом. Библиотека активно развивается и поддерживается. Как использовать все ее функции можно почитать в книге “Python Testing with pytest” Брайана Оккена.

Разделим предыдущий код на 2 полноценных теста: создание пользователя и получение информации о нем по id.

        import pytest
import requests
import json

# тест на создание пользователя и проверку успешного создания 
def test create_user():
    user = {"name": "Fred”, "age": 25, "mail":"[email protected]", "password": "134513"}
    url = "http://localhost/users/”
    r = requests.post(url, data=user)
    try:
        r.raise_for_status()
    except requests.exceptions.HTTPError as e:
        print('ERROR: %s' % e)
    assert r.text == "Ok"

# тест на получение пользователя по id
def test_get_user_by_id():
    example_user = json.dumps({"name": "Ron”, "age": 39, "mail": "[email protected]", "password": "123"})
    url = "http://localhost/users/1”
    r = requests.get(url)
    try:
        r.raise_for_status()
    except requests.exceptions.HTTPError as e:
        print('ERROR: %s' % e)
    user = json.loads(r.data)
    assert example_user == user
    

*Примечание: код будет работать, если локально поднят сервис, принимающий запросы POST и GET на создание пользователя и получение информации о нем.

В втором тесте на получение пользователя был использован стандартный модуль json. Он значительно упрощает работу с JSON-объектами, позволяя не задумываться над сериализацией и десериализацией, обращением по ключу и поиске значения. Подробнее почитать об этом можно, например, здесь.

Пара слов об отчетах
Библиотека pyTest уже умеет генерировать отчеты. Если хочется получить более подробные отчеты, содержащие информацию о покрытие кода, красивые графики и схемы, то можно дополнительно подключить библиотеку allure. Не буду дополнительно расписывать ее, поскольку это уже факультативно подключаемая библиотека. Для основной работы будет хватать и pyTest. Почитать об allure можно тут.

Плюсы Python
Тесты готовы. Отчеты получены. На каждое действия для Python есть удобная в использовании и легкая в освоении библиотека. На этом плюсы популярного языка программирования не заканчиваются. Python быстро развивается, постоянно появляются новые библиотеки для инженеров по QA, комьюнити растет, и всегда найдутся люди, готовые ответить вам на вопрос и помочь решить проблему. Также Python отличается одним из самых низких порогов вхождения, поэтому вам будет удобно начинать путь от ручного тестирования к автоматизации и покрытию продукта REST-тестами.

Минусы Python в автотестах
Конечно у любого инструмента есть и минусы. При разрастание проекта количество тестов обычно увеличивается в геометрической прогрессии. Тестирование будет идти слишком долго, что начнет замедлять процесс работы всей команды. Python – не самый быстрый язык. В какой-то момент придется запускать тесты параллельно, что достаточно сложно. Работать с многопоточностью в Python сложно, но когда такая проблема возникает перед тестировщиком, он уже имеет достаточно навыков и опыта для ее решения.

Выводы

Плюсы Python перевешивают минусы, особенно в начале развития проекта или для небольших продуктов. Сложно представить более универсальный инструмент, которым столь легко начать пользоваться. И конечно, всегда есть куда расти, всегда будут новые библиотеки, которые помогут улучшит продукт. Помните главное: лучший инструмент – тот, которым умеешь пользоваться.

***

Если вы только задумались о карьере в Quality Assurance или ручные тесты вам уже не в диковинку, стоит обратить внимание на курс автоматизации тестирования на Python от образовательной онлайн-платформы GeekBrains. Практикующие специалисты помогут вам освоить основы профессии и техники тест-дизайна, а также научат писать автотесты на Python. Успешно завершившие курс студенты получат диплом о профессиональной переподготовке и добавят в портфолио 4 проекта, а площадка поможет им с трудоустройством.