Как действовать, если нет спецификации или документации?

Question

deepseek-v3.2 · Accepted Answer

## Стратегия работы при отсутствии документации

Отсутствие спецификации — частая реальность в Agile-среде и стартапах. Моя стратегия строится на **проактивном восстановлении контекста и создании "живой" документации** через тестирование.

### Поэтапный план действий

**1. Экспертный анализ и реверс-инжиниринг**
- Изучаю рабочее приложение, если оно уже существует, или максимально близкий аналог.
- Использую инструменты браузера (DevTools) для анализа сетевых запросов, структуры DOM, localStorage.
- Для API применяю сниффинг трафика (Charles Proxy, Fiddler) или инспекцию клиентского кода.
```javascript
// Пример: анализ возможных состояний через консоль браузера
// Получение всех обработчиков событий на элементе
getEventListeners(document.getElementById('userButton'));
// Просмотр всех отправляемых XHR-запросов
console.log(window.performance.getEntriesByType('resource'));
```

**2. Активное вовлечение стейкхолдеров**
- Организую **специальные уточняющие сессии** с продукт-менеджером, разработчиками и поддержкой.
- Использую технику **5 Whys ("Пять почему")** для выявления истинных ожиданий бизнеса.
- Фиксирую все допущения в формате **Shared Understanding Document** (доступного всем участникам).

**3. Эвристическое и исследовательское тестирование**
- Запускаю сессии **исследовательского тестирования** по методикам Джеймса Уиттакера.
- Применяю **техники тест-дизайна без требований**:
  - **Классы эквивалентности** на основе наблюдений за системой
  - **Анализ граничных значений** через эксперименты
  - **Тестирование по чек-листам** (Happy Path, CRUD, негативные сценарии)
  - **Метод персонажей** — как разные пользователи будут взаимодействовать

**4. Создание документации через тесты**
- Использую **тесты как документацию** — пишу сценарии на Gherkin (BDD), которые становятся источником истины.
- Автоматизирую ключевые пользовательские потоки — **автотесты фиксируют текущее поведение** системы.
```python
# Пример BDD-теста на Behave как документации
Feature: User registration
  Scenario: Successful registration with valid email
    Given I am on registration page
    When I enter "valid_user@domain.com" in email field
    And I click "Register" button
    Then I should see confirmation message
    And welcome email should be sent
```

**5. Постоянная валидация и коммуникация рисков**
- Создаю **карту рисков** — визуализирую, какие модули наименее понятны и наиболее критичны.
- Регулярно (раз в день/спринт) делюсь **чек-листом обнаруженных неопределенностей**.
- Ввожу практику **парного тестирования** с разработчиками для немедленного уточнения.

### Критические принципы при работе "вслепую"

1. **Никогда не предполагать — всегда проверять** — каждое допущение должно быть подтверждено экспериментом
2. **Документировать все находки** — даже отрицательные результаты (что система НЕ делает) ценны
3. **Тестировать от общего к частному** — сначала основной поток, затем крайние случаи
4. **Использовать как можно больше источников данных**:
   - Коммиты и тикеты в Jira/Git
   - Логи сервера и мониторинга
   - Общение с техподдержкой и конечными пользователями

### Коммуникационные аспекты

Я всегда четко сообщаю о **рисках, вызванных отсутствием документации**:
- Увеличение времени на тестирование на 30-50%
- Высокая вероятность пропуска edge-кейсов
- Возможные разночтения в ожидаемом поведении

**Итоговая философия**: Отсутствие документации — не препятствие, а возможность построить более релевантные и практичные артефакты тестирования. Я превращаю этот недостаток в преимущество, создавая **живую, тестируемую спецификацию**, которая часто оказывается точнее формальных документов, устаревающих сразу после написания.

Как действовать, если нет спецификации или документации?

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

Стратегия работы при отсутствии документации

Поэтапный план действий

Критические принципы при работе "вслепую"

Коммуникационные аспекты