Как исследовать приложение вручную: пошаговый разбор на примере мобильного приложения

Зачем это нужно?

Представьте, что вы впервые зашли в незнакомый магазин. Прежде чем что-то купить, вы осматриваетесь: где стоят товары, удобно ли перемещаться между рядами, работает ли касса, чисто ли в примерочной. Вы ещё ничего не купили — но уже составили первое впечатление и, скорее всего, заметили несколько вещей, которые могли бы быть лучше.

Именно так работает ручное исследование приложения. Прежде чем писать сценарии проверок или запускать автоматизированные тесты, тестировщик исследует продукт вручную — буквально руками и глазами, как обычный пользователь, но с особым вниманием к деталям.

Этот навык — фундамент всего тестирования. Если вы не умеете замечать проблемы «на ощупь», автоматизация не поможет: автоматизированный тест проверяет только то, что вы ему скажете проверить. А сказать правильно можно лишь тогда, когда вы хорошо понимаете само приложение.

В этом уроке мы разберём по шагам, как тестировщик изучает мобильное приложение — возьмём в качестве примера простое приложение для ведения заметок.

Теория

Шаг 1. Познакомьтесь с приложением как обычный пользователь

Прежде чем что-то проверять, нужно просто поиграть с приложением. Запустите его, потыкайте кнопки, посмотрите, что происходит. Это называется разведочное тестирование (от английского exploratory testing) — свободное изучение продукта без заранее написанных сценариев.

💡 Термин: разведочное тестирование — это вид ручного тестирования, при котором тестировщик одновременно изучает приложение, придумывает проверки и сразу их выполняет. Нет заранее написанного плана — только любопытство и опыт.

На этом этапе задайте себе простые вопросы:

• Для чего это приложение?
• Кто его будет использовать?
• Что в нём можно сделать?
• Что выглядит необычно или странно?

Запишите ответы — хотя бы в блокноте. Это называется составление ментальной модели продукта: у вас в голове формируется карта приложения.

Шаг 2. Опишите структуру приложения

После первого знакомства попробуйте составить простую схему — что в приложении вообще есть. Тестировщики называют это картой экранов или навигационной схемой.

Например, для приложения-заметочника схема может выглядеть так:

Экран входа
    └── Главный экран (список заметок)
            ├── Кнопка "Создать заметку"
            │       └── Экран редактора заметки
            │               ├── Поле для заголовка
            │               ├── Поле для текста
            │               └── Кнопка "Сохранить"
            ├── Кнопка "Поиск"
            │       └── Экран поиска
            └── Настройки
                    ├── Тема оформления
                    └── Уведомления

Эта схема помогает убедиться, что вы не пропустили ни один раздел приложения. Начинающие тестировщики часто забывают проверить «второстепенные» экраны вроде настроек — а именно там нередко прячутся баги.

💡 Термин: баг (от английского bug — жук) — это ошибка в программе, которая приводит к неожиданному или неправильному поведению. Например, кнопка «Сохранить» нажимается, но заметка не сохраняется — это баг.

Шаг 3. Изучите каждый экран по отдельности

Теперь пройдитесь по каждому экрану более внимательно. На каждом экране есть несколько категорий элементов, которые нужно проверить:

3.1. Визуальная часть (то, что вы видите)

• Правильно ли отображаются тексты и надписи?
• Не «съезжают» ли кнопки и картинки?
• Читается ли шрифт?
• Правильные ли цвета?

💡 Визуальные ошибки называют UI-багами (от английского User Interface — пользовательский интерфейс, то есть то, что видит пользователь).

3.2. Функциональная часть (то, что работает)

• Что происходит, когда нажимаете каждую кнопку?
• Открывается ли нужный экран?
• Сохраняются ли введённые данные?
• Работают ли переключатели и выпадающие списки?

💡 Функциональное тестирование — проверка того, что каждая функция (возможность) работает так, как задумано.

3.3. Поведение при граничных условиях

Это — один из самых важных навыков тестировщика. Граничные условия — это нестандартные ситуации, которые «обычный» пользователь может не заметить, но которые легко ломают программу.

Примеры граничных условий для поля ввода текста в заметке:

💡 Граничное условие — это ситуация на «краях» нормального использования: самое маленькое значение, самое большое, пустое, несуществующее.

Шаг 4. Попробуйте сделать что-то «неправильно»

Хороший тестировщик думает не только о том, как использовать приложение правильно, но и о том, что произойдёт, если пользователь сделает что-то не так. Разработчики обычно пишут код «для правильного сценария», а вот защиту от ошибок добавляют не всегда.

Попробуйте:

• Нажать кнопку дважды подряд быстро — создастся две одинаковые заметки?
• Закрыть приложение в середине набора текста — сохранится ли черновик?
• Отключить интернет и попробовать синхронизировать — покажет ли приложение понятное сообщение об ошибке?
• Повернуть телефон — не сломается ли вёрстка при горизонтальной ориентации экрана?

Этот подход называется негативным тестированием — мы намеренно проверяем, что случается при неожиданном поведении.

💡 Негативное тестирование — проверка того, как программа реагирует на неправильные, неожиданные или экстремальные входные данные. В противоположность ему, позитивное тестирование — проверка нормального, ожидаемого использования.

Шаг 5. Фиксируйте всё, что заметили

Во время исследования вы будете находить как баги, так и вопросы («а это так задумано?»). Всё это нужно записывать — иначе забудете.

Для каждого замеченного бага или вопроса записывайте:

1. Что вы делали (шаги)
2. Что произошло (фактический результат)
3. Что должно было произойти (ожидаемый результат)
4. Где это случилось (экран, кнопка)

Это называется баг-репортом — описанием ошибки, которое передаётся разработчику.

Шаг 6. Задайте вопросы о требованиях

Иногда в ходе исследования вы находите не баг, а пробел в требованиях — ситуацию, о которой никто просто не подумал.

💡 Требования — это описание того, как должно работать приложение. Это может быть документ, таблица, сообщения в чате с командой — что угодно, где написано «должно делать вот так».

Например: вы заметили, что в заметке можно написать 0 символов и сохранить её. Баг ли это? Зависит от требований. Если в требованиях написано «заметка должна содержать хотя бы один символ» — баг. Если этого нет в требованиях — возможно, нужно уточнить у команды.

Пример: исследование экрана создания заметки

Представьте, что вы тестируете простое мобильное приложение-заметочник. Вот как мог бы выглядеть ваш мысленный (и письменный) процесс исследования экрана создания новой заметки.

Что мы видим на экране?

• Поле для заголовка (с подсказкой «Введите заголовок»)
• Поле для текста (с подсказкой «Начните писать...»)
• Кнопка «Сохранить» (внизу экрана)
• Кнопка «Назад» (стрелка в левом верхнем углу)

Шаг 1 — Позитивный сценарий

Действие:   Ввожу заголовок "Список покупок"
            Ввожу текст "Молоко, хлеб, яйца"
            Нажимаю "Сохранить"

Ожидаемо:   Заметка сохраняется, приложение возвращает на главный экран,
            новая заметка появляется в списке

Фактически: ✅ Всё работает

Шаг 2 — Пустые поля

Действие:   Не ввожу ничего ни в один поле
            Нажимаю "Сохранить"

Ожидаемо:   Приложение показывает ошибку "Заголовок не может быть пустым"

Фактически: ❌ Сохраняется пустая заметка без названия.
            В списке заметок она отображается как пустая строка — неудобно!

Вывод:      Вероятный баг. Нужно уточнить требования.

Шаг 3 — Очень длинный заголовок

Действие:   Ввожу заголовок из 500 символов (просто копирую один и тот же текст)
            Нажимаю "Сохранить"

Ожидаемо:   Либо ограничение ввода (нельзя ввести больше N символов),
            либо заголовок обрезается при отображении в списке

Фактически: ❌ Заголовок сохраняется полностью, но в списке заметок он
            «вылезает» за границы карточки и перекрывает другие элементы

Вывод:      UI-баг. Верстка «ломается» при длинных заголовках.

Шаг 4 — Кнопка «Назад» с несохранёнными изменениями

Действие:   Ввожу заголовок и текст, но НЕ нажимаю "Сохранить"
            Нажимаю кнопку "Назад"

Ожидаемо:   Приложение спрашивает "Сохранить изменения?" с вариантами
            "Да" / "Нет"

Фактически: ❌ Приложение сразу закрывает экран без предупреждения.
            Весь введённый текст теряется.

Вывод:      Функциональный баг. Пользователь может случайно потерять данные.

Шаг 5 — Специальные символы и эмодзи

Действие:   Ввожу в заголовок: "Заметка 🎉 #1 <важно>"
            Нажимаю "Сохранить"

Ожидаемо:   Заметка сохраняется и отображается именно с этим заголовком

Фактически: ✅ Всё отображается корректно. Эмодзи и спецсимволы работают.

Из этого короткого исследования одного экрана мы уже нашли 3 бага и не написали ни строчки кода. Это и есть сила ручного исследовательского тестирования.

Практика

Выполните следующие упражнения самостоятельно. Для них не нужно устанавливать никаких инструментов — достаточно телефона и блокнота (или любого приложения для заметок).

Упражнение 1. Составьте карту экранов

Что делать:
Возьмите любое мобильное приложение на вашем телефоне — например, приложение «Погода», «Калькулятор», «Контакты» или любое другое простое приложение. Запустите его и составьте карту экранов в виде схемы (как в примере выше).

Что записать:

• Название приложения
• Все экраны, которые вы нашли
• Как между ними перемещаться

Цель: научиться видеть структуру продукта целиком, а не отдельные кнопки.

Упражнение 2. Негативное тестирование

Что делать:
Откройте приложение «Контакты» на телефоне и попробуйте создать новый контакт со следующими данными:

1. Полностью пустой контакт (без имени и телефона) — разрешает ли сохранить?
2. Имя из 200 символов — что происходит в списке контактов?
3. Номер телефона, состоящий только из букв: абвгдеёжз
4. Имя с эмодзи: Иван 🤖

Что записать для каждого случая:

• Что вы сделали
• Что ожидали
• Что произошло на самом деле

Упражнение 3. Найдите три бага (или странности)

Что делать:
Возьмите любое приложение, которым вы пользуетесь каждый день. Потратьте 15–20 минут на его свободное исследование. Попробуйте найти хотя бы три вещи, которые вам кажутся странными, неудобными или неправильными.

Это могут быть:

• Настоящие баги (что-то сломано)
• Неудобства для пользователя (что-то работает, но неудобно)
• Непонятные сообщения или надписи
• Визуальные несоответствия

Что записать для каждой находки:

• Описание проблемы
• Шаги для воспроизведения
• Почему, на ваш взгляд, это плохо

Упражнение 4 (продвинутое). Мини-баг-репорт

Что делать:
Возьмите один из багов (или странностей), найденных в упражнении 3, и напишите для него полноценный баг-репорт по следующему шаблону:

Название бага:    [Короткое описание проблемы]

Приложение:       [Название и версия, если видно]
Устройство:       [Модель телефона, версия ОС]

Шаги для воспроизведения:
  1. ...
  2. ...
  3. ...

Ожидаемый результат:
  [Что должно было произойти]

Фактический результат:
  [Что произошло на самом деле]

Серьёзность:      [Критическая / Высокая / Средняя / Низкая]

💡 Серьёзность бага (или severity) — насколько сильно баг мешает работе приложения. Критический баг — приложение вообще не запускается. Низкий — опечатка в надписи на кнопке.

Ключевые выводы

• Исследование приложения вручную — это первый шаг любого тестирования; без него невозможно ни написать хорошие тест-кейсы, ни автоматизировать проверки.
• Начните с роли обычного пользователя, затем переходите к роли «ломателя» — проверяйте граничные условия и негативные сценарии.
• Карта экранов помогает убедиться, что вы не пропустили ни один раздел приложения.
• Позитивное тестирование проверяет, что правильные действия дают правильный результат; негативное — что неправильные действия обрабатываются корректно.
• Каждую находку нужно документировать: без записи баг существует только в вашей голове, а это бесполезно для команды.
• Хороший баг-репорт содержит: шаги воспроизведения, ожидаемый результат и фактический результат.
• Разведочное тестирование — это профессиональный навык, который развивается с опытом: чем больше приложений вы изучаете, тем быстрее находите слабые места.