Простой вопрос: что такое качество? Ерунда, все же знают ответ.

А теперь попробуйте обсудить то же самое с соседом. Дискуссии и дебаты вам обеспечены, потому что в голове соседа качество — не то же самое, что в вашей. То же самое случится, если задать этот вопрос на планёрке любого ИТ‑проекта: соберутся десять взрослых людей, у каждого своё качество, и ни у одного — то, что у заказчика.

А вот теперь можно посмотреть умное определение качества ПО из ГОСТа.

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

Вопрос: так что ж нам теперь, всех потенциальных пользователей опрашивать, если мы хотим, чтобы все пользовались нашим ПО?

Ответ: ну, кто сильно богатый — у него на проект выделен бюджет всей Российской Федерации, а почему бы и нет.

Но есть один способ никого не опрашивать. Правда, перед этим один вредный совет.

Вредный совет № 1. При разработке ПО никогда не спрашивайте пользователей, чего они хотят. Вы же ИТ‑шники, вам лучше знать, как лучше!

Если совет не сработал — читаем дальше.

Восемь характеристик, о которых никто не спросит

Существуют уже годами проработанные блоки требований к ПО и системам. Называются они «характеристики качества», и каждая делится на подхарактеристики. Характеристик всего восемь, и они описаны в ГОСТ Р ИСО/МЭК 25010–2015 «Модели качества систем и программных продуктов»: 

Характеристика

Что это значит на человеческом

Функциональная пригодность

Система делает то, что просили

Уровень производительности

Не тормозит под нагрузкой

Совместимость

Дружит с соседями по ландшафту

Удобство использования

Пользователь не плачет над интерфейсом

Надёжность

Не падает в самый неподходящий момент

Защищённость

Данные не уходят к тем, кому не положено

Сопровождаемость

Через год в коде ещё кто‑то разберётся

Переносимость

Работает не только на вашем счастливом окружении

Точные словарные определения подхарактеристик вы найдёте в том же ГОСТе — скукота, да и только. Но суть сжимается в одну строку:

Характеристика Качества = Требование к ПО.

И вывод, забегая в самый конец: пока отечественная ИТ‑отрасль не научится работать с требованиями, о качестве ПО речи быть не может.

«А нам‑то, простым смертным, что делать?» — спросите вы. Так всё уже придумано до нас.

Как измерить качество, не опрашивая полстраны

Вредный совет № 2. Не дочитывайте до конца. Кому нужно, чтобы система была качественной? Уж точно не директору производства — там главное сроки. А то, что лыжи не едут, — пусть тестировщик отдувается.

Если дочитали — все показатели по характеристикам и подхарактеристикам уже оцифрованы и описаны в ГОСТ Р ИСО/МЭК 25023–2021 «Измерения качества системы и программной продукции». Там несколько десятков формул, чтобы измерить, насколько качественно реализован продукт в целом, не спрашивая мнения каждого пользователя. Воспользуйтесь. 

Самый простой пример — функциональная пригодность, то есть «система делает то, что просили». Как это проверить цифрой, а не ощущением?

1. Показатель «функциональное покрытие»: 

X=1−A/В, где A — число нереализованных функций, B — число описанных функций.

Заявили 100 функций, реализовали 70 — получили покрытие 70%. А если из заявленных функций реализовано 10%, самое время бежать управлять требованиями и выяснять, как так вышло. Сомневаюсь, что было только по вине тестировщика, который «один отвечает за качество ПО».

2. Показатель «функциональная корректность»: 

X=1−A/B, где A — число некорректных функций, B — число рассмотренных.

Функция есть, но выдаёт ерунду? Она некорректна. Заметьте: две формулы отвечают на два разных вопроса — «всё ли, что просили, вообще есть» и «то, что есть, работает ли как надо».

3. Управление требованиями — не пустой звук.

Как правило, через полгода проекта никто уже не помнит, что просили и что реализовали. Первый шаг к качеству — это не волшебный тест‑план, а восстановленный процесс управления требованиями. И нет, выстраивать процессы на проекте должен не тестировщик, согласны?

И да: качество — это дорого. Наверное, поэтому на него все закрыли глаза.

Испытатель и конвейер

А тестировщики нам на что? — резонно спросите вы. Они же за качество! Им и зарплату за это «платят».

То есть вся ИТ‑отрасль решила, что испытатель автомобиля должен обеспечить качество этого автомобиля? Я правильно понимаю?

Вот сейчас выдам чистую крамолу. Оказывается, до ИТ‑производства на свете было много других производств: автомобили, техника, одежда. И там уже догадались, что испытатель (в нашем случае — тестировщик, к которому намертво приклеилась кличка QA) не может обеспечить качество авто, даже если он выявил: руль не крутится, кондиционера нет — возвращаем в разработку.

Разработчик на этом конкретном авто исправил руль и добавил кондиционер. Но следующее авто с конвейера выйдет точно в таком же виде. Потому что рули такие подвезли, и нет смысла клепать авто с таким рулём и возвращать их на доработку поточным методом.

Вишенка на торте: если тестировщик пропустил некрутящийся руль и мы выкатили на прод то, что выкатили, — получаем тот самый всеми любимый техсбой.

Качество закладывается в процесс, а не проверяется на выходе — это не моё открытие, это Деминг ещё в прошлом веке объяснил, и у него вся ИТ‑методология ее растащила по методичкам. Обеспечение качества любого производства — задача менеджмента. Прежде всего его, а не тестировщика, разработчика или аналитика.

Кому на самом деле нужно качество

Итог простой:

  • качество — это удовлетворение требований пользователя, а не личное ощущение соседа;

  • восемь характеристик из ГОСТа — это готовый чек‑лист требований, их не надо придумывать заново;

  • эти требования измеримы, и для этого не нужен бюджет всей Российской Федерации;

  • а обеспечивать качество обязан менеджмент — конвейер не чинит испытатель.

ВСЁ. Если тема заинтересовала — могу дальше небольшими статьями рассказать про модели качества, которые помогут обеспечить качество ИТ‑производства:

  • программного обеспечения, в том числе с ИИ;

  • удобства использования;

  • качества данных;

  • качества ИТ‑услуг.

И вопрос для обсуждения: а кто у вас на проекте реально отвечает за качество — и в чём это выражается кроме пункта в должностной инструкции?