✨
тут даже старички всегда ждут, так что :)
https://habr.com/ru/company/luxoft/blog/340192/
https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html
Size: a a a
2020 August 19
x
ловите
x
🐾M
Наес, спасибо
🐾M
Полезно почитать
Ж
ребята можно совет:?
Ж
Ж
смотрите тут із свайпами влево вправо проблема или мне кажеться
AD
Оо ,это utest походу или testIo?
Ж
тест ио:)
AG
Можно чуть подробнее, если не лениво?
Ну, давай так.
Среднее время жизни бага - вообще предельно странная история.
С одной стороны - не совсем понятно, как это считать что бы это было репрезентативно (потом что, неожиданно, переменных довольно много, что бы среднее по больнице имело смысл).
С другой стороны, не совсем понятно какую практическую пользу это несёт.
Количество дефектов ушедших на прод - предельно интуитивная метрика на уровне «пропустили меньше - молодцы, пропустили больше - не молодцы».
Но при этом на практике, именно как метрика или триггер для каких-то действий, она не работает.
Потому что, опять же, мерить баги в «штуках» вообще довольно грустная затея, имеет смысл считать упущенный value.
Потому что спринты, в целом, не однородные и разные по сути задачи рождают разные (по сути и по количеству) баги.
Я бы сказал, что в конечном итоге со скоупом пропущенных багов правильнее работать в формате плановых пост-мортемов и на этапе планирования роадмапов, а не в формате метрики тестирования.
Потому что как метрика она несёт, по сути, только функцию «показать начальнику что мы молодцы».
Количество реопенов (т.е. по сути процент регрессии) может быть полезен, но прям в очень точечных случаях, когда объём оной не понятен (да и то, не уверен что это правильно считать из багов).
Ну, в общем не очень понимаю, причём тут откат на предыдущую версию и какую задачу эта метрика должна решить.
Плотность дефектов - хорошая и интересная тема, но, опять же, использовать её в отрыве от решения конкретной задачи довольно бессмысленно.
И планировать распределение работы на основе оной - не совсем правильно.
Потому что Окей, она тебе может быть покажет место, где надо копать что бы найти максимум багов.
Но, неожиданно, задача тестирования то не в этом.
Ну и в общем:
Все эти метрики довольно стандартные и интуитивные.
Проблема тоже стандартная: тестирование строят вокруг багов, а не вокруг продукта.
Среднее время жизни бага - вообще предельно странная история.
С одной стороны - не совсем понятно, как это считать что бы это было репрезентативно (потом что, неожиданно, переменных довольно много, что бы среднее по больнице имело смысл).
С другой стороны, не совсем понятно какую практическую пользу это несёт.
Количество дефектов ушедших на прод - предельно интуитивная метрика на уровне «пропустили меньше - молодцы, пропустили больше - не молодцы».
Но при этом на практике, именно как метрика или триггер для каких-то действий, она не работает.
Потому что, опять же, мерить баги в «штуках» вообще довольно грустная затея, имеет смысл считать упущенный value.
Потому что спринты, в целом, не однородные и разные по сути задачи рождают разные (по сути и по количеству) баги.
Я бы сказал, что в конечном итоге со скоупом пропущенных багов правильнее работать в формате плановых пост-мортемов и на этапе планирования роадмапов, а не в формате метрики тестирования.
Потому что как метрика она несёт, по сути, только функцию «показать начальнику что мы молодцы».
Количество реопенов (т.е. по сути процент регрессии) может быть полезен, но прям в очень точечных случаях, когда объём оной не понятен (да и то, не уверен что это правильно считать из багов).
Ну, в общем не очень понимаю, причём тут откат на предыдущую версию и какую задачу эта метрика должна решить.
Плотность дефектов - хорошая и интересная тема, но, опять же, использовать её в отрыве от решения конкретной задачи довольно бессмысленно.
И планировать распределение работы на основе оной - не совсем правильно.
Потому что Окей, она тебе может быть покажет место, где надо копать что бы найти максимум багов.
Но, неожиданно, задача тестирования то не в этом.
Ну и в общем:
Все эти метрики довольно стандартные и интуитивные.
Проблема тоже стандартная: тестирование строят вокруг багов, а не вокруг продукта.
🐾M
Ну, давай так.
Среднее время жизни бага - вообще предельно странная история.
С одной стороны - не совсем понятно, как это считать что бы это было репрезентативно (потом что, неожиданно, переменных довольно много, что бы среднее по больнице имело смысл).
С другой стороны, не совсем понятно какую практическую пользу это несёт.
Количество дефектов ушедших на прод - предельно интуитивная метрика на уровне «пропустили меньше - молодцы, пропустили больше - не молодцы».
Но при этом на практике, именно как метрика или триггер для каких-то действий, она не работает.
Потому что, опять же, мерить баги в «штуках» вообще довольно грустная затея, имеет смысл считать упущенный value.
Потому что спринты, в целом, не однородные и разные по сути задачи рождают разные (по сути и по количеству) баги.
Я бы сказал, что в конечном итоге со скоупом пропущенных багов правильнее работать в формате плановых пост-мортемов и на этапе планирования роадмапов, а не в формате метрики тестирования.
Потому что как метрика она несёт, по сути, только функцию «показать начальнику что мы молодцы».
Количество реопенов (т.е. по сути процент регрессии) может быть полезен, но прям в очень точечных случаях, когда объём оной не понятен (да и то, не уверен что это правильно считать из багов).
Ну, в общем не очень понимаю, причём тут откат на предыдущую версию и какую задачу эта метрика должна решить.
Плотность дефектов - хорошая и интересная тема, но, опять же, использовать её в отрыве от решения конкретной задачи довольно бессмысленно.
И планировать распределение работы на основе оной - не совсем правильно.
Потому что Окей, она тебе может быть покажет место, где надо копать что бы найти максимум багов.
Но, неожиданно, задача тестирования то не в этом.
Ну и в общем:
Все эти метрики довольно стандартные и интуитивные.
Проблема тоже стандартная: тестирование строят вокруг багов, а не вокруг продукта.
Среднее время жизни бага - вообще предельно странная история.
С одной стороны - не совсем понятно, как это считать что бы это было репрезентативно (потом что, неожиданно, переменных довольно много, что бы среднее по больнице имело смысл).
С другой стороны, не совсем понятно какую практическую пользу это несёт.
Количество дефектов ушедших на прод - предельно интуитивная метрика на уровне «пропустили меньше - молодцы, пропустили больше - не молодцы».
Но при этом на практике, именно как метрика или триггер для каких-то действий, она не работает.
Потому что, опять же, мерить баги в «штуках» вообще довольно грустная затея, имеет смысл считать упущенный value.
Потому что спринты, в целом, не однородные и разные по сути задачи рождают разные (по сути и по количеству) баги.
Я бы сказал, что в конечном итоге со скоупом пропущенных багов правильнее работать в формате плановых пост-мортемов и на этапе планирования роадмапов, а не в формате метрики тестирования.
Потому что как метрика она несёт, по сути, только функцию «показать начальнику что мы молодцы».
Количество реопенов (т.е. по сути процент регрессии) может быть полезен, но прям в очень точечных случаях, когда объём оной не понятен (да и то, не уверен что это правильно считать из багов).
Ну, в общем не очень понимаю, причём тут откат на предыдущую версию и какую задачу эта метрика должна решить.
Плотность дефектов - хорошая и интересная тема, но, опять же, использовать её в отрыве от решения конкретной задачи довольно бессмысленно.
И планировать распределение работы на основе оной - не совсем правильно.
Потому что Окей, она тебе может быть покажет место, где надо копать что бы найти максимум багов.
Но, неожиданно, задача тестирования то не в этом.
Ну и в общем:
Все эти метрики довольно стандартные и интуитивные.
Проблема тоже стандартная: тестирование строят вокруг багов, а не вокруг продукта.
Недавно на эту тему читал годноту, доберусь до пеки, скину сюда
AD
тест ио:)
У вас там должно быть в требованиях написано ,что нужно искать.
На этом сайте куча проблем с фильтрами ,там Изи за 5 -10мин словите кучу багов
На этом сайте куча проблем с фильтрами ,там Изи за 5 -10мин словите кучу багов
AD
У вас там должно быть в требованиях написано ,что нужно искать.
На этом сайте куча проблем с фильтрами ,там Изи за 5 -10мин словите кучу багов
На этом сайте куча проблем с фильтрами ,там Изи за 5 -10мин словите кучу багов
А как тестировщик фильтры,есть инфа в гугле.
Удачи !!
Удачи !!
LA
тест ио:)
да да, там много разного
Ж
пасибки:)
Ж
Да само тз убогое как по мне:)
Ж
пишут что где нельзя искать а что искать не пишут
Ж
3 функциональных бага