Тьфу, это ж телега, много букоф никто читать не будет. Поэтому просто выгружаю мысли.
Был в комментах вопрос про то, как можно “мерять” качество. Оставив при этом за рамками определение “качества” (я тут немного пробовал потоптаться, но там с ним бесконечная история).
Начнем с того, что отчёт по условно багам сам по себе не несет никакой полезной информации.
Как в случае с любыми метриками - это лишь триггер подумать, а не результат работы, если конечно результаты измерений не являются целью реализации, типа ускориться, меньше тратить ресурсов.
Нельзя посмотреть на циферки и сказать “теперь мы качественные”. Но можно взять некоторые циферки и начать размышлять, глядя на них.
На что можно смотреть, окромя всеми любимых отчетов по багам (подробнее про баги, их подсчет и использование
В комментах упоминали DORA-метрики. Очень правильные метрики: ибо, имхо, например, скорость фикса (включая скорость его поставки) важнее 100% покрытия.
Редко анализируемая штука: стабильность автотестов.
Автотест грустные новости приносящий - это не гонец, которого надо убить (выключить из прогонов). Это повод к разбору, потому что “автотест моргают = в проде все будет моргать”. Хотя бы, потому что если мы не можем диагностировать проблему в тестовом окружении, то ровно то же самое будет и в проде. Шансы на то, что проблема в написании проверок, а не в продакшен коде, конечно есть. Но часто реальность может быть суровее.
Вообще писал когда-то про "что делать, когда автотесты зеленые". Но так как стабильные тесты - это фантастика, никто и не страдает этим вопросом 😂
Но это все про условно техничку и процессы. А что в реальном мире?
Качество для пользователя - это когда он без препятствий решает свои задачи и продукт убирает имеющиеся проблемы.
Качество для пользователя - это деньги 🙂
Зарабатывает продукт деньги - значит он достаточно качественный. Не зарабатывает - проблема может быть не только в его качестве.
#quality #ваши_вопросы