В российский офис компании Wiley (крупная американская издательская компания, www.wiley.com) приглашаются специалисты на позицию Инженер по автоматизации тестирования (Junior / Middle).
Требования:
- техническое образование;
- технический английский;
- базовые навыки программирования;
- опыт написания простых запросов на SQL;
- опыт практической работы с базами данных приветствуется, но не обязателен;
- опыт работы с JIRA;
- опыт написания скриптов для автоматизации тестирования;
- знание средств автоматизации тестирования (JUNIT, Selenium).
Обязанности:
- составление тестовых сценариев по спецификации;
- прохождение тестовых сценариев;
- автоматизация выбранных тестовых сценариев;
- составление и оформление дефектов;
- тесное сотрудничество с командой разработчиков;
- участие в обсуждении требований.
Условия:
- оформление согласно трудовому законодательству и «белая» заработная плата;
- фиксированная оплата труда, премирование по результатам работы за полугодие;
- размер заработной платы составляет от 100 000 руб. до 130 000 руб. (gross), обсуждается с успешными кандидатами, по результатам собеседования;
- периодическая индексация заработной платы;
- корпоративная программа добровольного медицинского страхования;
- корпоративные курсы английского языка;
- возможность изучения других иностранных языков на льготных условиях;
- обучение и сертификация по технологиям, используемым в компании;
- команда профессионалов мирового уровня;
- взаимодействие с коллегами из компаний партнёров – Amazon, Apple, Microsoft, EMC и др.;
- стабильность;
- благоприятное офисное пространство;
- участие в спортивно-оздоровительных мероприятиях (футбол, волейбол, баскетбол, йога);
- рядом с офисом стадион, бассейн, фитнес центр. Национальный парк "Лосиный остров" в шаговой доступности;
- иногородним кандидатам компенсируем стоимость переезда до Москвы;
- помогаем в быстром поиске жилья и обустройстве на новом месте.
Компания John Wiley & Sons, Inc. (www.wiley.com) является стабильной (более 200 лет успешной истории бизнеса) транснациональной компанией. На сегодняшний день в нашей компании работают более 5000 сотрудников, офисы компании открыты в США, Канаде, Великобритании, Дании, Германии, России, а также в Азиатском и Тихоокеанском регионах. Головной офис компании расположен в городе Хобокен (США).
Основными направлениями работы копании является публикация научного и технического контента, предоставление сервисов для образовательных, научных учреждений и исследовательских компаний по всему миру. В настоящее время наиболее быстро развивающимся направлением работы компании является публикация контента и предоставление информационных сервисов в электронном виде.
Наиболее известные бренды компании: For Dummies, Bloomberg Press, Sybex, Pfeiffer. В мае 2006 Wiley стала официальным партнёром Microsoft для публикации всех Microsoft Official Academic Course по всему миру.
Мы следуем стратегии найма только лучших специалистов на рынке и предоставления сотрудникам долгосрочных перспектив роста. Многие сотрудники продолжают работать в нашей компании более 10-15 лет а текучка кадров стабильно держится ниже 1-2 % в год.
Отвечу на все вопросы: itincorp@gmail.com , +7 (916) 0722958, Skype: valeriya390
Крылова Валерия, рекрутер компании Wiley
По исследованиям ведущих аналитиков страны 83% проектов в области IT-индустрии, работающих с гос. заказами, в России являются провальными, либо не удовлетворяют потребностям заказчика в полной мере.
Не, я понимаю, что скрам малоприменим для сколько нибудь сложных проектов. Но срам то тут причем?! Очевидно же что разруха в головах. В первую очередь головах менеджеров.
Быстрорастущая международная компания ищет талантливого и профессионального сотрудника на позицию QA Engineer / Специалист по тестированию в свой московский офис.
Вы будете:
Тесно работать с командами разработки (формировать тест-кейсы и тест-планы, определять скоуп задач, определять готовность выполнения задач разработки)
Участвовать в проектировании и проработке продуктовых задач до этапа разработки
Проводить ручное (функциональное, приемочное) тестирование
Разрабатывать и поддерживать автоматизированные регрессионные тесты
Мониторить стабильность всех наших продуктов
Участвовать в проведении релизов
Требования:
Опыт работы в области тестирования или контроля качества программного обеспечения — от 2 лет
Опыт работы с инструментами тест-менеджмента
Опыт тестирования веб-приложений, мобильных приложений
Плюсом будет опыт тестирования десктопных приложений и их интеграций с облачными сервисами
Опыт написания автотестов
Плюсом будет разговорный английский
Условия:
Заработная плата 80-120 тыс. рублей.
Работа в международной компании
Сложные и интересные задачи
Работа в высокопрофессиональной команде, которая умеет плодотворно работать и весело отдыхать
Белая достойная заработная плата, бонусы
Оформление по ТК РФ
Тип занятости:
Полная занятость, полный день
Адрес: Москва, 5-я улица Ямского Поля, 5с1, м. Белорусская, м. Савеловская Контакты:
Присылайте Ваше CV на адрес:
nikita@nphire.com
Здравствуйте, я только начинаю постигать чудесный мир JMeter и столкнулась с проблемой. Вместо обычных HTTP запросов на проекте для любого действия используются .dwr запросы, для которых мне нехватает одного параметра. Пример такого запроса (записанный с помощью Test Script Recorder):
Вопрос в том, что я не могу получить сам scriptSessionId.
Чтобы его получить, к запросу engine.js я добавила Regular Expression Extractor, но это не правильно, а как сделать правильно я не знаю:). Почему неправильно это - потому что ответ engine.js - это скрипт и, соответственно, мой экстрактор возвращает выражение, а не результат (dwr.engine._scriptSessionId = dwrsess + "/" + dwr.engine._pageId;). Подскажите, пожалуйста, как можно это решить?
Для планирования времени и красивых Burn down диаграмм мы решили создавать сабтаски в Jira для user story.
В том числе на одну юзер стори может быть несколько сабтасков от разработчиков и несколько от тестировщиков. Например: настроить окружение, написать тесткейс на это, написать тесткейс на то, выполнить тесткейс на одном окружении, выполнить тесткейс на другом окружении, написать новый cucumber test, запустить автотесты и проверить их результат (CI еще не толком не настроен, но автотестов уже много, так что запускаем пока вручную).
В качестве репозиториев тестов (тест менеджмента) используется Zephyr плагин для Jira.
До введения нового процесса (разделения юзерстори на сабтаски) тестировщики к каждой новой фиче/юзерстори линковами тикет с типом test case, который потом двигали по своему workflow (видимо независимо от user story).
Сейчас в связи с новым процессом разбиения юзерстори на сабтаски думаем настроить Jira так, чтобы тикеты с типом test case могли быть сабтасками.
Но с моей точки зрения это не совсем правильно, т.к. один тест может выполнятся несколько раз, не у каждой стори должен быть тесткейс, у одной стори может быть несколько тестов и у теста можно быть несколько юзерстори и т.д.
Кто как решил данную проблему у себя и что может посоветовать?
Думаю как должно выглядить планирование автоматизации в рамках Agile. Вот есь у нас несколько проектов в компании, условно "бэкенд"/"фронтенд". Тикеты на разработку автотестов лучше держать внутри этих же проектов или лучше завести отдельный проект в Джире? В плане репозиториев - они отдельные, но не думаю, что только от этого должно зависеть.
Плюсы и минусы отдельный проект на автоматизацию:
1. Тестировщики сами решают когда что начинать разрабатывать
2. Можно создать полностью отличный воркфлоу
3. Не отвлекать продукт менеджеров и разработчиков на планированиях и дейли митингах задачами на автоматизацию.
4. Но, не понятно, как согласовывать и координировать работу тестировщика на двух проектах.
5. Считаю что в agile тестировщики должны быть встроенны в продуктовую команду и не должны выделяться в отдельный "сервис".
6. Также хотелось бы привлекать продукт менеджеров иногда возможно, помогать с приоритизацией и т.д.
7. Хотелось бы привлекать разработчиков для парного программирования и ревью, получается тоже надо будет их координировать между двумя проектами, это сложнее.
Плюсы и минусы один проект с продуктом:
1. Продукт менеджеры видят "лишние" таски на своей продуктовой борде, которые никакой профит клиентам вроде и не приносят.
2. Труднее планировать и продвигать таски по автоматизации?
3. Все будут тратить больше времени на планировании и дейли, так как эти задачи на автоматизацию также попадут на борду.
4. Процесс более видимый, официальный и запланированный, это хорошо.
5. Разработчиков наверное так будет проще "официально" отвлекать.
6. Легче координировать работу, приоритизировать и тд.
Сама больше склоняюсь пропихивать автоматизацию открыто, в рамках продуктовых команд. Но буду очень рада услышать про опыт ведения автоматизации в отдельном проекте/команде, без встраиваивания в "продуктовую" команду.
Инженеры Перфоманс Лаб постоянно исследуют возможности применения наиболее эффективных передовых технологий, позволяющих получать более качественные результаты в работе, в том числе искусственный интеллект. У нас имеется опыт использования технологий машинного обучения для системы HelpDesk. Технология применяется для автоматического заполнения различных полей входящих инцидентов. Для успешного предсказания значений в данных полях, искусственный интеллект предварительно обучался на заданной выборке заполненных инцидентов и с помощью алгоритмов машинного обучения строил модель. На основе построенной модели в дальнейшем делались предсказания значений полей.
Что грядет
Технологии постепенно поглощают всё больше сфер деятельности, на очереди тестирование программного обеспечения. Мы все настолько избалованы повсеместной автоматизацией, что при появлении подходящих инструментов с радостью бы передали большую часть тест-дизайна и валидации тестов на откуп искусственного интеллекта (ИИ). Вместо того чтобы вручную настраивать автоматизированное тестирование, машины будут сами разрабатывать и выполнять тесты, постоянно совершенствуясь во время взаимодействия с людьми. Эта механизация тестового покрытия означает, что каждая команда разработки скоро будет иметь доступ к виртуальной команде тестировщиков с более развитым интеллектом, скоростью работы и уровнем охвата, чем даже самые высокооплачиваемые команды разработки могут получить сегодня.