Не поняла, типо задачи на одну функциональность один релиз?

Делать в конце регресс всех функциональностей, затратно по времени, надо разработку останавливать за неделю до дедлайна минимум

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

У нас релиз приложения раз в три недели. 2 недели на разработку, в конце 2й недели все задачи что остались в open (по ним не велась разработка), идут в следующий релиз. в 3ю неделю спринта багфикс, регресс начинаем как только все задачи закрыты и пофикшены критические дефекты (это может быть и за неделю до релиза, в целом регресс может растянуться на долго).

У нас релиз приложения раз в три недели. 2 недели на разработку, в конце 2й недели все задачи что остались в open (по ним не велась разработка), идут в следующий релиз. в 3ю неделю спринта багфикс, регресс начинаем как только все задачи закрыты и пофикшены критические дефекты (это может быть и за неделю до релиза, в целом регресс может растянуться на долго).

Андроид тестит один человек, айос другой

То есть, задачи, по которым не велась разработка, вы выносите не в бэклог спринта, а в следующий спринт напрямую? На планинге их не пересматриваете? А сколько раз подряд задача может переезжать в следующий спринт?)

То есть, задачи, по которым не велась разработка, вы выносите не в бэклог спринта, а в следующий спринт напрямую? На планинге их не пересматриваете? А сколько раз подряд задача может переезжать в следующий спринт?)

А ну вот, как раз я про это

>советом по построению процесса тестирования. Интересует как вы декомпозируете задачи (насколько мелко?), как часто релизите, в какой момент тестируете, если тестируете разные платформы, то пользуетесь разными инструментами или какими-то универсальными? Отвечаю на конкретные вопросы: 1. Процесс тестирования надо выстраивать. 2. Декомпозируем по разному по необходимости. 3. Релизим регулярно. 4. Тестируем перед релизом, после релиза и до релиза. 5. Тестируем разные платформы и пользуемся разными инструментами.

Коллеги, поделитесь ссылками на хорошие доклады по DevOps, плз.

А что конкретно интересует?

https://youtu.be/pqJQqsHoIt0

Доброе время суток! Подскажите, пожалуйста, по английским наименованиям различных вариантов нашей профессии - в чём именно отличия? Software tester, Software test-engineer, QA tester, QA engineer, etc? И как правильнее именовать нагрузочных тестировщиков - performance test-engineers?

Вроде никакой разницы. По второму вроде performance analyst зовут

в трудовой в России у нас у всех написано инженер

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

Вопрос в том, что при создании резюме надо бы правильно себя назвать, потому что поиск идёт не только по скиллам, но и по названию вакансии (особенно первичный, на уровне HR). Ответ Константина, наверное, всё объясняет. Если бы каждый называл просто как хотел, то и статистически такого разброса в костах не было бы. По России да, можно, наверное, что угодно писать.

Поэтому интересно ЛИЧНО пообщаться с тем, кто в этом верится

Это 5а5азввается

можно поставить focused hosts, но не пробовал его сам, возможно поможет

Инженер тестирует вплоть до кода и архитектуры, тестер бомбит по тесткейсам

т.е. что бы можно было «проверять» доверенные программы из профилей не выключая прокси, что бы можно было юзать аппстор и тд