Что такое качество программного обеспечения (Software Quality)?

А, слушай, про качество софта! Ну это ж святое, блядь. Это как с борщом: можно просто сварить, а можно так сварить, чтоб душа пела, а соседи по ночам плакали от зависти.

Вот смотри, по-простому: качество ПО — это когда программа делает то, что должна, не выёбывается, не падает в самый ответственный момент и не заставляет пользователя думать, что её писал полупидор с кривыми руками. Соответствует явным требованиям (функциональность) и неявным ожиданиям (удобство, надёжность). Всё, казалось бы, элементарно.

Но нет, ёпта! Чтобы это оценить, придумали целую хуеву тучу характеристик — атрибуты качества. По стандарту ISO 25010, который, я уверен, кто-то писал, сидя на унитазе в глубокой задумчивости.

Сейчас разложу по полочкам, но без этой офисной сухости, а как есть:

• Функциональная пригодность: Программа просто делает то, что от неё хотят. Не рисует единорогов, когда надо посчитать налоги. Проверяется acceptance-тестами — типа, «а работает ли эта ваша хрень вообще?».
• Производительность: Скорость, блядь! Чтобы не было как в том анекдоте: «программа думает… думает… а вы, пока, сходите, поужинайте». Время загрузки страницы должно быть меньше, чем у пользователя терпения (а его, терпения-то, ноль ебать).
• Совместимость: Чтобы софт не был как мартышлюшка, которая только на одном стуле умеет танцевать. Должен работать в разных браузерах, на разных системах. Кросс-браузерное тестирование — это священная война с этими ебучими рендерингами.
• Удобство использования: Вот это, блядь, больная тема. Чтобы интерфейс был не как у космического корабля для слепоглухонемых. Чтобы пользователь не чувствовал себя идиотом, пытаясь найти кнопку «Сохранить». Успешное выполнение задачи — вот метрика.
• Надёжность: Способность работать без сбоев. Не «ой, всё!» посреди рабочего дня. Измеряется временем наработки на отказ. Чем дольше — тем меньше волос вырвано на голове у админа.
• Безопасность: Чтобы вашу систему не взломали какие-нибудь пидарасы шерстяные, пока вы спите. Отсутствие уязвимостей из того самого списка OWASP Top 10 — это не пожелание, а обязаловка, иначе будет пиздец.
• Сопровождаемость: А вот это для нас, для тех, кто этот код потом будет читать и править. Код должен быть не как шифровка из абвера, а читаемым. Цикломатическая сложность — чтобы не было таких функций, где сам чёрт ногу сломит. Иначе каждый фикс — это впендюривание нового бага.
• Переносимость: Лёгкость переноса в другую среду. Чтобы не было жёсткой привязки к какой-нибудь одной библиотеке, которая умерла в 2015 году. Иначе перенос — это боль, пиздец и переписывание половины проекта.

А как этого качества добиться-то, спросишь? Да не магией, ёпта!

Через процессы, которые должны идти от начала и до самого конца, пока проект не накрылся медным тазом:

• Тестирование на всех уровнях: от маленьких unit-тестов до больших acceptance-тестов. Без этого — вы ходите по охуенно тонкому льду.
• Статический анализ кода: Code review, линтеры. Чтобы один мудак не засунул в прод какую-нибудь дичь, а все остальные потом ебались.
• Следование best practices и стандартам кодирования. Это как правила гигиены — мыть руки перед едой. Кажется ерундой, но без этого — жопа.
• Непрерывная интеграция и доставка (CI/CD). Чтобы всё собиралось, проверялось и деплоилось автоматически, а не вручную, с молитвами и подозрением ебать.
• Сбор и анализ отзывов пользователей. А то можно написать идеальный с точки зрения кода продукт, который нихуя не нужен никому. А пользователи — они ж внатуре лучшие тестировщики, найдут такие баги, что просто удивление пиздец.

Вот так вот, если коротко и на пальцах. А то читаешь эти стандарты — вротберунчик, спать хочется.