Я  почти год назад говорила о том, что QA становятся HR в плане найма квалифицированных сотрудников, и не только ПМ/dev. Смещается вектор далеко влево.

Интересно. А где говорила? Почитать можно?

Был разговор в офисе на тему что для вас означает shift left. Тогда сказала о том, что для меня это ещё и кадровые разборки, включая составление матриц компетенций совместно с дев лидами, отбор персонала и прпр

🥰🥰 об этом я бы с удовольствие послушала мысли и кейсы. Что то делаете уже в эту сторону?

Конкретно в той компании, максимум, согласование с тех. директором и лидами  матрицы было и в некоторые  проекты  собесились люди со всеми ключевыми участниками. А так, судя по собесам в других компаниях - это распространённая практика. В ЕРАМ на 1 проекте (из того, что я видела) также привлекали и dev, и QA даже на интервью аналитика. Основная цель - найти такого коллегу, который идеально впишется в коллектив и будет мыслить хотя бы примерными категориями ценностей (это касается любых ролей).

Омг... 2,5 года назад это было.

Нет, это совсем не так. Суть: отдельная стадия тестирования конкретных задач разработчиков - не нужна, но чтобы стало так, ее мы заменили несколькими пунктами:
1. Делается действительно детальная декомпозиция требований - чтобы в процессе разработки не хотелось задать ни одного вопроса продакту, UX дизайнеру. То есть точно понятно, что нужно сделать
2. Техническое решение также исследуется, до груммингов идет работа с кодом, чтобы оценка задач уже была приближена к реальности. Раньше были случаи, что из-за непонимания тех реализации, оценки были сильно не правильные. Ну и главная суть не в этом, а как в п.1 - нет сюрпризов и с технической стороны во время реализации
3. Грумминги включают в себя и оценку на покрытие тестиами и проведение различных тестов для определенной фичи
4. Планнинги учитывают оцененные задачи на обеспечение качества. Так как цели проработаны с тех и бизнесовой стороны - можно цель на спринт поставить конкретную и достежимую, а не - реализовать фичу и делать ее в итоге несколько спринтов не меняя цели
5. В процессе разработки QA практически не участвует. Максимум - покрывает функциональными тестами, если так договорились в команде. Тесты могут писать разработчики, SCRUM команда договаривается о ролях самостоятельно. В низкоуровневые тесты QA инженеры руками не лезут, они только обсуждаются на предыдущих шагах с разработчиками. В этом квартале будут реализованы обязательные проверки на тестовое покрытие для юнит и интеграционных тестов в пайплайне, чтобы без них нельзя было вмерджить код в мастер. Идея - все понятно что надо проверять, причем в тех командах, в которых процесс работает примерно пол года - тест-кейсы не пишутся. Результат example mapping - единственное место правды, где есть все ньюансы. А так как все понятно - то выделенный человек не нужен для тестирования. Разработчик отвечает за покрытие тестами в процессе разработки, минимальные проверки проводит самостоятельно, но не тщательные, они в тестах. Итого, разработчик создает ветку, делает изменения, покрывает их тестами, создает Pull Request, у него нет возможности вмерджить в мастер изменения пока не получены результаты е2е тестов (100% тестов должны быть успешны, чтобы разблокировалась кнопка мерджа). Прогоняются не все тесты, а те, которые автоматически определяются по изменениям кода. Далее, когда тесты пройдены, разработчик мерджит свои изменения, они попадают в мастер, на мастер проходит полный авто регресс (ручного регресса нет совсем), и дальше, релизные скрипты выкатывают версию раз в сутки на прод, проследнюю, где 100% тестов полного набора - зеленые. Процесс чуть сложнее, беты, канарейки и тд, но суть такая
6. Когда все задачи для реализации новой фичи уже на проде, но сама фича скрыта на фиче галкой, QA приступает к исследовательскому тестированию, а продакт к позитивному. QA ломает (незамыленным взглядом, потому что не принимал участие в итерациях разработки), смотрит конститентность UX, проводит нефункциональные тесты и тд. После чего фича активируется для пользователей

Антон, зачиталась. Звучит, как рай на земле.. 🥰
Бывает, что отходите от этих процессов?
Как долго практикуете эту конфигурацию?
Есть боли?

Большое спасибо за подробный текст. Но почему совсем не так?)
---
1. QA же принимают участие в 1-4 пунктах или нет?
2. Потом ты упомянул example mapping - где все нюансы, а дальше уже разрабы сами там всё покрывают тестами когда делают таску.
3. Потом QA исследует результат.
---
Выходит есть круто проработанные требования, за покрытие которых тестами отвечают разрабы (в основном). Но QA потом ещё полируют исследовательским.
---
Это я сильно упростил чтобы казалось будто нет противоречий😅 Но может я что-то не правильно понял?

Есть исключения - системные команды, они так не работают. Отходим ли? Да в целом нет, отходить то некуда)))
На счет рая - это не конечный вид, мы постоянно работаем над ним, есть много планов
Примерно 4 года назад начали двигаться в сторону этого процесса, финальной точкой существенных изменений можно назвать середину 19-го года, получается больше 2 лет
Боли есть. Отдельная интересная тема - как обеспечить команды действительно удобными инструментами для обеспечения этого процесса со стороны автоматизации, сейчас сделано новое решение для функциональных тестов, миграцию планируем завершить к концу года. Скоро Робин подготовит доклад на эту тему, не забуду - опубликую здесь. Одновременно мы погружаемся в туллинг для низкоуровневых тестов и работаем в коллоборации с системными командами, чтобы новые фундаментальные основы оказали более тестируемыми
Есть 2 проблемы, на мой взгляд:
1. Этот процесс не двигает вперед техническое качество кода. Да, есть разговоры про тесты, но вот на текущий момент жестких ограничений еще нет и за 2 года технические метрики кода не улучшились
2. На текущий момент, ожидния от фичевых команд в части качества - размыты. Работаем над метриками и формализацией, потому что команда быстро растет. Отсюда есть проблема в читких ожиданиях от QA роли. Сейчас это больше выглядит как - сделай хорошо, вот хорошие практики которые у нас работают, внедрять их так, а что есть хороший результат?

На счет - совсем, может перегнул. Я лишь имел ввиду, что "они стадию проверки переложили на разработчиков просто" - вот это пожалуй не так

Доклад Робина  - внутренний, или на какой то конференции? Когда будет? (когда поставить напоминалку потыкать в тебя палочкой? :) )
Очень интересно

А, ну тогда это должен был быть ответ на мое сообщение :) Теперь более четко представила процесс. Что для меня важно было понять - последнюю стадию ручной проверки вы оставили (не говорю, что это плохо или хорошо, просто отмечаю факт).

Пока нет точных дат и четкого понимания где, скорее всего даже на российской площадке (https://t.me/pro_test_chat), хотя будет на английском, Робин не знает русский, к сожалению

всем привет) ребят, а может кто-то пояснить: в вакансиях часто вижу пункт типа "Опыт интеграционного тестирования". Что на ваш взгляд скорее всего имеется в виду? Понятие интеграционного тестирования такое обширное на страницах интернета, что удивляет вынесение его в отдельный пункт. Спасибо)

Почему-то я всегда думал что имеется ввиду тестирование api)

Можно и через шину!

што есть шина?)

Будь как Саша - иди на собес и спрашивай, какую роль тестировщику они отводят в интеграционном тестировании. Если успеешь задать этот вопрос до того, как тебя спросят - будешь в плюсе - будешь вооружена 😉