Исследовательская сессия и полезный баг-репорт
Отделите наблюдение от объяснения, сохраните контекст и передайте воспроизводимый дефект.
- Описывать цель и заметки исследовательской сессии.
- Собирать минимальный воспроизводимый пример.
- Различать влияние дефекта и порядок его исправления.
Исследование имеет цель и след
Исследовательское тестирование сочетает изучение системы, проектирование и выполнение следующих проверок на основе увиденного. Оно не означает беспорядочные нажатия. Хороший charter задаёт область, риск, ограничение времени и идеи наблюдений: «За 20 минут исследовать сохранение длины заголовка около 80 кодовых точек; искать скрытые ограничения Unicode; записывать исходные строки и фактические состояния». В процессе уточняйте следующий шаг, но оставляйте след: сборка, окружение, данные, действия, наблюдения и вопросы.
Не превращайте предварительную заметку в доказанный дефект раньше проверки оракула. «На эмодзи появляется ошибка» недостаточно: неизвестны длина, операция и исходное состояние. Сохраните точный ввод или способ генерации, затем сопоставьте с Q1. Если у вас только скриншот, не дорисовывайте пропущенные действия. Укажите, что воспроизведение ещё нужно. Полезная честная неполнота лучше подробной выдуманной истории.
Репорт помогает другому человеку принять действие
Заголовок должен называть условие и наблюдаемый результат: «Создание отклоняет title из 80 эмодзи при допустимой длине Q1». В теле укажите версию/окружение, предусловия, воспроизводимые шаги, ожидаемое, фактическое, повторяемость и свидетельства. Ожидаемое не сводится к «должно работать»: новый ID, draft, точное значение. Фактическое сообщает видимый отказ и отсутствие записи, если это действительно проверено. Ссылку на правило добавляют рядом с ожиданием.
Серьёзность описывает влияние: часть допустимых названий невозможно сохранить. Приоритет исправления зависит ещё от охвата пользователей, сроков и обходного пути. В учебной шкале можно предложить medium, но не требовать единственный универсальный уровень: политика команды неизвестна. Формулировка «вероятно, длину считают UTF-16 units» допустима отдельной гипотезой. Она не должна становиться установленной причиной без анализа реализации.
Минимизируйте пример, сохраняя условие
Начните с наблюдаемого сбоя и удаляйте лишние условия по одному. Вместо большого текста оставьте повтор одного символа. Сравните 80 кириллических букв и 80 эмодзи при одной сессии и тех же остальных полях. Это помогает локализовать отличие единиц измерения, но не заменяет проверку кодовой точки: некоторые видимые символы состоят из нескольких. Убедитесь, что каждый прогон стартует с известного состояния и что другой дефект не мешает нужной операции.
После исправления нужен ретест исходного примера на новой сборке. Регресс проверяет соседние риски: 79/80/81 обычной строки, сохранение пробелов, ограничения description. Закрывать дефект по сообщению «починили» нельзя; одновременно один успешный ретест не подтверждает весь релиз. В отчёте разделите результат конкретного дефекта, выполненный регресс и оставшиеся ограничения. В этом уроке вы анализируете предоставленный журнал; своего динамического ретеста у вас пока нет.
Учебный журнал U1
| Шаг | Данные | Предоставленное наблюдение |
|---|---|---|
| Создание | А×80, description="", priority=normal | ID q80, draft; значение сохранено |
| Создание | 😀×80, те же поля | Сообщение «Слишком длинный заголовок», новая запись отсутствует |
| Повтор второго шага | Новый чистый снимок | Тот же отказ; 2/2 повторов в выданном журнале |
Источники и проверка фактов
ISTQB CTFL 4.0.1 — официальный syllabusСправочник терминов и техник: главы 1, 3–5. Курс QA Orbit — самостоятельный авторский практикум; аккредитация и подготовка к экзамену не заявляются.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1