Ура, первый пост! Рассказывать буду о буднях тестировщиков, событиях и митапах, взаимодействии с командой разработки. В общем, располагайся поудобнее - будет интересно)
Сходил на митап к роботам, они же Redmadrobot - в IT-сфере, а точнее - в мобильной разработке - ребята известные и работают аж с 2008 года.
Доклады были очень доступные, рассчитаны на QA-джунов и -миддлов.
А вот и сами темы:
- UI-автотесты под iOS для самых маленьких
- UI-автотесты: неочевидные очевидности в планировании и реализации
- No pain, no gain: тестируем голосовые приложения
Меня особенно впечатлил последний из этих докладов: Паша Булич из KODE рассказал о сложностях, которые решала его команда при тестировании голосовых навыков для Алисы. Вообще, тестирование голосовых помощников - тема неизбитая - информации мало, перенять чужой опыт практически не у кого. Но стандартные техники анализа работают, к счастью, и тут: естественно, есть и граничные условия, и классы эквивалентности и т.п. О них обязательно расскажу более подробно в ближайших постах.
Доклады были очень доступные, рассчитаны на QA-джунов и -миддлов.
А вот и сами темы:
- UI-автотесты под iOS для самых маленьких
- UI-автотесты: неочевидные очевидности в планировании и реализации
- No pain, no gain: тестируем голосовые приложения
Меня особенно впечатлил последний из этих докладов: Паша Булич из KODE рассказал о сложностях, которые решала его команда при тестировании голосовых навыков для Алисы. Вообще, тестирование голосовых помощников - тема неизбитая - информации мало, перенять чужой опыт практически не у кого. Но стандартные техники анализа работают, к счастью, и тут: естественно, есть и граничные условия, и классы эквивалентности и т.п. О них обязательно расскажу более подробно в ближайших постах.
К слову, о митапах. На днях ходили с коллегами на обед, и разгорелся у нас спор не на шутку: имеет ли смысл ходить на все эти ивенты, митапы, конференции, или же это пустая трата времени?
Доводы ЗА и ПРОТИВ, по-моему, очевидны, но все же приведу их ниже.
Доводы ПРОТИВ:
- гораздо быстрее нужную информацию можно нагуглить
- тратится время/деньги, особенно, если ивент платный
- кейсы, которые разбираются на таких встречах, достаточно специфичны для конкретного проекта
Доводы ЗА:
- можно расширить свой кругозор, узнать о новых инструментах и техниках
- завести новые знакомства и контакты
- пообщаться с лидерами IT-индустрии
- задать вопросы экспертам вживую
Я склоняюсь к тому, что митапы - это мегаклассная штука. Неформальные встречи с коллегами, знакомства - все это помогает отвлечься от рутины.
Кстати, на митапе Redmadrobot, о котором писал выше, я совершенно случайно встретился с Алиной, своей бывшей... коллегой, которая перешла совсем недавно в другую компанию и теперь занимается там автотестами. С Алиной вы ещё познакомитесь в этом канале - она расскажет про автотесты лучше меня.
Доводы ЗА и ПРОТИВ, по-моему, очевидны, но все же приведу их ниже.
Доводы ПРОТИВ:
- гораздо быстрее нужную информацию можно нагуглить
- тратится время/деньги, особенно, если ивент платный
- кейсы, которые разбираются на таких встречах, достаточно специфичны для конкретного проекта
Доводы ЗА:
- можно расширить свой кругозор, узнать о новых инструментах и техниках
- завести новые знакомства и контакты
- пообщаться с лидерами IT-индустрии
- задать вопросы экспертам вживую
Я склоняюсь к тому, что митапы - это мегаклассная штука. Неформальные встречи с коллегами, знакомства - все это помогает отвлечься от рутины.
Кстати, на митапе Redmadrobot, о котором писал выше, я совершенно случайно встретился с Алиной, своей бывшей... коллегой, которая перешла совсем недавно в другую компанию и теперь занимается там автотестами. С Алиной вы ещё познакомитесь в этом канале - она расскажет про автотесты лучше меня.
Весомый плюс работы в IT-сфере - возможность работы удаленно. Даже если вы привязаны к офису, то, как правило, несколько раз в месяц, а то и в неделю, сотрудник может поработать из дома.
В каких-то компаниях нужно согласовать с руководителем весомую причину для удаленной работы (обычно это из серии "приболел, но готов поработать по VPN и не идти на больничный"), в других компаниях для удаленной работы достаточно предупредить коллег, а в третьих компаниях люди и вовсе всегда работают удалённо - из дома, коворкинга или сидя в гамаке где-нибудь на Бали.
Обычно я работаю из дома, когда действительно себя неважно чувствую или когда нужно немного абстрагироваться от офиса и полностью переключиться на свои текущие задачи. Эта потребность обоснованна: тестировщики наряду с менеджерами проектов самые общительные в IT-команде (готов поспорить с теми, кто так не думает, в чате канала @qa_chat ;). А продвинутые QA и тимлиды в течение рабочего дня часто переключаются на задачи своих же коллег. В итоге к концу дня может оказаться так, что задачи коллег закрыты, а твои остались нетронутыми до следующего дня) Вот в такие моменты удалёнка сильно выручает.
В каких-то компаниях нужно согласовать с руководителем весомую причину для удаленной работы (обычно это из серии "приболел, но готов поработать по VPN и не идти на больничный"), в других компаниях для удаленной работы достаточно предупредить коллег, а в третьих компаниях люди и вовсе всегда работают удалённо - из дома, коворкинга или сидя в гамаке где-нибудь на Бали.
Обычно я работаю из дома, когда действительно себя неважно чувствую или когда нужно немного абстрагироваться от офиса и полностью переключиться на свои текущие задачи. Эта потребность обоснованна: тестировщики наряду с менеджерами проектов самые общительные в IT-команде (готов поспорить с теми, кто так не думает, в чате канала @qa_chat ;). А продвинутые QA и тимлиды в течение рабочего дня часто переключаются на задачи своих же коллег. В итоге к концу дня может оказаться так, что задачи коллег закрыты, а твои остались нетронутыми до следующего дня) Вот в такие моменты удалёнка сильно выручает.
#Ролевыеигры
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Регрессионное тестирование (Regression testing)
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
Ребята, совсем забыл рассказать про Heisenbug Moscow - мегакрутое событие для тестеров и не только. Конференция проходила 5-6 декабря. Я поприсутствовать не смог, а вот моя хорошая подруга, Мила, там побывала и сделала несколько фоток для вас.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
This media is not supported in your browser
VIEW IN TELEGRAM
Опытный тестировшик решает проблему накопившихся тасок
Бэклог
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Резюме
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Новый год
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
#Ролевыеигры
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
С наступившим Новым годом, ребятки! Пусть бэклог уменьшается, баги своевременно находятся, а собеседования проходятся!
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Какой будет зарплата, если ты решил переехать в Германию?
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.