Тестировщик никакого отношения к devOps не имеет, поэтому знания не входят никаким боком в маст-хев. Нагрузочное и особенно security тестирование тоже относится к узкой направленности. Автоматизация ещё более менее, и то, если компания ищет general qa, в иных случаях команды разделены на манкуальщиков и автоматизаторов.
Это, конечно, топик, спрашивать у Пети, а работал ли такой-то, у более менее крупных компаний высокая гранулярность, Петя даже может не подозревать, что Вася там работал, а он работал
"Кто был руководителем?" - а вот это уже нарушение защиты персональных данных
Сама проблема и заключается в этих воронках и автоматизированных системах, которые отбирают резюме. 1. Рекрутер может проверить соответствие навыков/опыта вакансии, и софтскиллы, но это не гарантирует того, что человек пройдет технический собес и описанные знания и опыт у него присутствуют. Рекрутер не является тех. специалистом, и ему легко можно навешать на уши. 2. Упомянутые автоматизированные системы требуют от соискателей знаний, как они работают, как правильно составить резюме, иначе даже самый классный спец пролетит мимо
Опять эти клише про цифры в резюме, единственная цифра, которая важная для рекрутера, это опыт (исключение должности, которые собственно ради цифр работают). Рекрутеры смотрят на релевантность навыков, которые нужны для вакансии.
Это все есть на аутсорсе, все зависит от проекта. Про развитие на продуктовом, конечно, смешно, это всегда один и тот же продукт, в отличии от аутсорса, где проекты могут быть совершенно разные.
В смысле, кому? Стейкхолдерам, метрики по багам в целом дают возможность оценить качество продуктов. В команде такие метрики ещё более ценны, потому что они позволяют скорректировать процессы и приоритеты
Если так реагировать на процессы и на тестировщика, который 'о боги' делает свою работу, то вообще не стоит работать, метрики по багам в целом полезны, позволяют оценить в целом продуктивность, bottlenecks, качество и прочее. На проде НЕ должно быть критических багов, поэтому их искать нужно ДО
Из каждого угла хвалят игру, не понятно за что. Игра выглядит визуально хорошо, ок, но что это за примитивизм со страдашками по даме (я о начале игры)? Герои, не могу подобрать слово, пресные что ли, практически ни у одного нет хотя бы минимальной харизмы. Боевка? Смахивает на какую-то MMOшку, заявлена как пошаг, но совершенно не ощущается таковой.
Обычно для регрессионного тестирования отдельная команда не требуется, это выполняет основная команда. А описанное в статье случай очень редкий.
И, кстати, что значит используем cucumber для обучения manual qa? Иными словами, автоматизатор сидит и чиллит, пока вместо него мануальщики пишут тесты и получают зп как мануал куа, а потом потом просто проверяет их работу? Хитрый ход, конечно.
Увы и ах, но архитектора и ПМа тоже можно заменить вновь нанятыми специалистами, которые разбираются в данной сфере.
Относительно готового продукта. Можно уволить менеджмент кроме одного, а всех программистов оставить, и продукт будет существовать, потому что некоторое время можно заниматься его поддержкой и фиксами, пока команда будет ждать обновленную верхушку.
Статья более похожа на описание ощущений автора, чем реальных + и - скрама. Чтобы не было стресса и было время передохнУть, нужно адекватно оценивать трудозатраты. Аспекты/роли предопределены - так это огромный плюс, каждый знает, что ему делать и что от него требуется. Если кто-то не доволен процессами, то можно их обсудить на ретроспективе.
Автор забыл, что а) для формирования требований есть бизнес аналитики (иные специалисты) + маркетологи, которые и обсуждают с заказчиками/продакт оунерами, что можно, что не можно, что нужно, что не нужно. Люди, которые не имеют соответствующих знаний и опыта (в данном случае команда, разрабатывающая продукт), не могут сами решать, как делать, какие требования там должны быть - как предлагает автор сей статьи. Если что-то сделать технически не возможно или можно сделать лучше/проще, то это все обсуждается на пленнингах/рифайнментах - то бишь, команда в некоторой степени может "управлять содержанием"; б) продакт оунер это не мальчик на побегушках, ему не нужно каждый раз бегать к своему руководству, чтобы одобрить те или иные требования.
Тестировщик никакого отношения к devOps не имеет, поэтому знания не входят никаким боком в маст-хев. Нагрузочное и особенно security тестирование тоже относится к узкой направленности. Автоматизация ещё более менее, и то, если компания ищет general qa, в иных случаях команды разделены на манкуальщиков и автоматизаторов.
Это, конечно, топик, спрашивать у Пети, а работал ли такой-то, у более менее крупных компаний высокая гранулярность, Петя даже может не подозревать, что Вася там работал, а он работал
"Кто был руководителем?" - а вот это уже нарушение защиты персональных данных
Роман Савин - смешной анекдот, неудивительно, что джуны совбесы не проходят
Сама проблема и заключается в этих воронках и автоматизированных системах, которые отбирают резюме. 1. Рекрутер может проверить соответствие навыков/опыта вакансии, и софтскиллы, но это не гарантирует того, что человек пройдет технический собес и описанные знания и опыт у него присутствуют. Рекрутер не является тех. специалистом, и ему легко можно навешать на уши. 2. Упомянутые автоматизированные системы требуют от соискателей знаний, как они работают, как правильно составить резюме, иначе даже самый классный спец пролетит мимо
Опять эти клише про цифры в резюме, единственная цифра, которая важная для рекрутера, это опыт (исключение должности, которые собственно ради цифр работают). Рекрутеры смотрят на релевантность навыков, которые нужны для вакансии.
Это все есть на аутсорсе, все зависит от проекта. Про развитие на продуктовом, конечно, смешно, это всегда один и тот же продукт, в отличии от аутсорса, где проекты могут быть совершенно разные.
В смысле, кому? Стейкхолдерам, метрики по багам в целом дают возможность оценить качество продуктов. В команде такие метрики ещё более ценны, потому что они позволяют скорректировать процессы и приоритеты
Если так реагировать на процессы и на тестировщика, который 'о боги' делает свою работу, то вообще не стоит работать, метрики по багам в целом полезны, позволяют оценить в целом продуктивность, bottlenecks, качество и прочее. На проде НЕ должно быть критических багов, поэтому их искать нужно ДО
Выглядит как ненужные танцы с бубнами и сомнительные тест-кейсы на выходе, которые не редактируются, если изменились АК
Из каждого угла хвалят игру, не понятно за что. Игра выглядит визуально хорошо, ок, но что это за примитивизм со страдашками по даме (я о начале игры)? Герои, не могу подобрать слово, пресные что ли, практически ни у одного нет хотя бы минимальной харизмы. Боевка? Смахивает на какую-то MMOшку, заявлена как пошаг, но совершенно не ощущается таковой.
'QA не мешали релизам' - когда цель не поставить качественный продукт, а побыстрее отчитаться о работе
Обычно для регрессионного тестирования отдельная команда не требуется, это выполняет основная команда. А описанное в статье случай очень редкий.
И, кстати, что значит используем cucumber для обучения manual qa? Иными словами, автоматизатор сидит и чиллит, пока вместо него мануальщики пишут тесты и получают зп как мануал куа, а потом потом просто проверяет их работу? Хитрый ход, конечно.
Увы и ах, но архитектора и ПМа тоже можно заменить вновь нанятыми специалистами, которые разбираются в данной сфере.
Относительно готового продукта. Можно уволить менеджмент кроме одного, а всех программистов оставить, и продукт будет существовать, потому что некоторое время можно заниматься его поддержкой и фиксами, пока команда будет ждать обновленную верхушку.
Статья более похожа на описание ощущений автора, чем реальных + и - скрама. Чтобы не было стресса и было время передохнУть, нужно адекватно оценивать трудозатраты. Аспекты/роли предопределены - так это огромный плюс, каждый знает, что ему делать и что от него требуется. Если кто-то не доволен процессами, то можно их обсудить на ретроспективе.
Хорошая попытка, ChatGPT, но нет, все равно приходится искать другие варианты при решении иногда даже элементарных задач.
Нельзя поломать то, что уже поламано☝️
Автор забыл, что а) для формирования требований есть бизнес аналитики (иные специалисты) + маркетологи, которые и обсуждают с заказчиками/продакт оунерами, что можно, что не можно, что нужно, что не нужно. Люди, которые не имеют соответствующих знаний и опыта (в данном случае команда, разрабатывающая продукт), не могут сами решать, как делать, какие требования там должны быть - как предлагает автор сей статьи. Если что-то сделать технически не возможно или можно сделать лучше/проще, то это все обсуждается на пленнингах/рифайнментах - то бишь, команда в некоторой степени может "управлять содержанием"; б) продакт оунер это не мальчик на побегушках, ему не нужно каждый раз бегать к своему руководству, чтобы одобрить те или иные требования.
"доверие к тестам в команде" - тут нужно доверие к коду в команде
Не выдуманные истории, о которых не можно молчать... Ничего не знает, но все умеет
"уменьшилось количество проблем, связанных с редактированием того или иного теста или шага в нем" - тесты начали сами себя исправлять? Понятно.