Все приемы "перевода" качества в количество основаны на примитивных отношениях (например таком: X=1-A/B, где А - число нереализованных функций; В - число описанных функций). И дальше все это так или иначе "агрегируется". Вообще гляньте этот ГОСТ Р 25023-2021 "Измерения качества системы и программной продукции" - прикольно для фанатов отчетности и тех, кого мучают вопросами "а что у нас с качеством?". Как это применять в реале представить сложно (не сталкивался), но видимо кто-то пользуется. Виталий Шароватов у себя подробнее рассказывает тему с рисками.

Ну а если по старинке, то определяем то, на что больше обращать внимание исходя из контекста и ответов на вопросы из прошлого поста.

Начнем с поставки продукта (фичей) - без этого пользователь не получит ничего.
Если поставляем коробку для on-premise, то значит будет установка - риск по “совместимости”. Если хостим сами (что-то а-ля SaaS) - то вопрос чуть другой.
Какие вопросы задаем (или решаем сами исходя из опыта поддержки):
- какая самая популярная ОС из поддерживаемых (но, помним - проверять, что ставимся на все поддерживаемое, все равно нужно, вопрос лишь в том, как часто).
- или самая “капризная” (исходя из опыта предыдущих тикетов)
- свежая ОС в списке
Им больше всего внимания.

Обновление установки:
- целостность хранимых данных при обновлении - важный вопрос. Тестирование миграций часто идет фоном и происходит “благодаря” тестированию обычных фичей. А именно в этом месте может стрельнуть, особенно если стенды обнуляются при накатывании новых версий. Но данные бывают разными, каких-то и не жалко.
- кастомные настройки (“тюнинг”) -что с ними происходит после обновления? Сброс, изменение дефолта.

Функциональность:
- новые фичи - тут понятно, пользователи в них будут тыкаться, даже если им оно и не нужно. Но опять же, перфекционизм - зло. Не надо вылизывать все до тех пор, пока не будет блестеть. Ибо есть шанс, что оно никому это блестящее уже и не нужно будет, когда решитесь таки выйти.
- “старые” фичи - что задели, как, что у нас с проверками в этих местах? Поэтому для определения скоупа тестирования важно понимать, что меняли. История “доверяй разрабам - но проверяй” конечно имеет место быть, но проверять вообще все каждый раз вы не вывезете. А действовать "на удачу" - не самая удачная стратегия 🫠
- интеграционные сценарии - не забываем про договоренности со смежными командами, кто что проверяет и на какую глубину. Отталкиваемся от сценариев друг друга.
- возвращаясь к совместимости: если реализация независима от специфики ОС, то проверять можно на одной, а не пачке. И в этом месте важно понимать, что у нас зависит от ОС или, скажем, браузер-специфик, чтобы учесть это при составлении плана тестирования. Урезаем количество проверок, рискуем, но осознанно.

Самое забавное - дальше, про все остальные характеристики качества (которые не “функциональность”).
“По умолчанию” считается, что продукт безопасный, надежный, удобный в использовании и поддержке.
А тут на самом деле самые яркие риски и кроются. И чем яснее текущий статус для всех, тем больше шансов на понимание того, что именно требует повышенного внимания.

Много заказчиков из банков - готовьтесь к полным ИБ-проверкам, ограничивающим настройкам сети и фоткам логов вместо самих логов (особенно, если не позаботились об экранировании чувствительных данных там).

Основная аудитория на Android - выбрали ее как основную мобильную платформу? Все равно готовьтесь чинить iOS “ахтунги”, потому что их используют топы.

Основной профиль использования, по мнению бизнеса, это компании до 5к пользователей - можно фокусироваться в тестировании на таких, но не удивляться 100к, потому что сейлзы могут, умеют и практикуют. Истории с надежностью (отказо- и катастрофоустойчивостью) в ту же копилку.

Именно в этом месте важны договоренности и прозрачность: "мы срезаем углы - цена вот такая".

Короче, оцениваем не какие-то "далекие" от нас неосязаемые риски, а то где может стрельнуть исходя из наших последних действий (добавления/изменения).

#quality