Спасибо за статью! Автор, не переживай - это одно собеседование из многих - и ты его прошел более чем хорошо) Бывают такие собеседования, что потом вообще думаешь, а стоит ли мне в этой профессии дальше пытаться что-то)
Так что поздравляю) Да, если давать совет, хоты вы уже сами себе его дали, не спешите с ответом на вопросы и принятием решений, если покажете ход мысли собеседующим, будете рассуждать перед ответом, то им станет намного понятнее - есть ли у вас потенциал.
Джунов правда берут по принципу - "Теорию вроде знает, ошибки есть, но голова работает как надо".
Так что вы быстро сможете себя зарекомендовать)
А ну еще. Не бойтесь говорить, что чего-то не знаете, это не страшно - от вас и не ждут знания всей теории а тем более практических задач, лучше вместо длинной паузы сказать - Затрудняюсь ответить, и время занять другими вопросами)
Я дико извиняюсь но зачем вводить людей в заблуждение " Лично моя зарплата за первый год работы выросла ровно в 14 раз, при том, что на старте я получал как работник Макдональдса. "
Это просто кастомная обертка над аллюр.. По мне так не тянет на отдельный плагин если честно. Всю логику можно описать в одном/двух классах прямо в проекте.
Если людям, которые используют ваш плагин нужно будет чуть-чуть изменить логику вывода отчета или добавить туда что-то свое, как они могут это реализовать, используя ваш плагин?
Плюс вопрос в том - если у меня в одном проекте и интеграционные и UI тесты - мне отдельно allure использовать и отдельно ваш плагин? Это как минимум неудобно...
Да и в целом мне честно говоря не очень нравятся плагины плагинов. В какой-то момент возникнут проблемы с версиями allure или pytest. Ваш плагин сломается, придется идти искать его новую версию, не факт что она будет корректно работать и т.д.
Не согласен с утверждением про Xpath и его громоздкость. Как правило проблема либо в нахождении короткого локатора, либо в фронтендерах...
Для динамического построения и поиска локаторов - без xpath никак, для оперирования с селектами - без xpath никак, для условий contains/not contains/and/or/length и т.д. - без xpath никак.
Исходя из 5 лет опыта. По работе с вебом - только в 1-2 случаях из десяти есть корректные id и классы, к которым красиво можно привязаться по CSS. Остальное - поиск по xpath сверху до низу по соседям/наследникам/родителям и применение условных операторов внутри локаторов.
На мой взгляд стоить изучать xpath - это сложнее для новичков, это не так красиво как структура .class - но профита от этого больше, в том числе и для понимания расположения и работы с элементами на страницах + универсальность и мощное преимущество в виде встроенных функций.
А CSS локаторы использовать только в качестве красивых примеров на шаблонных проектах, ну или в статьях на хабре_)
Хорошая статья - спасибо. Если вы занимаетесь только бэком - то в принципе такой вариант хорошо подходит. Другое дело что оно на раннем развитии сейчас. Мой выбор - это простота написания тестов на Python с request + понятные структуры тестов на Java с Rest Assured + огромное комьюнити для решения проблем и вопросов без велосипедов. Один вопрос - если у вас появится UI - чем вы будете его тестировать? Добавлять новый язык в пирамиду автотестов?
П.С. Я бы не стал рекомендовать эту статью тем, кто не знает с чего начать... Начинать надо всегда с простого, но не с го)
Спасибо за статью — много текста, прочитал взахлеб. Некоторые фразы даже выписал. Особенно понравилось про опыт "… про профессионалов с большим опытом можно сказать, что они кладезь воспоминаний о вещах, в которых когда-то хорошо разбирались."
Это настолько точно описывает некоторых бывших коллег))
Скажу про софт скиллы. Очень полезно проходить собеседования, даже если и не надо)
Это помогает во всем. В развитии навыков, в понимании тренда, в выборе компании и направления в будущем.
В свои 32 чувствую себя уже старым, особенно когда в чате постоянно мелькают новые сотрудники от 18 до 25 лет с кучей опыта работы (сам в ИТ с 27 лет).
Считаю, что сейчас для специалистов с большим опытом удобные условия для устройства на работу. Как заметили выше сейчас все стремятся в ИТ, все проходят/покупают курсы, самообучаются и хотят влезть на корабль удаленки в солидную компанию.
Но по факту, такие ребята валятся на собеседованиях, либо частенько уходят в первые месяцы после трудоустройства. и таких людей все больше и больше.
Еще раз спасибо за крутую статью)
Вообще это неправильно — заставлять разработчиков писать е2е тесты. Во-первых, как упоминали выше — каждый должен заниматься своим делом. Ну, казалось бы — пилят разрабы автотесты — это не так сложно для них, время идет, зп идет — все проверяется. Но при этом они не видят картины в целом по фреймворку, и насколько точно в нем тестируется весь продукт.
Отсюда вторая проблема — очень не зря говорят, что хорошо, когда автоматизацией занимаются бывшие ручные тестеры — люди с опытом составления кейсов и документации. Разработчик так не сможет покрыть автотестами функционал, как сделает это тестировщик. У него будет минимум сценариев е2е тестов на фичу, которые будут напоминать расширенные юнит тесты с кучей моков и заглушек — лишь бы в отчете загорелся зеленый свет.
И третья проблема — она тоже на мой взгляд важна — разработчики знают код и уверенно усложняют фреймворк дополнительными самописными библиотеками, кучей оверрайда и т.д… Потом, если захотите возобновить набор автотестеров — то им будет очень сложно интегрироваться, так как там может ждать TestNG+Junit+Cucumber+Rest+ что-то еще монстр собранный из разных частей фреймворков.
И по поводу «утерянной экспертизы» — надо все документировать — в конфлюенс в битбакете в гитлабе в проекте — где угодно, но комменты нужны такие, чтобы и дураку понятно было.
Короче — наймите нормального QA лида — он разберется)
Читать было интересно))
Честно говоря, странно утверждать, что данный проект каким-то образом имитирует нагрузку, при этом проходя аж в целых 3! поток…
А можно уточнить каким образом делается отчет в excel? И примерчик работы с БД хотелось бы увидеть?
И вообще, друг просил ссылку на репозиторий)
P. S. Друг, если тебе платят 80000 руб. и при этом ты один всю эту систему пилишь, поддерживаешь и внедряешь, то проси прибавку x1,5 хотя бы, или подумай о море вакансий после карантина)
Опять кто-то рефераты на хабре постит свои.
Странно, что не упомянули про очереди в Магнитах и их искусственный интеллект, который Галю вызывает, чтобы толпу покупателей раскидать… Сейчас вон громкими звоночками из 90х обходятся)
Статья отличная!, последний пример про гуглодок вообще сюрреализм какой-то) Тестировщик должен прежде всего уметь общаться со всей командой.
Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет. И вот он пытается на этапе обсуждения требований заказчика что-то свое предложить, но его не слушают, пытается объяснить разработчику, как будет удобнее для пользователя сделать кнопку, форму и т.д. — разработчик говорит — этого нет в ТЗ. Рассказывает в никуда про автоматизацию и юнит тесты. В общем пытается сделать качество продукта более высоким, но безрезультатно.
Что делать вот в такой ситуации? Увольняться? Давить? Писать предложения руководству? Забить и плыть по течению?
Поделитесь, пожалуйста, опытом, сталкивались ли вы с чем-то подобным и есть ли какие-то универсальные решения?
Мобильные приложения это вообще отдельная тема, если покопаться как следует, то в каждом втором можно найти явные баги.
К сожалению, данным приложениям уделяется относительно мало внимания. У меня конкретные ошибки были в чате Сбербанк онлайн, когда ответы от поддержки отображались выше чем мои вопросы, и то, что они не могут открыть скрины, которые я им присылал.
Не тестировал на XSS уязвимости, но уверен, что и с безопасностью при таком подходе к разработке у них есть проблемы.
Особенно в таких случаях «радует» тех. поддержка таких крупных компаний(привет EA и hh), тратишь кучу времени, чтобы зарегистрировать для них ошибку, проходит неделя — смотришь баг, смотришь обращение — все осталось на своих местах.
Так что продолжайте — может хотя бы здесь компании будут реагировать быстрее, если им важна репутация
Спасибо за статью! Автор, не переживай - это одно собеседование из многих - и ты его прошел более чем хорошо) Бывают такие собеседования, что потом вообще думаешь, а стоит ли мне в этой профессии дальше пытаться что-то)
Так что поздравляю) Да, если давать совет, хоты вы уже сами себе его дали, не спешите с ответом на вопросы и принятием решений, если покажете ход мысли собеседующим, будете рассуждать перед ответом, то им станет намного понятнее - есть ли у вас потенциал.
Джунов правда берут по принципу - "Теорию вроде знает, ошибки есть, но голова работает как надо".
Так что вы быстро сможете себя зарекомендовать)
А ну еще. Не бойтесь говорить, что чего-то не знаете, это не страшно - от вас и не ждут знания всей теории а тем более практических задач, лучше вместо длинной паузы сказать - Затрудняюсь ответить, и время занять другими вопросами)
В общем удачи)
Я дико извиняюсь но зачем вводить людей в заблуждение " Лично моя зарплата за первый год работы выросла ровно в 14 раз, при том, что на старте я получал как работник Макдональдса. "
Это вообще как, за год с 20 до 280 прыгнули?
Это просто кастомная обертка над аллюр.. По мне так не тянет на отдельный плагин если честно. Всю логику можно описать в одном/двух классах прямо в проекте.
Если людям, которые используют ваш плагин нужно будет чуть-чуть изменить логику вывода отчета или добавить туда что-то свое, как они могут это реализовать, используя ваш плагин?
Плюс вопрос в том - если у меня в одном проекте и интеграционные и UI тесты - мне отдельно allure использовать и отдельно ваш плагин? Это как минимум неудобно...
Да и в целом мне честно говоря не очень нравятся плагины плагинов. В какой-то момент возникнут проблемы с версиями allure или pytest. Ваш плагин сломается, придется идти искать его новую версию, не факт что она будет корректно работать и т.д.
Я как тест с time.sleep увидел - понял что ничего хорошего от поста ждать не приходится...
Серьезно в 2022 году автоматизировать веб с помощью робота мышки и записи сценариев аля selenium IDE ?
В чем плюс этого инструмента? В универсальности?
Нет смысла смешивать разные виды тестирования в одном инструменте..
Опять же - ладно выбрали новый крутой(нет) инструмент, но поддержка, решение проблем и коммьюнити?
В общем к посту больше вопросов, чем ответов.
Не согласен с утверждением про Xpath и его громоздкость. Как правило проблема либо в нахождении короткого локатора, либо в фронтендерах...
Для динамического построения и поиска локаторов - без xpath никак, для оперирования с селектами - без xpath никак, для условий contains/not contains/and/or/length и т.д. - без xpath никак.
Исходя из 5 лет опыта. По работе с вебом - только в 1-2 случаях из десяти есть корректные id и классы, к которым красиво можно привязаться по CSS. Остальное - поиск по xpath сверху до низу по соседям/наследникам/родителям и применение условных операторов внутри локаторов.
На мой взгляд стоить изучать xpath - это сложнее для новичков, это не так красиво как структура .class - но профита от этого больше, в том числе и для понимания расположения и работы с элементами на страницах + универсальность и мощное преимущество в виде встроенных функций.
А CSS локаторы использовать только в качестве красивых примеров на шаблонных проектах, ну или в статьях на хабре_)
В кубере можно поднять moon, тот же селеноид. За время использования с UI тестами на java и на python проблем не было. Так что можно и без ВМ)
Так на курсе по Python автоматизации на Stepik сделано)
Очень жаль терять образованного, опытного хирурга, из-за умирающего здравоохранения в нашей стране(
Хорошая рекламная коллаборация Яндекс Практикума и "Кавычек"... Но в целом маразм.
Да, у них есть чаты с вакансиями, да у них вам будут давать знания и практику.
Но история Сергея - исключение по большому счету.
А уж про QA лидерство через 1.5 года.. Это только по большому блату и родственным связям.
Ну или в компании на самом деле беда с толковыми тестерами.
Стремление - это круто, желание - это огонь.
Но будьте готовы к тому что первую работу вы найдете через год или два после обучения. И то почти за бесплатно.
Хорошая статья - спасибо. Если вы занимаетесь только бэком - то в принципе такой вариант хорошо подходит. Другое дело что оно на раннем развитии сейчас. Мой выбор - это простота написания тестов на Python с request + понятные структуры тестов на Java с Rest Assured + огромное комьюнити для решения проблем и вопросов без велосипедов. Один вопрос - если у вас появится UI - чем вы будете его тестировать? Добавлять новый язык в пирамиду автотестов?
П.С. Я бы не стал рекомендовать эту статью тем, кто не знает с чего начать... Начинать надо всегда с простого, но не с го)
Это настолько точно описывает некоторых бывших коллег))
Скажу про софт скиллы. Очень полезно проходить собеседования, даже если и не надо)
Это помогает во всем. В развитии навыков, в понимании тренда, в выборе компании и направления в будущем.
В свои 32 чувствую себя уже старым, особенно когда в чате постоянно мелькают новые сотрудники от 18 до 25 лет с кучей опыта работы (сам в ИТ с 27 лет).
Считаю, что сейчас для специалистов с большим опытом удобные условия для устройства на работу. Как заметили выше сейчас все стремятся в ИТ, все проходят/покупают курсы, самообучаются и хотят влезть на корабль удаленки в солидную компанию.
Но по факту, такие ребята валятся на собеседованиях, либо частенько уходят в первые месяцы после трудоустройства. и таких людей все больше и больше.
Еще раз спасибо за крутую статью)
Отсюда вторая проблема — очень не зря говорят, что хорошо, когда автоматизацией занимаются бывшие ручные тестеры — люди с опытом составления кейсов и документации. Разработчик так не сможет покрыть автотестами функционал, как сделает это тестировщик. У него будет минимум сценариев е2е тестов на фичу, которые будут напоминать расширенные юнит тесты с кучей моков и заглушек — лишь бы в отчете загорелся зеленый свет.
И третья проблема — она тоже на мой взгляд важна — разработчики знают код и уверенно усложняют фреймворк дополнительными самописными библиотеками, кучей оверрайда и т.д… Потом, если захотите возобновить набор автотестеров — то им будет очень сложно интегрироваться, так как там может ждать TestNG+Junit+Cucumber+Rest+ что-то еще монстр собранный из разных частей фреймворков.
И по поводу «утерянной экспертизы» — надо все документировать — в конфлюенс в битбакете в гитлабе в проекте — где угодно, но комменты нужны такие, чтобы и дураку понятно было.
Короче — наймите нормального QA лида — он разберется)
Читать было интересно))
А можно уточнить каким образом делается отчет в excel? И примерчик работы с БД хотелось бы увидеть?
И вообще, друг просил ссылку на репозиторий)
P. S. Друг, если тебе платят 80000 руб. и при этом ты один всю эту систему пилишь, поддерживаешь и внедряешь, то проси прибавку x1,5 хотя бы, или подумай о море вакансий после карантина)
Сохранил картинку с графиком)) Очень похоже на мой день)
Странно, что не упомянули про очереди в Магнитах и их искусственный интеллект, который Галю вызывает, чтобы толпу покупателей раскидать… Сейчас вон громкими звоночками из 90х обходятся)
Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет. И вот он пытается на этапе обсуждения требований заказчика что-то свое предложить, но его не слушают, пытается объяснить разработчику, как будет удобнее для пользователя сделать кнопку, форму и т.д. — разработчик говорит — этого нет в ТЗ. Рассказывает в никуда про автоматизацию и юнит тесты. В общем пытается сделать качество продукта более высоким, но безрезультатно.
Что делать вот в такой ситуации? Увольняться? Давить? Писать предложения руководству? Забить и плыть по течению?
Поделитесь, пожалуйста, опытом, сталкивались ли вы с чем-то подобным и есть ли какие-то универсальные решения?
К сожалению, данным приложениям уделяется относительно мало внимания. У меня конкретные ошибки были в чате Сбербанк онлайн, когда ответы от поддержки отображались выше чем мои вопросы, и то, что они не могут открыть скрины, которые я им присылал.
Не тестировал на XSS уязвимости, но уверен, что и с безопасностью при таком подходе к разработке у них есть проблемы.
Особенно в таких случаях «радует» тех. поддержка таких крупных компаний(привет EA и hh), тратишь кучу времени, чтобы зарегистрировать для них ошибку, проходит неделя — смотришь баг, смотришь обращение — все осталось на своих местах.
Так что продолжайте — может хотя бы здесь компании будут реагировать быстрее, если им важна репутация