Как начать тестирование если нет документации

Как подходить к тестированию без документации

Отсутствие документации — распространённая, хотя и нежелательная, ситуация в реальных проектах. Мой подход основан на принципе «тестирование — это исследование», и в таких условиях особенно важны исследовательское тестирование и адаптивность.

Ключевые шаги и стратегии

1. Немедленный старт через исследование (Exploratory Testing)

    *   Не жду документов, а начинаю взаимодействовать с продуктом как пользователь. Для веб-приложения это означает:
        *   Навигация по всем видимым интерфейсам.
        *   Составление **ментальной карты (mind map)** или блок-схемы основных модулей и их связей.
        *   Фиксация всех найденных экранов, кнопок, форм в простом документе (например, в Confluence или даже в текстовом файле).

1. Поиск и анализ любых доступных артефактов

    Даже если нет формальной спецификации, ищу:
    *   **Коммиты и тикеты в трекере (Jira, Git):** Описание задач разработчика часто содержит ключевую логику.
    *   **Письма и сообщения в чатах (Slack, Teams):** Обсуждения между продакт-менеджером и командой.
    *   **Рабочую версию продукта (production или staging):** Самый точный «документ». Сравниваю поведение новой версии с текущей.
    *   **Тесты разработчиков (Unit, Integration):** Просмотр кода тестов помогает понять ожидаемое поведение модулей.

1. Активное взаимодействие с командой

    *   **Разработчики:** «Я вижу здесь поле ввода. Какие валидные данные оно ожидает? Какие основные сценарии обработки?»
    *   **Продакт-менеджер или владелец продукта:** «Какова основная цель этого раздела? Кто ключевой пользователь и что он хочет здесь сделать?»
    *   **Технические специалисты:** Запросы к базе данных или API через инструменты вроде **Postman** или **Swagger** (если есть), чтобы понять контракты данных.

Практические техники и примеры

• Реверс-инжиниринг через API:

    Часто API более стабильны и информативны, чем UI. Я анализирую сетевые запросы в DevTools браузера (`F12 -> Вкладка Network`) и воспроизвожу их в Postman, чтобы понять модель данных и бизнес-правила.

```javascript
// Пример: анализ ответа API для понимания структуры данных пользователя
// Ответ на GET /api/v1/user/123
{
  "id": 123,
  "email": "user@example.com",
  "subscription": {
    "type": "premium",
    "expires_at": "2024-12-31",
    // Поле "active" отсутствует. Значит, статус, вероятно, вычисляется на основе даты.
    // Это важно для тестирования сценариев истечения подписки.
  }
}
```

• Метод «Черного ящика» и техники тест-дизайна:

    Даже без знаний о внутреннем устройстве, применяю:
    *   **Эквивалентное разделение:** Предполагаю, что если поле принимает email, то все валидные email-адреса (класс эквивалентности) должны работать, а все не-email (другой класс) — вызывать ошибку.
    *   **Анализ граничных значений:** Для числового поля с видимым ограничением от 1 до 100 тестирую значения: 0, 1, 2, 99, 100, 101.
    *   **Тестирование состояний и переходов:** Составляю упрощенную диаграмму состояний. Например, для заказа: `Корзина -> Оформлен -> Оплачен -> Доставлен`. Тестирую каждый переход.

• Документирование «на лету»:

    В процессе исследования сам создаю документацию, которая станет основой для будущих тест-кейсов и для команды.

```
### Модуль: Регистрация пользователя
**Найденные поля:**
1. Email - обязательное, проверка на формат.
2. Пароль - обязательное, минимум 8 символов, требуется цифра и заглавная буква.
3. Подтверждение пароля - обязательное, должно совпадать с полем "Пароль".

**Наблюдаемое поведение:**
- При неверном email показывается сообщение "Введите корректный email".
- При слабом пароле - сообщение "Пароль слишком простой".
- Успешная регистрация перенаправляет на /dashboard.

**Неясности (вопросы к разработчику):**
- Есть ли ограничение на длину email?
- Блокируется ли повторная регистрация на один email?
```

Важные принципы и выводы

• Коммуникация важнее перфектной документации. Постоянный диалог с командой снижает риски недопонимания.
• Продукт — это и есть документация. Его поведение — главная истина.
• Я создаю артефакты тестирования в процессе. Мои заметки, чек-листы и баг-репорты со временем становятся ценным источником информации для всех.
• Фокусируюсь на рисках. Без спецификации легко утонуть в деталях. Задаю вопрос: «Что может сломать бизнес-логику или привести к потере данных?» Тестирую это в первую очередь.

Таким образом, отсутствие документации не блокирует начало тестирования, а смещает фокус на активное исследование, критическое мышление и усиленную коммуникацию. Этот подход часто приводит к более глубокому пониманию продукта и более эффективному выявлению серьезных дефектов, которые могли быть пропущены при формальном следовании спецификации.