Одна из ведущих мировых gamedev компаний ищет Quality Analyst в свой мобильный офис.
Я обязательно расскажу все подробности о вакансии в скайпе (mistymary3) или в общении по почте (eischuk@spice-agency.ru).
Обязанности:
- Тестирование игровых приложений с занесением найденных багов в багтрекинговую систему; написание тест-кейсов для дизайна документов; работа в тесном контакте с Product Owner’ом и командой разработчиков.
Требования:
- От двух лет опыта в тестировании мобильных приложений
- Законченное высшее образование
- Понимание процессов тестирования, процедур и процессов отладки
- Опыт в написании тестовых сценариев
- Очень желательна осведомлённость в области мобильных игр и встроенных систем
- Желателен опыт работы с мобильными платформами
- Предпочтительно владение различными инструментами управления тестированием и опыт работы с багтрекинговыми системами
- Несомненным плюсом станет предшествующий опыт работы в геймдеве
- Отлично развитые навыки общения как письменно, так и вслух. В том числе и на английском.
- Осознание взаимосвязи тестирования с жизненным циклом разработки ПО
- Успешный опыт использования продуктов MS Office
- Способность к аналитической деятельности и внимание к деталям
- Проактивный подход к решению задач
- Способность мыслить стратегически в условиях разрешения проблем
- Умение работать с разными людьми так же хорошо, как и без них
- Скилл работать даже в условиях возрастающей напряжённости
- Непринуждённые отношения с ПК, а также последними версиями ОС Mac и Windows
- Опыт работы с Jira или любой другой похожей системой
- Опыт с методологиями Agile
Условия:
- Медицинская страховка для сотрудника, а также членов семьи
Изначально никто не разделял исследовательское тестирование и тестирование по сценариям. Джерри Вейнберг определяет тестирование как исследовательское по своей природе в своей книге "Основы программирования" 1961 года издания, и предостерегает от излишней формализации тестирования. "Конечно, сложно заставить машину проверять, насколько программа соответствует изначальным целям программиста, не скармливая ей достаточное количество информации об этих целях. Если бы предоставление такой информации машине было легким делом, с тем же успехом можно было бы поручать машине сам процесс программирования. Не следует забывать, что сложные логические операции выполняются путем комбинации простых инструкций, выданных компьютеру, а не в результате предположений компьютера о том, чего хотел программист", - пишет Джерри.
Джерри хорошо понимал, чем отличается человеческий труд от машинного. Однако за ним пришли формализаторы и всех запутали. Официально формализация тестирования началась в 1972 году, когда была опубликована книга "Методы тестирования приложений". Книга концентрировалась не на сути, а на форме тестирования – то есть на словах, изображениях, строках кода, файлах, таблицах, диаграммах и прочих точно определенных формах и моделях. Эти формы и модели можно увидеть, прочитать, указать на них, переместить их, сосчитать, хранить, воспроизводить, и поэтому так прельщает возможность определить их как "тестирование". Но тестирование – это не модели и артефакты. Тестирование - это использование артефактов человеком. Артефакты тестирования без участия людей похожи на суперсовременные клиники без докторов или медицинских сестер: как минимум – практически бесполезны, как максимум – опасны для несведущих, пытающихся их использовать.
Нет, мы не виним инноваторов – им приходилось иметь дело с едва родившимися предположениями, и их ждали великие дела. Однако формализация и механизация тестирования вскоре вырвались в большой мир. Люди заговорили о "фабриках тестирования" и плохо сформулированных стандартах IEEE, и вскоре любая приличная беседа о тестировании подразумевала тестирование по сценариям. Неформальное тестирование стало синонимом непрофессионального. Мыслящие, чувствующие, общающиеся люди были задвинуты на второй план.
Джеймс Бах ввязался в этот бой в 1987 году и попытался разложить ситуацию по полочкам. Наблюдая процесс тестирования, он обнаружил, что ad hoc тестирование хорошо работает для поиска багов, а сценарное – нет (Примечание: Мы не пытаемся показать, что обнаружить это было легко и просто. Мы хотим сказать, что неочевидные истины тестирования присутствуют вокруг нас, и их можно осознать, если отложить фольклор о моделях и сценариях и присмотреться к тому, как на самом деле работают люди). Джеймс начал рассказывать о своем опыте и писать о нем. Когда он проработал тест-менеджером несколько лет (в основном тестируя компиляторы и другие инструменты разработки), до него дошла информация, что Кем Кэнер придумал термин "исследовательское тестирование" как антоним сценарного. В своей небольшой статье Кем не дал точного определения и только кратко наметил суть понятия, но он был первым, кто заговорил о создании тестов во время их исполнения.
Так появилось то, что мы называем "Исследовательским тестированием 1.0".
Вчера промелькнула новость , что ошибка при установке программного обеспечения привела к майскому крушению военного самолета в Испании – само ПО багов не содержало, а вот установка и использование в реальных условиях проверки не выдержали. Цена ошибки – 4 унесенных жизни и сотни самолетов этой модели, не допущенные к полетам в настоящий момент.
Поделитесь, с каким наиболее критическим багом сталкивались лично вы в своей практике?
Из моего опыта (конечно, размах трагедии не тот) – баг в ММОРПГ, при котором сервер передавал право на определение того, что это за предмет, клиентской части. Багоюзер ловил пакет какой-нибудь дешевой бесполезной фигни, подменял его на что-нибудь ценное, а дальше производил с предметом ряд манипуляций в игре. При определенной последовательности манипуляций сервер начинал доверять клиенту и воспринимал предмет, как ценный. Баг был выловлен при обнаружении, что экономика сервера падает стремительным домкратом, так как ушлые игроки вовсю начали багом пользоваться. Последовательность действий с предметом была такая, что, наверное, ни одному тестировщику в страшном сне бы не привиделось это проверять.
Добрый день! Помогите пожалуйста с трансфером данных в POST-запрос в виде Json!
Мне нужно сделать трансфер данных В post запрос. Post запрос должен иметь content-type = multipartform/data. Из одного запроса я получаю нужный мне mediaId и пытаюсь вставить его в другой Post-запрос. Только не знаю как вставить в параметр mediaIds вот такую json конструкцию:
Сейчас у меня вместо этого передается просто "4e2c056931d398831128ad2c6a45ec91".
Мне надо как то дописать тип, а чему он равен. задаю я сама. Получается мне надо в mediaIds в target-запросе передать еще и второй статичный параметр. Можно ли это сделать через Property Expansion и как? А если просто через request?
Столкнулся со следующей проблемой при работе с selemium, при нажатии на кнопку в Fire Fox открывается новый tab, на котором необходимо произвести действия.
При отладке новое окно открывается на той же странице, а элемент по xpath не находится, я подозреваю, что проблема в том, что я ищу на предыдущей странице. Прошу направить на путь перехода на новый tab.