Простой вопрос: что такое качество? Ерунда, все же знают ответ.
А теперь попробуйте обсудить то же самое с соседом. Дискуссии и дебаты вам обеспечены, потому что в голове соседа качество — не то же самое, что в вашей. То же самое случится, если задать этот вопрос на планёрке любого ИТ‑проекта: соберутся десять взрослых людей, у каждого своё качество, и ни у одного — то, что у заказчика.
А вот теперь можно посмотреть умное определение качества ПО из ГОСТа.
Качество системы — это степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон, которая позволяет, таким образом, оценить её достоинства.
Вопрос: так что ж нам теперь, всех потенциальных пользователей опрашивать, если мы хотим, чтобы все пользовались нашим ПО?
Ответ: ну, кто сильно богатый — у него на проект выделен бюджет всей Российской Федерации, а почему бы и нет.
Но есть один способ никого не опрашивать. Правда, перед этим один вредный совет.
Вредный совет № 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) не может обеспечить качество авто, даже если он выявил: руль не крутится, кондиционера нет — возвращаем в разработку.
Разработчик на этом конкретном авто исправил руль и добавил кондиционер. Но следующее авто с конвейера выйдет точно в таком же виде. Потому что рули такие подвезли, и нет смысла клепать авто с таким рулём и возвращать их на доработку поточным методом.
Вишенка на торте: если тестировщик пропустил некрутящийся руль и мы выкатили на прод то, что выкатили, — получаем тот самый всеми любимый техсбой.
Качество закладывается в процесс, а не проверяется на выходе — это не моё открытие, это Деминг ещё в прошлом веке объяснил, и у него вся ИТ‑методология ее растащила по методичкам. Обеспечение качества любого производства — задача менеджмента. Прежде всего его, а не тестировщика, разработчика или аналитика.
Кому на самом деле нужно качество
Итог простой:
-
качество — это удовлетворение требований пользователя, а не личное ощущение соседа;
-
восемь характеристик из ГОСТа — это готовый чек‑лист требований, их не надо придумывать заново;
-
эти требования измеримы, и для этого не нужен бюджет всей Российской Федерации;
-
а обеспечивать качество обязан менеджмент — конвейер не чинит испытатель.
ВСЁ. Если тема заинтересовала — могу дальше небольшими статьями рассказать про модели качества, которые помогут обеспечить качество ИТ‑производства:
-
программного обеспечения, в том числе с ИИ;
-
удобства использования;
-
качества данных;
-
качества ИТ‑услуг.
И вопрос для обсуждения: а кто у вас на проекте реально отвечает за качество — и в чём это выражается кроме пункта в должностной инструкции?
Источник: habr.com