ну вот индусы на которых я работал о нём не в курсе. им cto или я хз кто сказал делать тесты на селениуме и всё. а что такое селенид никто не знает там и объяснений от гребца с галеры из каких-то снгшных пердей они слушать вряд ли станут

Народ, всем привет!
Имею жгучее желание развиваться в QA, но совсем не хочу  сотку на гигбрэйн и тд.

Занимаюсь самостоятельно, учу postman, devtools, понимаю начальный синтаксис SQL , HTLM, CSS. Теорию знаю.
Но пока это происходит очень сферически в вакууме.
Если, кто-то ищет джунов, мануальщиков могу совершенно безвозмездно приходить к вам в офис три дня в неделю и брать несложные таски, остальные дни в неделю, могу работать удаленно.

Гуглить умею, дергать по любому поводу не разобравшись не буду.

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

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

Возвращаясь к архитектуре. Почти во всех источниках, что я находил описывается архитектура именно для selenium. А вот с теми же api очень мало инфы смог накопать.

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

Ну вот про это бы и написали

так это в любом примере\уроке как писать тесты на рест ашуред итак говорят

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

ну это некст-левел так сказать

Это если у нас пара апишек, пара параметров и почт нет тест кейсов )
То да, как правило все тестовые примеры довольно просты.

А так - везде 4 слоя:
1) слой работы с кишками (накручивание своиих вейтеров на селениум или заголовков на спецификацию запроса)
2) слой с доступными действиями (page objects или все доступные эндпоинты)
3) слой бизнес-логики (типичные действия над предыдущим слоем вроде "залогиниться" в несколько действий)
4) слой тестов - то где у нас написаны сами тесты в терминах бизнес-логики

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

В общем случае - генерить новые.
Ну это даже не автоматизация, это в мануальщине то же самое по сути

Везде по-разному в зависимости от ситуации. Мне нравится работать с заранее известными данными, которые ещё и уникальны для каждого теста. Но подготовка этих данных = отдельная задача, нифига не простая. А ещё их и в актуальном состоянии держать надо

Значит я по правильному пути пошёл, спасибо! )

когда будешь думать когда чистить бд - после теста или до теста - чисть до)

Этот этап  я уже прошёл ))
Но, спасибо за совет! )

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

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

гораздо приятнее если тест упал во время дебага то ничего не почистилось и ты просто зашёл в бд и глянул что там происходит)