K
И дело в том, что тестировщик всё же должен брать на себя больше обязанностей. Он последний рубеж между безумием в компании и конечным пользователем.
Size: a a a
2020 December 22
AG
И дело в том, что тестировщик всё же должен брать на себя больше обязанностей. Он последний рубеж между безумием в компании и конечным пользователем.
Нет, не должен.
IG
И дело в том, что тестировщик всё же должен брать на себя больше обязанностей. Он последний рубеж между безумием в компании и конечным пользователем.
Звучит очень пафосно, уж простите)
VK
Ну вот собрали мы фидбек, дали его разработчикам, они его проигнорировали. В релиз у нас ушла сырая и плохая версия продукта.
Вы утрируете.
Вот забухал тестировщик и не стал тестировать, появились баги?
Кто виноват что он идиот?
Или начальник решил купить любовнице шубу не задержал вам ЗП и не купил железо для тестового стенда?
Вот забухал тестировщик и не стал тестировать, появились баги?
Кто виноват что он идиот?
Или начальник решил купить любовнице шубу не задержал вам ЗП и не купил железо для тестового стенда?
K
Нет, не должен.
Давайте сойдёмся на том, что у нас разные подходы к работе. :)
E
И дело в том, что тестировщик всё же должен брать на себя больше обязанностей. Он последний рубеж между безумием в компании и конечным пользователем.
С чего бы?
VK
И дело в том, что тестировщик всё же должен брать на себя больше обязанностей. Он последний рубеж между безумием в компании и конечным пользователем.
в корне не согласен
AG
Решать что катить в прод, а что не катить должен тот, кто отвечает за продукт.
Это может быть тестировщик, может быть разработчик, может быть ПМ или любой другой участник команды.
Но это не относится к тестированию как таковому.
Это может быть тестировщик, может быть разработчик, может быть ПМ или любой другой участник команды.
Но это не относится к тестированию как таковому.
E
Тестировщик просто исполнитель
Он не должен весь проект на себя брать
Он не должен весь проект на себя брать
AG
Если команда решает что "QA решает, когда можно катиться в прод" это просто значит, что QA взял на себя часть задач условного продакт оунера.
DN
И дело в том, что тестировщик всё же должен брать на себя больше обязанностей. Он последний рубеж между безумием в компании и конечным пользователем.
Этому городу нужен герой...
K
Если команда решает что "QA решает, когда можно катиться в прод" это просто значит, что QA взял на себя часть задач условного продакт оунера.
Т.е. если вы увидите в продукте критикал баг, с которым решат выпустить этот самый продукт, то вы ничего делать не станете и просто скажете "это уже не мой круг обязанностей"?
VK
Т.е. если вы увидите в продукте критикал баг, с которым решат выпустить этот самый продукт, то вы ничего делать не станете и просто скажете "это уже не мой круг обязанностей"?
Если вы его нашли, и вам сказали, что это норм., то да, ничего не стану делать.
K
Если вы его нашли, и вам сказали, что это норм., то да, ничего не стану делать.
Как я уже говорил, у меня, видимо, слегка иное отношение к тестированию.
И
Ну вот собрали мы фидбек, дали его разработчикам, они его проигнорировали. В релиз у нас ушла сырая и плохая версия продукта.
А почему разработчикам?
AG
Т.е. если вы увидите в продукте критикал баг, с которым решат выпустить этот самый продукт, то вы ничего делать не станете и просто скажете "это уже не мой круг обязанностей"?
Вопрос не в "это уже не мой круг обязанностей".
Это вопрос в том, что решение "катить или не катить" должен принимать тот, кто отвечает за продукт.
Это его прямая задача. У него для этого больше контекста, и он будет нести за это решение ответственность.
И да, в этой ситуации я ещё раз проверю, что человек понимает степень рисков от этого бага, и если он решит катить - то будем катить.
Всё.
Это вопрос в том, что решение "катить или не катить" должен принимать тот, кто отвечает за продукт.
Это его прямая задача. У него для этого больше контекста, и он будет нести за это решение ответственность.
И да, в этой ситуации я ещё раз проверю, что человек понимает степень рисков от этого бага, и если он решит катить - то будем катить.
Всё.
K
А почему разработчикам?
Это была условность. Фидбек даётся всем участникам процесса: ПМам, аналитикам, саппорту и т.д.
VK
Как я уже говорил, у меня, видимо, слегка иное отношение к тестированию.
Если баг критикал, то тут есть очень много факторов почему он может остаться в проде какое-то время и почему его бизнес оставил. Ваша задача выявить и сообщить о своих опасениях. Принимать решение о том пойдет это в прод или нет, не ваша компетенция (
И
Это была условность. Фидбек даётся всем участникам процесса: ПМам, аналитикам, саппорту и т.д.
И в том числе тем, кто принимает решение о том, какие баги будут чиниться, и почему именно эти баги. Если тебе ответственный человек говорит "нам плевать на этот баг, он сейчас не настолько важен для бизнеса как то, что мы уже напланировали", что ты будешь делать?
K
Вопрос не в "это уже не мой круг обязанностей".
Это вопрос в том, что решение "катить или не катить" должен принимать тот, кто отвечает за продукт.
Это его прямая задача. У него для этого больше контекста, и он будет нести за это решение ответственность.
И да, в этой ситуации я ещё раз проверю, что человек понимает степень рисков от этого бага, и если он решит катить - то будем катить.
Всё.
Это вопрос в том, что решение "катить или не катить" должен принимать тот, кто отвечает за продукт.
Это его прямая задача. У него для этого больше контекста, и он будет нести за это решение ответственность.
И да, в этой ситуации я ещё раз проверю, что человек понимает степень рисков от этого бага, и если он решит катить - то будем катить.
Всё.
Вот эта проверка на то понимает человек степень риска или нет уже выходит за рамки "собрал информацию и дал фидбек". Вам уже приходится анализировать и дополнительно работать с людьми.