Какие метрики используют для определения уровня качества программного обеспечения?

А, слушай, ну это ж классика, блядь! Приходят эти менеджеры с глазами круглыми: «Как там качество?». А ты им такой: «Ну, вроде норм». А они тебе: «Ну это не ответ, ёпта! Нам метрики подавай, цифры, графики, чтобы начальству впендюрить!»

Ну ладно, хуй с ними, давай разберём эту пляску с бубнами вокруг качества. Главное — не обосраться с интерпретацией, а то накосячишь.

1. Метрики дефектов, или «Где тут у нас говно завалялось?»

• Плотность дефектов: Это сколько багов мы наковыряли на тысячу строк нашего гениального кода. Цифра маленькая — хорошо? Не факт, блядь! Может, мы просто нихуя не тестировали, или код такой простой, что и ломаться нечему. А может, наоборот, код — говно, но и тесты — такое же говно, вот они багов и не находят. Пиздец, а не метрика.
• Эффективность тестирования: Вот это интереснее. Смотрим, сколько багов мы выловили до того, как пользователь начал материться в продакшене. Если 90% багов нашли тестировщики — молодцы, красавчики. Если 70% нашли пользователи — это, сука, позор и повод всем разработчикам и тестерам ебало в монитор тыкать. Волнение ебать!
• Скорость обнаружения: Смотрим график. Если в начале тестов баги сыпятся как из дырявого мешка, а к концу — тишина, вротберунчик, это хорошо. Если баги лезут до самого релиза — пидары налетели, процесс хромает.
• Серьезность дефектов: Тут просто. Если у тебя половина багов — Critical и Blocker, то проект, блядь, накрылся медным тазом. Если все баги — тривиальные «не там запятая» — может, и живём. Но опять же, подозрение ебать чувствую — может, просто глубокие косяки искать не умеем?

2. Метрики покрытия, или «Мы всё проверили или только сделали вид?»

• Покрытие кода: О, это священная корова всех начальников! «Нам нужно 90% coverage!». Ага, щас. Можно написать тесты, которые проходят по всем строкам, но нихуя не проверяют. Coverage 95%, а система — пиздопроебибна. Но если coverage 20% — это вообще ни в какие ворота, тут даже думать нечего. Инструменты вроде pytest-cov покажут цифру, но мозги-то свои включать надо.

  # Вот так запустишь и получишь красивый процент
  pytest --cov=my_project tests/

  А потом смотришь на отчёт и думаешь: «И чё, блядь, эта цифра мне даёт?». А нихуя, если не думать.

• Покрытие требований: Вот это уже дело. Все фичи, которые заказчик хотел, реализованы и протестированы? Да? Ну, уже неплохо. Нет? Ну, готовься к разбору полётов, хитрая жопа.

3. Метрики надёжности, или «Упадёт или не упадёт? А если найду?»

• MTBF/MTTR: Среднее время между падениями и среднее время на починку. Если система падает каждые пять минут, а чинят её сутки — это, блядь, катастрофа. Если падает раз в год, а чинят за пять минут — ну, можно жить, терпения ебать ноль не потребуется.
• Время отклика и RPS: Твоё приложение тупит как манда с ушами или летает? Пользователю похуй на твой красивый код, ему важно, чтобы страница грузилась быстрее, чем он успеет матернуться.

4. Метрики процесса, или «Мы быстро работаем или просто суетимся?»

• Скорость тестов: Если прогон всех тестов занимает три рабочих дня — это пиздец. Никакой agile не вывезет.
• Процент автоматизации: Ручные тесты — это, извини, каменный век. Если каждый раз двести тест-кейсов прогоняет живой человек — это деньги на ветер и адская задержка.
• Статус тестов: Если каждый второй коммит валит половину тестов — в команде бардак, чувак. Если всё зелёное — либо гении, либо тесты хуйня.

Итог, блядь, какой? Смотреть на одну цифру — это как судить о фильме по одному кадру. Овердохуища метрик, но если ты их в кучу не сведёшь и мозгом не проанализируешь, то это просто циферки для красивых презентаций. Контекст, ёпта! Для ядерного реактора и для сайта-визитки метрики — это, блядь, два разных мира. Так что думай, анализируй, а не просто графики начальству подсовывай.