В
Тоесть по вашему тестировщик это лишнее звено
Size: a a a
2020 July 27
АБ
Тоесть по вашему тестировщик это лишнее звено
Интересные выводы. Почему? :)
А
Тоесть по вашему тестировщик это лишнее звено
без QA в современном мире практически не бывает качественного продукта
В
Он же ни за что не отвечает и т.д. он только бьёт в набат
В
Если видит баг
AV
без QA в современном мире практически не бывает качественного продукта
бывает иногда )
А
Он же ни за что не отвечает и т.д. он только бьёт в набат
меньше слушайте
АБ
без QA в современном мире практически не бывает качественного продукта
define качественный :)
AМ
мне всегда казалось, что бьет в набат скорее уж сопровождение, которое отлавливает баги уже в релизе
AМ
оно не может повлиять на качество
А
бывает иногда )
да бывает, один костыль упал и поехало)
AМ
потому что "а все. а все уже. а раньше надо было"
А
потому что "а все. а все уже. а раньше надо было"
баги только после релиза?
АБ
Он же ни за что не отвечает и т.д. он только бьёт в набат
В системе пожаротушения есть датчик дыма, спринклеры и бак с водой. Какое звено в ней - лишнее, если начнется пожар?
TA
потому что "а все. а все уже. а раньше надо было"
А это превентивные методы, их нету. Мы бьем в набат только когда "а всееее, всеее"))
AМ
баги только после релиза?
ну, сопровождение в некоторых конторах именно после релиза находит баги. ну, как находит. пользователи жалуются
АБ
мне всегда казалось, что бьет в набат скорее уж сопровождение, которое отлавливает баги уже в релизе
Опять же, надо определиться, что такое "бить в набат". Баг, найденный в документации - тоже баг. Даже блокирующим может быть :)
AМ
>тестировщик сообщает
Именно, в этом и функция
>запускать ли релиз/мерж или отправиться на доработку
А вот это - нет. Вы можете это делать (как может это делать любой участник процесса), в вашей компании даже может считаться, что вы за это отвечаете. Но, еще раз, мысленный эксперимент: собственник бизнеса сказал, что завтра фича должна быть на проде. В этот момент, даже если фича - отстой, она поедет на прод. То есть полномочия не ваши, а делегированные.
Именно, в этом и функция
>запускать ли релиз/мерж или отправиться на доработку
А вот это - нет. Вы можете это делать (как может это делать любой участник процесса), в вашей компании даже может считаться, что вы за это отвечаете. Но, еще раз, мысленный эксперимент: собственник бизнеса сказал, что завтра фича должна быть на проде. В этот момент, даже если фича - отстой, она поедет на прод. То есть полномочия не ваши, а делегированные.
но я так скажу. если бизнесу надо "прямща", то даже тимлида не будут слушать о том, что код ревью говно
АБ
но я так скажу. если бизнесу надо "прямща", то даже тимлида не будут слушать о том, что код ревью говно
Конечно. Потому что решение о том, что будет на проде, а что не будет, в конечном итоге всегда принимает бизнес. Он может делегировать эти полномочия, но от этого они не перестанут принадлежать бизнесу
AМ
Конечно. Потому что решение о том, что будет на проде, а что не будет, в конечном итоге всегда принимает бизнес. Он может делегировать эти полномочия, но от этого они не перестанут принадлежать бизнесу
но если бизнес будет пытаться решать за КуА и за тимлидов, то получится плохо