D
Size: a a a
2019 April 02
АМ
Хорошо , всем спасибо за помощь )
2019 April 03
СМ
Ребята, если не сложно, поделитесь метриками, которые используете в командах для контроля качества и, если не секрет для какого размера команд. //Я пока использую метрики, которые на 80% совпадают со Skyeng (где-то в этом или соседнем чате обсуждали). Но интересно как они меняются в зависимости от масштабов и энтерпрайзности компаний, если есть такая корреляция, конечно.
ОН
@stelmashenkosvan для себя я выбрал скорость релизов, IPU и code coverage, по крайней мере я понимаю, что за ними стоит и как их улучшать.
СМ
time to market +100500 :) спасибо @oneumyvakin
ОН
@stelmashenkosvan вспомнил еще время решения инцидента в саппорте - TTR - ticket time to resolution
СМ
@oneumyvakin а какой кавередж собирается - по строкам/операторам/etc ?
СМ
@stelmashenkosvan вспомнил еще время решения инцидента в саппорте - TTR - ticket time to resolution
да, спасибо, точно!
ОН
то что репортят встроенные утилиты языка в котором собирается покрытие, phpunit репортит строки, методы, классы, Go test считает только строки.
СМ
я к тому,что кому-нибудь на практике с "невероятной" пользой мутационных тестов пришлось столкнуться или это time waist?
СМ
то что репортят встроенные утилиты языка в котором собирается покрытие, phpunit репортит строки, методы, классы, Go test считает только строки.
а для js?
ОН
для js / ts пока не считаю покрытие, но по тому же принципу - то что есть из коробки, на то и буду смотреть.
СМ
спасибо // имхо - не сторонник наплодить хренову гору метрик при любом размере команды.
ОН
Пока не вижу где мутационное тестирование будет у меня полезным.
Тоже с фаззингом - негде применить т.к. мы не делаем своих парсеров / валидаторов / мы не работаем с произвольными данными пользователей и у нас нет C/C++.
Тоже с фаззингом - негде применить т.к. мы не делаем своих парсеров / валидаторов / мы не работаем с произвольными данными пользователей и у нас нет C/C++.
СМ
ОН
Если бы я был каким-нибудь консультантом-аутсорсером, то наверное я бы использовал количество открытых багов к закрытым, bug trends , burndown и тому подобное, но я плохо разбираюсь в этом, чтобы на этих метриках что-то делать дальше.
СМ
ну.. может я не права, но это не отражает профит для бизнеса, только пыль в глаза и оправдание своей работы.
ОН
Для меня это метрики 'снаружи' команды, например по ним можно понять занимается ли команда багфиксом если у продукта релиз занимает месяцы и ещё нет обратной связи от клиентов.
ОН
Или разработка фичи заниматься месяцы и нужно смотреть тренды пофично.
2019 April 04
E
Ребята, если не сложно, поделитесь метриками, которые используете в командах для контроля качества и, если не секрет для какого размера команд. //Я пока использую метрики, которые на 80% совпадают со Skyeng (где-то в этом или соседнем чате обсуждали). Но интересно как они меняются в зависимости от масштабов и энтерпрайзности компаний, если есть такая корреляция, конечно.
У нас маленькая команда - 3 человека, заказной проект, так что в качестве метрики у меня только количество проблем от заказчика. Думала про другие, но поняла, что будет лишней тратой времени и сил в данном случае.