Comments 16
по истории вопросов нет, кейс нормальный, но... " Я работаю в «Цифровых решениях» уже почти полгода. Сейчас я занимаю должность ведущего специалиста в области тестирования". и до этого никакого опыта в тестировании нет, сам автор пишет что "теория тестирования - слабо".
Спрашивать-то, спрашивают. Только толку от этого. Вот сколько раз потом на практике понадобилось писать код маркером на доске?
Сколько проектов по тестированию требуют глубоких знаний базовых методов языка?
Куча проектов по поддержке, где вся работа сводится исключительно к написанию новых тестов и выпишиваеию старых. Кстати, я бы сказал они именно идеальная среда для начала карьеры. Есть куча примеров и можно по разбираться на текущей базе кода как всё работает. Никаких гарантий, что это будет наилучший вариант. Но для базы, понимания архитектуры фреймворка и базовых слоёв подойдёт.
В тестировании нэгораздо больше пользы от понимания тест фреймворков, их возможностей и ограничений.
Некоторые фреймворки вообще ломают логику базового языка.
Например, работа с Selenium в Python, всё равно превращает код в JAVA образный.
Поэтому лучше знать тестовые фреймворки и как их интегрировать. Почему Cypress подойдёт для тестирования онлайн магазинов, но не сложных бизнес приложений. Чем Playwright лучше Selenium. Чем так хорош pyTest и как его осилить после jUnit и TestNG. Как тесты параллелизировать и с какой CI.
Почему Azure в минимальной подписки не имеет смысла. И т.д.
Ну слушай, рынок так устроен сейчас, я тоже не совсем понимаю принцип собеседования во многих компаниях, но таковы реалии сейчас)
Вот тут не соглашусь, для качественного выстраивания того же паттерна POM , понадобятся базовые знания языка)
А вот с последней частью полностью согласен)
Это не совсем рынок так устроен. Это так устроен круг людей проводящих технические собеседования. Которые иногда просто спрашивают то что нравится им самим, или просто находят вопросы в интернете. А кандидаты также находят ответы на эти вопросы. Всё таки нужно больше стараться отталкиваться от конкретной позиции, конкретного состава команды и продукта. Но как говорил один боксёр:"Все, но не каждый" могут так делать.
В реальности фреймворк на проекте поднимается 1 раз, ну может 2. Это не то знание, которое будешь применять каждый день. Для этого достаточно открыть документацию, прочитать, осознать и применить. Вот этот навык куда важнее, знания наизусть информации, которая и так всегда под рукой. Вот работу с git, ревью, составление тестовых сценариев, работа с тестовыми данными, просмотр результатов, триаж и починка CI - это действительно то что применяется каждый день.
Кроме того, надо понимать домен в котором работаешь. У меня на одном собеседовании волосы дыбом вставали. Когда спрашивали по Python перечни базовых методов, магисеские мотоды классов, декораторы и т.д. Когда я спросил зачем, то получил ответ который меня ввёл в ступор. Потому что обычно идут путём привлечения девеелоперов для написания моков и стабов и возможно базовых методов взаимодействия тест фреймворка с продуктом. Но тут решили что тестировщики должны помочь девелоперам переписать продукт под новую версию Python.
Но интервьювер вообще не принял в рассчёт одну такую маленькую деталь. Что продукт был медицинским. А тут по стандарту не могут быть никаких смешений взаимодействия разработчиков и тестировщиков. В идеале - это вообще должны быть люди из разных организаций с максимальным уровнем независимости на принятие решений.
Ну найдут они подходящего кандидата по соображениям тех интервьювера. Но при сдаче проекта внезапно осознают, что всё сделанное нужно переделать. Потому как FDA такую халтурку в жизни не пропустит, когда код писал и полностью тестировал один и тот же человек.
Так что сейчас есть наглядная проблема больших контор которые подводят унификацию требований для кандидатов сами не осознают область на которую эту унификацию стоит и можно расспространять.
Всё таки в идеале, интервью должны проводить люди имеющие прямое отношение к конкретному проекту. А сейчас получаем в большинстве случаев - когда интервьювер, в лучшем случае, получил строк 20 описания проекта. Пришёл проводить интервью, потому что за эту активность можно получить некий бонус. И задаёт вопросы, которые весьма интересны с точки зрения погружения в глубины языка. Но ответы на которые можно будет благополучно забыть ровно до следующего интервью.
Прям аж захотелось срочно пойти в Яндекс практикум и добиться успеха как у автора. Настолько классный, что аж с первой попытки написал хорошую, содержательную, статью которая читается будто ее писал человек с большим опытом написания на Хабр.
Да я и не скрываю, что помогли составить грамотно, но разве это плохо для конечного читателя?)
Слушай, а где ты отклик получил, перед тем как попасть в "Цифровые решения"? Вообще интересная ситуация на рынке вырисовывается, компания пишет на katalon, и как найти работу python разработчику если она не на python :D А другие чисто галерки
Я имею ввиду на каком сервисе ты оставил отклик туда?
Знаю что хабр свободная площадка, однако не понимаю негатива комментаторов. На гораздо менее информативных постах и того меньше. Юрий спасибо за такое подробное описание своего пути, во многом схожи) но я пока не нашёл того места ,где бы чувствовал что на своём месте. Всех с Наступающим!
Эта статья в очередной раз доказывает тот факт, что разработчик должен быть разносторонним и должен присматриваться и к другим, востребованным областям своего ЯП. Копать не только в дурацкие, в основном, ролики на ютубе, но и в такие статьи)
Хотел устроиться Python-разработчиком, стал мидлом в QA-отделе — как я искал первую работу