Здесь мы будем холиварить на тему фреймворков, показывать друг другу свои пейдж обджекты и фантазировать о позициях сдета и 8к$ зарплате.
И так, пока 90% вкатунов пробуют вкатиться в прогу и конкурируют там с задротами-олимпиадниками, учат каждый день новые фреймворки и выгорают. Мы спокойно конкурируем со вчерашними ручными тестировщиками, наташками и михалычами, которые в тестирвоание пришли с кассы пятерочки.
Пока яйцеголовые в свитерах ломают свой мозг над дата сайнс и машин лернингом. Мы со знанием языка на уровне дев жуна получаем свои 5к$ и смеемся.
Милости просим к нашему шалашу.
два года ждал этот тред
Да ладно, хорош заливать. Вы такие же программисты, как и те, кто пилит бизнес-логику, разве что не отвечаете головой за функционал. Приколисты с селенумом и кукумбером к реальной автоматизации отношения не имеют
я прав или нет?
> авто-куа - это тот же программист, только пилит тестирование и поэтому зп меньше
Да.
> куашник-мануалист может вырасти в управленца и спокойно обогнать по бабкам чела, который пилит свои фреймворки и дебажит код разрабов
А ещё вырасти в управленца может авто-куа. И программист. И кто угодно.
Зп 2к
Задавайте вопросы
Знакомые автоматизаторы говорят, что разницы в зп уже нет и крепкие мидлы/синьоры получают также как и девелоперы.
>так никто не говорит, что нет. Да, мы пишим код, просто у автомамтизаторов на первом месте знание инструмента стоит. (душнилы закукарекают, что яп на первом месте, но это не так )
Да, ты прав. Но знать язык на 6 уровней джавараш (core) было будет неплохо, чтобы не заблудиться в коде.
Хороший тред, годный. Давно его ждал. А полезные материалы, связаные с QA будут?
Что сейчас по сеньорским зепкам? Есть сеньоры итт? Получаю 200, но что-то начинаю подозревать что мало. Охуел ли я, или сейчас рынок выше? Если что - я ручник, на авто то понятно что выше. А вот с ручным хз, реально ли получать 250 без лидовской позиции?
Я думаю он в ДС, если у него 5 лет опыта, то вполне ок. Если еще продуктовая компания, то на ручном куэе могут быть завязаны все команды, он управляет релизом, он говорит да или нет. Так что дохуя всего на нем может быть.
>А какие ты хочешь материалы?
>Учи кор любого яп (java, js, python), учи selenium, прочитай книгу Куликова "тестирование базовый курс"
Это читал. Мне бы где-то про allure, junit прочесть. Они же тоже в java-maven POM <dependencies> летят. Н, например, что можно конкретное написать на junit автомэйшн тестеру - не знаю. Ну понимаю, что прогеры проверки кода на нем пишут, а список команд не знаю.
Спасибо банкам за это. У меня буквально за год с небольшим зепка в два раза выросла, не переходя в менеджмент или авто. Правда сча девопс активности прибавились еще, но там не сложно (не полноценно девопс, а так - хелмы в кубере пописать). Cча всем нужны сеньоры, а их нет нихуя. Собешу людей на 150+ денег, мне объяснить что такое хттп не могут или селект не могут составить. Я три года назад собесил джунов - такая же хуйня была.
>>2106345
Дс2, но ремоут в дс1. Практически 4 года, вот это вот все что ты описал - делаю.
я пробовал. не хватило времени, денег, мотивации. Страдал сильно при изучении.
Пошел в ручники, а потом эти знания пригодились при переходе в автоматизацию. Автоматизация проще, а оплачивается не хуже. Да и как правило в компании кроме тебя никто не знает, что ты там в своих тестах пишешь.
Мимо проходил, но знаю одного ручного тимлида, который полд 300к получает. Но он не совсем ручной т.к. в баше часто однострочники пишет полуавтоматические. Тестирует софт для облаков. Тестирует весь стек. От гипервизора то образа внутри вмки. в тестрэился миллион сценариев и он их все наизусть знает. Я автотесты пишу на основе его ручных сценариев. Так вся команда говорит чуть что сбегать к нему и узнать как называется тест, в котором какая-то супер редкая хуйня тестируется, а он их все наизусть знает и моментально сразу несколько ссылок на тестрэилс кинет. Короче ручники тоже крутые бывают
мимопроходил
>ручными тестировщиками, наташками и михалычами
а что с ними бывает через пару лет, ведь они наверняка не собираются уйти в автоматизацию или стать сдетами?
Реальность рынка такова, что автоматизатора стоят столько же как и разрабы. Рынок адаптируется под европку-сша, где нет такого разрыва в зарплатах. Раньше дев мог в 4-5 раз куа получать, сейчас если брать среднего сеньер куа и среднего сенер дева разница у них в зп будет в 1.5-2к$
Как бы многим не хотелось, но разрабы для бизнеса не настолько крутые чуваки, в основной массе, конечно есть ключевые люди, но... Если ты работал в какой-нибудь компании с большим продуктом, который приносит сотни миллионов, то ты наверняка знаешь, что весь отдел раработки будет человек 50-100 и еще 1000 всяких менеджеров, сапортеров, маркетологов и т.д. Просто сделать продукт - мало, его надо продать, им надо управлять, чтобы не свернул куда не следует. Конечно разрабы крутые ребята и востребованные, но не надо удивлятся почему ключевой сотрудник, отвечающий как качество продукта имеет такую же зп, как и разраб. Я успеел поработать в 4 компаниях и работаю уже в 5ой и хочу сказать, что наверно хватит пальцев одной руки, чтобы пересчитать разрабов, которые хотя бы билд собирали и смотрели, что они там написали и как это работает, перед тем как отдать таску в куэй. Ты скажешь, что не их работа это, мол есть тостеры, ну вот так это и работает. Или ты делаешь отдел куэй или твои разрабы становятся куэями и выпускают фичи в два раза дольше.
>>2107372
Дальше руками тестят за свои условные 3к$ в месяц в каком-нибудь теплом месте без овертаймов и сапога в заднице, уходят в 6 часов домой, тратят время на семью и хобби, а не изучение новых фреймворков.
Легко вкатыватся? Сколько примерно времени займет если каждый день учит пару часов? Я вот михалыч и моей мухосранске только работа кассира, хуесоса и итшника. Решил как каждый второй индус кинуться в кодинг но хочется чего то легенкого.
Смотрю но на ютубе только пару видосов от индусов на эту тему.
>Зашел на hh и что-то охуел. Сеньоры ручники 3-4к в месяц. Авто еще больше
Ну это сеньоры, которые бэкенд тестят. А это означает, что они полупрогеры по API и SQL и IDE у них открыта.
Ручные сеньоры вероятно натасканные по тест-дизайну и могут такими акробатическими тестами покрыть регрессию, что все офигевают, какой вылизанный продукт получился.
>Пробовали ли вы вкатиться в разрабы перед вкатом в qa? Почему не получилось?
Тестеры хоть какой-то полуфабрикат получают. Даже если там SOAP бэкенд, то тестеры готовую WDSL-ку дёргают и уже что-то на руках держат.
А разрабу нужно и накодить с нуля и связать модули с нуля. Ему на падение или экзотические баги вылавливать времени нет, нужно наполнить продукт функциональностью. Поэтому тестер ему как продолжение руки.
Есть один прогер в бугурт треде. Такое как он написал там "создал энд-2-энд" тесты и уволили QA, а ему деньжат подкинули - существует. Но это в маленьких стартапах на 4 человека, где продукт один и он поддерживается годами. И чтоб хуи не пинать, прогер тесты писал, 100% продукта покрыл автотестами. То есть он - взмыленный фуллстак, который и разрабатывает и тестит. Это "оптимизация" по-восточному, где люди = убыток. Такое не только в АйТи.
А там где аутсорс, корпорации и большой куш - запросов больше, команда больше, нужны и QA, PM, БА и так далее.
QA всегда будет существовать.
пытаюсь подружить градл проект с докером и селеноидом при запуске тестов в селеноиде, инпуты заполняются хуйней вместо кириллицы, поэтому хочу попробовать запускать тесты из контейнера, проблема в том, что при поднятии контейнера должен происходить gradle build, который запустит мои тесты, но на деле нихуя не происходит, просто build succesful. мне кажется, что запускается не мой градл файл, а файл из базового образа но мб я просто тупой докерфайл на пикриле
Можно ли как-то применить СиРешетку в этом вашем автокуа?
Косвенно касаясь темы.
Где гайды вообще по вкату в тестировщики?
Если нулевой: книги
Букварь "Савин - тестирование дот.ком"
Структурированная инфа для ручника "Святослав Куликов - Тестирование ПО"
Плюсы: это и есть та инфа, которая на курсах.
Минусы: впереди большой объем работы.
Если хоть что-то знаешь:
learn.epam.com в списке лекций ставишь фильтр qa и обалдеваешь, сколько всего знать нужно и какой список инструментов.
Плюс: пережевывают и в рот кладут.
Минусы: не вся инфа. Всю они дают в лабораториях, а туда не попасть.
А какие инструменты не расписал ЕПАМ, то:
Можешь Artiom Rusau YT канал глянуть.
Плюсы: после него ты будешь точно знать базу, с которой можно на собесы хотя бы ходить.
Минусы: он как и все человеки, в общих чертах объясняет и после него всё равно нужно искать инфу.
Топовый спец, хочешь убрать шероховатости и раскрыть глаза;
software testing ru:
Плюсы: там реально полезная инфа, пригодится уже работающим.
Минусы: не уроками, а "записями в блоге" а-ля хабр расположена.
мимо первый собес с лайфкодингом на днях будет
не так уж и много для автоматизатора
>>2139207
в том, что знать надо в 5 раз меньше, думаю, что конкуренция тоже меньше, сейчас рынку пиздец как не хвататет авто куа.
>не так уж и много для автоматизатора
> Киев
Говорят там русских режут, слышат московский акцент, сразу нож в печень, покрышки на тело, бензином обольют и сжигают, крича "путинская свинья".
На ХХ вроде не выдающиеся зарплаты указаны. А если умеешь несколько языков, всякие многопотоки, докеры и т.п., на сколько реально в пынестане рассчитывать?
https://hh.ru/vacancy/46670202
с вилкой 40-70, кучей требования, и жирным выделено
> Опыт работы тестировщиком от одного года. Кандидатов без опыта работы на данную позицию не рассматриваем!
но потом глянул их другие вакансии, там и для программистов до 100тр.
А вообще, если смотреть ХХ, там большинство вилок явно ограниченый суммой на уровне 100, ну максимум 150. Очень мало вилок с какими-то приличными зарплатами. Есть, но мало.
ХХ не то, чтобы показатель, но прогерские и девопс вакансии там явно с заметно бОльшими вилками, чем тестеры-автоматизаторы.
Решил с небольшим опытом бэкэнд разраба перекатиться в QA устал, хочу работку попроще. Чето пока Всем абсолютно похуй на бэкграунд. Всем нужно знать точные определения какого-нибудь попарного тестирования. Похуй, что твой ответ раскрывает суть, похуй, что это вообще не crucial знания. Определение не совпало с пунктом в чек-листе эйчара - идешь нахуй. Алсо, стандартный вопрос - "Почему из разработчиков переходите в тестирование? Обычно делают наоборот."
Закрыл вакансию тестера, переоткрыл на разраба. Два оффера за неделю, лол.
Алсо, был случай, когда успешно прошел техинтервью и получил добро от тимлида, но на последнем интервью слили руководители. Короче, цирк ебучий. В разрабы набирают как нехуй, а у вас че за хуйня творится?
смотря чего ты хочешь. Сейчас рынок такой что и ручником можно получать 3.5-4к$ на руки. (Киев)
Но если нравится кодить, но не настолько чтобы становится девом, а денег хочется, то можешь сразу в авто идти, через года 3-4 сможешь претендовать на свои 5к$.
Я вот после 2.5 года в ручниках, счас на новой галере по тихоньку погружась в авто, пишу простенькие ui тесты + ручная работа какая-то тоже на мне осталась ( процентов 60 я авто и 40 ручник) пока все нравится, свичнутся получилось без потери по баблу и даже наоборот в плюсе (сейчас получаю 3к$). Но я вот для себя пока не решил, хочу я полностью уйти в авто и руками ничего не делать или хочу оставаться генерал куэй который и руками и автоматизацией занимается, пока бывает устаю сильно если по 8 часов код пишу, иногда хочется и руками потыкать без задней мысли.
Рынок растет вместе в этими конторами. Это же так работает - крупные игроки повышают, средние подхватывают, чтобы быть конкурентноспособными в найме.
>>2141480
qa_jobs тг канал
>>2144027
Я щитаю что душная хуета, но вкатываться надо, если хочешь вверх идти - лидовые/хэдовые позиции, нужно технически шарить во всем и в случае чего разрулить какие-то вопросы.
Видимо из-за массового вката в разработку выпускников курсов стремительно растёт потребность в QA.
а я не ставлю равно. я гвоорю что автоматизация легче, а деньги почти те же. Я в айти шел за деньгами, я не хочу там сидеть ночами, чето придумывать и вот это вот все псевдо айти романтика, мне похуй. Я хочу в 18.00 сложить ноут в рюкзак, сесть в машину и поехать домой ОТДЫХАТЬ, а не поесть и опять сесть за код.
Каждому свое, но у меня хватает занятий и увлечений помимо РАБоты.
А фреймворк для автотестера кто напишет? Скилл требуется конечно не такой как в разработке, но знания на уровне Джавараш 10 уровень недостаточны.
P.S. Если сравнивать требования на собеседованиях, то проверка знаний языка на стажера-джуна разраба выше чем на мидла-синьора тестера.
обещают полную удаленку
1)Какой из стулов выбирать и как же всё таки попасть в Етот ваш AUTOMATION ТЕСТИНГ?
2)С чего начать и какие базовые хуйни мне нужно ТЕОРЕТИЧЕСКИЕ выучить, чтобы я смог с ходу прыгнуть на хотя бы 80+к готов ебошить параллельно ручником
Сейчас каждая вторая контора хочет у себя выращивать фулстеков QA. Делаешь тестовый проект на гитхабе и идешь устраиваться на позицию 50/50 ручник/автоматизатор. Не то чтобы с руками оторвут, но за 80к заказчик шибко кривить ебало не будет. А там если увидят что тянешь, перекатишься полностью.
Сеньор (ведущий тестировщик) должен уметь протестировать крупную фичу, затрагивающую несколько сервисов и платформ; декомпозировать задачу такого уровня, определить необходимые виды тестирования, ресурсы и сроки. Способен контролировать качество продукта на уровне сервиса (модуля) или группы сервисов. Впрочем, это чисто на основе моих ожиданий, формальных требований нет.
Вторая проблема авто-QA - туда активно ломятся вкатуны ебаные, мечтаюшие через это вкатиться в _настоящее_ погромирование. Прогать они не умеют, тестировать руками ненавидят, перспектив в индустрии не имеют.
SDET - это полноценный разраб, умеющий в управление качеством. Такой человек способен запилить инструмент вроде того же Selenium, а не только его использовать. Стоят такие люди дороже обычных разрабов и, как следствие, востребованы в основном в больших конторах.
мимо head of QA не самой маленькой конторы в ЕС, немного удивлён возникновением треда; задавайте свои ответы
>задавайте свои ответы
окей, если ты и правда
>head of QA не самой маленькой конторы в ЕС
то погнали:
>нанимаю только хороших ручников
каковы критерии "хорошести"?
>умеющий в управление качеством
сколько для этого нужно софт-скиллов?
>в ЕС
что там с востребованностью авто-куа? у меня есть пример, когда челу платят за хорошее знание продукта, навыки тестирования он добирает по ходу работы, а автотесты вообще пишут аутсорсеры за тарелку риса
>каковы критерии "хорошести"?
Нужно любить тестировать руками; это монотонная, рутинная работа даже по меркам айти. Случайный человек с ума сойдет и выгорит очень быстро.
Из теории понимать нужно в основном стандартные, банальные вещи: пирамида, классы эквивалентности и т.д. - никакой экзотики, ГОСТов и ISO. Но понимать их нужно нутром, а не просто зазубрить; это как с SOLID у разрабов - формулировки оттарабанит любой вкатун, а эффективно применять их на практике могут немногие.
Нужно уметь постоянно учиться и овладевать новыми технологиями, чтобы понимать, где и как в принципе можно автоматизировать рутину. Это не так остро стоит, как у разрабов, если над тобой мощный отдел с парочкой SDETов, но все равно важно.
И главное - нужно иметь выраженный деструктивный менталитет, посточнное желание ломать, уметь испытывать чувство победы при обнаружении дефекта; но в то же время понимать, насколько чувствительная это тема для разрабов и уметь с ними общаться конструктивно.
> что там с востребованностью авто-куа?
Востребовано управление качеством. Как я уже писал выше, автотесты можно научить писать любую макаку, что и подтверждается твоим примером; но вот человек, который может выстроить процесс таким образом, что труд макак эффективен - такой на вес золота.
>Нужно любить тестировать руками; это монотонная, рутинная работа даже по меркам айти. Случайный человек с ума сойдет и выгорит очень быстро.
ну не надо вот этого. Почемиу вам скучно? Выбирайте проекты, которые интересны и не будет скучно. Я вот сам любил поиграть в казино, с состоял в покерном клубе, играл на покер старс. И сейчас работаю в онлайн казино, мне пиздец интересно и нравится, совесть не мучает.
>Первая проблема авто-QA - в том, что они часто перескакивают через ступеньку развития в виде ручника.
Что значит перскакивают?
Ты определись какие задачи у вас в компании ставят перед авто Куа. Если автоматизировать готовые кейсы, то на опыт ручника пох. Если писать кейсы + автоматизировать, то нет проблем взять джуна с базой ЯП и тестирования.
а здесь даже хуй знает что выгодней компании. Вот я типа был сеньер ручник, меня взяли на галеру как женерал куа и начали учить автоматизации. Сейчас я пишу простенькие автотесты + занимаюсь ручной работой. Бывает по разному, иногда неделю пишу тесты и ручным вообще не занимаюсь, бывает что работаю руками и за неделю могу строчек 50 кода написать.
Но в целом я получаюсь дороже для компании. Мне платят 3к$ зарплату+ меня обучают автоматизации, меня лиддев с 10 летним опытом обучает программированию и вместе со всем этим они же и повышают мою стоимость себя для компании, т .к. с такими знаниями и опытами я становлюсь ценным сотрудником на рынке и слега припиздев можно пробовать и на 4к заскочить куда тварь я неблагодарная такая.
А так могли бы взять чисто ручника на 1.5к$ и не пускать его к автоматизации, он бы писал кейсы для автоматизации. На автоматизацию взять студента за 400$ в месяц. И все. Так у тех еще и соблазнов меньше будет свалить.
> автоматизировать готовые кейсы
Для этого не нужен специальный человек. С этим вполне справляется хороший ручник, которому показали пару примеров; а если ручники не успевают - подключаются разрабы (которые, разумеется, тоже обязаны владеть автоматизацией).
Кроме того, ты сдохнешь автоматизировать кейсы "чистого" ручника, который никогда не автоматизировал.
>Вторая проблема авто-QA - туда активно ломятся вкатуны ебаные, мечтаюшие через это вкатиться в _настоящее_ погромирование. Прогать они не умеют, тестировать руками ненавидят, перспектив в индустрии не имеют.
И чё происходит с такими вкатунами? Выгорают и бросают айти?
>И чё происходит с такими вкатунами? Выгорают и бросают айти?
Не знаю, наверное. Я таких не нанимаю. Чтобы из ручных тестировщиков вырастали хорошие SDETы - такое я видел, на прошлой работе такой чел занял мое место, когда я ушел. Чтобы из разрабов народ сливался в автоматизаторы, чтобы поменьше напрягаться - тоже видел, >>2139564 вот, кстати, пример такого наивного полупокера; но чтобы чистый авто-куэй сделал карьеру - такого не видел никогда.
В автоматизации как таковой нет сложности. Сложность есть в том, чтобы написать и поддерживать хорошие тест-кейсы; сложность есть в том, чтобы наврнуть поверх вебдрайвера конечный автомат для восстановления после ошибок а-ля Selenide; написать скрипты и пейдж-обжекты на готовых инструментах могут и ручник, и разраб. И они успешно с этим справляются. Зачем же, спрашивается, нанимать долбоеба, который не умеет ни прогать, ни тестировать руками?..
Не понимаю тебя. Ты хочешь сказать что дай ручнику условный webdriver io и он тебе автоматизацию сделает и тесты писать начнет или что? Или дай ему все готовое и он сможет тесты писать и ctrl c + ctrl v делать новых страниц? Если второй вариант, то толку с такого "специалиста"
> чистый авто-куэй
Да что такое этот чистый авто куей? авто куа это куа + программист. Если ручник у тебя базовые паттерны знает, пишет хороший код и может дописывать твой фреймворк, то он уже авто куа.
При этом уже проще взять человека со знанием ЯП и научить тестировать чем наоборот.
>Не понимаю тебя. Ты хочешь сказать что дай ручнику условный webdriver io и он тебе автоматизацию сделает и тесты писать начнет или что?
Нет, этого мало, разумеется.
> Или дай ему все готовое и он сможет тесты писать и ctrl c + ctrl v делать новых страниц?
Именно.
> Если второй вариант, то толку с такого "специалиста"
Гораздо больше толку, чем с "автоматизатора", так как он умеет тестировать, строить адекватные модели и не ссыт ручной работы там, где автоматизация буксует.
>Да что такое этот чистый авто куей? авто куа это куа + программист.
Проблема в том, что чаще всего в "куа" так называемый "автоматизатор" понимает примерно нихуя, то есть чуточку меньше, чем понимает в программировании.
>При этом уже проще взять человека со знанием ЯП и научить тестировать чем наоборот.
Это утверждение в корне неверно, с точностью до наоборот.
>Это утверждение в корне неверно, с точностью до наоборот.
В чём может быть проблема научить программиста тестировать что-то?
Любой программист может мыслить категориями последовательных шагов, "если нажал сюда, то должен получить что-то" и т.п.
Что вообще нужно понимать в QA такого особого, кроме того, чтобы тонны бюрократии разводить в виде каких-то пачек бумаг по составлению тестовых планов и т.п.?
>дескать, "нужно быть прирождённым тестером, те плохие, эти не годятся"
Я такого не говорил, я только перечислял важные навыки хорошего тестера. Я нигде не утверждал, что их нельзя приобрести.
Но я утверждал и утверждаю, что навык автоматизации для тестировщика вторичен.
Но тут проблема в том, кого называть тестером.
Проблема в том, что те, кого берут в тест-отделы, просто не в состоянии делать полноценное тестирование, потому что программерские скиллы очень низкие. Соответственно ту работу, которую по идее должны бы были выполнять тестеры, выполняют просто разработчики. А тестеры делают какую-то ручную рутину, которую конечно всем лень делать, особенно разработчикам.
Как, например, тестеры смогут тестировать АПИ, если они программировать не умееют?
>Проблема в том, что те, кого берут в тест-отделы, просто не в состоянии делать полноценное тестирование, потому что программерские скиллы очень низкие.
Так возьми в отдел одного SDETа, чтобы сделал все обвязки; и сразу окажется, что достаточно даже очень низких программерских скиллов, чтобы эффективно решать все задачи.
>>2153322
>Как, например, тестеры смогут тестировать АПИ, если они программировать не умееют?
Для этого не нужно уметь программировать, для этого достаточно, чтобы один раз показали пример какую-нибудь шняги в духе RestAssured и научили ее копипастить.
Этот прав. Я как раз этим и занимаюсь на постоянной основе. Удивительно, но факт - с примерами и небольшой помощью ручники бодро шлепают тесты на джаве/котлине/js без всяких огурцов и прочих костылей. Да, хуевые поначалу, но что поделать. Разработчики автотесты тоже крайне хуево как правило пишут, особенно интеграционные, придется это терпеть.
Я мобилки и автоматизирую и верстку у нас нейросетка проверяет, а не тестер глазами, ручные тесты только позвонить
>>2153349
>что достаточно даже очень низких программерских скиллов, чтобы эффективно решать все задачи.
Правило 1: чем лучше тестер в техническом плане тем лучше он протестирует систему.
Ох, сколько я сценариев видел которые абсолютно бесполезные и не реальные, проверяют целое нихуя. Или тестов ctrl+c + ctrl+v где половину можно выбросить и время выполнения уменьшить вдвое. И потом эти тесты начинают падать.
А всего лишь нужно было нанять автоматизаторов, а не мануалов
>так тут дело в тест-дизайне?
В тест дизайне, а причиной тому низкие программерские скилы и отсутствие понимания как в теории работает система под капотом.
>Или тестов ctrl+c + ctrl+v где половину можно выбросить и время выполнения уменьшить вдвое.
То же самое, низкие программерские скилы, пишут тесты абы работало, потом оно падает при малейших изминениях в системе, начинается боль на регрессии и боль стабилизации всего этого перед релизом.
Работаю сисадмином эникеем, планирую развиваться. Слышал что в девопсов вырастают из сисадминов. Но также нравится и QA. Он вроде проще, чем сразу ломиться в девопс. Хочу пройти яндекс практикум по QA. Есть ли путь в девопс через QA? Вполне допускаю что могу и просто в QA остаться, развиться в автоматику.
Нравится и то, и то. А что выгодней? Как я понимаю порог входа в QA ниже, можно быстрее выйти на 100к зарплатку? Но в девопсах вроде бы стартовые зп для джунов уже больше 100к, но и знать/уметь надо больше чем джун QA?
Это все мои предположения. Поясните кто в теме.
Не троллю. По девопсу ничего не умею, вобще весьма смутно представляю что там нужно. Знаю про проги Doker и Kubernetes, но не изучал. Я ж говорю что хочу учиться. Про QA тут не раз писали - читаешь Куликова и ты джун. Базовые знания ЯП у меня есть Выводы делаю из страниц курсов на скиллбоксе например. Там пишут зп опытного QA - 100к, зп начинающего девопса - 130к.
>По девопсу ничего не умею, вобще весьма смутно представляю что там нужно.
Ну вот значит ты не можешь быть ни начинающим девопсом, ни пытаться на стажировку идти.
Задача девопса очень много чего знать, понимать, и уметь, хорошо дружить с компьютерами. Его работа в том, чтобы понимать, куда ткнуть отвёрткой, самой работы может не так много.
Задача QA противоположная. Ничего знать не надо, надо более-менее дружить с компьютерами на уровне пользователя, быть ответственным, усидчевым и готовым работать рутину.
Поэтому больших денег в начальном QA нет.
Всё-таки чуть разные направления. Скорее мидлу-девопсу необходимо быть хотя бы начинающим админом. Но начинающий админ это, конечно, не просто "уверенный пользователь линукс".
Девопсу надо уметь работать и быстро осваивать разные сложные системы, соединять их между собой, это чуть другие вещи и чуть другие мозги.
Как ты можешь что то протестировать нормально если все знания что у тебя есть это спецификация?
Пример:
Чел на собесе, опыт 2 года мануалом, тестирует форму логин пароль
valid, valid
valid, invalid
invalid, valid
invalid, invalid
О чем дальше говорить?
Дали тебе протестировать грузовик, кто лучше протестирует, ты или механик с завода который его собирал?
Так же и в ИТ. Кто лучше протестирует микросервис, ты или дев который их по КД высирает?
>О чем дальше говорить?
>Дали тебе протестировать грузовик, кто лучше протестирует, ты или механик с завода который его собирал?
>Так же и в ИТ. Кто лучше протестирует микросервис, ты или дев который их по КД высирает?
другой анон
Лучше всего протестирует "профессиональный пользователь".
То есть грузовик лучше протестирует не механик с завода, а профессиональный водитель, который знает, что в действительности надо от грузовика, какие там реально встречаются проблемы.
А механик с завода понимает, как устроен грузовик, но не понимает, как грузовиками пользуются.
Но это, конечно, лишь часть тестирования.
>>2154616
Ебать долбаеб заленый. Еще скажи, нахуя нужны QA если зарзраб за разрабом лучше проверить и все баги уже на ревью поймает, ага.
Смысл как раз в том, что лучше ручника никто тебе тест кейсы не опишет, поэтому в многих компаниях так это и работает - ручник пишет сценарии, автобот - автоматизирует.
>все знания что у тебя есть это спецификация?
О, да, мой мальчик, здесь мы идем. Добро пожаловать в увлекательный мир исследовательского тестирования. Самое время щадать вопрос, что такое test oracle.
>Дали тебе протестировать грузовик, кто лучше протестирует, ты или механик с завода который его собирал?
Хороший вопрос на понимание пирамиды тестирования, возьму на вооружение.
Это проблема найма и позиционирования тест-отдела.
Вообще тестирование неотделимо от производства-разработки.
В корпоративной логике тестирование это как аудит и арбитраж, QA даёт заключение, что разработчики плохо работают и т.п.
Для любой сложной системы внешний контроль необходим.
При разработке просто получается, что сами разработчики выполняют функции QA, хотя так себя не называют.
Вот что написано:
------------------
1) Создать коллекцию для работы с rest api в Postman
Адрес тестового rest api:
При работе использовать два метода:
- Авторизации.
POST
https://апиконторы/auth
{
"login": "{{string}}",
"password": "{{string}}"
}
- Получение баланса кошелька – требует передачи в заголовках токена авторизации. (Как я понял, токен я смогу посмотреть после успешной авторизации через Postman, но у меня не получается - показал на скрине).
GET
Headers:
Authorization: token
https://апиконторы/balance
2) Автоматизировать и добавить проверки в Postman для раннее написанной коллекции.
Написать, почему вы решили проверять те или иные данные.
------------------
Правильно ли я понял, что я должен проверить две вещи: вход в аккаунт и баланс, так? Почему в ТЗ так всрато написаны значения ключей - с двумя фигурными скобками? Они нужны или нет? Алсо, в каком формате обычно записывается номер телефона в базе данных? Я думаю, примерно так "7777777777", а не ''+7 (777) 7777777'. Просто на этом сайте он ещё и роль логина играет. Но у меня с какого-то хуя не получается авторизоваться через постман используя логин и пароль существующего аккаунта. Может я просто логин (телефон) не в том формате в теле отправляю? Хотя, я уже разные варианты ввода перепробовал и даже с этими скобками.
Извиняюсь, если невнятно сформулировал, просто ссу из-за того, что скоро совсем сдавать, а я нихуя не сделал.
>если разработчики начнут углубляться в тестирование и тратить больше времени на тесты и тест-дизайн, то у тебя разработка сильно замедлиться?
Это, кстати, распространенное заблуждение. Когда разраб сам пишет хотя бы хуевые тесты, количество возвратов задачи на доработку заметно сокращается, а каждый возврат - это сжигание впустую дохуя времени.
>разраб сам пишет хотя бы хуевые тесты
в том-то и дело, что хуевые тесты, с хуевым покрытием ускоряют разработку, но если они будут проектировать и писать качественные тесты по тест-дизайну, то скорость возрастет или все-таки упадет?
я даже не говорю о том, что у разрабов могут быть замылены глаза, когда он пишет тесты на свою фичу
Скажите пожалуйста, а что обычно на собесах свеженьких джунов спрашивают? А то навскидку так погуглил и складывается ощущение, что мне гугл только инструктажи на вакансию синьора или тимлида даёт.
Привет. Работаю qa auto в банковской сфере на js, но чувствую, будто бы занимаюсь ерундой, которая никому не нужна и не интересна мне самому (по крайней мере это касается всяких финансовых бирж).
Хотелось бы как-то сменить направление. Задумался вот как устроена работа у автотестеров игр. Знаю, что в wargaming есть такое, но в целом по миру вроде как не очень распространено пока что.
Может кто-то может что-то рассказать или посоветовать посмотреть / почитать, чтобы понять как устроена автоматизация в геймдеве?
Куда вообще советуете двигаться, чтобы ощущать развитие, но при этом не выгорать от напряжения?
Через курсы епама, по сути. Еще когда в университете учился
Потому уже пошел сначала в одну контору, потом в другую
Если ты новичок, то я бы посоветовал попробовать глянуть курсы Баранцева. Ну или на сайте его почитать что-нибудь, правда сам я ленюсь и не читал, но курс его глянул мельком пару лет назад и зашло.
>>2159157
Я не в банке. На галере, просто в финансовом секторе на данный момент.
как менеджить дохуя (пару сотен) джоб в Дженкинсе?
>Доброго всем вечера.
>Скажите пожалуйста, а что обычно на собесах свеженьких джунов спрашивают? А то навскидку так погуглил и складывается ощущение, что мне гугл только инструктажи на вакансию синьора или тимлида даёт.
Ну поляки тут мне про автомейшн такие спрашивали:
А ты знаешь что такое Смоук? А ты за нас интеграционные и юнит тесты писать будешь?
А у них сайт полупустой, забагованный и стоило бы его вручную потестить.
Стажировщики в Беларуси про авто и ручника:
1. Зали формочку регистрации и сказали написать идеи тестов.
2. Дали тест по for, while i++, модификаторам доступа и наследованию на Джава.
3. Тест по странным чудаковатым вопросам с логичными для QA ответами. Как например, за черной дверью живёт муж Полины, за красной жена Степана, а кто имеет кота?
4. Тест по английскому, а именно гоняют по предлогам.
Если работать не на отъебись, ручное тестирование одна из самых хуевых работ в it.
Не на кого будет свалить вину, да и бабки нужны.
>>2160665
Ты не заметил, что я написал в it. Понятно, что хуевая позиция в it > средняя позиция в другом месте.
Хотя, если говорить про ДС, я бы уже поспорил. В ДС какая-нибудь тяночка маркетолог может рубить 300к в мес, когда кодеру на такой зп нужно знать уже очень дохуя. Я считаю itшникам ещё не доплачивают. По нынешним рублям, миддл должен стоить 300, синьор 500-600.
>В ДС какая-нибудь тяночка маркетолог может рубить 300к в мес
Вообще очень-очень вряд ли, то есть только совсем не рядовая тяночка, а с очень большой отдачей.
Но я в целом согласен, что рассказы о каких-то выдающихся доходах в ИТ это больше раздуваемый миф. По Москве очень много ездит дорогих авто, очень много продаётся квартир ценой в 20М+, но ИТ-шников среди этой публики меньшинство.
ИТ-шники на вершине только среди получающих фиксированный оклад по найму.
Подскажите какой-нибудь инструмент тестирования рест апи, который записывает тестовые сценарии на ямле. То, что я нахожу либо примитивные, которые тупо один джисон отправляют и схему ответа валидируют или усложнены в ненужно направлении типа поддержка пяти способов валидации джисона, шаблонизация теста через переменные окружения и встреонные инструмент проверки дат.
А мне бы последовательный запуск сценариев с сохранением промежуточных результатов.
То есть ужно на yaml записать следующий сценарий:
1. Отправить auth реквест.
2. Получить токен аутентификации.
3. Отправить реквест на создание нового тестового объекта с токеном аутентификации в хейдерах.
4. Получить 202 ответ и айди нового ресурса, который будет создан.
5. С таймаутом в 5 минут на репите слать GET запросы к эндпоинту этого ресурса с айдишником полученном на предыдущем шаге до тех пор пока ответ 404 не сменится на 200.
6. Валидировать полученный ресурс
7. Отправить PATHC запрос на одно из полей этого ресурса.
8. Валидировать, что поле изменилось.
9. Отправить DELETE запрос с айди этого ресурса.
10. С таймаутом в 5 минут слать GET запросы к эндпоинту этого ресурса пока ответ 204 не сменится на 404.
Кто-нибудь знает инструмент, который позволяет такие тесты декларативно прописывать?
Какова позиция нагрузки в иерархии разработки?
У нас есть три тимы - XYZ, тима Z всегда хочет влезть вперед паровоза, вот думаю как их поставить на место
1) Сделать отдельыне тестовые контура для команд.
2)Поднять проблему на уровне лидов пусть решают и строят график, кто за кем тестируется каждый спринт.
3) Сместить начала спринтов всех команда на пару дней между собой. Так что самые загруженные по тесту дни в конце спринта будет разными для разных команд.
Собственно я ничего лучше не придумал чем скрипт который пробегается по элементам через xpath, чекает их на соответствие и вставляет данные.
На мой высер мне ответили что мои локаторы хрупкие и в целом код не организован в виде теста.
Собственно вопрос - как должен выглядеть код организованный в виде теста? Пока как то особо не удалось нагуглить вменяемых ответов.
Гугли всякие cси икспасов - анцестор, парент, чайлд итд
Обычно берут какой-то элемент, который скорее всего не поенятся и от него ищут ищут искомый. А то что у тебя изначально было, это прям самая простая версия, которая упадает если немного верстку поменяют на 1 див.
тг @iwantLIVe
например
//button[contains(text(), 'Любой опыт')]
Хотя препод говорил что по тексту искать типо не оч, но на проекте вообще все кнопки обернуты в класс button, куда передается текст кнопки. Отваливалось все что угодно, кроме этих ебучих кнопок, так что хз. мимо вкатун-полгода уже как джун
1. Автоматизатору маст хэв знать ручное тестирование ради знания документации, процессов и самого главного - тест дизайна. Ибо с первой работой тебя не возьмут в корпу. А на мелких фирмах ты будешь QA фуллстек (и ручник и авто).
2. Чем лучший ты программист - тем лучший ты автотестер. у Автотестеров на сегодня есть 3 стула: Java, Java Script, Python. Остальные языки игнорятся обычно. Python - язык-вкатун на курсах. Java Script - язык адептов веба, которые думают, что их веб-портал и разрабатывать и тестить можно только на том же языке (не правда) и Java - ради ООП и паттернов. Потому что без ООП и без паттернов и знания языка ты будешь писать процедурные тесты. А они никому не нужны.
3. Если знаешь один из этих языков - вкатишься за 3 месяца. Если нет и с нуля - вкатишься за год (полгода на вливание инфы в себя и курсы инфоцыган в остальной полугод).
>мои локаторы хрупкие
Да, xpath у тебя длинный /html/div[1]/div[1]/div[5]/div[6]/div[1]/div[1]/Кнопка. Нужно делать коротенький //Кнопка{@contains("текст")] и тогда тест не упадёт, если разрабы новые фичи на сайт повесят. Xpath используй, если там айдишек нет или класс ссылается на несколько элементов.
>>и в целом код не организован в виде теста.
От тебя захотели, чтобы ты отдельно создал классы кнопкам, логику в методах описал. А потом как король в главном тесте вызывал методы. Это и есть Page object паттерн. Так поддерживать тесты проще. Их разочаровало, что ты так не сделал, а следовательно написал процедурный тест. А если процедурный тест - значит не в курсе про ООП.
fingerprint'ы (отпечатки бразуера в js)?
>>2166960
>>2167048
Спасибо всем. Переделал все что смог. Все запускается, тесты проходятся, локаторы вроде теперь имеют приличный вид, никаких дивов и прочей дичи. Все разбито по классам, страницы - объекты страниц итд, у каждого свои методы на вводы выводы в зависимости от типа элемента, дроплист или просто поле для ввода.
Это уже больше похоже на правду или остаются какие то дикие неприемлемые фейлы и косяки? Нужна ли такая вещь как повсеместная валидация данных или это для других случаев?
Пишем тестовое всем двачом. В дополнение к анонам предложу:
- вынести элемент cookieclose в отдельный пейдж
- найти подходящую реализацию этого паттерна под c# (чтобы не просто в строках хранить
- вынести настройки и инициализацию драйвера в отдельный класс. В идеале - сделать или найти реализацию, не требующего явной передачи драйвера в конструктор (через Di или threadlocal)
https://t.me/joinchat/NnLJ08_n2iY5NTNi
Ключевые проблемы:
1) неявное поведение
2) избыточная логика
3) божественный объект
С первым понятно - размещение части логики выполнения в базовом классе скрывает не только детали реализации, но и сам факт наличия этой логики. Например, ты чистишь в базовом классе куки, и когда тебе они вдруг понадобятся, будешь в недоумении.
Второе - заранее невозможно угадать, что необходимо для всех тестов, а что для части. Например, у тебя ui тесты и ты инициализируешь драйвер в базовом классе. И тут тебе понадобилось накидать пару апишных тестов, а у тебя в базовом классе еще и репортинг например реализован. Теперь ты либо ебешься с флагами, либо пытаешься оторвать от базового класса эту функциональность.
Третье - базовый класс становится свалкой не связанных между собой фич, т.к. он один и формируется по принципу "все, что может понадобиться тестам".
В тестовых фреймворках как правило есть готовые решения для подключения общей функциональности - рулы, хуки, листенеры etc.
Наконец то годный тред.
Пноны подскажите, хочу вкатиться в QA Automation. Раньше изучал Python, но вроде как в автоматизации Java больше тащит.
Что посоветуете изучить помимо Java и Selenium чтобы успешно пройти на джуновскую позицию автоматизатора?
питон тоже на многих проектах используется, поэтому нет смысла специально учить джаву, если ты уже на каком-то уровне знаешь питон
тем более, на уровне джуна ты ни то, ни другое знать нормально не будешь, а пересесть на другой язык - пара недель
если ты вкатыш, то еще нужна теория тестирования и тест дизайн, имхо
Коротко об уровне программировании в QA, статистика на основе моих пет проектов:
>ноль приглашений программистом
>10 приглашений QA
Я понимаю твою боль, мне самому обидно, что придётся идти работать QA, вместо программиста, а потом спустя год опять пытаться перекатываться на программиста и единственные полезные навыки для кодинга которые у меня будут это знание пары команд из докера, открывание IDE с кодом, и написание примитивной заглушки и запушивание её в репу. Т.е. знаний для пограммиста по прежнему будет 0+0,00000000001.
Я имея опыт работы qa и видевший навыки мидлов и сеньоров qa, могу сказать, что qa со стажем 3-5 лет это этакий полуджун разраб, полуджун девопс. Мне напомнило павлинов, как распушив хвост сеньор qa ПМу рассказывает, что мы не успеем еще бы, разрабам похуй, они так и говорят, некогда им протестить все эндпоинты, у нас нет спеки, всё черный ящик. Начинает кудахтать про качество и про весь этот петушинный аджаил. Причем почти везде автотесты пишутся задолго позже, чем разработанная система, т.е. все клоунада с автотестированием она как бы показать заказчику за что такие бабки уплочены. Ну это как дарят кому-то подарок, сам подарок это то что сделали разрабы, упаковка это девопсы и qa бантик сверху натянули, но в прочем этот бантик, как и автотесты нахуй не нужны, скорее всего их придется переписывать еще не успев написать на весь функционал, потому что поменялась логика и кафка шлет теперь ещё куда-то топик, в бд новые колонки и т.д. Я даже видел сокращения в компаниях и первых кого сокращают - qa, потом АНАЛитиков, даже ручных тестировщиков не трогают, про разрабов я вообще молчу, скорее всех сократят, а разраба ни одного. Поэтому можно сколько угодно жить в манямирке, но qa это что-то уровня 1С программиста, и то, если 1ass-ник что-то там кодит, парсит джейсонины, кроме своего 1Са, то даже у него шансов уйти в разрабы на нормальный язык больше. Не забудьте написать
>пук
ведь это звук вашей рвущейся жопы, от очень грустной для меня и Вас правды.
Ты во всем прав, друг
Я тоже давно понял что это профессия изжила себя, мы все биомусор перед начальником.
Если нас даже в офисе не ценят, куда нам в раю? Бог наверно при виде нас скажет - "Вы в прошлом были очень плохими людьми", и прогонит нас обратно в ад, к начальнику, и будем мы сидеть и слушать от более умных людей какие мы говно
К сожалению qa это не работа, это твое ментальное состояние души - то есть быть всегда последним, то есть говном.
Теперь ребята давайте все вместе признаемся, мы говно! аминь
Есть такая поговорка "если от всех воняет говном, то может это ты обосрался?" Я видел даже как сеньор qa просил у мидла разраба помочь ему переписать код, потому что не понимал как протащить через слои. И подобный треш был в трех компаниях, да, маленькая выборка, но 3/3 для меня уже показательно. Кстати, если кто-то думает, что я настрочил текст потешить чсв сам будучи обосранным кек то он глубоко ошибается, скорее я раздосадован и хочу предупредить вкатунов, что дальнейший перекат в разрабы невозможен. Если готовы быть на позиции просящего и зависеть от разраба, девочки аналитика, девопса и даже местного сиськадмина, то qa ваш путь, зп у qa это -30% -50% от зп разраба, в зависимости от грейдов, потолок значительно раньше, подработка естественно невозможна. Я бы и рад перекатиться в разраба джуна, но у меня нет требуемых знаний, да и за 2 года опыта работы qa, придется потерять в зп. Вот так вот!
выкатился из треда, живете с этой инфой как хотите
1) Есть классы SoundTrack и Player. Когда я тестирую Player, нужно ли предоставлять ему заглушку вместо оригинального SoundTrack? С одной стороны, да, ведь в юнит-тестировании классы тестируются изолированно, а в SoundTrack могут быть свои баги, разумно подложить максимально облегчённую заглушку. С другой стороны, зачем городить дополнительные классы, если есть оригинальный?
2) тестирую метод-сеттер. Поле, с которым он работает, приватно, соответственно проверить значение могу только через геттер. Получается результат теста зависит от работы не одного а двух методов, а это не айс. Есть пути решения?
Есть профессия тестировщик - QA automation testing.
Чем это отличается от тестирования во фронтенде? Cypress, Jest, Enzyme, вот это вот все.
Условно говоря, применимы ли знания тестировщика во фронтенде и наоборот? Вроде бы тестировщик должен знать какой-то ЯП и многие выбирают JS. Получается они тестят на тех перечисленных инструментах (Cypress, Jest)?
>С одной стороны, да, ведь в юнит-тестировании классы тестируются изолированно
Выброси из головы эту дебильную концепцию. "тестировать изолированно" не равно "замокать весь окружающий мир", а скорее обозначает фокус текущего теста. Мокать имеет смысл только то, над чем у тебя в тесте нет контроля, например запросы к внешним ресурсам. Все остальное должно оставаться как можно ближе к оригиналу. Если для работы одному классу нужно вызвать другой, то это часть его функционала и должно быть отражено и проверено в тестах.
В твоем случае, если ты пишешь юнит-тест для плеера, то очевидно нужно проверить его работу с саундтреками, ведь это часть требуемого функционала. Но очевидно тебе будет очень неудобно писать тесты для всей отдельной логики внутри саундтрека, если придется каждый раз проходить через плеер, поэтому у саундтрек класса должен быть свой тест, фокусирующийся на этой логике более подробно, только и всего.
>Получается результат теста зависит от работы не одного а двух методов, а это не айс
Почему не айс? Ты должен фокусироваться не на отдельных методах, и тем более не на их количестве, а на том, как этот класс используется в остальном коде. Если остальной код выставляет значение через сеттер, а потом получает его через геттер, то это и нужно проверять, какая разница, что там два метода?
QA - это когда человек сидит и тыкает мышкой по сайту. У него могут быть всякие приблуды, скрипты, доступ к дев логам и прочее, чтобы облегчать тыканье мышкой, но по сути это всегда сводится к мануальному тестированию. Потыкал, посмотрел, сверился с ожидаемым результатом - по сути машинная работа, переложенная на человека. Ты же привел в пример инструменты автоматического тестирования, которые используются для проверки своего кода самими разработчиками, и они требуют реальных навыков программирования, а не просто базового знания скриптов.
>- найти подходящую реализацию этого паттерна под c# (чтобы не просто в строках хранить
Какой C#?
>>2181513
>Поясните за тестирование.
>Есть профессия тестировщик - QA automation testing.
>Чем это отличается от тестирования во фронтенде? Cypress, Jest, Enzyme, вот это вот все.
>Условно говоря, применимы ли знания тестировщика во фронтенде и наоборот?
Вопрос не понял. Может ты имел ввиду "применимы ли знания мануальщика". Да, если ты в мелких фирмах работать собрался, ибо ты там а-ля фуллстек. Но даже в корпорациях автотестер должен уметь в мануальщину ради тест-дизайна.
>Вроде бы тестировщик должен знать какой-то ЯП и многие выбирают JS.
Без разницы, если честно. Просто, если ты Java выучишь с его шикарным ООП подходом, тебе всё равно придется выучить JS вдовесок, чтобы раскрылись глаза на веб. А на каком языке пишешь автотесты - без разницы.
>Получается они тестят на тех перечисленных инструментах (Cypress, Jest)?
Ну да. Cypress, Jest (для фронта), Postman (для АПИ) - JS.
Selenium Web driver (для фронта), REST Assured (для АПИ) - Java.
На обоих фреймворках можно написать одинаковые тест кейсы.
>Ты же привел в пример инструменты автоматического тестирования
Я думал, что QA делится на ручное и автоматическое тестирование.
>>2181532
Понял. Просто я вкатываюсь в JS/React, попутно узнал о профессии тестировщика. Слышал, что некоторые сворачивают туда, не вкатившись в разработку. Тем более, там тоже JS.
Будет ли тестировщику полезен такой курс? - https://javascript.ninja/workshops/unit-testing
Учитывая, что автор ни разу не тестировщик, а фронтендер.
>Я думал, что QA делится на ручное и автоматическое тестирование.
"Автоматическое тестирование" может означать либо скрипт, который елозит мышкой по экрану за тебя, либо код, тестирующий другой код напрямую. Первое может писаться кем угодно, включая QA, второе - только разработчиками.
1) Ты только что детально описал два подхода - классический и лондонский. В лондонском в качестве юнита рассматривается только класс (соответственно мокируется все остальное), в классическом - любой набор объектов в коде, соответственно обязательно мокаются только внешние зависимости, остальные - по желанию.
2) Надо тестировать поведение, а не реализацию, а приватное поле это безусловно деталь реализации. Вопрос - что с точки зрения публичного контракта является успехом после вызова сеттера? Ответ "соответствующее значение геттера" является логичным, но вероятно не единственным. Если это не data class, то мы ожидаем изменения и в каких-то других публичных методах, иначе зачем там это поле. Соответственно, наша задача - проверить, что после вызова сеттера поведение класса в целом изменилось соответствующим образом.
Есть кто вкатился в разрабство после автоматизации? Сам уже несколько лет авто куа на жаве - веб тырпрайз, тестирование фронта и бека.
Хочу в андроид на котлине вкатиться. Какие мои шансы?
Шанс большой. Только вопрос зарплаты сильно зависит от многих факторов. Например, будешь ты в той же компании или уйдешь в другую. Какая зарплата сейчас? С какой позиции в автоматизации переходишь на программерскую (например, если ты из сеньор automation станешь джун котлин, то скорее всего денег будет меньше). В больших аутсорсных компаниях обычно есть набор требований, которым нужно удовлетворять, а также специальные люди, которые помогут переквалифицироваться.
> Если для работы одному классу нужно вызвать другой, то это часть его функционала и должно быть отражено и проверено в тестах.
> Ты должен фокусироваться не на отдельных методах ... а на том, как этот класс используется в остальном коде.
Хех, это уже получается интеграционное тестирование, а речь о юнит-тестах.
>Хех, это уже получается интеграционное тестирование, а речь о юнит-тестах.
Нет, это получается, что у тебя дебильное определение "юнит-теста", в котором если ты не замокал все интеракции(некоторые шизы хотят мокать вообще все другие вызываемые методы/функции), то это якобы не юнит-тест. Это определение было придумано диванными дебилами, которые тестами в повседневной работе не пользуются и не знают, для чего они и какую роль выполняют. Тест должен тестировать функционал. Если функционал замокан, то он не тестируется, вместо него тестируется мок, и получается не тест, а раздутое бесполезное говно, которое ломается от малейшей смены интерфейса.
Да, QA делится на ручное и автоматизированное.
Если ты задумал, что программирование (для разработчика) - это сложно, а QA - лёгкий, то вот тебе ответ:
QA Manual - лёгкий, но там вкатунов горы. Там кнопкодавство и база данных SQL.
QA Automation - это все равно про изучение языка, изучение фреймворков автоматизации, изучение паттернов, и способы это запустить на CI, CD Jenkins и знания SQL впридачу.
Поэтому я тебе рекомендую от профессии разработчика не отходить, потому что автотестером ты пройдешь одинаковое количество кругов ада по обучению.
Что выбрали и почему?
bottom line - это то, что писание полноценных автоматических тестов на код, которые пишут программисты, требует реальных навыков программирования. Если ты можешь писать такие тесты, то ты можешь писать и код, т.е ты уже разработчик, а не QA. QA к коду никто не подпустит, если ты где-то там копаешься в сыром SQL, то соболезную, потому что скорее всего проект дизайнил дебил. Все, что можно написать через "фреймворк автоматизации" - это end-to-end тест, который будет охватывать самый широкий скоуп и по сути просто имитировать действия пользователя, т.е тестировать через UI или в крайнем случае дергать сырое API(правда непонятно нахуя). Это хоть и важно, но, во-первых, является вершиной айсберга, и ты никогда не протестируешь и десятой части логики в приложении таким образом, во-вторых, это могут(и должны) сделать и сами разработчики, в-третьих, end-to-end тестирование - это самый ненадежный, неудобный, громоздкий и медленный вид тестирования, и его всегда надо сводить к минимуму, переходя к нему только после того, как код уже покрыт более низкоуровневыми тестами.
Нихуя феерическая расстановка точек. То есть если человек умеет писать код - то он автоматом разработчик. А если умеет выкатывать на прод, то он сисадмин, управлять командой - менеджер, а писать документацию - техпис? Чудный мир, где до сих пор не знают про T-shape.
Умеет писать код - да. Пусть и Джун, но да.
Разница лишь в том, что после кора разработчик свои фреймворки учит (сервлеты там, spring, hybernate),
а автомейшн тестер свои (селениум там, рест-ашуред, ну ты понял).
А javarush пройти приходится обоим, тот же самый Java collectiob framework учат оба.
Да похуй, я написал один сервис на спринге => смогу написать и другой. Спринг такая штука, что программиста с любым опытом на нем можно обломать, что он чем-то не пользовался и не знает. Глубокие эксперты сейчас нахуй не нужны, нужны люди, которые способны сделать проект, впервые видя этот язык, технологию и платформу. Ну по крайней мере в QA/SDET.
Да нахуй уже иди отсюда со своим нытьём. Программирование само по себе - скучная залупа, но тут платят не плохие деньги, если в рот ебал код, но хочешь денег, то QA лучший вариант.
Если ты красноглазый опущ, которому нравится ебстись с кодом и забивать себе голову тонной говна про языки и кучи фреймворков - дело твоё, лол. Мне не западло подойти к потному разрабу, который хуячит овертайм свой ссаный код и попросить о помощи по коду на тему автоматизации тестов
Т.е. придётся превращать в заглушку тот класс, который тестирую.
И тут я вспомнил, что вместо наследования можно было использовать делегирование...
Получается, в процессе написания теста я упёрся в неудобную архитектуру своей программы. И чтобы хорошо написать тест, мне придётся переделывать архитектуру. Можно сказать, подгонять архитектуру под тест (!).
Насколько это правильно и встречается в продакшене?
Читал, что грамотная архитектура облегчает тестирование. Но ведь тестовые фреймворки бывают разными, под все не наподгоняешься...
Классные вопросы задаешь.
Технически, ты можешь замокать методы супер класса, которые ты используешь в проверяемых методах наследника. В этом смысле все легально - ты замокал внешний код на уровне методов и тестируешь только свой. Если это сделать нетривиально ввиду сильной связанности кода, тогда уже возникает вопрос к архитектуре - а стоило ли завязываться на реализацию стороннего класса так сильно, что потом это невозможно распутать. Такая тесная интеграция создаст серьёзные проблемы потом, когда надо будет дорабатывать класс-наследник, обновится апи родителя или вообще надо будет переехать на другую библиотеку. Так что в этом случае проблемы с тестированием могут быть маркером плохой архитектуры.
>Чтобы её протестировать, мне надо mock-нуть системный MediaPlayer
Если я правильно понял, то мокать тебе прежде всего надо не MediaPlayer, а его системный интерфейс, если такая возможность есть. Для моков всегда надо стараться найти самый нижний уровень, например сам вызов конечных системных функций, а не обертку над ними в виде MediaPlayer'а
>Получается, в процессе написания теста я упёрся в неудобную архитектуру своей программы. И чтобы хорошо написать тест, мне придётся переделывать архитектуру. Можно сказать, подгонять архитектуру под тест (!).
Тесты - это просто код, который использует другой код. Ты обнаружил не то, что твой код хуево тестируется, а то, что его неудобно использовать из другого кода. Например, твой код нельзя в принципе запустить и проверить, не притащив с собой весь контекст системы. Так что если ты хочешь, чтобы твоим кодом было удобно пользоваться, то разумеется под это нужно подгонять архитектуру, из воздуха удобство не возьмется.
>Читал, что грамотная архитектура облегчает тестирование. Но ведь тестовые фреймворки бывают разными, под все не наподгоняешься...
Тестовые фреймворки тут не при чем, у них всех одна задача - выполнить кусок кода, сравнить с ожидаемым результатом и дать тебе знать о несовпадении. Хорошая архитектура будет хорошей и тестируемой любым фреймворком даже если на нее изначально не было ни одного теста. Но конечно до такой архитектуры ты не дойдешь своим ходом никогда, если нет тестов, чтобы тебя направлять.
ДОРОЖНАЯ КАРТА ТЕСТИРОВЩИКА ОДНОЙ КАРТИНКОЙ ПО ВЕРСИИ СВЯТОСЛАВА КУЛИКОВА.
http://svyatoslav.biz/wp-pics/testing_career_path.png
Можно добавить в следующий тред, ибо часто спрашивают "как вкатиться".
>Если ты красноглазый опущ, которому нравится ебстись с кодом и забивать себе голову тонной говна про языки и кучи фреймворков
Новичок спалился. АвтоQA тоже засирает себе голову языком и фреймворками (много о своих и немножко разрабских для понимания).
А причина, почему не иду в разработку, а сижу на авто QA, так это мое нежелание страдать над кодом модуля. Я подключаюсь в этапе, когда модуль уже что-то умеет и подставляю проверки.
И вот это все полистай, плюс SQL задрочить нужно
https://vladislaveremeev.github.io/#h.so6rdivehgaf
https://dou.ua/forums/topic/13389/
https://docs.google.com/spreadsheets/d/18giT_NbYLo9yc7yArAeTMnB8W9m3EqUvwftrfZMUyWQ/edit#gid=0
Прувет, на днях гулял на ютабе, нашел видос чувака с собеседом в luxoft, кто может сказать что про эту контору?
И кстати что насчет lifecodinga, насколько он распространен среди компаний?
Планирую полностью также сделать. Навыки и основы проги у меня есть. Сейчас пытаюсь ускоренными темпами что-то еще освоить
А куда поступил? Как в твоем вузе назывался факультет и в какой вуз? Я вот присматриваюсь к ЮУрГУ профиль 02.04.02 фундаментальная информатика а факультет - Машинное обучение и анализ данных. У них вроде как программа обучения вкусная. И java и python. Но не знаю смогу ли поступить, везде где до этого смотрел направления data science и ML требования были драконовские. Аля быть олимпиадником и по проге и по матану. Еще и краснодипломником и красноглазиком с B2 английским
А кто такой сдет? Они продукт трогают или только сложные тесты имплементят? Вот я например на работке обычно только тестики прогаю и наш кастомный тестовый фреймворк развиваю. Хотя формально в команде разработчиков и официально программист в трудовой написано. А если мой тест найдёт упадёт, то репорт придёт мне. И если это проблема в продукте, то чинить тоже мне. В итоге я сдет или это хуйня какая-то? Мы с вами коллеги или я вс1 таки прогер?
У нас нет опенсорса и сдеты занимаются созданием велосипедов для тестирования. Например, если обычно автотестер берет готовый инструмент типа селенида + репорт + тест раннер и на их основе пишет тесты, то у нас Селенид и другие инструменты СДЕТы пишут с 0, а мы, автотестеры, на основе этих инструментов пилим тесты. У нас СДЕТ к продукту, тестированию/автотестам отношения вообще не имеет. К коду продукта доступ только у девов.
У нас тут в снг SDET - ебала похуже девопса, который, как известно, по идее вообще не человек, а методология. Я под SDET понимаю чувака, который больше про технологии в тестировании, чем про автотесты. Например: разработка инструментов тестирования, внутренних сервисов, настройка пайплайнов, настройка статических анализаторов, разбиение тестовой модели на разные уровни - от юнитов до e2e. Может у анонов свое представление, я бы послушал.
А ты скорее личинка Product Developer, когда один человек покрывает несколько этапов из SDLC. Если проще, когда "я и песни петь могу, и ебаться мастер"
>А кто такой сдет? Они продукт трогают или только сложные тесты имплементят?
SDET обычно не касается саиого продукта (хотя может требовать его доработки с целью повышения тестопригодности, а то и сам в ней участвовать). Его дело - пилить инструменты и методологии; по сути это программист, который дополнительно шарит в тестировании и автоматизации. Вот этот >>2191861 более-менее верно описал, с той разницей, что на написание собственно автотестов у SDET обычно времени нет - этим занимаются тестеры, в том числе ручные.
>Слова типичного директора микрогалеры с зп в два раза ниже рыночной.
Иногда хочется стать таким директором, кек. Но поздно.
Тот долбоеб ни хера не умеет и сам в ахуе, что ему заплатили каких-то денег за его неумение. Я просто пытаюсь до него донести, что его удача - заслуга не его, а голода на рынке труда, из-за которого конторы хайрят кого ни поподя; но тот хер уже решил, что ухватил бога за бороду. Штош.
Йоу, можешь подсказать что необходимо для переката в SDET?
Я сейчас довольно топовый ручник (по-крайней мере по зепке, которая больше чем у половины девов в компании), но немного застрял в понимании того, куда двигаться дальше. Помимо тестирования неплохо умею в девопс (на уровне джуна девопса).
правда ли что 35+ лвл проще вкатиться в тесты, чем кодинг?
Тут смотри какое дело. Тестирование в целом проще на уровне джуна-мидла. По сути для вката хватает одной-двух книжек.
С другой стороны - в последние пару лет в тестирование пытается вкатиться каждый бомж, потому что сеньорам платят как программистам, а вкат не то чтобы тяжелый. Из-за этого рынок джунов дал ебу и на одно место по несколько сотен человек.
>Тот долбоеб ни хера не умеет
Эй, чепушила. Ты думаешь меня с улицы взяли? У меня было стандартное трехэтапное собеседование. И я еще и бабок больше попросил, т.к. были варианты пойти и в сберлизинг, и в другие места. И мне дали столько, сколько я попросил. И если дали, значит посчитали что я стою этих денег. И это не простые ui макакинг тесты. И контора не маленькая. Так что завидуй молча и соси бибу
Чел, не мороси, не важно кто ты, тестер не тестер. Просто учишь программирование, идешь к начальнику сдетов, говоришь хочу к вам и все. Не знаю ни одного продуктового девелопера кто бы в сдеты хотел. Сдет это вообще самая тупая работа, ты вроде программист, но актуальных рыночных технологий не знаешь, вроде со своим скилом программирования автотесты можешь написать, но ты не тестер, теория тестирования в сдет не нужна. Крч, SDET - юзлесс хуйня. Кста, в FAANG, SDET = автотестер. В сдеты недодевелоперов после стажировки набирают.
работаю с гуглом
>Просто учишь программирование, идешь к начальнику сдетов, говоришь хочу к вам и все.
Ну приди ко мне, лол. Как придешь, так и уйдешь с таким-то говном в мозгах и со скиллами уровня "просто выучил программирование".
>>2193574
>Не знаю ни одного продуктового девелопера кто бы в сдеты хотел
Многие хотят, ибо круды многих заебали, а платят сдетам больше, чем крудошлепам. Но мало кто тянет.
6 месяцев стучусь в закрытые двери
У каждой вакансии разный спек скилов. Я вот, например, вообще не шарю в мобайле, ибо уже несколько лет с этим не работал. Но сейчас углубленные познания бэка на своем проекте, умею настраивать стенды в кубах,
Конкретные скиллы учатся под конкретную вакансию, это нормально. Главное - уметь в приоритезацию, уметь в тест дизайн, уметь в работу с неявными требованиями, ну и в самостоятельность.
Ну и, понятное дело, такие зепки появились недавно, с кадровым голодом. Еще полтора года тому назад 120-150 было топом для сеньоров не в манагерских позициях. Сейчас столько хотят не очень сильные мидлы. Сколько это продлится - хуй знает. Спекуляций и срачей на эту тему - много
Нужна ли матеша?
Где брать инфу?
Как подтянуть англ?
Читаешь Куликова, смотришь курсы на ютубе, снова курсы и так до тех пор пока не надоест одно и тоже смотреть то есть нового не узнаешь, в резюме вписываешь себе яндекспрактикум унылые курсы - концентрат воды, которые наиболее котируются у рабовладельцев и идешь искать работу.
Главная теория - быть не долбоебом. Это сложно.
>>2194284
Ага, знаю. У них типа еще много скиллов вроде бы, начинаешь расспрашивать чо да как. Оказывается - ничего не знают, делали "как им сказали", не пытались разобраться как, зачем, нахуя. Вот типа чувак жмет на кнопку собрать билд в тимсити, потому что ему показал программист - а в навыках уже CI/CD. Ну такое конечно. Хотя, конечно, попадаются и оч крутые ребята. Но их мало.
https://youtu.be/ECiUmmfMjpI?t=1535
В рф сейчас очень конкурентноспособный рынок, после того как гиганты стали пылесосить. Я в финке/эстонии смотрел (многие страны мне закрыты из-за отсутствия во) - и после вычета налогов не нашел ваканстй, которые перебивали бы мою по бабкам.
А по скиллам - совет конечно хороший, очевидно что это не предел и надо двигаться. Просто 200 для авто сейчас в рф это не высокий уровень, и что там лоу-скиллы на этих зепках - это норма.
>Ну давай хотя бы теорию тестирования.
Лажает.
Я тоже могу в отрицание пойти, когда у меня собесы не ладятся. Но вместо этого взял и записал вопросы, которые чаще всего задают, но которые не применимы на работе так глубоко как их на собеседованиях гоняют (OSI, TCP там, юнит тесты тестировщиком, завальные вопросы по Java).
Ну раз их задают, выставляю перед собой и нажимаю на них перед следующим собесом.
Зато когда сможешь успешно пройти собес - не станешь же ныть, что всё заданное там не нужно. Наоборот! Скажешь "какой я у мамы молодец, даже с этим справляюсь и собес как семечки пощелкал".
А вот у меня встречный философский вопрос о не веб приложениях на Windows:
1. Stand alone приложение, а именно GUI через что проверяют? Windows driver для селениум что-ли? Если да, то что там локатор? Или же там findElement(By.name) всегда?
2. Я на ютесте запускал дамп данных для stand alone приложения. Куда он обычно лезет, чтобы логи собирать? В журнал-планировщик Windows? Или куда?
Засрали людям мозг, что из автотестеров разработчик и СДЕТ не получится.
И при этом самим разработчикам засирают мозг "можно стать левом с нуля в 40, 50, 70 лет".
Мой ответ МОЖНО во всех случаях!
Разница лишь в том, что AQA применяет половину javarush-a, а для дева и сдета придется заучить целиком. Материал же вот даже бесплатный доступен/на торрентах/на Ютубе. Или те же платные курсы улетают девов.
МОЖНО? МОЖНО!
>У кого-нибудь есть пример реализации xray+junit4
Не понял тебя.
Во первых. Если какая-то технология мне непонятна, я учусь гуглить.
xray только на английском https://youtu.be/L5Ht_SWgYTE
Не столько важно упоминание junit4, сколько в целом junit, testng.
И когда возникает вопрос о "связке и реализации этого в Java", то открываешь свою intelliJ IDEA, создаёшь мавен проект, заходишь в pom.xml, заходишь на сайт с документацией xray https://docs.getxray.app/plugins/servlet/mobile?contentId=62271372#content/view/62271372
И учишься в свободное от работы время.
Звонишь либо пишешь на е-почту аудиозапись кадровику.
Говоришь: "а хочу вкатиться таким-то в вашу галеру, а тест по английскому валится. Я уверен в своем уровне языка. Давайте я вам кулстори по-английски расскажу и вы мне поставите В2. И рассказываешь".
Кадровик сама залезет в панель управления и поставит тебе нормальный уровень.
