Правильно понимаю, что анализ рисков можно сделать, уточнив у девов

что затронуту и может быть затронут потенциально их изменениями?
То есть идеально: все, а если куча ручного и мало времени - риск менеджмент?

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

Интересно про модель/карта продукта! Спасибо, ясно!

У Руколь было про зависимости с 13:12 https://youtu.be/S5cRXYb_isw Мы так же делали, Смоук + регресс только на части, которые могут быть затронуты

Опыт показывает, что слова разработчиков в таком вопросе ничего не стоят. Надёжнее самому смотреть изменения по Git'у и оценивать риски. Либо вы должны ну очень хорошо знать разработчика и понимать, что "фигни" он вам не скажет. Обычно я стараюсь проанализировать что именно было изменено, прикинуть какой функционал эти изменения затрагивают и дальше пытаюсь сделать как можно больше регресса. В итоге всё упирается в наличие времени и скорость выполнения.

Если разработчик сказал что там смотреть не надо, то стоит ему проверить - именно он несёт ответственность за качество в первую очередь. Если потом повылезало, то на ретро уже обсудить и выработать Action Points.

Спасибо!

Грустный у тебя опыт, если слова коллег по команде ничего не стоят.

Кто в этом процессе несёт ответственность за качество можно обсуждать долго. Я придерживаюсь мнения, что все в компании ответственны за качество, но последнее слово за QA инженерами.

Да, понял, понимаю. У нас также. Мы даём sign off для деплоя в production, а не программер, и не Product owner etc

Лучше все же сразу договориться и в доке закрепить. Но все же за качество отвечает исполнитель в первую очередь, контроль за качество не в ответе (кроме качества самого контроля)

То есть если QA сказал, что не релизим, значит не релизим?)

Я не говорил, что они ничего не значат. Идея в том, что сказать могут многое и из-за банальной узости своей ответственности люди могут не знать на что их изменения ещё повлияют. Приду с вопросами в конце концов к QA. И отвечать потом "Но мне же девелопер так сказал" как-то не очень. :)

У нас для этого есть Working agreements, как раз где такие договорённости прописаны в спринт 0

Вы не поверите, но да. В текущей компании так и работает.

Очень даже очень, девелопер получает деньги и должен быть в ответе за свою работу

Поверю. Это плохая практика )

+

Я так не считаю.

У нас решает релизить ли фичу командно, но итоговое за Product owner, остальные дают рекомендации. Но сейчас сделали так: AUTH тестит QA, и если ок, идёт в продакшн. Там тестят уже Product Owners. Если им нравится - оставляем. Выходит последнее слово за Product Owner ну и командным мнением.

Нет. Это прям дословная цитата «слова разработчика в этом вопросе ничего не стоят». Не «разработчик может ошибаться», не «разработчик может не видеть всей картины зависимостей», не любая другая формулировка. А вот так. Любой человек, как и любой инструмент, может (и будет) показывать не полную картину. Если в команде скоуп тестирования определяется через «то, что разработчик посоветовал проверить и то, что куа посчитал нужным проверить» то «разработчик сказал это не должно аффектиться» - это нормальный ответ. Не ок - это считать, что мнение тиммэйтов ничего не стоит, потому что «если что - придут с вопросами ко мне».

Не очень хочу участвовать в очередном раунде дискуссий, где вы будете утрировать и выворачивать мои идеи наизнанку. Давайте здесь и закончим.