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

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

Отсутствие формальной документации — распространённая ситуация в agile-средах. Это не катастрофа, а вызов, требующий адаптивного подхода и проактивных техник. Строить работу можно через комбинацию исследовательского тестирования, анализа существующих артефактов и налаживания коммуникаций.

Основные этапы работы без документации

1. Разведка и контекстный анализ

Первым делом изучаю всё доступное:

• Работающее приложение (продукт): Самый главный артефакт. Тестирую его как конечный пользователь, чтобы понять базовую функциональность, бизнес-логику и пользовательские сценарии.
• Исходный код: Если есть доступ (в роли QA Automation или в доверительной среде), анализ кода, особенно модульных тестов и комментариев, даёт бесценные сведения о предполагаемом поведении системы.
• Коммиты и история изменений: Просмотр git log помогает понять эволюцию фичи.

git log --oneline -n 20 -- path/to/feature/

• Коммуникации: Письма, задачи в Jira, комментарии в Confluence, переписка в Slack — всё может содержать ключевые требования и решения.

2. Активная коммуникация с триангуляцией источников

Поскольку нет "истины в документе", приходится её выяснять у людей, но важно перепроверять информацию.

• Главные источники: Продуктовый владелец (PO) или бизнес-аналитик для понимания "зачем" и бизнес-ценности.
• Ключевые эксперты: Разработчики (особенно архитектор и тимлид) для понимания "как" работает система, ограничений и технических рисков.
• Техника "Трёх Ампер": Задаю один и тот же вопрос разным людям (PO, dev, другой QA) и сравниваю ответы. Расхождения выявляют "серые зоны", требующие уточнения.

3. Эксплораторное и эвристическое тестирование

Это становится основным инструментом. Использую структурированные подходы:

• Сценарное тестирование: Составляю сценарии от лица пользователя на основе анализа из п.1.
• Применение эвристик: Системы правил, такие как SFDPOT (Structure, Function, Data, Platform, Operations, Time) или MFCP (Модели, Функции, Компоненты, Платформы) для систематического осмотра приложения.
• Техника "Мысленная карта" (Mind Map): Быстро фиксирую функциональность, связи, вопросы и риски в виде диаграммы. Это становится "живой документацией" на время тестирования.
• Парное тестирование (Mob/Pair Testing): Тестирую вместе с разработчиком или другим QA. Это мгновенно закрывает вопросы по ожидаемому поведению и в разы увеличивает эффективность.

4. Создание документации "на лету"

Чтобы не терять знания и задавать вопросы по делу, сразу начинаю создавать артефакты:

• Чек-листы и конспекты: В простом .md-файле или прямо в задаче фиксирую ключевые сценарии, найденные дефекты, вопросы и полученные ответы.
• Быстрые скринкасты: Запись короткого видео, демонстрирующего баг или неочевидное поведение, часто эффективнее длинного описания.
• Тест-кейсы постфактум: После того как поведение стало понятным и проверенным, можно задокументировать его в виде тест-кейса для регресса.

Пример: Практический алгоритм действий

Допустим, поступила задача на тестирование новой кнопки "Экспорт в PDF".

1. Анализ:

    *   Запускаю приложение, нахожу кнопку.
    *   Смотрю задачу в Jira: есть ли там комментарии разработчика о реализованных случаях?
    *   Ищу в репозитории файлы, связанные с `export` или `pdf`.

1. Уточнение (если в задаче ничего нет):

    *   Пишу в общий чат команды: "@dev_Имя, @PO_Имя, по задаче TEST-123. Кнопка 'Экспорт в PDF' готова к проверке. Для начала тестирования мне нужно понять: 1) Какие данные должны экспортироваться (все поля таблицы или выбранные)? 2) Есть ли ограничения по количеству строк? 3) В каком формате ожидаем даты и суммы?"
    *   Ответы фиксирую прямо в комментариях к задаче.

1. Тестирование:

    *   Использую чек-лист, созданный на основе ответов.
    *   Проверяю позитивные сценарии (выбор данных -> нажатие -> получение PDF).
    *   Применяю эвристики: что если таблица пуста? Что если выбрать 10 000 строк? Что если во время генерации сменить язык? (**Тестирование на временные и нагрузочные аномалии**).
    *   Изучаю полученный PDF (полнота данных, форматирование, корректность кириллицы).

1. Фиксация результатов:

    *   Найденные баги оформляю с четкими шагами, данными и скриншотами/видео.
    *   Уточняю у разработчика, является ли найденное поведение багом или "так и задумано".
    *   Дополняю описание задачи итогами тестирования и создаю в тест-менеджменте простой чек-лист "Экспорт в PDF" для будущего регрессионного тестирования.

Ключевые принципы и выводы

• Сдвиг парадигмы: Из "тестирования на соответствие документации" к "тестированию на исследование и выявление рисков".
• Проактивность: QA становится активным детективом и коммуникатором, а не пассивным проверяльщиком.
• Прозрачность: Все действия, вопросы и находки должны быть максимально видимыми для команды (комментарии в задачах, сообщения в чатах).
• Фокус на ценности: Главный вопрос — "Несёт ли эта функция ценность пользователю и работает ли она без критических сбоев?", а не "Соответствует ли она неизвестному требованию?".

Итог: Работа без документации развивает наиболее важные навыки QA — аналитическое мышление, коммуникацию и способность быстро обучаться. Она делает тестирование более интеллектуальным и приближенным к реальному пользовательскому опыту, где также нет инструкций. Успех зависит от умения добывать информацию, структурировать её и эффективно доносить найденные риски до команды.