Let us google it for you.

офк я попробовала

от слова качество, а не качаство

офк я попробовала

плохо получилось. пробуйте ещё.

аааа. Копипасты не доводят до бобра.

выглядит как что-то неинтересное (в плане тем)

Ну, Альфабанк может расскажешь что-то новое про то, зачем нужен альфа-БДД.

Кстати, м.б. кто-нибудь знает, почему у Альфа-Банка постоянно висит вакансия на QA Engineer ? Уже больше года как...

Текучка/так сложилось что регулярно открываются новые вакансии/иногда компаниям выгодно чтоб висели вакансии на сайте (хотя по факту пустышка)

Есть ли тут люди, кто занимался автоматизацией проверки платежей в приложениях для андроид и IOS? Интересует подход и инструментарий. У меня Unity3D Приложение, и покупки, соответственно, вызываются из него. Либо обычно такие проверки делаются без участия устройства?

у них должна быть песочница

для инапп покупок есть санбокс юзеры, регается в админке в аитюнс коннект для аиос

Такие проверки далаются и участием устроства тоже ?

https://youtu.be/sY0D2pPxYIk

Привет! ОК, обещаю не материться.

Всем привет) можете посоветовать сайт, видео, про описание интеграционных тестов? Не про Selenium) Заранее спасибо!

Selenide))))

Всем привет) можете посоветовать сайт, видео, про описание интеграционных тестов? Не про Selenium) Заранее спасибо!

А ты попробовала гуглить "интеграционное тестирование"?

А ты попробовала гуглить "интеграционное тестирование"?

Пробовала) результат, не тот выдаёт, который хочу

А какой хочешь?

В моей практике это дело генерировалось в обычном IE, но там были заточенные под это дело XML, в них руками прописывали ссылку на схему и при открытии в IE получали красивый документ. Попробуйте у dev'а спросить?

Всем привет! Портянка текста с размышлением вслух и вопросом в конце. Мне действительно интересно услышать ваше мнение. Нужно составить сценарии по функционалу для автотестов (UI тестирование). К примеру, добавление раздела. Есть сандарнтые операции: добавление раздела, редактирование, удаление. Помимо этого есть ещё функционал типа: включить/выключить видимость раздела. Как можно составить сценарии: 1 вариант. Всё через интерфейс с жесткой зависимостью - добавление раздела - редактирование - проверка видимости/невидимости раздела - удаление раздела 2 вариант. Частично через sql - добавление раздела - редактирование - удаление - добавление раздела через sql - проверка видимости/невидимости раздела - удаление раздела через sql Плюсы-минусы: 1 ваниант. - тесты должны быть независимыми, а тут жесткая зависимость. Это большой минус, если тестов много: один упадет (к примеру добавление чего-то основного) и пиши-пропало, не проверится куча другого функционала + не надо париться с sql 2 вариант. - Сложность добавления через sql - предполагается, что добавление раздела не самая простая операция, много взаимосвязей с разными таблицами. + тесты менее зависимы. Теоретически сможем проверить функционал включения/выключения видимости раздела, даже если добавление раздела не работает Вроде по описанному понятно, что 2ой вариант лучше, но какой бы вы выбрали, если учесть, что добавление через sql действительно геморрно из-за того, что нужно учесть кучу взаимосвязей? Или есть другие мысли-предложения?

Всем привет! Портянка текста с размышлением вслух и вопросом в конце. Мне действительно интересно услышать ваше мнение. Нужно составить сценарии по функционалу для автотестов (UI тестирование). К примеру, добавление раздела. Есть сандарнтые операции: добавление раздела, редактирование, удаление. Помимо этого есть ещё функционал типа: включить/выключить видимость раздела. Как можно составить сценарии: 1 вариант. Всё через интерфейс с жесткой зависимостью - добавление раздела - редактирование - проверка видимости/невидимости раздела - удаление раздела 2 вариант. Частично через sql - добавление раздела - редактирование - удаление - добавление раздела через sql - проверка видимости/невидимости раздела - удаление раздела через sql Плюсы-минусы: 1 ваниант. - тесты должны быть независимыми, а тут жесткая зависимость. Это большой минус, если тестов много: один упадет (к примеру добавление чего-то основного) и пиши-пропало, не проверится куча другого функционала + не надо париться с sql 2 вариант. - Сложность добавления через sql - предполагается, что добавление раздела не самая простая операция, много взаимосвязей с разными таблицами. + тесты менее зависимы. Теоретически сможем проверить функционал включения/выключения видимости раздела, даже если добавление раздела не работает Вроде по описанному понятно, что 2ой вариант лучше, но какой бы вы выбрали, если учесть, что добавление через sql действительно геморрно из-за того, что нужно учесть кучу взаимосвязей? Или есть другие мысли-предложения?

а апи может есть какой-то?

а апи может есть какой-то?

с апи всё плохо

сваггера нет?

или другой подобной штуки?

ну смотри, в любом случае ваш сайт отправляет запрос на создание раздела и удаление - используй эти запросы как прекондишн для теста

если другого публичного апи нет

скорее всего понадобится ещё csrf токен - то найди его в доме странички и отправляй вместе с ним запрос

Всем привет! Портянка текста с размышлением вслух и вопросом в конце. Мне действительно интересно услышать ваше мнение. Нужно составить сценарии по функционалу для автотестов (UI тестирование). К примеру, добавление раздела. Есть сандарнтые операции: добавление раздела, редактирование, удаление. Помимо этого есть ещё функционал типа: включить/выключить видимость раздела. Как можно составить сценарии: 1 вариант. Всё через интерфейс с жесткой зависимостью - добавление раздела - редактирование - проверка видимости/невидимости раздела - удаление раздела 2 вариант. Частично через sql - добавление раздела - редактирование - удаление - добавление раздела через sql - проверка видимости/невидимости раздела - удаление раздела через sql Плюсы-минусы: 1 ваниант. - тесты должны быть независимыми, а тут жесткая зависимость. Это большой минус, если тестов много: один упадет (к примеру добавление чего-то основного) и пиши-пропало, не проверится куча другого функционала + не надо париться с sql 2 вариант. - Сложность добавления через sql - предполагается, что добавление раздела не самая простая операция, много взаимосвязей с разными таблицами. + тесты менее зависимы. Теоретически сможем проверить функционал включения/выключения видимости раздела, даже если добавление раздела не работает Вроде по описанному понятно, что 2ой вариант лучше, но какой бы вы выбрали, если учесть, что добавление через sql действительно геморрно из-за того, что нужно учесть кучу взаимосвязей? Или есть другие мысли-предложения?

"Нужно составить сценарии..." Обычно такие затруднения возникают по причине непрояснённой посылки. Кому нужно? Что именно нужно, действительно ли сценарии? Что такое это "нужно"? С какой гипотезы вы начинаете, приступая к выбору одного из этих вариантов?

сваггера нет?

ага, спасибо за наводку. Просто параллельно уточняю детали у разраба про сваггер и прочее)

"Нужно составить сценарии..." Обычно такие затруднения возникают по причине непрояснённой посылки. Кому нужно? Что именно нужно, действительно ли сценарии? Что такое это "нужно"? С какой гипотезы вы начинаете, приступая к выбору одного из этих вариантов?

есть функционал, его нужно покрыть автотестами, основное. Нужно составить сценарии, хотя бы примерный план. Есть опыт работы с большими сьютами (тест-кейсами) и это была жесткая зависимость тестов один от другого. И если что-то падало, то - ой всё. Есть опыт работы с добавлением данных через sql, но некоторые данные подобным образом просто тяжело добавить. Вопрос в том, как построить тестирование и подготовку тестовых данных. Просто сценарии - это первый этап и на нем уже возникают все вышеперечисленные мысли-вопросы

Приготовить один раз сидированный слепок базы данных, с нужным вам содержимым и использовать его в тестах. При добавлении новых тестов - добавлять сидов, если требуется.

есть функционал, его нужно покрыть автотестами, основное. Нужно составить сценарии, хотя бы примерный план. Есть опыт работы с большими сьютами (тест-кейсами) и это была жесткая зависимость тестов один от другого. И если что-то падало, то - ой всё. Есть опыт работы с добавлением данных через sql, но некоторые данные подобным образом просто тяжело добавить. Вопрос в том, как построить тестирование и подготовку тестовых данных. Просто сценарии - это первый этап и на нем уже возникают все вышеперечисленные мысли-вопросы

Сценарии это даже не второй этап.)) Если цель религиозная - Свидетели Покрова [функционала тестами], то выбирайте любой вариант, где быстрее сможете показать результат. Тот, который проще, комфортнее, где вы будете звучать уверенно и убедительно.

Сценарии это даже не второй этап.)) Если цель религиозная - Свидетели Покрова [функционала тестами], то выбирайте любой вариант, где быстрее сможете показать результат. Тот, который проще, комфортнее, где вы будете звучать уверенно и убедительно.

когда на руках большой, тяжелый проект, который постоянно куда-то движется, и говорят - надо тесты! - увы, это первый этап)) Либо мне не зватает знаний. За ответ спасибо большое

Приготовить один раз сидированный слепок базы данных, с нужным вам содержимым и использовать его в тестах. При добавлении новых тестов - добавлять сидов, если требуется.

разраб предлагает подобное тоже. Наверное, будем двигаться в этом направлении. Спасибо!

хороший вариант

Shoo автоматизацией под нативные мобильный апки занимался?

Shoo автоматизацией под нативные мобильный апки занимался?

А вы с какой целью интересуетесь?

хороший вариант

на счет апи тоже мысль хорошая, может что и получится

когда на руках большой, тяжелый проект, который постоянно куда-то движется, и говорят - надо тесты! - увы, это первый этап)) Либо мне не зватает знаний. За ответ спасибо большое

Ну хоть у кого-то действительно большой, тяжёлый проект, который постоянно куда-то движется.)) Набирать опыт из состояния боязни ошибиться слишком травматично. Будете спокойны и уверены, тогда и поэкспериментируете.

цель - узнать

Ну хоть у кого-то действительно большой, тяжёлый проект, который постоянно куда-то движется.)) Набирать опыт из состояния боязни ошибиться слишком травматично. Будете спокойны и уверены, тогда и поэкспериментируете.

спасибо))

Интересно мнение коллег кто занима-лся/-ется автоматизацей нативных апок под мобилки у кого какое удовлетворение от appium крос платформенного решения на android и ios платформы против подхода разделения интеграционного тестирования в 2 репозитория esspresso для andoid и xctest для ios (скорее всего в репы приложений)

Я пока что не видел ни одного примера, когда применение кросс-платформенных фреймворков автоматизации не рождало бы больше боли, чем нативные тесты.

и у меня аналогичное мнение

appium достаточно больно для мозга использовать

может еще сыроват

я жду что Poco изменит кроссплатформенное тестирование )) но опять же проще два сьюта сделать, локаторы же другие будут

Это не проблема аппиума, на самом-то деле.

У нас вот тут свой кросс-платформенный тестовый фреймворк.

и как? )

Я уже выше написал.

Сам фреймворк неплох, довольно стабилен и понятен. Но по факту у тебя ни экономии на времени, ни экономии на ресурсах.

Но, надо признать, у нас своя специфика приложения, поэтому может всё так.

я жду что Poco изменит кроссплатформенное тестирование )) но опять же проще два сьюта сделать, локаторы же другие будут

ну чтоб проблем с локаторами не было - надо менять их в коде апки - тогда это дело будет попроще но в любом случае - аппиум категорически медленнее чем нативные инструменты

Ребят, подскажите, для тестера ручного опыт год, в Спб 55 к это нормальная зп? Как вообще приращение зп происходит у тестировщиков?

Ребят, подскажите, для тестера ручного опыт год, в Спб 55 к это нормальная зп? Как вообще приращение зп происходит у тестировщиков?

Норм

ЗП зависит только от того, за сколько ты сможешь себя продать.

С годом опыта можно получать 40, можно получать 120.

Ребят, подскажите, для тестера ручного опыт год, в Спб 55 к это нормальная зп? Как вообще приращение зп происходит у тестировщиков?

Судя по опыту. Чаще прибавка к зп происходит переходом в другую компанию)

Ребят, подскажите, для тестера ручного опыт год, в Спб 55 к это нормальная зп? Как вообще приращение зп происходит у тестировщиков?

Работаешь в фирме, параллельно ходишь на собесы в другие и просишь там процентов на 20 больше нынешней зп, как предлагают идешь к менеджеру и говоришь так и так, предложили больше ухожу и, если ты ценен, тебе повышают на 25-30 процев

Судя по опыту. Чаще прибавка к зп происходит переходом в другую компанию)

ну почему же. Иногда когда заявление кладешь на стол, сразу вспоминают, что могут тебе увеличить ЗП :)

и начать искать тебе замену)

и начать искать тебе замену)

там еще есть такой тонкий момент как элемент шантажа))) Когда допустим у тебя в команде 2 тестировщика. один недавно пришел и ниче не знает, а ты с опытом. Если ты будешь увольняться, то новый тестер не потянет проект. и скорее всего тебя будут просить остаться

ну почему же. Иногда когда заявление кладешь на стол, сразу вспоминают, что могут тебе увеличить ЗП :)

Бывает, да. Хотя у нас пожалуй чаще работает "уходя уходи". Если уж потратил время на собесы и тебе дали оффер. А то и правда могут замену начать искать, палки в колеса вставлять)

Хм. Никто не сталкивался с вакансиями Test Developer?

По поводу уходи - есть пару вакансий для тестеров мануалов и автоматизаторов. Это так... Оффтоп (если кто-то думал о смене работы)

Хм. Никто не сталкивался с вакансиями Test Developer?

https://m.hh.ru/vacancy/27184445

https://m.hh.ru/vacancy/27184445

Судя по требованиям эт просто инженер по тестированию у них так назван

еще есть вариация Developer in Test

но все то же самое - QA Automation

Developer - имеется ввиду что должен уметь программировать и читать чужой код )

еще есть вариация Developer in Test

Не, developer in test пишет и дорабатывает кастомный тестовый фреймворк а также подходы к автоматизированному низкоуровневому тестированию, в том числе и к юнит тестам. Автоматизатор в этом фреймворке пишет функциональные высокоуровнивые тесты

Инженер-валидатор, инженер-верификатор... интересно там у них)

Нужны Qa auto и тестировщики. Работа в хороших комфортных офисах. Автоматизаторы на python и java. Огромный плюс - знания бд оракл #Питер #Пенза #Киев #Минск #Чернигов #Черкассы #Витебск #Полоцк #Харьков #Одесса

Нужны Qa auto и тестировщики. Работа в хороших комфортных офисах. Автоматизаторы на python и java. Огромный плюс - знания бд оракл #Питер #Пенза #Киев #Минск #Чернигов #Черкассы #Витебск #Полоцк #Харьков #Одесса

Вам в https://t.me/qa_jobs Только сначала правила публикации прочитайте, пожалуйста

Судя по требованиям эт просто инженер по тестированию у них так назван

SDET еще бывает

Вам в https://t.me/qa_jobs Только сначала правила публикации прочитайте, пожалуйста

дык этот друг уже успел и там вбросить

А, извиняюсь тогда. Пропустил

Поцоны, чем заменить Firebug в 61-й FF?