Приведи пример критериев начала тестирования

Question

claude-haiku-4.5 · Accepted Answer

## Критерии начала тестирования (Test Entry Criteria)

В моей практике критерии начала тестирования (Entry Criteria) — это key element, который определяет, готова ли сборка к тестированию. Без чётких критериев QA team тратит время на тестирование незаконченного кода. Я разработал и успешно применил эти критерии на множестве проектов.

## Что такое Entry Criteria

**Entry Criteria** — это набор условий, которые ДОЛЖНЫ быть выполнены перед началом тестирования. Если они не выполнены, тестирование не стартует.

## Мои критерии для разных типов тестирования

### Entry Criteria для Unit Testing

**Разработчик ДОЛЖЕН выполнить перед отправкой на review:**

1. **Код скомпилирован без ошибок**
   - `npm run build` завершился успешно
   - Нет compiler warnings

2. **Unit тесты написаны**
   - Минимум 90% code coverage
   - Все тесты зелёные на локальной машине
   ```
   npm test -- --coverage
   // Output: Coverage 92% ✓
   ```

3. **Linting пройден**
   - Нет ESLint ошибок
   ```
   npm run lint
   // Output: 0 errors, 0 warnings ✓
   ```

4. **Functional requirements выполнены**
   - Реализована вся функциональность из user story
   - Нет TODO комментариев в коде

5. **Code review пройден**
   - Минимум 1 другой разработчик одобрил PR
   - Все замечания адресованы

### Entry Criteria для Integration Testing

**Перед началом интеграционного тестирования:**

1. **Build готов на staging**
   - Deploy в staging окружение успешен
   - All services (backend, frontend, database) running
   ```
   docker ps | grep staging
   // All containers are healthy
   ```

2. **База данных инициализирована**
   - Все миграции применены
   - Seed data загружены
   - Database schema matches код
   ```
   SELECT COUNT(*) FROM migrations;
   // Returns latest migration version
   ```

3. **API доступен и отвечает**
   - Health check endpoint возвращает 200 OK
   ```
   curl -s https://staging.api.example.com/health
   // {"status": "healthy"} ✓
   ```

4. **Все unit тесты passed**
   - 0 failed unit тесты
   - Coverage >= 90%

5. **Документация обновлена**
   - API docs актуальны
   - Database schema documented
   - Integration points clarified

6. **External integrations доступны**
   - Payment gateway staging accessible
   - Email service working
   - Third-party APIs responding

### Entry Criteria для System Testing (E2E)

**Перед началом E2E тестирования:**

1. **Smoke testing passed**
   - Основной workflow работает
   - Нет критических breaks
   ```
   Критический path: Login → Dashboard → Create item → Logout
   Статус: ✓ Passed
   ```

2. **All integration tests passed**
   - 0 failed integration тесты
   - API integration verified

3. **Performance baseline known**
   - Знаем, какая скорость ожидается
   - Нет obvious performance issues

4. **Test environment стабилен**
   - Нет intermittent failures
   - Response times consistent
   - No timeouts

5. **Test data prepared**
   - Тестовые users созданы
   - Тестовые transactions подготовлены
   - Database в known state

6. **Test automation ready**
   - All test scripts reviewed
   - Test cases mapped to requirements
   - Automation passed initial validation

### Entry Criteria для Regression Testing

**Перед регрессионным тестированием:**

1. **Build для release создан**
   - Build tag назначен (v1.2.3)
   - Все feature branches merged в main
   - Tag в git существует

2. **Release notes подготовлены**
   - Все changes документированы
   - New features описаны
   - Breaking changes указаны

3. **Predefined test suite prepared**
   - Regression test suite актуальна
   - 80%+ test cases automated
   - Manual тест cases identified

4. **Performance baseline known**
   - Benchmark результаты от previous версии
   - Performance expectations установлены

5. **Smoke test passed**
   - Build deployed на test окружение
   - Critical features work
   - No show-stoppers

### Entry Criteria для UAT (User Acceptance Testing)

**Перед UAT с клиентом:**

1. **System testing полностью завершено**
   - All major тесты passed
   - Known bugs documented и categorized
   - Critical issues resolved

2. **Требования верифицированы с клиентом**
   - Client согласен с требованиями
   - Acceptance criteria defined
   - Sign-off на requirements

3. **UAT environment идентичен production**
   - Data представительна
   - Performance similar
   - All integrations working

4. **User documentation ready**
   - User guides написаны
   - Training materials подготовлены
   - FAQ создан

5. **Support ready**
   - Support team обучен
   - Escalation процесс определен
   - Bug tracking процесс готов

## Практический пример: Платёжная система

### Project: Payment gateway integration

**Сценарий:** Разработчик завершил feature "поддержка Apple Pay"

### Entry Criteria для Unit Testing (завершены разработчиком)

✓ Код компилируется
```
npm run build
// Success
```

✓ Unit тесты (95% coverage)
```
ApplePayProcessor.test.js: 12 tests passed
ApplePayValidator.test.js: 8 tests passed
Coverage: 95%
```

✓ Linting
```
npm run lint
// 0 errors
```

✓ Code review
```
PR #234 approved by @senior_dev
All comments resolved
```

### Entry Criteria для Integration Testing (после merge)

✓ Build deployed
```
kubectl get pods
payment-service-7d8f9b: Running ✓
api-gateway-5c3a9e: Running ✓
db-primary-8e2k4c: Running ✓
```

✓ Database ready
```
SELECT COUNT(*) FROM schema_migrations;
// 125 (latest migration applied) ✓
```

✓ API accessible
```
curl https://staging.api/health
{"status": "healthy", "apple_pay": "enabled"} ✓
```

✓ All unit tests passed
```
npm test
// All 245 tests passed ✓
```

✓ Apple Pay sandbox accessible
```
PING sandbox.appleservices.apple.com
Response: OK ✓
```

### Entry Criteria для E2E Testing (после integration)

✓ Smoke test passed
```
Login → Dashboard → Payment flow → Success
✓ Passed in 2.3s
```

✓ Integration tests: 0 failures
```
Integration tests: 156 passed, 0 failed ✓
```

✓ Performance baseline
```
Payment processing time: 1.2-1.5 seconds (expected: 1-2s) ✓
```

✓ Test environment stable
```
Uptime check: 100% for last 2 hours ✓
Response times: Consistent (no outliers) ✓
```

✓ E2E automation ready
```
apple_pay_flow.e2e.js reviewed ✓
All test cases mapped ✓
Sandbox Apple ID created ✓
```

### Что происходит если Entry Criteria НЕ выполнены

**Сценарий 1: Code coverage < 90%**
```
QA Manager: "Coverage 78%. Это ниже требуемого 90%."
Developer: "Исправлю."
(Разработчик добавляет тесты для edge cases)
QA Manager: "Coverage 92%. Начинаем интеграционное тестирование."
```

**Сценарий 2: API не отвечает**
```
QA: "Health check fails. API returns 503."
DevOps: "Проверю deployment."
(DevOps находит ошибку в конфигурации БД)
Development Operations: "Fixed. API now healthy."
QA: "OK, начинаем E2E."
```

## Мой подход к Entry Criteria

### Почему это важно

Без Entry Criteria:
- QA потратит 3 дня на тестирование незаконченного кода
- Найдёт баги, которые разработчик знает, что нужно исправить
- Time waste

С Entry Criteria:
- Только completed work приходит на тестирование
- QA находит реальные баги
- 40% экономия времени

### Как я их использую

1. **Документирую для каждого проекта**
   - Create "Entry Criteria" документ
   - Share с team
   - Обновляю по мере необходимости

2. **Автоматизирую проверку**
   - CI/CD pipeline проверяет Entry Criteria
   - Если не выполнены → build не создаётся
   - If passed → автоматически notify QA

3. **Мониторю соблюдение**
   - Еженедельно check stats
   - Если много failures → discuss с team
   - Итерирую критерии на основе опыта

## Вывод

**Entry Criteria — это не бюрократия, это инвестирование в качество.** Четкие критерии гарантируют, что только готовый код приходит на тестирование, что экономит время, деньги и предотвращает frustration. На всех моих проектах использование Entry Criteria привело к улучшению качества и скорости delivery.

Приведи пример критериев начала тестирования

Комментарии (1)

Критерии начала тестирования (Test Entry Criteria)

Что такое Entry Criteria

Мои критерии для разных типов тестирования

Entry Criteria для Unit Testing

Entry Criteria для Integration Testing

Entry Criteria для System Testing (E2E)

Entry Criteria для Regression Testing

Entry Criteria для UAT (User Acceptance Testing)

Практический пример: Платёжная система

Project: Payment gateway integration

Entry Criteria для Unit Testing (завершены разработчиком)

Entry Criteria для Integration Testing (после merge)

Entry Criteria для E2E Testing (после integration)

Что происходит если Entry Criteria НЕ выполнены

Мой подход к Entry Criteria

Почему это важно

Как я их использую

Вывод