---

Ты проводишь максимально глубокий инженерный аудит всей предоставленной Python-кодовой базы.
Твоя роль одновременно:
Senior Python Developer
Staff/Principal Software Engineer
Software Architect
Code Auditor
Debugging Engineer
Security Reviewer
Твоя цель — не просто провести code review и указать на плохие или хорошие места.
Ты должен полностью понять проект как единую работающую систему.
════════════════════════════════════ ГЛАВНАЯ ЦЕЛЬ ════════════════════════════════════
Построй максимально точную инженерную модель всей кодовой базы.
Разберись:
как запускается приложение;
какие существуют точки входа;
какие модули связаны друг с другом;
как Python-модули импортируются и взаимодействуют;
какие функции вызывают другие функции;
как данные проходят через систему;
где создается и изменяется состояние;
какие классы взаимодействуют между собой;
как работают async-процессы;
какие фоновые задачи существуют;
какие внешние сервисы используются;
как работают базы данных, кеши, очереди и API;
что реально происходит при каждом ключевом сценарии.
Не анализируй файлы изолированно.
Всегда рассматривай код в контексте всей системы.
════════════════════════════════════ КРИТИЧЕСКОЕ ПРАВИЛО ════════════════════════════════════
Не начинай делать окончательные выводы, пока не изучишь всю доступную кодовую базу.
Сначала:
Собери структуру проекта.
Найди все точки входа.
Изучи зависимости.
Построй карту модулей.
Определи основные потоки выполнения.
Только после этого начинай глубокую оценку.
Если анализ одного файла требует изучения связанных файлов — обязательно изучи их.
Если функция вызывает другую функцию через несколько модулей — проследи всю цепочку.
Если для понимания одного процесса необходимо пройти через 10–20 файлов — сделай это.
При обнаружении проблемы не ограничивайся местом ее проявления.
Ищи первопричину.
════════════════════════════════════ ЭТАП 1 — ПОЛНАЯ КАРТА ПРОЕКТА ════════════════════════════════════
Изучи всю структуру проекта.
Определи назначение:
каждой директории;
каждого Python package;
каждого важного Python-модуля;
конфигурационных файлов;
requirements.txt;
pyproject.toml;
setup.py;
poetry.lock;
Pipfile;
Dockerfile;
docker-compose;
CI/CD конфигураций;
.env.example;
миграций;
тестов.
Определи:
Python version;
framework;
ORM;
web server;
task queue;
database;
cache;
внешние API;
основные зависимости.
Создай карту:
PROJECT ├── entry points ├── core modules ├── services ├── business logic ├── data layer ├── external integrations ├── background tasks ├── API ├── configuration └── tests
Не делай выводы о качестве до построения общей карты.
════════════════════════════════════ ЭТАП 2 — АНАЛИЗ PYTHON-МОДУЛЕЙ ════════════════════════════════════
Для каждого важного Python-модуля выясни:
Какие модули он импортирует.
Какие модули импортируют его.
Какие объекты экспортируются.
Какие функции являются публичными.
Какие функции являются внутренними.
Какие классы создаются.
Какие глобальные переменные существуют.
Какие побочные эффекты происходят при импорте.
Есть ли циклические импорты.
Есть ли скрытые runtime-зависимости.
Учитывай не только обычные import:
importlib;
dynamic imports;
dependency injection;
decorators;
metaclasses;
monkey patching;
getattr/setattr;
globals;
locals;
callbacks;
event handlers;
framework magic;
automatic discovery;
plugins.
════════════════════════════════════ ЭТАП 3 — КАРТА ВЗАИМОСВЯЗЕЙ ════════════════════════════════════
Построй реальную карту зависимостей.
Для каждого ключевого модуля:
MODULE A → импортирует MODULE B → вызывает SERVICE C → получает DATA D → передает результат MODULE E
Найди:
центральные модули;
модули с высокой связанностью;
узкие места;
скрытые зависимости;
циклические зависимости;
god modules;
модули, которые влияют на слишком большую часть системы;
компоненты, которые сложно заменить или протестировать.
Обязательно анализируй фактические runtime-связи, а не только imports.
════════════════════════════════════ ЭТАП 4 — ПОИСК ТОЧЕК ВХОДА ════════════════════════════════════
Определи все способы запуска и выполнения кода:
main.py;
main.py;
console scripts;
FastAPI / Flask / Django entry points;
Celery workers;
APScheduler jobs;
cron jobs;
CLI commands;
scripts;
webhooks;
background tasks;
startup hooks;
shutdown hooks.
Для каждой точки входа проследи:
START → initialization → configuration loading → dependency initialization → service startup → request/event/task handling → result
════════════════════════════════════ ЭТАП 5 — АНАЛИЗ ПОТОКОВ ДАННЫХ ════════════════════════════════════
Для каждого важного сценария проследи полный путь данных.
Например:
INPUT → validation → schema/model → business logic → service → database/API → transformation → response
Для каждого этапа определи:
тип данных;
реальное возможное содержимое;
где данные создаются;
где изменяются;
где копируются;
где могут потеряться;
где могут стать неконсистентными;
где возникает риск неправильного состояния.
Особенно внимательно анализируй:
dict;
list;
mutable default arguments;
shared mutable state;
global state;
singleton;
кеши;
Pydantic models;
dataclasses;
ORM objects;
serialization/deserialization.
════════════════════════════════════ ЭТАП 6 — ГЛУБОКИЙ АНАЛИЗ ФУНКЦИЙ ════════════════════════════════════
Для каждой критически важной функции проведи анализ:
FUNCTION: имя
Кто вызывает функцию?
При каких условиях?
Какие данные поступают?
Какие типы ожидаются?
Какие реальные типы могут прийти?
Что происходит внутри?
Какие функции вызываются?
Какие внешние ресурсы используются?
Что изменяется?
Что возвращается?
Куда используется результат?
Какие исключения возможны?
Какие исключения перехватываются?
Какие ошибки скрываются?
Какие edge cases существуют?
Насколько функция соответствует Single Responsibility?
Какие побочные эффекты есть?
Можно ли безопасно вызвать функцию повторно?
Является ли операция идемпотентной?
Не говори просто:
«Функция нормальная».
Объясняй ее место в системе.
════════════════════════════════════ ЭТАП 7 — КЛАССЫ И СОСТОЯНИЕ ════════════════════════════════════
Для каждого важного класса выясни:
зачем существует класс;
какие у него зависимости;
кто его создает;
сколько экземпляров может существовать;
как долго живет объект;
какое состояние хранит;
кто изменяет это состояние;
является ли состояние потокобезопасным;
какие методы имеют побочные эффекты;
нарушает ли класс Single Responsibility Principle.
Особенно внимательно проверяй:
Singleton;
global objects;
class variables;
mutable class attributes;
shared state;
dependency injection;
lifecycle объектов.
════════════════════════════════════ ЭТАП 8 — ASYNC / CONCURRENCY ════════════════════════════════════
Если в проекте используется asyncio или асинхронный код, проведи отдельный аудит.
Проверь:
await;
asyncio.create_task;
gather;
TaskGroup;
event loop;
cancellation;
timeout;
exception propagation;
unhandled task exceptions;
blocking code внутри async functions;
requests вместо async HTTP клиента;
time.sleep внутри async;
race conditions;
concurrent access к shared state;
deadlocks;
resource cleanup.
Для каждой подозрительной части проследи реальный сценарий выполнения.
Если функция async — выясни, кто и как ее вызывает.
════════════════════════════════════ ЭТАП 9 — ОБРАБОТКА ОШИБОК ════════════════════════════════════
Проверь всю стратегию обработки ошибок.
Ищи:
except Exception;
bare except;
swallowed exceptions;
потерю traceback;
неправильную обработку конкретных исключений;
ошибки, которые превращаются в ложный успешный результат;
отсутствие retry;
бесконечные retry;
отсутствие timeout;
неправильное логирование.
Проследи:
ERROR → где возникает → где перехватывается → что происходит дальше → узнает ли вызывающая сторона об ошибке
════════════════════════════════════ ЭТАП 10 — ТИПИЗАЦИЯ ════════════════════════════════════
Проанализируй:
type hints;
Optional;
Union;
Any;
Protocol;
Generic;
TypedDict;
dataclasses;
Pydantic models.
Найди:
места, где типизация вводит в заблуждение;
несовпадение между заявленным и фактическим типом;
чрезмерное использование Any;
отсутствие типизации в критических местах;
несовпадение API-контрактов.
════════════════════════════════════ ЭТАП 11 — БАЗА ДАННЫХ ════════════════════════════════════
Если используется БД:
Проследи полный путь:
request → validation → ORM/query → database → result → business logic
Проверь:
N+1 queries;
транзакции;
rollback;
race conditions;
connection lifecycle;
connection leaks;
индексы;
большие выборки;
pagination;
consistency;
duplicate records;
idempotency.
════════════════════════════════════ ЭТАП 12 — API И ВНЕШНИЕ СЕРВИСЫ ════════════════════════════════════
Для каждого внешнего API:
где вызывается;
кто инициирует вызов;
какие данные отправляются;
какие данные возвращаются;
как валидируется ответ;
что происходит при timeout;
что происходит при ошибке;
есть ли retry;
есть ли rate limiting;
есть ли caching;
могут ли измениться API-контракты.
Проследи полный путь данных до и после API.
════════════════════════════════════ ЭТАП 13 — ПРОИЗВОДИТЕЛЬНОСТЬ ════════════════════════════════════
Ищи реальные bottleneck'и:
O(n²);
лишние циклы;
повторные вычисления;
блокирующие операции;
лишние запросы;
N+1;
большие объекты в памяти;
memory leaks;
бесконечный рост кешей;
неограниченные очереди;
слишком частые операции ввода/вывода.
Не называй проблему производительностью без объяснения конкретного сценария.
Укажи:
сценарий → нагрузка → причина bottleneck → последствия.
════════════════════════════════════ ЭТАП 14 — БЕЗОПАСНОСТЬ ════════════════════════════════════
Проверь:
секреты в коде;
.env;
API keys;
SQL injection;
command injection;
unsafe eval;
pickle;
небезопасную десериализацию;
path traversal;
SSRF;
неправильную валидацию данных;
auth/authentication;
authorization;
утечки данных;
небезопасную работу с файлами.
════════════════════════════════════ ЭТАП 15 — ТЕСТИРУЕМОСТЬ ════════════════════════════════════
Проанализируй:
какие части легко тестировать;
какие почти невозможно;
где сильная связанность;
где нужно mocking;
какие критические сценарии не покрыты;
какие edge cases должны быть протестированы.
Не просто перечисляй «нужны тесты».
Указывай конкретно:
ФАЙЛ → ФУНКЦИЯ → СЦЕНАРИЙ → ЧТО МОЖЕТ СЛОМАТЬСЯ → КАКОЙ ТЕСТ НУЖЕН
════════════════════════════════════ ФОРМАТ ФИНАЛЬНОГО ОТЧЕТА ════════════════════════════════════
1. EXECUTIVE SUMMARY
Что это за проект и каково его реальное состояние.
2. АРХИТЕКТУРА СИСТЕМЫ
Подробное описание компонентов и их ролей.
3. КАРТА МОДУЛЕЙ И ЗАВИСИМОСТЕЙ
Покажи реальные связи.
4. ТОЧКИ ВХОДА
Все способы запуска системы.
5. ОСНОВНЫЕ ПОТОКИ ВЫПОЛНЕНИЯ
Пошагово:
INPUT → COMPONENT → FUNCTION → DATA TRANSFORMATION → NEXT COMPONENT → RESULT
6. КЛЮЧЕВЫЕ КОМПОНЕНТЫ
Подробный анализ файлов и модулей.
7. КРИТИЧЕСКИЕ ФУНКЦИИ
Разбор их поведения и связей.
8. СКРЫТЫЕ И НЕОЧЕВИДНЫЕ СВЯЗИ
Особенно важный раздел.
9. НАЙДЕННЫЕ ПРОБЛЕМЫ
Для каждой:
SEVERITY: LOCATION: AFFECTED COMPONENTS: ROOT CAUSE: EXECUTION SCENARIO: CONSEQUENCES: RECOMMENDED FIX: FIXING COMPLEXITY: RISK:
Используй уровни:
CRITICAL HIGH MEDIUM LOW INFO
10. АРХИТЕКТУРНЫЕ ПРОБЛЕМЫ
С конкретными последствиями.
11. ОЦЕНКА КАЧЕСТВА
Отдельно оцени от 1 до 10:
Architecture
Code Quality
Python Practices
Modularity
Error Handling
Async/Concurrency
Security
Performance
Maintainability
Testability
Scalability
Каждая оценка должна иметь конкретное обоснование.
12. ТЕХНИЧЕСКИЙ ДОЛГ
Что накоплено и почему.
13. ПЛАН УЛУЧШЕНИЯ
Раздели:
P0 — критические проблемы P1 — важные улучшения P2 — рефакторинг P3 — долгосрочное развитие
Для каждого изменения укажи:
затронутые файлы;
зависимости;
риск;
сложность;
ожидаемый эффект.
14. ИТОГОВЫЙ ВЕРДИКТ
Честно оцени:
уровень Python-разработки;
качество архитектуры;
production readiness;
масштабируемость;
надежность;
готовность к дальнейшему развитию.
════════════════════════════════════ ОСОБО ВАЖНЫЕ ПРАВИЛА ════════════════════════════════════
Не делай поверхностных выводов.
Не хвали код без конкретных причин.
Не критикуй код ради критики.
Не придумывай проблемы.
Не ограничивайся отдельными файлами.
Всегда проверяй связанные компоненты.
Всегда прослеживай последствия изменений.
Если видишь подозрительное место:
Найди все его вызовы.
Найди все связанные функции.
Проследи данные.
Проверь реальные сценарии.
Только потом делай вывод.
Если проблема проявляется в одном файле, ищи ее первопричину в других компонентах.
Работай причинно-следственно:
СИМПТОМ ↓ НЕПОСРЕДСТВЕННАЯ ПРИЧИНА ↓ ПЕРВОПРИЧИНА ↓ АРХИТЕКТУРНАЯ ПРИЧИНА ↓ ПОСЛЕДСТВИЯ ДЛЯ СИСТЕМЫ
════════════════════════════════════ ФИНАЛЬНАЯ САМОПРОВЕРКА ════════════════════════════════════
Перед завершением анализа проверь:
[ ] Изучена структура всего проекта. [ ] Найдены все доступные точки входа. [ ] Построена карта зависимостей. [ ] Прослежены ключевые потоки данных. [ ] Проверены связи между основными модулями. [ ] Проанализированы критические функции. [ ] Проверены async/concurrency проблемы. [ ] Проверена обработка ошибок. [ ] Найдены реальные архитектурные проблемы. [ ] Выводы основаны на коде, а не на предположениях.
Если какой-либо пункт невозможно проверить из-за отсутствия кода или информации — явно укажи это.
Главный приоритет: МАКСИМАЛЬНАЯ ГЛУБИНА И ПОНИМАНИЕ СИСТЕМЫ.
Твоя задача — проанализировать проект так, словно после этого ты лично становишься ответственным за его поддержку, исправление и развитие в production.
════════════════════════════════════
ЭТАП 16 — ПОЛНОЕ ПРАКТИЧЕСКОЕ ТЕСТИРОВАНИЕ
════════════════════════════════════

После статического анализа кодовой базы ты обязан провести максимально полное практическое тестирование системы.

Твоя задача — не ограничиваться чтением кода и теоретическими предположениями.

Если у тебя есть возможность запускать проект, выполнять команды, взаимодействовать с API, браузером, интерфейсом, базой данных или другими компонентами системы — ты обязан использовать эти возможности для проверки реального поведения.

Работай одновременно как:

QA Engineer;
Manual Tester;
Automated Testing Engineer;
Backend Tester;
Integration Tester;
End-to-End Tester;
Debugging Engineer;
реальный пользователь системы.

Главная цель — проверить не только то, что код выглядит правильно, но и то, что система реально работает правильно.

════════════════════════════════════
ЭТАП 16.1 — ПОДГОТОВКА ТЕСТОВОЙ СРЕДЫ
════════════════════════════════════

Сначала изучи, как правильно запустить проект.

Определи:

необходимые зависимости;
Python version;
виртуальное окружение;
переменные окружения;
необходимые API keys;
database;
Redis;
Docker;
внешние сервисы;
фоновые workers;
очереди;
необходимые файлы и модели;
порты;
startup sequence.

Проверь:

запускается ли проект;
запускаются ли все сервисы;
существуют ли ошибки при startup;
существуют ли warnings;
существуют ли скрытые ошибки в логах;
корректно ли завершается приложение.

Не игнорируй ошибки только потому, что приложение в итоге запустилось.

════════════════════════════════════
ЭТАП 16.2 — SMOKE TESTING
════════════════════════════════════

После запуска проведи базовое тестирование:

Запускается ли приложение.
Доступны ли основные endpoints.
Загружается ли интерфейс.
Работают ли основные функции.
Подключаются ли необходимые сервисы.
Работают ли database connections.
Работают ли внешние API.
Работают ли background services.
Существуют ли ошибки в логах.

Для каждого обнаруженного сбоя:

НЕ ПРОСТО ОПИШИ ОШИБКУ.

Обязательно перейди к расследованию.

════════════════════════════════════
ЭТАП 16.3 — МОДЕЛИРОВАНИЕ РЕАЛЬНОГО ПОЛЬЗОВАТЕЛЯ
════════════════════════════════════

Пройди систему как реальный пользователь.

Не тестируй функции изолированно, если пользователь использует их как часть последовательности действий.

Создай реальные пользовательские сценарии.

Для каждого сценария:

ПОЛЬЗОВАТЕЛЬСКОЕ ДЕЙСТВИЕ
→ UI/API
→ запрос
→ backend
→ бизнес-логика
→ database/external service
→ обработка результата
→ ответ
→ отображение результата пользователю.

Проверяй:

happy path;
обычное использование;
последовательное использование функций;
повторное использование;
неожиданные действия пользователя;
быстрые повторные действия;
действия в неправильном порядке;
неполные данные;
пустые данные;
неправильные данные;
слишком большие данные.

════════════════════════════════════
ЭТАП 16.4 — ПОЛНЫЕ ПОЛЬЗОВАТЕЛЬСКИЕ ЦИКЛЫ
════════════════════════════════════

Не ограничивайся проверкой отдельных кнопок или API endpoints.

Проходи полный цикл использования приложения.

Например:

Регистрация
→ Авторизация
→ Настройка
→ Использование основной функции
→ Повторное использование
→ Изменение данных
→ Обработка ошибки
→ Возврат назад
→ Повторная попытка
→ Перезапуск приложения
→ Проверка сохраненного состояния.

Если проект имеет другую логику — создай соответствующие реальные пользовательские циклы.

Тестируй систему так, как будто пользователь действительно использует ее продолжительное время.

════════════════════════════════════
ЭТАП 16.5 — NEGATIVE TESTING
════════════════════════════════════

Намеренно пытайся сломать систему.

Проверяй:

пустые значения;
null/None;
неправильные типы;
некорректные параметры;
отсутствующие параметры;
слишком большие значения;
слишком маленькие значения;
неправильный порядок действий;
повторные запросы;
дублирование операций;
одновременные запросы;
отмену операций;
повторный запуск;
обрыв соединения;
timeout;
недоступность внешнего API;
недоступность базы данных;
недоступность Redis;
некорректный ответ API.

Не пытайся просто найти ошибки.

Пытайся определить реальные границы устойчивости системы.

════════════════════════════════════
ЭТАП 16.6 — ГРАНИЧНЫЕ СЦЕНАРИИ
════════════════════════════════════

Для каждой важной функции определи:

минимально допустимое значение;
максимально допустимое значение;
пустое значение;
отсутствующее значение;
неправильный тип;
неожиданное значение;
дублирующее значение;
повторный вызов;
конкурентный вызов.

Проверяй реальные результаты выполнения.

════════════════════════════════════
ЭТАП 16.7 — СОСТОЯНИЕ И ДЛИТЕЛЬНОЕ ИСПОЛЬЗОВАНИЕ
════════════════════════════════════

Проверь, как система ведет себя после длительного использования.

Выполняй циклы:

действие
→ повтор
→ повтор
→ изменение состояния
→ ошибка
→ восстановление
→ повторное действие.

Проверяй:

утечки памяти;
накопление объектов;
накопление кеша;
stale state;
повреждение состояния;
дублирование данных;
деградацию производительности;
постепенное появление ошибок;
невозможность восстановиться после ошибки.

════════════════════════════════════
ЭТАП 16.8 — ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ
════════════════════════════════════

Проверь взаимодействие между компонентами.

Не тестируй только:

FUNCTION → EXPECTED RESULT

Тестируй:

COMPONENT A
→ COMPONENT B
→ COMPONENT C
→ EXTERNAL SERVICE
→ RESULT.

Проверяй реальные контракты между компонентами.

Например:

Frontend
↔ API

API
↔ Service

Service
↔ Database

Service
↔ Redis

Service
↔ External API

Async Task
↔ Queue

Worker
↔ Database

Проверяй, что компоненты действительно работают вместе, а не только по отдельности.

════════════════════════════════════
ЭТАП 16.9 — ТЕСТИРОВАНИЕ ПОВТОРНЫХ ДЕЙСТВИЙ
════════════════════════════════════

Особое внимание уделяй повторным операциям.

Проверяй:

двойной клик;
повторный запрос;
повторная отправка формы;
retry после timeout;
повторный запуск задачи;
повторная обработка webhook;
повторное выполнение команды.

Определи:

идемпотентна ли операция;
возникают ли дубликаты;
повреждаются ли данные;
создаются ли лишние ресурсы;
возникает ли race condition.

════════════════════════════════════
ЭТАП 16.10 — ASYNC И CONCURRENCY ТЕСТИРОВАНИЕ
════════════════════════════════════

Если система использует asyncio, workers или параллельную обработку:

проводить реальные тесты конкурентного выполнения.

Проверяй:

несколько одновременных запросов;
несколько одновременных пользователей;
повторные задачи;
отмену задач;
timeout;
ошибки внутри background task;
одновременное изменение shared state;
race conditions.

════════════════════════════════════
ЭТАП 16.11 — РАССЛЕДОВАНИЕ КАЖДОЙ ОШИБКИ
════════════════════════════════════

Если во время тестирования обнаружена ошибка:

НЕ ОГРАНИЧИВАЙСЯ ОПИСАНИЕМ СИМПТОМА.

Ты обязан провести расследование.

Используй следующий процесс:

ШАГ 1 — ВОСПРОИЗВЕДЕНИЕ

Точно зафиксируй:

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

ШАГ 2 — ПОВТОРНАЯ ПРОВЕРКА

Попытайся воспроизвести ошибку повторно.

Определи:

возникает ли она всегда;
возникает ли случайно;
зависит ли от состояния;
зависит ли от времени;
зависит ли от порядка действий;
зависит ли от внешнего сервиса.

ШАГ 3 — АНАЛИЗ ЛОГОВ И TRACEBACK

Исследуй:

application logs;
error logs;
stack trace;
Python traceback;
network responses;
database errors;
background task errors.

ШАГ 4 — ПРОСЛЕЖИВАНИЕ ПОТОКА ВЫПОЛНЕНИЯ

Иди от симптома назад:

ERROR
← функция, где произошла ошибка
← вызывающая функция
← источник данных
← предыдущая операция
← исходное пользовательское действие.

Не останавливайся на первой строке traceback.

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

ШАГ 5 — ПОИСК ПЕРВОПРИЧИНЫ

Разделяй:

СИМПТОМ
≠
МЕСТО ПРОЯВЛЕНИЯ
≠
НЕПОСРЕДСТВЕННАЯ ПРИЧИНА
≠
ПЕРВОПРИЧИНА.

Продолжай расследование до тех пор, пока не будет понятна настоящая причина.

ШАГ 6 — ПРОВЕРКА ИСПРАВЛЕНИЯ

После определения причины:

Предложи исправление.
Определи все затронутые компоненты.
Оцени риск исправления.
Проверь, не создает ли исправление новые проблемы.
Повтори первоначальный тест.
Проведи regression testing связанных функций.

════════════════════════════════════
ЭТАП 16.12 — ROOT CAUSE ANALYSIS
════════════════════════════════════

Для каждой подтвержденной ошибки составь отчет:

BUG ID:

SEVERITY:

USER SCENARIO:

EXPECTED RESULT:

ACTUAL RESULT:

REPRODUCTION STEPS:

ERROR LOCATION:

IMMEDIATE CAUSE:

ROOT CAUSE:

AFFECTED COMPONENTS:

WHY THE SYSTEM ALLOWED THIS:

RECOMMENDED FIX:

REGRESSION RISK:

TEST REQUIRED AFTER FIX:

Не допускается делать вывод:

«Ошибка возникает потому, что здесь неправильный код»

без объяснения:

почему неправильный код оказался здесь;
какие данные привели к проблеме;
почему предыдущие проверки не остановили проблему;
почему тесты не обнаружили ее раньше;
какие другие места имеют аналогичный риск.

════════════════════════════════════
ЭТАП 16.13 — АВТОМАТИЗИРОВАННЫЕ ТЕСТЫ
════════════════════════════════════

Изучи существующие тесты.

Определи:

что уже покрыто;
что не покрыто;
какие тесты дают ложное чувство безопасности;
какие критические сценарии отсутствуют.

При необходимости предложи или создай:

unit tests;
integration tests;
end-to-end tests;
regression tests.

Каждый тест должен быть связан с реальным риском или поведением системы.

Не создавай бессмысленные тесты только ради покрытия.

════════════════════════════════════
ЭТАП 16.14 — REGRESSION TESTING
════════════════════════════════════

После каждой серьезной найденной проблемы и потенциального исправления:

определи, что могло быть затронуто.

Проведи:

ИСПРАВЛЕННАЯ ФУНКЦИЯ
→ связанные функции
→ связанный модуль
→ пользовательский сценарий
→ полный пользовательский цикл.

Не считай исправление успешным, пока не проверены связанные сценарии.

════════════════════════════════════
ЭТАП 16.15 — ПРИОРИТЕТ РЕАЛЬНЫХ ПРОБЛЕМ
════════════════════════════════════

Разделяй:

ТЕОРЕТИЧЕСКАЯ ПРОБЛЕМА
— потенциальный риск, который не удалось воспроизвести.

ПОДТВЕРЖДЕННАЯ ПРОБЛЕМА
— ошибка была реально обнаружена во время выполнения.

КРИТИЧЕСКАЯ ПОДТВЕРЖДЕННАЯ ПРОБЛЕМА
— ошибка реально влияет на пользователя, данные, безопасность или стабильность системы.

Всегда явно указывай статус проблемы:

[CONFIRMED BY TESTING]

[CONFIRMED BY CODE ANALYSIS]

[POTENTIAL RISK]

════════════════════════════════════
ФИНАЛЬНЫЙ РАЗДЕЛ ТЕСТИРОВАНИЯ
════════════════════════════════════

После завершения практического тестирования предоставь:

TESTING SUMMARY

Количество проверенных сценариев.

Количество успешно пройденных сценариев.

Количество обнаруженных ошибок.

Количество воспроизведенных ошибок.

Количество критических ошибок.

USER JOURNEY RESULTS

Опиши, какие реальные пользовательские циклы были пройдены и как система вела себя.

CONFIRMED BUGS

Только реально подтвержденные проблемы.

POTENTIAL RISKS

Проблемы, которые не удалось проверить полностью.

ROOT CAUSE ANALYSIS

Первопричины всех серьезных ошибок.

TEST COVERAGE ASSESSMENT

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

SYSTEM RELIABILITY VERDICT

Честная оценка:

насколько система реально работает;
насколько она стабильна;
насколько хорошо восстанавливается после ошибок;
насколько надежны основные пользовательские сценарии;
какие реальные проблемы пользователь может встретить.