Гугл, в данном случае, как почти всегда, прав )) Речь идет о т.н. нефункциональных требованиях, т.е. таких, которые нельзя вот так вот взять, проверить тестом, и убедиться, что "оно работает, как заказывали". Это суть требования качественного характера, предъявляемые к архитектуре в целом, или к отдельным группам функциональных и/или системных требований. Например: "горизонтальное масштабирования хранилища данных не должно влиять на время реакции системы для операций регистрации новых и удаления ранее зарегистрированных пользователей", или, "система должна быть с минимальными затратами переносима на 64-битную архитектуру"... или еще круче: "разрабатываемая система должна обеспечивать легкость сопровождения кода новыми разработчиками".
Термин "Ility" происходит из (ныне устаревшего) ISO/IEC-9126, разросшегося в целое семейство стандартов ISO/IEC-250*, которые перечисляют и классифицируют все мыслимые и немыслимые аспекты качества ПО и даже определяют методику их оценки (SQuaRE)... правда, эта методика настолько туманна, что после ее прочтения
растет число самоубийств остается больше вопросов, чем было до него )) В самой же классификации, большинство аспектов верхнего уровня заканчиваются на "ility" - Testab
ility, Reliab
ility, Portab
ility и т.д. - oтсюда и название.
Однако, если есть требование, QA должен хоть извертеться на пупке, но найти возможность проверить/подтвердить, выполнено оно или нет... и такие возможности действительно есть. Только вот "тестированием" назвать их можно весьма условно. Скорее, речь идет о методиках анализа кажущихся на первый взгляд субъективными, характеристик качества ПО на основе его объективных характеристик - от мнений независимых экспертов, проводящих аудит (архитектуры, процессов разработки и системы управления качеством на предприятии), и вплоть до результатов структурного анализа архитектуры и статического/динамического анализа кода (в качестве примера последнего подхода:
SQALE).
Простой