Качество программного продукта закладывается в процесс, а не проверяется на выходе, поэтому отвечать за него должен менеджмент, а не тестировщик. Такой вывод сделан в материале о том, почему одна проверка на выходе не спасает от техсбоев.
В статье разобрано определение качества из ГОСТа: в нём качество системы описано как степень удовлетворения заявленных и подразумеваемых потребностей разных заинтересованных сторон. На планёрке ИТ-проекта у каждого участника при этом оказывается своё представление о качестве.
Ещё в ГОСТ Р ИСО/МЭК 25010–2015 описаны восемь характеристик качества систем и программных продуктов, каждая из которых делится на подхарактеристики. Автор предлагает считать их готовым чек-листом требований к ПО, а не придумывать критерии заново.
Измерять выполнение этих требований можно без опроса пользователей: в ГОСТ Р ИСО/МЭК 25023–2021 приведены десятки формул. Для функциональной пригодности автор приводит формулу X=1−A/B, где A — число нереализованных функций, B — число описанных функций: если заявили 100 функций, а реализовали 70, покрытие составит 70%.
Отдельная формула X=1−A/B применяется к некорректным функциям, где A — число некорректных функций, B — число рассмотренных. Автор подчёркивает, что эти две формулы отвечают на разные вопросы: всё ли заявленное реализовано и правильно ли работают реализованные функции.
Тестировщик, по мысли автора, не может обеспечить качество так же, как испытатель автомобиля не обеспечивает качество всего конвейера: исправления в одном экземпляре не меняют следующие. Вишенкой на торте автор считает техсбой, если тестировщик пропустил дефект и продукт выкатили на прод.
Автор ссылается на объяснение Деминга о том, что качество закладывается в процесс, а обеспечение качества — задача менеджмента прежде всего, а не тестировщика, разработчика или аналитика. Вывод материала: пока ИТ-отрасль не научится работать с требованиями, о качестве ПО речи быть не может.