Shift-Left Тестирование: Ранняя Интеграция Качества для Экономии Затрат

## Дефект Логики Аутентификации

### Сценарий 1: Найден Во Время Обзора Требований (Shift-Left)
- **Обнаружение**: Бизнес-аналитик замечает что требование login не указывает таймаут сессии
- **Исправление**: Добавить требование таймаута в спецификацию (30 минут)
- **Стоимость**: 30 минут × $50/час = $25
- **Влияние**: Нет, требование уточнено до реализации

### Сценарий 2: Найден Во Время Продакшна (Традиционный)
- **Обнаружение**: Клиент сообщает что остаются залогиненными бесконечно, проблема безопасности
- **Расследование**: 4 часа времени разработчика на идентификацию первопричины
- **Исправление**: 8 часов на реализацию управления сессиями
- **Тестирование**: 12 часов полного регрессионного тестирования
- **Развёртывание**: Экстренный релиз, 2 часа координации
- **Влияние на клиентов**: Уязвимость безопасности, недовольные клиенты
- **Стоимость**: 26 часов × $75/час + ущерб репутации = $1,950+

**Экономия с Shift-Left: Снижение стоимости в 77 раз**

# Калькулятор стоимости дефектов на основе фазы обнаружения

def rasschitat_stoimost_defekta(bazovaya_stoimost, faza_obnaruzheniya):
    """
    Рассчитать стоимость дефекта на основе того когда он обнаружен

    Args:
        bazovaya_stoimost: Стоимость если найден во время требований (базовая линия)
        faza_obnaruzheniya: Фаза где дефект был обнаружен

    Returns:
        Общая стоимость исправления дефекта
    """
    mnozhiteli_stoimosti = {
        'trebovaniya': 1,
        'dizajn': 5,
        'razrabotka': 10,
        'testirovanie': 25,
        'prodakshn': 100
    }

    mnozhitel = mnozhiteli_stoimosti.get(faza_obnaruzheniya, 100)
    obshchaya_stoimost = bazovaya_stoimost * mnozhitel

    return {
        'faza': faza_obnaruzheniya,
        'mnozhitel': f"{mnozhitel}x",
        'obshchaya_stoimost': obshchaya_stoimost,
        'dopolnitelnaya_stoimost': obshchaya_stoimost - bazovaya_stoimost
    }

# Пример: Дефект требования безопасности
bazovaya_stoimost = 50  # $50 для исправления во время требований

for faza in ['trebovaniya', 'dizajn', 'razrabotka', 'testirovanie', 'prodakshn']:
    rezultat = rasschitat_stoimost_defekta(bazovaya_stoimost, faza)
    print(f"{rezultat['faza'].capitalize()}: {rezultat['mnozhitel']} = ${rezultat['obshchaya_stoimost']}")

# Вывод:
# Trebovaniya: 1x = $50
# Dizajn: 5x = $250
# Razrabotka: 10x = $500
# Testirovanie: 25x = $1250
# Prodakshn: 100x = $5000

## Обзор Тестируемости Требований

### Ясность
- [ ] Требование однозначно (возможна только одна интерпретация)
- [ ] Нет расплывчатых терминов как "быстро", "удобно", "приблизительно"
- [ ] Определены конкретные критерии приёмки

### Полнота
- [ ] Все входы указаны
- [ ] Все выходы определены
- [ ] Покрыты сценарии ошибок
- [ ] Установлены ожидания по производительности

### Тестируемость
- [ ] Описано наблюдаемое поведение
- [ ] Измеримые критерии успеха
- [ ] Ясны требования к тестовым данным
- [ ] Идентифицированы зависимости

### Согласованность
- [ ] Нет конфликтов с другими требованиями
- [ ] Терминология согласована повсюду
- [ ] Приоритет выровнен с бизнес-целями

## Плохое Требование (Не Тестируемое)
"Система должна быстро отвечать на запросы пользователей"

**Проблемы:**
- "Быстро" субъективно и неизмеримо
- Не идентифицированы конкретные запросы пользователей
- Нет критериев приёмки

## Хорошее Требование (Тестируемое)
"Система должна возвращать результаты поиска в течение 2 секунд для 95% запросов
когда база данных содержит до 1 миллиона продуктов, измерено на 95-м перцентиле
во время пиковой нагрузки (1000 одновременных пользователей)"

**Производные Тест-Кейсы:**
1. Поиск со 100K продуктов: время отклика < 2с (95% запросов)
2. Поиск с 1M продуктов: время отклика < 2с (95% запросов)
3. Load test: 1000 одновременных пользователей, проверить 95-й перцентиль < 2с
4. Граничный случай: Поиск превышающий 2с должен всё равно успешно завершиться

## Обзор Тестируемости Архитектуры

### Модульность
- [ ] Компоненты имеют хорошо определённые интерфейсы
- [ ] Зависимости явные и минимальные
- [ ] Каждый компонент имеет единую, чёткую ответственность

### Наблюдаемость
- [ ] Фреймворк логирования на месте
- [ ] Метрики и мониторинг запланированы
- [ ] Состояния ошибок видимы и различимы

### Контролируемость
- [ ] Тестовые данные могут быть инжектированы
- [ ] Внешние зависимости могут быть замоканы/заглушены
- [ ] Состояние может быть настроено программно

### Дружественность к Автоматизации
- [ ] API спроектированы для автоматизированного тестирования
- [ ] База данных доступна для настройки тестовых данных
- [ ] Конфигурация может быть изменена для тестирования

# Плохой Дизайн: Сложно тестировать
class ObrabotchikPlatezheJ:
    def obrabotit_platezh(self, summa, nomer_karty):
        # Напрямую вызывает внешний платёжный gateway
        otvet = VneshnijPlatezhnyjGateway.snyat(summa, nomer_karty)

        # Хардкоженный продакшн эндпоинт
        self.otpravit_chek('https://api.production.com/send-email', otvet)

        # Нет способа проверить без реальных списаний
        return otvet

# Хороший Дизайн: Тестируемый
class ObrabotchikPlatezheJ:
    def __init__(self, platezhnyi_gateway, servis_uvedomlenij):
        # Внедрение зависимостей позволяет тестовые дублёры
        self.platezhnyi_gateway = platezhnyi_gateway
        self.servis_uvedomlenij = servis_uvedomlenij

    def obrabotit_platezh(self, summa, nomer_karty):
        # Использует инжектированный gateway (может быть замокан в тестах)
        otvet = self.platezhnyi_gateway.snyat(summa, nomer_karty)

        # Использует инжектированный сервис уведомлений (можно верифицировать вызовы)
        self.servis_uvedomlenij.otpravit_chek(otvet)

        return otvet

# Пример теста
def test_uspeshnogo_platezha():
    # Arrange: Создать тестовые дублёры
    mock_gateway = MockPlatezhnyjGateway()
    mock_uvedomleniya = MockServisUvedomlenij()
    obrabotchik = ObrabotchikPlatezheJ(mock_gateway, mock_uvedomleniya)

    # Act
    rezultat = obrabotchik.obrabotit_platezh(100.00, "4111111111111111")

    # Assert
    assert rezultat.uspeh == True
    assert mock_gateway.snyatie_vyzvano_s(100.00, "4111111111111111")
    assert mock_uvedomleniya.chek_otvpavlen == True

# Шаг 1: КРАСНЫЙ - Написать падающий тест
import pytest

def test_pustaya_korzina_imeet_nuljevoy_total():
    korzina = KorzinaPokupok()
    assert korzina.total() == 0

# Запуск теста: ПАДАЕТ - KorzinaPokupok ещё не существует

# Шаг 2: ЗЕЛЁНЫЙ - Минимальный код для прохождения
class KorzinaPokupok:
    def total(self):
        return 0

# Запуск теста: ПРОХОДИТ

# Шаг 3: КРАСНЫЙ - Следующий тест
def test_korzina_s_odnim_tovarom():
    korzina = KorzinaPokupok()
    korzina.dobavit_tovar(Produkt("Kniga", 15.99))
    assert korzina.total() == 15.99

# Запуск теста: ПАДАЕТ - dobavit_tovar не существует

# Шаг 4: ЗЕЛЁНЫЙ - Реализовать dobavit_tovar
class KorzinaPokupok:
    def __init__(self):
        self.tovary = []

    def dobavit_tovar(self, produkt):
        self.tovary.append(produkt)

    def total(self):
        return sum(item.tsena for item in self.tovary)

class Produkt:
    def __init__(self, nazvanie, tsena):
        self.nazvanie = nazvanie
        self.tsena = tsena

# Запуск тестов: ПРОХОДИТ (оба теста)

# Шаг 5: КРАСНЫЙ - Тест с множественными товарами
def test_korzina_s_mnozhestvenymi_tovarami():
    korzina = KorzinaPokupok()
    korzina.dobavit_tovar(Produkt("Kniga", 15.99))
    korzina.dobavit_tovar(Produkt("Ruchka", 2.50))
    korzina.dobavit_tovar(Produkt("Tetrad", 5.99))
    assert korzina.total() == 24.48

# Запуск тестов: ПРОХОДИТ (все тесты, не нужен новый код)

# Шаг 6: РЕФАКТОРИНГ - Извлечь логику расчёта
class KorzinaPokupok:
    def __init__(self):
        self.tovary = []

    def dobavit_tovar(self, produkt):
        self.tovary.append(produkt)

    def total(self):
        return self._rasschitat_total()

    def _rasschitat_total(self):
        """Рассчитать сумму всех цен товаров"""
        return sum(item.tsena for item in self.tovary)

# Запуск тестов: ПРОХОДИТ (рефакторинг сохранил поведение)

Feature: Вход Пользователя
  Как зарегистрированный пользователь
  Я хочу войти в свой аккаунт
  Чтобы получить доступ к персонализированным функциям

  Scenario: Успешный вход с валидными учётными данными
    Given я на странице входа
    And у меня есть валидный аккаунт с логином "ivan@primer.com"
    When я ввожу логин "ivan@primer.com"
    And я ввожу пароль "BezopasnyParol123"
    And я нажимаю кнопку "Войти"
    Then я должен быть перенаправлен на dashboard
    And я должен видеть "Добро пожаловать, Иван"

  Scenario: Неудачный вход с неправильным паролем
    Given я на странице входа
    And у меня есть аккаунт с логином "ivan@primer.com"
    When я ввожу логин "ivan@primer.com"
    And я ввожу пароль "NepravilnyParol"
    And я нажимаю кнопку "Войти"
    Then я должен остаться на странице входа
    And я должен видеть сообщение об ошибке "Неверный логин или пароль"
    And поле пароля должно быть очищено

  Scenario: Блокировка аккаунта после множественных неудачных попыток
    Given я на странице входа
    And у меня есть аккаунт с логином "ivan@primer.com"
    When я ввожу логин "ivan@primer.com"
    And я ввожу неправильный пароль 5 раз
    Then мой аккаунт должен быть заблокирован
    And я должен видеть "Аккаунт заблокирован. Пожалуйста, сбросьте пароль"
    And я не должен иметь возможность войти даже с правильным паролем

# features/steps/login_steps.py

from behave import given, when, then

@given('я на странице входа')
def step_perejti_na_vhod(context):
    context.browser.get('https://primer.com/login')

@given('у меня есть валидный аккаунт с логином "{login}"')
def step_sozdat_testovogo_polzovatelya(context, login):
    context.testovyj_polzovatel = sozdat_polzovatelya(login, "BezopasnyParol123")

@when('я ввожу логин "{login}"')
def step_vvesti_login(context, login):
    pole_login = context.browser.find_element_by_id('login')
    pole_login.send_keys(login)

@when('я ввожу пароль "{parol}"')
def step_vvesti_parol(context, parol):
    pole_parol = context.browser.find_element_by_id('parol')
    pole_parol.send_keys(parol)

@when('я нажимаю кнопку "{tekst_knopki}"')
def step_klik_knopki(context, tekst_knopki):
    knopka = context.browser.find_element_by_xpath(f"//button[text()='{tekst_knopki}']")
    knopka.click()

@then('я должен быть перенаправлен на dashboard')
def step_proverit_dashboard(context):
    assert context.browser.current_url == 'https://primer.com/dashboard'

@then('я должен видеть "{tekst}"')
def step_proverit_tekst_viden(context, tekst):
    assert tekst in context.browser.page_source

# Python: Pylint, Flake8, mypy
pylint moy_modul.py
flake8 moy_modul.py --max-line-length=100
mypy moy_modul.py --strict

# JavaScript: ESLint, TSLint
eslint src/**/*.js
tslint src/**/*.ts

# Java: SonarQube, Checkstyle, SpotBugs
sonar-scanner

# Сканирование безопасности
bandit -r ./src  # Проблемы безопасности Python
npm audit        # Уязвимости зависимостей JavaScript

## Области Фокуса Обзора Кода

### Функциональность
- [ ] Код корректно реализует требование
- [ ] Граничные случаи обработаны
- [ ] Реализована обработка ошибок
- [ ] Присутствует валидация входных данных

### Тестирование
- [ ] Включены юнит-тесты
- [ ] Покрытие тестами адекватное (>80%)
- [ ] Тесты проверяют граничные случаи
- [ ] Интеграционные тесты для внешних зависимостей

### Безопасность
- [ ] Нет хардкоженных учётных данных
- [ ] Входные данные санитизированы для предотвращения инъекций
- [ ] Применена аутентификация/авторизация
- [ ] Чувствительные данные зашифрованы

### Производительность
- [ ] Нет очевидных узких мест производительности
- [ ] Запросы к БД оптимизированы
- [ ] Используется соответствующий кеш
- [ ] Очистка ресурсов (соединения, файлы)

### Сопровождаемость
- [ ] Код читаем и самодокументирующийся
- [ ] Функции/методы имеют единую ответственность
- [ ] Нет дублирования кода
- [ ] Комментарии объясняют "почему" не "что"

## Оценка Готовности к Shift-Left

### Когда обнаруживаются дефекты?
- [ ] Фаза требований: ____%
- [ ] Фаза дизайна: ____%
- [ ] Разработка: ____%
- [ ] QA тестирование: ____%
- [ ] Продакшн: ____%

**Цель: Увеличить обнаружение на ранней фазе (требования, дизайн, разработка)**

### Участвуют ли тестировщики рано?
- [ ] Обзоры требований: Да / Нет
- [ ] Обзоры дизайна: Да / Нет
- [ ] Sprint планирование: Да / Нет
- [ ] Daily standups: Да / Нет

**Цель: Тестировщики вовлечены с начала проекта**

### Автоматизация на месте?
- [ ] Покрытие юнит-тестами: ____%
- [ ] Покрытие интеграционными тестами: ____%
- [ ] Автоматизированные приёмочные тесты: Да / Нет
- [ ] CI/CD пайплайн: Да / Нет

**Цель: Высокая автоматизация для непрерывного тестирования**

### Уровень коллаборации команды?
- [ ] Разработчики и тестировщики работают в одной команде: Да / Нет
- [ ] Общая ответственность за качество: Да / Нет
- [ ] Сессии обмена знаниями: Да / Нет

**Цель: Культура совместной команды**

## Фаза 1: Немедленные Действия (Неделя 1-2)

1. **Включить тестировщиков в планирование**
   - Пригласить QA на обсуждения требований
   - Пересматривать пользовательские истории вместе
   - Определять критерии приёмки совместно

2. **Внедрить чеклист требований**
   - Использовать чеклист тестируемости для каждого требования
   - Отклонять неясные или нетестируемые требования
   - Явно документировать предположения

3. **Начать обзоры кода**
   - Требовать peer review для всего кода
   - Включить обзор тестов в обзор кода
   - Делиться чеклистом обзора кода

## Фаза 2: Построить Фундамент (Месяц 1-2)

1. **Ввести TDD для новых функций**
   - Начать с простых компонентов
   - Парное программирование для изучения TDD
   - Отслеживать метрики покрытия тестами

2. **Автоматизировать критические пути**
   - Идентифицировать топ-10 пользовательских путей
   - Написать автоматизированные тесты для этих путей
   - Запускать в CI/CD пайплайне

3. **Процесс обзора дизайна**
   - Планировать обзоры дизайна перед кодированием
   - Использовать чеклист тестируемости
   - Вовлекать QA в архитектурные решения

## Фаза 3: Масштабировать и Развивать (Месяц 3-6)

1. **Расширить принятие TDD**
   - TDD для всего нового кода
   - Рефакторить legacy код с тестами
   - Обучение TDD для всех разработчиков

2. **Внедрить BDD**
   - Определить сценарии для новых функций
   - Автоматизировать BDD сценарии
   - Использовать сценарии для валидации требований

3. **Непрерывное улучшение**
   - Анализировать метрики фазы обнаружения дефектов
   - Ретроспективы по прогрессу shift-left
   - Корректировать практики на основе обучения