https://t.me/cypress_ru1
По тексту можно поискать своей вопрос

Спасибо)) нашёл способ 👍

Встречный вопрос: а почему вы не задали этот вопрос тренеру, у которого проходите "курс"?

тут чутка не понял, это UI или usability ?

А разве преподаватели не говорят всем, что онлпайн круглосуточно и готовы прийти на помощь? )

понял, не буду спамить

Да не, дело не в спаме. Просто когда люди приходят с такими вопросами, то первое что хочется предложить - это обратиться к тому, кто является в контексте их домашки, собственно, кто её придумал и задал ) Это позволит вам получить более качественную обратную связь.

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

ок,  буду с куратором работать

Хотя, кажется, я слишком ного хочу от преподавателей современных "курсов" по тестированию.

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

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

В итоге всё упирается в наличие времени и скорость выполнения.

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

Спасибо!

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

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

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

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

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

Я не говорил, что они ничего не значат. Идея в том, что сказать могут многое и из-за банальной узости своей ответственности люди могут не знать на что их изменения ещё повлияют.

Приду с вопросами в конце концов к QA. И отвечать потом "Но мне же девелопер так сказал" как-то не очень. :)

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