Кто тестирует твой функционал?

Тестирование функционала: многоуровневый подход

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

Уровень 1: Я сам (разработчик)

Локальное тестирование перед сдачей

Прежде чем показать код кому-то, я тестирую его сам:

// Шаг 1: Базовое функциональное тестирование
Процедура ТестировноватьНовыйФункционал()
    
    // Создаю тестовые данные
    ТестовыйТовар = СоздатьТестовыйТовар();
    
    // Проверяю нормальное выполнение
    Результат = МойНовыйФункционал(ТестовыйТовар);
    Если Результат.Успех Тогда
        Сообщить("✅ Нормальный сценарий работает");
    Иначе
        Сообщить("❌ Ошибка в нормальном сценарии");
    КонецЕсли;
    
    // Проверяю граничные случаи
    Если ТестировкаГраничныхСлучаев(ТестовыйТовар) = Ложь Тогда
        Сообщить("❌ Баг в граничном случае!");
    КонецЕсли;
    
    // Проверяю обработку ошибок
    ТестировкаОбработкиОшибок();
    
КонецПроцедуры

// Сценарии, которые проверяю:
// ✅ Нормальный путь (happy path)
// ✅ Граничные значения (пусто, null, 0, максимум)
// ✅ Ошибки и исключения
// ✅ Производительность (на больших данных)
// ✅ Откат изменений
// ✅ Интеграция с другим кодом

Я использую:

• Свой тестовый стенд
• Копию production базы
• Встроенные инструменты 1С (отладчик, профилировщик)
• Unit тесты

Уровень 2: Code Review (коллега-разработчик)

Перед push в main любой код проходит review:

Поцесс:
1. Я пишу код
2. Создаю Pull Request (или заявку в хранилище)
3. Опытный коллега читает код
4. Проверяет:
   - Логику
   - Производительность
   - Следование стандартам
   - Дублирование
   - Секьюрити
5. Если нашел проблемы → обсуждение и правки
6. Если ОК → merge

Чек-лист Code Review:

• Нет дублирования (DRY)
• Нет усложнения (KISS)
• Обработаны все ошибки
• Нет утечек памяти
• Производительность приемлема
• Есть комментарии в сложных местах
• Нет хардкода
• Запросы оптимальны
• Безопасность (SQL injection и т.д.)
• Следование стандартам команды

Мой опыт: На код review находят 30% багов, которые я пропустил сам.

Уровень 3: QA (тестировщик)

Если есть отдельная QA команда:

Они тестируют:
- Все сценарии использования
- Интеграцию с другими модулями
- UI/UX
- Совместимость данных
- Regression (не сломалось ли старое)
- Edge cases

В моих проектах:

• У нас была QA команда (2-3 человека)
• Они тестировали по тест-кейсам
• Я подготавливал для них:
  • Подробное описание функции
  • Тест-планы
  • Тестовые данные
  • Окружение для тестирования

Результаты: QA находит баги, которые я и code reviewer пропустили (в среднем 10-15 багов на фичу).

Уровень 4: Бизнес-анализ (аналитик/владелец продукта)

Проверяет соответствие требованиям:

Вопросы, которые они задают:
- Это соответствует требованиям?
- Это решает бизнес проблему?
- Интерфейс интуитивен?
- Есть ли лишний функционал?
- Соответствует ли процесс бизнес-логике?

В моем опыте:

• BA проверяет мой код в staging
• Проводит сценарии от себя
• Дает feedback на UX
• Находит неправильные интерпретации требований

Уровень 5: Пользователи (UAT - User Acceptance Testing)

Реальные пользователи тестируют на staging:

Мой процесс с UAT:
1. Подготавливаю окружение (копия production)
2. Обучаю пользователей
3. Даю им сценарии для проверки
4. Собираю feedback
5. Исправляю проблемы
6. Повторяю UAT если нужно

Пользователи находят:

• Непонятные сообщения об ошибках
• Неинтуитивные процессы
• Missing функционал
• Performance проблемы
• Интеграционные проблемы

Мой опыт: UAT часто переворачивает мое понимание того, как должна работать система. Находят самые критичные баги.

Уровень 6: Production Monitoring (автоматический)

После запуска в production:

// Я мониторю:
// ✅ Логи ошибок
Процедура МониторитьОшибки()
    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ Количество() КАК КолОшибок
        |ИЗ ЖурналОшибок
        |ГДЕ ДатаВремя > &ДатаВремени
        |    И МодульКода = &Модуль";
    
    ОшибкиСегодня = Запрос.Выполнить().Выбрать();
    Если ОшибкиСегодня.КолОшибок > 10 Тогда
        ПредупредитьАдминистратора("Много ошибок: " + ОшибкиСегодня.КолОшибок);
    КонецЕсли;
КонецПроцедуры

// ✅ Производительность
// ✅ Данные (не содержат явных ошибок)
// ✅ Поведение (соответствует ожиданиям)

Уровень 7: Я сам (долгосрочный мониторинг)

После недели/месяца работы:

• Проверяю логи для закономерностей
• Слушаю feedback пользователей
• Анализирую performance
• Исправляю найденные проблемы

Виды тестирования, которые я провожу

1. Функциональное тестирование

// Работает ли функция как ожидается?
Тест: "Товар создается с правильными параметрами"
Ожидаемо: Товар.Наименование = "Тест"
Результат: ✅ Прошло

2. Интеграционное тестирование

// Работает ли со смежными модулями?
Тест: "При создании товара обновляется каталог"
Ожидаемо: Каталог.Содержит(НовыйТовар) = Истина
Результат: ✅ Прошло

3. Performance тестирование

// Быстро ли работает на большом объеме данных?
Тест: "Загрузка 10000 товаров < 5 секунд"
Время выполнения: 3.2 сек
Результат: ✅ Прошло

4. Stress тестирование

// Выдерживает ли система нагрузку?
Тест: "1000 одновременных запросов"
Ожидаемо: Система остается стабильной
Результат: ✅ Прошло (3 timeout из 1000)

5. Security тестирование

// Защищена ли от атак?
Тест: "SQL injection в поиск"
Вход: "'; DROP TABLE Товары; --"
Ожидаемо: Ошибка, данные не потеряны
Результат: ✅ Защищено параметризованным запросом

Метрики качества, которыми я руководствуюсь

✅ Code coverage: > 90% (критичный код)
✅ Bug density: < 0.5 на 1000 строк (в production)
✅ Time to fix: < 1 часа для критичных
✅ Отсутствие P1 инцидентов: в течение месяца
✅ User satisfaction: > 4.5/5

Классификация багов

P1 (Critical): Потеря данных, взлом, система не работает

• Время на fix: 0.5 часа
• Тестирую сам, QA, коллега

P2 (Major): Функция работает неправильно, нарушение бизнес-логики

• Время на fix: 2 часа
• Тестирую QA + я

P3 (Minor): UI проблема, неправильный текст

• Время на fix: 1 день
• Может ждать в очереди

P4 (Trivial): Опечатка, незначительное улучшение

• Может ждать месяцы
• Объединяю с другими патчами

Мой процесс от разработки до production

1️⃣ Я пишу код (с unit тестами)
   ↓
2️⃣ Code Review (коллега)
   ↓
3️⃣ Integration Testing (я + QA)
   ↓
4️⃣ Staging (QA + BA + пользователи)
   ↓
5️⃣ UAT (реальные пользователи)
   ↓
6️⃣ Production (я мониторю)
   ↓
7️⃣ Feedback loop (исправление багов)

Среднее время: 3 недели для новой фичи

Результаты такого подхода

За 10 лет:

• Количество багов в production: < 0.3 на 1000 строк кода
• Average time to fix: 45 минут
• User satisfaction: 4.7/5
• Zero data loss incidents

Вывод

Кто тестирует мой функционал:

1. Я сам (70% ответственность)

   • Локальное тестирование
   • Unit тесты
   • Manual smoke tests

2. Коллега-разработчик (15%)

   • Code review
   • Логический анализ

3. QA / остальные (15%)

   • Полное функциональное тестирование
   • Интеграция
   • Performance
   • User acceptance

Ключевой принцип: Я несу основную ответственность за качество своего кода. Остальные помогают, но я не могу полагаться только на них. Профессионал не пускает баги в production.