Когда использовал Automation?

Когда использовал Automation

Автоматизация тестирования — это core часть моей работы за последние 8+ лет. Расскажу, когда и как я её использую.

Когда Automation имеет смысл

1. Регрессионное тестирование

Использование: После каждого спринта/релиза

Почему автоматизировать:

• Тесты повторяются каждую неделю
• Ручное тестирование = 3-4 дня работы
• Автоматизированное = 15-20 минут
• Окупаемость: за 2 недели

Пример:

Проект: E-commerce платформа

Регрессионный test suite:
- Login flows (10 cases)
- Product browsing (20 cases)
- Cart operations (15 cases)
- Checkout flow (25 cases)
- Order tracking (10 cases)
Total: 80 test cases

Время:
- Ручное: 3-4 дня (QA в 8 часов работы)
- Автоматизированное: 20 минут CI/CD run

Частота:
- Каждый спринт (2 недели)
- После каждого релиза

Экономия за год: 200 часов = $20,000

2. Smoke testing

Использование: После каждой сборки (несколько раз в день)

Задача: Быстро проверить, что основной функционал работает

Почему автоматизировать:

• Нужно запускать часто
• Время критично (quick feedback)
• Результат быстро: 5-10 минут

Пример smoke tests:

1. Application starts
2. Login page loads
3. Can login with valid credentials
4. Dashboard loads
5. Can access main features
6. No JavaScript errors
7. Database connection works

3. Performance/Load testing

Использование: Перед каждым релизом

Почему автоматизировать:

• Невозможно сделать ручным
• Нужно симулировать 1000 concurrent users
• Нужно запускать под нагрузкой

Инструменты: JMeter, Locust, Artillery

Пример:

Тест: Можно ли API обработать 1000 RPS?

Вручную: Невозможно (нельзя кликать 1000 раз в секунду)

Автоматизированное:
locust -f tests/load_test.py -u 1000 -r 100 --run-time 5m

Результат:
- 1000 users
- Response time: avg 200ms, p95 500ms
- Success rate: 99.5%
- Recommendation: System OK for production

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

Использование: Постоянно (для каждой API версии)

Почему автоматизировать:

• API меняется часто
• Много endpoints (100+)
• Много edge cases
• Нужна воспроизводимость

Пример:

test_api.py:
  test_get_users() → GET /users
  test_create_user() → POST /users
  test_update_user() → PUT /users/{id}
  test_delete_user() → DELETE /users/{id}
  test_invalid_email() → 400 Bad Request
  test_unauthorized() → 401 Unauthorized
  test_pagination() → GET /users?page=2&limit=10
  
Каждый тест запускается автоматически

5. E2E критических путей

Использование: Перед релизом (critical workflows только)

Почему автоматизировать:

• Критические (покупка, платёж, сохранение данных)
• Часто меняются
• Много шагов (5-10 действий)
• Руками медленно и подвержено ошибкам

Пример: Payment flow

test('Complete payment flow', () => {
  // 1. Login
  cy.login('user@test.com', 'password')
  
  // 2. Add product to cart
  cy.visit('/products/123')
  cy.get('[data-testid="add-to-cart"]').click()
  
  // 3. Checkout
  cy.visit('/cart')
  cy.get('[data-testid="checkout"]').click()
  
  // 4. Enter shipping
  cy.get('[data-testid="address"]').type('123 Main St')
  cy.get('[data-testid="city"]').type('NYC')
  
  // 5. Enter payment
  cy.get('[data-testid="card-number"]').type('4242424242424242')
  cy.get('[data-testid="submit"]').click()
  
  // 6. Verify success
  cy.contains('Order confirmed').should('be.visible')
  cy.url().should('include', '/orders')
})

Когда НЕ использовать Automation

1. Exploratory testing

Ситуация: Нужно найти неожиданные баги

Почему не автоматизировать:

• Невозможно предсказать что тестировать
• Нужна творчество и интуиция
• Автомат может пропустить интересные scenarios

Пример:

QA: Попробаю случайные комбинации полей в форме
  - очень длинные значения
  - специальные символы
  - разные order fields
  - быстрые clicks
  
Найду: баги которые автомат бы не нашёл

2. UI/UX testing

Ситуация: Проверить дизайн, юзабилити

Почему сложно автоматизировать:

• Visual regression требует сравнения скриншотов
• Нужен человеческий взгляд
• UX зависит от контекста

Пример:

❌ Автоматизировать:
cy.visit('/home')
cy.screenshot() // Скриншот
compare(screenshot, baseline) // Сравнить

✓ Ручное:
Я вижу: кнопка слишком маленькая
Я вижу: выравнивание неправильное
Я вижу: цвета не соответствуют дизайну

3. Новые features (первый раз)

Ситуация: Feature только что разработана

Почему не сразу автоматизировать:

• Requirements могут меняться
• Автоматизация требует стабильности
• Лучше сначала протестировать ручью
• Потом переводить в автомат

Процесс:

День 1: Разработчик делает feature
День 1: QA тестирует вручную, находит баги
День 2: Разработчик исправляет
День 2: QA тестирует вручную, feature stable
День 3: QA автоматизирует тест
День 4+: Тест запускается автоматически

4. One-off tests

Ситуация: Нужно протестировать что-то один раз

Почему не автоматизировать:

• Overhead > benefit
• Время на написание > на ручное выполнение

Пример:

Need: Проверить совместимость с Internet Explorer 11
(браузер deprecated, почти никто не использует)

Оптимально: Ручной тест на одном компьютере (30 минут)

Не оптимально: Автоматизировать на всех браузерах (4 часа)

Процентное распределение Automation vs Manual

Свой опыт

Unit тесты: 100% автоматизированы
- Разработчики пишут при разработке
- Запускаются в CI/CD
- Быстрые (< 5 минут)

Integration тесты: 85% автоматизированы
- API testing
- Database testing
- Service integration
- ~15% complex scenarios ручьем

E2E тесты: 60% автоматизированы
- Critical paths: 100% автомат
- Happy path: 80% автомат
- Error paths: 40% автомат
- Edge cases: 20% автомат

Exploratory: 0% автоматизированы
- Только ручная работа
- 10-15 часов на спринт

Manual overall: 30-40% всего времени QA

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

             🧪 E2E (10%)
         ┌───────────────┐
         │ Cypress, Play │
         │ wright (slow) │
         └───────────────┘
             Integration (30%)
         ┌───────────────┐
         │ REST API test │
         │ ing, Service  │
         └───────────────┘
             Unit (60%)
         ┌───────────────┐
         │ Jest, pytest  │
         │ (fast, cheap) │
         └───────────────┘

По затратам:
- Unit: $1
- Integration: $5
- E2E: $25

По скорости:
- Unit: 1 сек
- Integration: 10 сек
- E2E: 1 минута

Мой workflow автоматизации

На каждый спринт

День 1-3: Разработка

• Разработчик пишет feature
• Разработчик пишет unit тесты (TDD)

День 2-4: QA тестирование

• QA тестирует вручную (exploratory)
• Находит баги, сообщает разработчику
• Разработчик исправляет
• QA автоматизирует critical tests

День 5: Финал

• Все регрессионные тесты запускаются в CI/CD
• Если падают → fix
• Ready для release

День 6-7: Maintenance

• Обновляю автоместы если UI изменилась
• Добавляю новые автоместы для баг-фиксов

Инструменты автоматизации которые использовал

Unit тестирование

• pytest (Python, основной)
• Jest (JavaScript, React)
• JUnit (Java)

E2E

• Cypress (5+ лет, основной)
• Playwright (2+ года, растущий)
• Selenium (8+ лет, legacy)

API

• pytest + requests
• REST Assured (Java)
• Postman (для быстрых тестов)

Load

• JMeter (3+ года)
• Locust (Python, newer)

Performance

• Lighthouse (для Lighthouse audits)
• WebPageTest (third-party)

ROI (Return on Investment)

Проект Payment Gateway

Инвестирование в автоматизацию:

Написание автотестов: 40 часов
$60/hour × 40 = $2,400

Framework setup: 16 часов = $960

CI/CD integration: 8 часов = $480

Total investment: $3,840

Экономия:

Регрессионный тест:
- Было: 16 часов / спринт (ручное) = $960 / спринт
- Стало: 0.5 часов / спринт (автомат) = $30 / спринт
- Экономия: $930 / спринт

Frequency: каждый спринт (2 недели)

3 месяца: $930 × 6 = $5,580 экономии
Окупаемость: 3 недели

12 месяцев: $930 × 26 = $24,180 экономии
Ratio: 24,180 / 3,840 = 6.3x ROI

Когда я решил автоматизировать

Правило 3x (если сделаю 3 раза — автоматизирую)

Если тест выполняется более 3 раз → автоматизирую

Примеры:
- Регрессионный тест: выполняется 26 раз в год → автоматизировать
- Payment flow: выполняется 3 раза в месяц → автоматизировать
- One-off test: выполняется 1 раз → не автоматизировать
- Feature test: выполняется 2 раза (до release) → может быть

Проблемы с автоматизацией

Problem 1: Flaky tests

Описание: Тесты иногда pass, иногда fail (50/50)

Причины:

• Race conditions
• Timing issues (sleep 5 sec вместо wait)
• Unstable environment

Решение:

• Использовать waitFor вместо setTimeout
• Изолировать от других тестов
• Использовать stable selectors

Problem 2: Maintenance burden

Описание: Когда UI меняется, 100+ тестов break

Причины:

• Hardcoded selectors (CSS classnames)
• Brittle tests (implementation detail)

Решение:

• Использовать data-testid (explicit)
• Page Object Model pattern
• Shared locators

Problem 3: Speed

Описание: E2E тесты очень долгие (1 час для 100 тестов)

Причины:

• UI slow (browser load time)
• Waiting for elements
• Database operations

Решение:

• Parallelization (запускать 10 тестов одновременно)
• Optimize slow operations
• Reduce test count (focus на critical paths)

Заключение

Автоматизация — это не all-or-nothing. Это strategic investment.

Когда использую автоматизацию:

• Регрессионные тесты (повторяется 3+ раза)
• Smoke tests (после каждой сборки)
• API tests (много endpoints)
• Performance tests (невозможно ручью)
• Critical paths (важны для бизнеса)

Когда НЕ использую:

• Exploratory (нужна творчество)
• UX (нужен человеческий взгляд)
• One-off tests (не окупается)
• Новые features (сначала ручью)

Мой опыт показал, что правильная автоматизация экономит 50-60% времени на тестирование и значительно улучшает качество. Но бездумная автоматизация всего — это трата времени и денег.