Когда программные ошибки могут навредить людям
Большинство программных багов просто раздражают — сломанная кнопка, медленная страница, ошибка форматирования. Но в некоторых отраслях баги могут травмировать или убить людей, вызвать финансовое мошенничество или скомпрометировать национальную безопасность.
В этих регулируемых отраслях правительства и отраслевые органы предписывают конкретные стандарты. Тестирование здесь выходит далеко за рамки обычного QA — оно требует валидации, формальной документации, журналов аудита и регуляторного одобрения.
Здравоохранение и медицинские устройства
Ключевые стандарты
| Стандарт | Область | Орган |
|---|---|---|
| FDA 21 CFR Part 11 | Электронные записи и подписи | FDA США |
| IEC 62304 | Жизненный цикл ПО медицинских устройств | Международный |
| ISO 14971 | Управление рисками для медицинских устройств | Международный |
| HIPAA | Конфиденциальность и безопасность медицинских данных | HHS США |
| EU MDR | Регулирование медицинских устройств | ЕС |
Требования к тестированию
Валидация ПО (FDA): FDA требует, чтобы ПО медицинских устройств было «валидировано» — то есть существовала документальная база, подтверждающая, что ПО стабильно выдаёт результаты, соответствующие заранее определённым спецификациям.
Валидация включает:
- Installation Qualification (IQ) — правильно ли установлено ПО?
- Operational Qualification (OQ) — работает ли ПО согласно спецификации?
- Performance Qualification (PQ) — работает ли ПО корректно в реальной среде?
Тестирование на основе рисков (ISO 14971): Каждая функция должна оцениваться по риску для безопасности пациента.
Журналы аудита: Каждое действие в медицинской системе должно записываться — кто обращался к данным пациента, когда и какие изменения были сделаны.
Трассировка: Полная трассировка от требований к дизайну, к тест-кейсам, к результатам, к дефектам. Это обязательно — аудиторы проверят.
Финансы
Ключевые стандарты
| Стандарт | Область | Орган |
|---|---|---|
| PCI-DSS | Безопасность данных платёжных карт | PCI Security Council |
| SOX | Целостность финансовой отчётности | Конгресс США |
| Basel III/IV | Управление банковскими рисками | Базельский комитет |
| GDPR/CCPA | Конфиденциальность данных | ЕС/США |
Требования
PCI-DSS: Любая система, хранящая, обрабатывающая или передающая данные кредитных карт, должна соответствовать PCI-DSS: ежеквартальное сканирование уязвимостей, ежегодный penetration testing, ревью безопасного кода, проверка контроля доступа.
SOX: Требует целостности данных в финансовых системах — точные расчёты, невозможность изменения данных без авторизации, контроль доступа, работающие процедуры резервного копирования.
Автомобильная отрасль
Уровни ASIL (ISO 26262)
| Уровень ASIL | Пример | Требования к тестированию |
|---|---|---|
| A | Управление внутренним освещением | Базовое функциональное тестирование |
| B | Системы фар | Систематическое тестирование, покрытие требований |
| C | Круиз-контроль | Тестирование по требованиям, внесение отказов |
| D | Тормозная система, рулевое управление | Исчерпывающее тестирование, формальные методы, независимая верификация |
Авиация
DO-178C
Уровни DAL (Design Assurance Level) от A до E:
| DAL | Последствие отказа | Пример |
|---|---|---|
| A | Катастрофическое | ПО управления полётом |
| B | Опасное | Мониторинг двигателя |
| C | Серьёзное | Навигационный дисплей |
| D | Незначительное | Развлекательная система |
| E | Без последствий | Журнал обслуживания |
ПО уровня DAL A требует Modified Condition/Decision Coverage (MC/DC) — самой строгой формы анализа покрытия кода.
Фармацевтика
Категории GAMP 5
| Категория | Тип | Объём валидации | Пример |
|---|---|---|---|
| 1 | Инфраструктура | Минимальный | ОС, базы данных |
| 3 | Неконфигурируемые продукты | Низкий | Коммерческое ПО |
| 4 | Конфигурируемые продукты | Средний | ERP, LIMS |
| 5 | Пользовательские приложения | Высокий | Разработанные на заказ лабораторные системы |
Общие требования регулируемых отраслей
1. Валидация vs верификация
| Концепция | На какой вопрос отвечает | Пример |
|---|---|---|
| Верификация | «Правильно ли мы построили продукт?» | Соответствует ли код спецификации? |
| Валидация | «Построили ли мы правильный продукт?» | Удовлетворяет ли продукт реальные потребности пользователя? |
2. Документация
Регулируемое тестирование порождает значительно больше документации: план валидации, протокол валидации, отчёт о валидации, матрица трассировки, оценка рисков, записи контроля изменений.
3. Контроль изменений
Любое изменение в валидированном ПО должно проходить формальный процесс: задокументированный запрос, анализ влияния, одобрение, реализация, регрессионное тестирование, обновлённая документация.
4. Целостность данных (ALCOA+)
| Принцип | Значение |
|---|---|
| Attributable (Атрибутируемые) | Кто создал данные? |
| Legible (Читаемые) | Можно ли прочитать данные? |
| Contemporaneous (Своевременные) | Были ли записаны в момент события? |
| Original (Оригинальные) | Это оригинальная запись? |
| Accurate (Точные) | Верны ли данные? |
| +Complete (Полные) | Все ли данные включены? |
| +Consistent (Непротиворечивые) | Есть ли противоречия? |
| +Enduring (Долговечные) | Будут ли доступны весь период хранения? |
| +Available (Доступные) | Можно ли получить доступ при необходимости? |
Основы compliance testing
- Маппинг регуляторных требований к конкретным тест-кейсам
- Сбор доказательств для аудиторов
- Анализ пробелов где ПО ещё не соответствует
- Тестирование после исправлений
- Периодическая повторная валидация
Упражнение: определите требования соответствия
Сценарий: Вы QA Lead стартапа в области здравоохранения, разрабатывающего приложение телемедицины. Приложение позволяет:
- Видеозвонки с врачами
- Просмотр и скачивание медицинских записей (результаты анализов, рецепты)
- Оплата консультаций кредитной картой
- Получение напоминаний о приёме лекарств через push-уведомления
Приложение запустится сначала в США, затем расширится в ЕС.
Задания:
- Какие регуляторные стандарты применимы? Перечислите все и объясните почему.
- Для каждого стандарта определите 3 главных требования к тестированию.
- Создайте чек-лист compliance testing (минимум 15 пунктов), организованный по регуляциям.
- Каковы последствия несоответствия для каждого стандарта?
Подсказка
Подумайте, какие данные обрабатывает приложение:
- Медицинские записи → HIPAA, FDA
- Данные кредитных карт → PCI-DSS
- Расширение в ЕС → GDPR
- Напоминания о лекарствах → Возможная классификация как медицинское устройство
Решение
1. Применимые стандарты
| Стандарт | Почему применим |
|---|---|
| HIPAA | Приложение обрабатывает PHI (медицинские записи, рецепты) |
| FDA 21 CFR Part 11 | Электронные медицинские записи и e-рецепты |
| FDA SaMD | Может классифицироваться как Software as a Medical Device |
| PCI-DSS | Обработка платежей кредитными картами |
| GDPR | Расширение в ЕС — обработка данных граждан ЕС |
| ADA/Section 508 | Медицинские приложения должны быть доступными |
2. Топ-3 требования на стандарт
HIPAA: 1) Тестирование шифрования 2) Контроль доступа 3) Журнал аудита
PCI-DSS: 1) Ежегодный penetration testing 2) Ежеквартальное сканирование уязвимостей 3) Тестирование хранения данных
GDPR: 1) Управление согласием 2) Права субъектов данных 3) Уведомление об утечках
3. Чек-лист compliance testing
HIPAA: PHI зашифрована в покое, зашифрована при передаче, RBAC, журнал аудита, тайм-аут сессии, BAA
PCI-DSS: Данные карт никогда в открытом виде, токенизация, квартальные сканы, годовой pen test, сегментация сети
GDPR: Явное согласие, доступ к данным, удаление данных, DPIA, политика конфиденциальности
Доступность: WCAG 2.1 AA, совместимость с программами чтения с экрана
4. Последствия несоответствия
| Стандарт | Последствие |
|---|---|
| HIPAA | Штрафы до $1.5M за категорию нарушения в год, уголовное наказание |
| PCI-DSS | Штрафы $5K-100K/месяц, потеря возможности обрабатывать карты |
| GDPR | Штрафы до 4% годового мирового оборота или EUR 20M |
| FDA | Предупреждения, отзывы продукции, уголовное преследование |
Ключевые выводы
- Регулируемые отрасли требуют тестирования, выходящего далеко за рамки обычного QA
- Ключевые отрасли: здравоохранение (FDA/HIPAA), финансы (PCI-DSS/SOX), автомобильная (ISO 26262), авиация (DO-178C), фарма (GAMP 5)
- Все разделяют общие требования: трассировка, контроль изменений, целостность данных, независимая верификация
- Несоответствие может привести к серьёзным последствиям: штрафам, отзывам продукции, уголовному преследованию
- Строгость тестирования пропорциональна риску — больший риск для жизни требует более тщательного тестирования