Продолжаем.
Что нам поможет с рисками? (почему-то вспомнился мем "а чего мы хотим?")
Теория.
ISO 25010 (Systems and software engineering|Systems and software Quality Requirements and Evaluation (SQuaRE)|System and software quality models и ее аналог ГОСТ Р ИСО/МЭК 25010-2015 (в виде pdf).
Этот ISO описывает модель качества продукта через характеристики.
• Functional Suitability (Функциональная пригодность): Полнота, корректность и уместность функций.
• Performance Efficiency (Эффективность производительности): Временные характеристики, использование ресурсов, емкость (потенциальные возможности).
• Compatibility (Совместимость): Совместное использование, интероперабельность.
• Usability (Удобство использования): Понятность, обучаемость, управляемость, защита от ошибок пользователя, эстетика интерфейса.
• Reliability (Надежность): Завершенность, доступность, отказоустойчивость, восстанавливаемость.
• Security (Безопасность): Конфиденциальность, целостность, неподдельность, отслеживаемость, подлинность.
• Maintainability (Поддерживаемость): Модульность, возможность повторного использования, анализируемость, модифицируемость, тестируемость.
• Portability (Переносимость): Адаптируемость, возможность установки, замещаемость.

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

“Просто” берем каждую из характеристик/подхарактеристик, уточняем наше текущее состояние и обсуждаем с бизнесом насколько его ожидания расходятся с нашей суровой реальностью.
Что из этого критично, а чем можно пренебречь на данном этапе и как долго можно “пренебрегать”. Для новой функциональности делаем это на входе.

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

Банальный пример: вместо вопроса "а у нас будут заказчики с большими файлами?" (с ответом "конечно будут"), лучше задавать "у нас сейчас грузятся файлы до 10GB, этого достаточно будет в текущих условиях?". (Поверьте, только на собесах по системному дизайну такие вопросы задаются на входе и на такие вопросы всегда есть ответы)

Практические знания (получаем контекст):
- о тестируемом объекте (SUT) в целом
- о том, что мы сделали нового
- о внесенных изменениях и затронутой ими части функциональности
- об основных (самых популярных/ожидаемых/итп) пользовательских сценариях
- о пользовательских данных и том, как они участвуют во всех пунктах выше
- кто и как тестировал внешние для нас компоненты, которые делают другие команды

Дальше обсудим, как это все можно применить на практике.

#quality