Здравствуйте, ДОУ-форумчане!
Есть ли шансы для QA инженера с опытом работы 3 года получить работу за границей? Может кто-то подскажет эффективные сайты для поиска, какие компании берут на работу иностранцев.
Спасибо за ответы и потраченное время!
Пришлите мне свое резюме, попробую вам помочь.
А можно я тоже вам пришлю резюме?
Ни к коем случае! :D
Можно было даже не спрашивать :) присылайте
Коментар порушує правила спільноти і видалений модераторами.
Nikita Barsukov
Software engineer, data analysis, business intelligence and machine learning
23.08.2013 12:11
Работа QA за границей — возможно ли?
Да, можно.
Надо уметь программировать + свободный английский + настойчивость и терпение.
Поддерживаю.
Хочу добавить, что также необходима взвешенная, аргументированная (в первую очередь для себя) мотивация
С тремя годами опыта можно попасть только в Майкрософт, если повезет, и только потому что они берут всех подряд.
Реально стоит расчитывать шансы на уезд через пару лет. Для большинства компаний легче и обычно надежнее взять выпускника Стенфорда, чем везти условного индуса с тремя годами опыта через весь мир.
Ну и вообще, почитайте на счет что делают SDET и развивайтесь в эту сторону. Мануальщики из-за границы тоже никому не интересны, хоть с 20ю годами опыта
Вот же как получается. у меня 10+ опыта работы, работал в многих наших лидерах.В микрософт на собеседования 3 раза ходил и не взяли. Выходит я даже не вхожу в множество
всех подряд:D
Ты просто не «все подряд»
Ну тут сложно что-то говорить ) может стоит попробовать узнать свои слабые стороны и улучшить их?
Кстати, «tunein» радио аггрегатор- отличное приложение под андроид.
QA по-вашему что, — делиться на мануальшиков и SDET (которые, к слову, — вообще не QA!)?! oO
Я не разбираюсь в полной иерархии QA, знаю только что мануальщиков обычно никто не перевозит
Ну как сказать, перевозят, просто не так много как тех кто занимает Grey/white-box_овым тестированием.
Да и есть продукты на которые нужна армия мануальщиков на самом деле, например игры :)
Взять тот же League of Legends от Riot Games — там толпа просто!
А почему SDET вообще не QA?
Потому что SDET — по большей части quality control, а QA — quality assurance. 2 разные роли в процессе разработки ПО
Потому что SDET это Software Development Engineer in Test.
А кроме названий, по функционалу разницу назовите. Интересно просто. Не берем мануальщиков, с ними понятно.
Что, простите? Мне вам лекцию прочесть на тему «чем занимается SDET»? Вы не в курсе? — Пишет юнит-тесты при в TDD и BDD методологиях разработки софта. Еще, как вариант, работает с синхронизаторами требований и кода, например, на Кукумбере...
Специалистам из Microsoft надо объяснять очевидное?
Вы просто очаровательны) Нет, правда) Особенно когда объясняете роль SDETов людям, которые работают SDETами в компании, которая по сути создала эту роль. Причем именно с той позиции, что вы точно знаете как оно должно быть. А остальные не знают.
Может я Вас разочарую, но юнит тесты это удел программиста. На SDET лежит тяжелая ноша енд2енд тестирования, плюс система автоматизированного контроля качества кода и прочие плюшки.
Большое спасибо всем ответившим! Теперь я знаю над чем еще нужно поработать и куда обращаться потом. Всем удачи! :)
Если отбросить всякие «умные» комментарии, изложенные здесь, по поводу формулировки вопроса, скажу, что найти работу вполне реально. По крайней мере, я нашел. Путей поиска огромное множество. Начиная от упомянутого здесь LinkedIn(вполне хороший ресурс) и заканцивая web serfing по компаниям отрасли в интересующей вас стране.
От себя добавлю что отправка резюме напрямую в крупную компанию (например Майкрософт :) ) тоже годный способ. Изучите вакансии на сайте компании, и отправляйте заявку на интересующую Вас. И не бойтесь, шансы достичь успеха есть всегда.
Да есть, спрос на SDET большой. Примерно 3 попытки хантинга в месяц на Linkedin.
Требования быть хорошим QA и Программистом. Ну и знания языка конечно.
Какие компании — да много их, перечисляйте все крупные и будете правы. Мелкие тоже иногда организовывают релокейшн. Самый эффективный сайт — LinkedIn, ну могу еще Glassdoor назвать, хотя через него ничего никогда не искал. Удачи Вам
А при чем тут SDET? — Вы профиль девушки посмотрите, обычный мануальщик в одной компании.
Я бы вообще SDET к QA не относил, это программист как бы, сама аббревиатура как бы намекает.
Да вот при том же, что QA как таковых почти никто не набирает. А SDET пользуется спросом, поэтому учитывая навыки топикстартера это оптимальный вариант, хотя может повезет и найдет себе позицию мануальщика. Но SDET позиций больше.
Учитывая навыки топик стартера, ей заграница не светит. «мануальные девочки» пользуются спросом только в Украине, и то, — это не надолго!
SDET вырастает из программиста или в крайнем случае из автоматизатора (хотя это странный карьерный путь, как по мне), но никак не из манульного QA.
Мануальные девочки еще как пользуются спросом вот например в Голландии, как пример — Амазон, Европейское космическое агенство. Там работала/работает тестером моя жена, кстати именно по ее визе мы тут находимся. Уже тут на месте она начала заниматься автоматизацией и достигла успехов. В Логике HP (Одесса) она была лучшей мануальщицей (больше всего открытых дефектов за год, в два раза где то больше чем 2е место). Мои 3 тестера в Люксофте за год открыли в сумме в 50 раз меньше дефектов чем она за тот же период.
Впервые вижу, чтобы эффективность тестера оценивали по количеству найденных дефектов. Это что, специальная олимпиада?
Ну почему же, так делают многие и не только в Одессе-Израиле, но и на западе. Я же написал — выборка за год была. Олимпиада длится от 4ч до
Если мы говорим об этом и том же продукте и одних и тех же сроках, то количество можно использовать как одну из метрик, но только как ОДНУ ИЗ, так как найденных 10 критических багов или блокеров перекрывают бесконечное количество всех других ;)
А вы не задумывались, что это может быть связано с профессиональностью человека? Со знанием большего числа техник, технологий, инструментов. С опытом в конце-концов. В этом свете у более эффективного тестера действительно будет больше открытых дефектов. Проект от проекта отличается, но немного зная контекст, могу сказать что количество, в данном случае, может иметь значение :)
И, кстати, раз уж вы решили покопаться в формулировке, количество найденных дефектов не всегда равно количеству открытых дефектов
Это все бла-бла-бла, а в метриках цифры (открытые дефекты, процент режекта и т.п). По повода нашел != открыл причем здесь это, если не открыл то вполне возможно «не то нашел, не там искал, уже нашли, и еще 100500, что говорит не в вашу пользу, поэтому в метриках «открытые дефекты» а не че то другое и «процент режектов» типа открыли а не то. Особо радует когда такие герои описывают как профессионально они искали а потом приходит молоденькая девушка тестер или добрый дяд-немец ПМ, запускает и все падает. А мы все искали...
Вот уж точно где
бла-бла-бла
бла-бла-бла есть пока не предложите вместо работающей плохой метрики лучше, но измеряемой, а пока что у вас бла-бла-бла, что и было расписано. По СМАРТу не пройдет.
Вы перепутали, это был не я. Я как раз не вижу ничего плохого в том, чтобы использовать эту метрику для high level оценки инженера.
простите если не вам, иногда конвеерный процессинг рулит и модуль дополненной реальности экстраполирует данные с предыдущего шага :). Просто столько наслушался «почему нет» вместо «что для да». Понятное что даже такой бронебойный фактор как «чью работу тестируешь» полного разгильдяя который выкладывает не компилируя или скурпулезного дева за которым хвост найти что иголку в стоге сена влияет на метрики но что делать. Поправочных коэф. не подберешь, на практике я разруливал паралельностью и ротацией чтобы понять ху из ху. Но это дорого...
Может быть, в данном «споре» мы путаем процесс работы «Тестера» нажимающего кнопочки на форме в уже готовом продукте, и QA инженера, который участвуя в разработке функциональности с момента планирования, анализирует требования и занимается выявлением потенциальных дефектов ещё на ранней стадии разработки. В таком случае, часто бывает, что в исходном продукте количество багов сведено к минимуму, именно благодаря тесному сотрудничеству разработчика и QA инженера.
хохо комрат, жги дальше
В таком случае, часто бывает, что в исходном продукте количество багов сведено к минимуму, именно благодаря тесному сотрудничеству разработчика и QA инженера.
А что вызывает внутренний конфликт, собственно?
Может с нормальными QA просто не довелось работать?
Да, в скольких конторах побывал, но это фантастика, что описано. Это как в рекламе сыра. Есть теория, а есть практика. Теория не учитывает 100500 факторов, поэтому на практики такого не наблюдается. Видел такое своими глазами только в одном случае — когда дев, тестер, аналитег и т.д. в одном лице (аля фриланс).
Ну что-же, может быть и вам когда-то повезёт работать на проектах где подобное взаимодействие успешно реализовано.
А причем здесь мне: три примера из моей личной практики:
1, HP, толпа QA инженеров, с самого начала проекта, только моя жена за 2 года работы на проекте открыла более 1000 дефектов!!!, пусть даже все остальные в пять раз меньше открыли, вы себе представляет порядок и это при наличие не только QC инженеров но и горячо вами любимыми QA.
2. BMW. Опять же толпа QA and QC, с самого начала проекта, сам с начала проекта работал знаю, некоторые QA с германии с зп по 200к+ евро в год, вы себе представляете этот уровень. И опять же промах. Моя скромная команда в неделю в среднем фиксила по 20 дефектов, остальные 10 команд фиксили де то столько же — это 200 дефектов в неделю — за 4 года нафиксили 4 * 52 * 200 = 40000 дефектов, и это на не очень сложную часть проекта.
3. Моя теперешняя работа, делаем печки (духовки). На данный момент модификация духовки, в котором я принимаю свое посильное участие — 3000 дефектов уже открытых и на самом деле там копать и копать. Опять же контора работает на боинг и эирбас и QA самого разного ранга тут каждый первый. Плюс отдельно сертификейшен инженера и процесс инженера. Вообщем и тут промах.
Я могу приводить много примеров, да возьмите любую контору на слуху, везде багов шо грязи, даже как будто бы в элементарных проектах. Смотрите только на солидные конторы, там где по дефолту пруд пруди QA, и нигде вы не найдете шо вот о чудо, тестерам работы QA не оставили — это миф. Проверено жизнью.
И вдумайтесь мне «не повезло» на проектах в конторах, где поддерживается уровень по CMMI-5, работа на боинг и эирбас, тут процесс процессами погоняет и мне не повезло, а также не повезло 100500 человек, шо работали-работают рядом со мной. Не многовато ли кому не повезло с такими то процессами. О боги наверноя я проклят и прокляты все с кем мне пришлось или придется работать. О какой ужас. Или же на вас упала благодать и только вам и тем кто вместе с вами работает везет.
и нигде вы не найдете шо вот о чудо, тестерам работы QA не оставили — это миф.
Да, это миф, а я разве писал об обратном? Количество дефектов всегда можно только уменьшить, они никогда не будет нулевым.
Перечитайте внимательно ещё раз мои сообщения: я писал именно о минимизации количества дефектов в процессе разработки.
Чтобы было понятно, что я имею в виду, приведу пример: Представьте момент, когда никакой «альфа» версии ещё нет и в помине. QA получает от разработчика даже не полный билд всего продукта, а, к примеру, отдельную .dll, подложив которую в предыдущую версии программы и прогнав некоторые, заранее подготовленные тесты, найти случаи неправильного поведения данных с этой новой библиотекой. Далее, не заводя никаких дефектов (ведь никакой сборки программы с дефектной библиотекой в данный момент не существует в природе) сразу же сообщить разработчику об ошибке. Почему разработчик сам не мог сделать такой тест? Возможно у него не настроено окружение, на котором подобная ошибка будет воспроизводиться, а у QA инженера тем временем, пока разработчик ковырялся с этой библиотекой, уже подготовлено 20 виртуальных машин с разными ОС и разной конфигурацией, специально для этой проверки. Так вот, разработчик исправляет ошибку, через час даёт новую версии библиотеки, проверка проходит успешно, и он продолжает дальше трудиться над функциональностью входящий в его текущее задание. При этом, в полноценную сборку программы, в которую войдут все изменения которые сделал этот конкретный разработчик, и которая будет проверяться тем же QA инженером этот, «заранее исправленный дефект» уже не войдёт.
Вот теперь, скажите мне, как считать эффективность данного QA инженера по количество заведённых дефектов, если на момент проверки программного продукта оно заранее сведено к минимуму его же стараниями?
ага ну ну, хорошенькая такая минимизация, вы на порядок цифр посмотрите после минимизации в моих примерах: там на десятки сотни тысяч багов находятся уже обычными тестерами после якобы «стараний» доблестных куа. А у вас выходит что
В таком случае, часто бывает, что в исходном продукте количество багов сведено к минимуму, именно благодаря тесному сотрудничеству разработчика и QA инженера.Какой же это нах минимум — 40000 багов для средней руки проекта, более 3000 багов для млин духовки у которой вентилятор крутится и тен включается. И это в конторе с уровнем CMMI-5. Нет вы подумайте. Я не знаю работали ли вы когда нить вне процессов и-или фрилансером. Я работал и там и там и могу сказать что без всяких куа у меня дефектов оставалось на
Простите, но я ещё больше запутался в вашей логике, и после трёхкратного прочтения вашего поста вообще перестал понимать, что вы мне пытаетесь доказать.
Я так понял, из ваших слов, что если в команде есть QA то на выходе обязательно будет 40000 багов, а если QA нет, то багов будет меньше сотни.
Вы и вправду так считаете?
И вообще какой-то странный спор. Я вам говорю что это красное, а вы мне доказываете что оно тёплое.
Изначально же речь шла о том, что на мой взгляд, нельзя эффективность QA оценивать по количеству найденных багов. И я не понимаю, про чём тут 40000 багов вашем проекте. У меня за на проекте за пять лет было найдено (только что проверил): 2321 дефект. Из них пользовательских ~5%. Остальное находилось и исправлялось до релиза. И что?
Хорошая метрика — количество Major+ декектов в продакшене, которые не были найдены до релиза.
Еще например — количество дефетов major+ уровня что репортит «не-QA» после того как по билду/продукту прошлись QA инженеры и программисты с фиксами.
Это говорит о качестве тестирования в целом и уровне тестировщиков.
А голое «количество багов» не говорит ни о чём, особенно смешно это видеть в вашем сравнении с людьми из других компаний, что делают другие продукты :D
В этом свете у более эффективного тестера действительно будет больше открытых дефектов.Количество найденных дефектов зависит далеко не только от уровня QA-я, но и от многих других факторов.
количество найденных дефектов не всегда равно количеству открытых дефектовОх как тонко, спасибо, это всё меняет в корне! :D
больше всего открытых дефектов за год, в два раза где то большеКлинический случай.
Если вы за год нашли один секьюрити баг и все, то вы проиграли, и все по чеснаку. Или имея супер пупер скоуп можно почивать на лаврах победителя и лениво постить 1 баг в год. Также девочка-тестер получит ваш скоуп и найдет все за
Глупить не надо, приведен утрированный пример.
Каков пример — таков и ответ.
Я не говорю что не пользуются вообще, я говорю что мало. Сравните количество вакансий более технических людей и мануальных тестировщиков.
Мои 3 тестера в Люксофте за год открыли в сумме в 50 раз меньше дефектов чем она за тот же период.А это вообще не показатель, я даже не понял что вы этим хотели сказать?!
Я бы вообще SDET к QA не относилНу не скажите, это QA только большинство тестов автоматизируются. А так все тоже самое. Как по мне хороший QA должен уметь писать код
QA только большинство тестов автоматизируются.Верно.
А так все тоже самое.Не верно.
Как по мне хороший QA должен уметь писать кодВерно.
Я бы сказал по другому. То что в Украине называют QA за границей называют Software Test Engineer. SDET ближе к STE, чем к QA.
То что в Украине называют QA за границей называют Software Test Engineer.Нет, их называют QE — Quality Engineer.
SDET это программист что пишет Unit-тесты в TDD/BDD разработке софта, которые потом наполняются рабочим кодом.Facepalm как он есть.
Опыт кодинга имеется. У Вас как-то получается, что если мануальщик, то других навыков нет :)
Какой? В LinkedIn об этом ничего нет.
Есть ли шансы для QA инженера...Да.
...с опытом работы 3 годаНет. Если вы опыт измеряете количеством лет, которые просидели за компом, то шансов нет.
Ожидаемый комментарий :) Опыт я считаю все-таки мерилом полученных знаний и навыков. Ну, если работать и развиваться, а не просиживать штаны. Длинный список моих скиллов тут никто бы не читал, правда ведь?
Кстати, опыт работы в описаниях вакансий стоит в первых строчках ;)
Опыт я считаю все-таки мерилом полученных знаний и навыковОпыт — это и есть полученные знания и навыки, по определению. А не мерило их и не количество лет работы.
Длинный список моих скиллов тут никто бы не читал, правда ведь?Длинный и не нужно. Достаточно
Кстати, опыт работы в описаниях вакансий стоит в первых строчках ;)Ну это скорее чтоб отсеять совсем уж молодых бойцов, пытающихся на позиции сениоров собеседоваться. Больше никакого смысла нет в таком требовании.
Многие (иногда не зря) считают, что опыт работы — это своеобразное мат. ожидание уровня профессионализма, если бы его можно было количественно измерить.
У тестировщиков, например, с годами растет количество типичных тест-кейсов, так или иначе откладывающихся в голове.
Конечно, такие доводы часто притянуты за уши, но что поделать...
А если уж речь идет о тракторе, то годы опыта могут быть важны для получения ВНЖ/гражданства.
И вы тоже используете «опыт работы» как синоним «количество лет работы». Или как понимать вашу фразу
Многие (иногда не зря) считают, что опыт работы — это своеобразное мат. ожидание уровня профессионализма
Ну да, почему бы и не использовать количество лет работы как мат ожидание профессионализма, если вы описываете открытую вакансию (хотя я предпочитаю список требований и обязанностей)
Но использовать «мат ожидание профессионализма» для описания своего личного опыта — все равно что написать «среднестатистический инженер» в резюме. Не думаю, что кто-то хочет так себя преподносить. В целом рынок горячий, и «среднестатистических инженеров» тоже с удовольствием возьмут на работу. Но не из-за границы.
Да и вопрос наивно-простодушный.
«У меня есть 3 года опыта работы, можно ли уехать? Подскажите где искать вакансии за рубежом».
Ну прям как
«У меня есть 100 баксов, можно ли создать свой бизнес? Подскажите как.»
Надо бы уже понимать что «опыт работы» = «кол-во лет работы» для человека, который парсит по 200 резюме в день, фильтрует и отправляет отобранное тех.спецам. Это, так сказать, первый барьер где опыт работы имеет значение, особено если человек из другой страны и ему нужно выбивать разрешение на работу.
Бывший коллега связался с HR в европе, и те ему уже нашли работу с relocation.
Вы имеете в виду независимое рекрутинговое агентсво?
видимо да, в детали не вникал. у бывшего коллеги все прошло быстро, в рамках полугода до момента поселения семьи в Германии
Кстати, в Ciklum-е многие клиенты со временем (от полугода после начала работы на проекте) при обоюдном желании перевозят человека в страну клиента в офис работать непосредственно на него. В основном — это Европа.
Расскажите мне про перевоз пожалуйста, я тут уже три года, ни разу о подобном не слышал.
Проект Рикардо сейчас массово выезжает
dou.ua/...ums/topic/7148
+ бодишопы Епам и Люксофт перевозят, правда им лучше писать сразу в заграничные офисы.
Спасибо! Евгений, а предложение в топике все еще актуально?
Да, актуально
Как и программистов, и любых наших специалистов, вас там измерять не годами опыта будут, а реальными способностями и скиллами.
Получить работу по шансам так же, как и программисту.
Сейчас очень активизировался Skype в этом плане, кстати.
На счёт сайтов не скажу, я сам не искал никогда, но предложения приходили и без этого.
Коментар порушує правила спільноти і видалений модераторами.
Спасибо, промониторю Скайп. А чтобы предложения приходили, нужно все равно засветить где-то резюме :)
Нет, нужно обращаться к людям что занимаются подобной работой.
Таких и людей, и агенств хватает. Но конретно я вам не смогу посоветовать, ибо не искал.
T Lobanovska
Denys Khlivnyy
Alexander Kuznyak
T Lobanovska
Котэ гуляющее само по себэ
Максим Чумаченко
Anton Bredykhin
Lyova Zi
Anton Bredykhin
Vladimir Prudnikov
Oleg Trygub
Alina Gefter
Максим Чумаченко
Vladimir Prudnikov
chronoman
Sergey Khaperskov
Sergey Khaperskov
Andrey Tkachenko
Andrey Tkachenko
Alexander Kuznyak
Eugene Kirian
Eugene Kirian
Andrey Polokh
84 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів