Когда люди только начинают изучать ручное тестирование, WEB-приложение кажется довольно простой вещью. Есть страница, есть кнопки, формы, меню, ссылки, и остается лишь проверить, что все нажимается и отображается правильно. Но уже после первых рабочих задач становится понятно, что интерфейс — лишь небольшая часть того, что происходит в браузере.
Современное WEB-приложение напоминает театр. Пользователь видит красивую сцену, актеров и декорации, но основная работа происходит за кулисами. Пока человек нажимает кнопку «Войти», браузер отправляет запрос на сервер, сервер обращается к базе данных, проверяет пользователя, формирует ответ и возвращает его обратно. Только после этого интерфейс показывает успешную авторизацию или сообщение об ошибке.
Именно поэтому сегодня практически невозможно представить ручного тестировщика, который занимается исключительно UI. Чем сложнее становятся продукты, тем важнее понимать, что происходит между браузером и сервером.
Современное WEB-приложение напоминает театр. Пользователь видит красивую сцену, актеров и декорации, но основная работа происходит за кулисами. Пока человек нажимает кнопку «Войти», браузер отправляет запрос на сервер, сервер обращается к базе данных, проверяет пользователя, формирует ответ и возвращает его обратно. Только после этого интерфейс показывает успешную авторизацию или сообщение об ошибке.
Именно поэтому сегодня практически невозможно представить ручного тестировщика, который занимается исключительно UI. Чем сложнее становятся продукты, тем важнее понимать, что происходит между браузером и сервером.
UI — то, что видит пользователь
UI (User Interface) — это все элементы, с которыми взаимодействует человек. Кнопки, поля ввода, карточки товаров, всплывающие окна, меню, изображения, адаптивная верстка — все это относится к пользовательскому интерфейсу.
Именно UI формирует первое впечатление о продукте. Даже идеально написанный серверный код не спасет приложение, если пользователь не сможет оформить заказ из-за неработающей кнопки или незаметного сообщения об ошибке.
Но проверка интерфейса давно перестала ограничиваться вопросом «кнопка нажимается или нет». Сегодня тестировщик оценивает десятки различных аспектов.
Каждая подобная ситуация может скрывать дефект.
Хороший UI-тестировщик всегда старается мыслить как пользователь. Он не проверяет только заранее описанный сценарий, а ищет способы случайно или намеренно нарушить ожидаемое поведение приложения.
Именно UI формирует первое впечатление о продукте. Даже идеально написанный серверный код не спасет приложение, если пользователь не сможет оформить заказ из-за неработающей кнопки или незаметного сообщения об ошибке.
Но проверка интерфейса давно перестала ограничиваться вопросом «кнопка нажимается или нет». Сегодня тестировщик оценивает десятки различных аспектов.
- Например, достаточно открыть форму регистрации. Казалось бы, несколько полей и кнопка отправки. На практике возникает множество вопросов. Что произойдет, если оставить поле пустым? Можно ли ввести слишком длинный текст? Как система реагирует на специальные символы? Отображаются ли ошибки рядом с нужным полем? Не исчезают ли введенные данные после неудачной отправки? Корректно ли выглядит форма на мобильном устройстве?
Каждая подобная ситуация может скрывать дефект.
Хороший UI-тестировщик всегда старается мыслить как пользователь. Он не проверяет только заранее описанный сценарий, а ищет способы случайно или намеренно нарушить ожидаемое поведение приложения.
За интерфейсом начинается API
Интересно, что большинство действий пользователя вообще невозможно выполнить без API.
Представим обычный интернет-магазин.
Пользователь открывает каталог товаров. Кажется, что браузер просто показывает страницу. На самом деле в этот момент он отправляет запрос на сервер, получает список товаров в формате JSON и только потом отображает карточки на экране.
Получается, практически каждое действие пользователя сопровождается обменом данными между клиентом и сервером.
Именно этот обмен и называется взаимодействием через API.
Для тестировщика это открывает совершенно другой уровень поиска ошибок. Иногда интерфейс работает идеально, но сервер возвращает неправильные данные. А иногда, наоборот, API полностью исправен, а проблема возникает уже при отображении информации на странице.
Представим обычный интернет-магазин.
Пользователь открывает каталог товаров. Кажется, что браузер просто показывает страницу. На самом деле в этот момент он отправляет запрос на сервер, получает список товаров в формате JSON и только потом отображает карточки на экране.
- Если добавить товар в корзину, снова отправляется запрос.
- Если оформить заказ — еще один.
- Если обновить список сообщений в чате — снова запрос.
Получается, практически каждое действие пользователя сопровождается обменом данными между клиентом и сервером.
Именно этот обмен и называется взаимодействием через API.
Для тестировщика это открывает совершенно другой уровень поиска ошибок. Иногда интерфейс работает идеально, но сервер возвращает неправильные данные. А иногда, наоборот, API полностью исправен, а проблема возникает уже при отображении информации на странице.
Что такое API простыми словами
API можно представить как официанта в ресторане:
Посетитель не идет на кухню готовить блюдо самостоятельно. Он делает заказ официанту, официант передает информацию повару, кухня готовит блюдо, после чего официант приносит результат обратно.
Пользователь сайта тоже не взаимодействует напрямую с сервером. Он нажимает кнопку, браузер отправляет запрос, сервер выполняет необходимые действия и возвращает ответ.
Для тестировщика важно понимать обе стороны этого процесса.
Например, пользователь нажимает кнопку «Получить профиль».
В ответ сервер возвращает такой JSON:
Посетитель не идет на кухню готовить блюдо самостоятельно. Он делает заказ официанту, официант передает информацию повару, кухня готовит блюдо, после чего официант приносит результат обратно.
Пользователь сайта тоже не взаимодействует напрямую с сервером. Он нажимает кнопку, браузер отправляет запрос, сервер выполняет необходимые действия и возвращает ответ.
Для тестировщика важно понимать обе стороны этого процесса.
Например, пользователь нажимает кнопку «Получить профиль».
В ответ сервер возвращает такой JSON:
На основании этих данных интерфейс отображает имя пользователя, адрес электронной почты и дополнительные возможности премиум-аккаунта.
Но если сервер случайно отправит пустое поле name, проблема может проявиться совершенно неожиданно: интерфейс окажется пустым, хотя визуально никаких ошибок в верстке нет.
Но если сервер случайно отправит пустое поле name, проблема может проявиться совершенно неожиданно: интерфейс окажется пустым, хотя визуально никаких ошибок в верстке нет.
Почему UI-тестирование без API становится сложнее
Иногда дефект невозможно найти, если смотреть только на экран.
Представим ситуацию.
Пользователь оформляет заказ. После нажатия кнопки появляется сообщение:
"Заказ успешно создан."
Большинство начинающих тестировщиков на этом заканчивают проверку.
Однако более опытный специалист откроет инструменты разработчика, посмотрит сетевые запросы и обнаружит, что сервер вернул ошибку 500. Сообщение об успехе показал сам интерфейс, хотя заказ на самом деле не сохранился.
Получается интересная ситуация: визуально все выглядит правильно, но бизнес-процесс полностью сломан. Именно такие ошибки зачастую оказываются наиболее дорогими для компании.
Представим ситуацию.
Пользователь оформляет заказ. После нажатия кнопки появляется сообщение:
"Заказ успешно создан."
Большинство начинающих тестировщиков на этом заканчивают проверку.
Однако более опытный специалист откроет инструменты разработчика, посмотрит сетевые запросы и обнаружит, что сервер вернул ошибку 500. Сообщение об успехе показал сам интерфейс, хотя заказ на самом деле не сохранился.
Получается интересная ситуация: визуально все выглядит правильно, но бизнес-процесс полностью сломан. Именно такие ошибки зачастую оказываются наиболее дорогими для компании.
Инструменты разработчика — лучший друг ручного тестировщика
Многие считают, что DevTools нужны исключительно фронтенд-разработчикам. На практике большая часть ручных тестировщиков ежедневно работает именно с ними.
Даже поверхностное понимание DevTools значительно ускоряет расследование большинства дефектов.
- Вкладка Network позволяет увидеть все запросы, которые выполняет браузер. Можно проверить, какой адрес вызывается, какой метод используется, какие параметры были отправлены и какой ответ вернулся.
- Вкладка Console помогает обнаружить JavaScript-ошибки, которые пользователь может даже не заметить внешне.
- А через вкладку Application можно посмотреть cookies, Local Storage, Session Storage и разобраться, где приложение хранит данные пользователя.
Даже поверхностное понимание DevTools значительно ускоряет расследование большинства дефектов.
Когда стоит тестировать API отдельно
Бывает, что интерфейс еще не готов, а серверная часть уже работает.
Или наоборот: разработчики изменили API, а фронтенд пока не успел адаптироваться.
В таких случаях тестировщик может проверить сервер напрямую, используя специальные инструменты вроде Postman или аналогичных API-клиентов.
Например, вместо того чтобы каждый раз заполнять длинную форму регистрации, достаточно отправить один HTTP-запрос и сразу увидеть ответ сервера.
Это экономит огромное количество времени, особенно если приходится выполнять десятки похожих проверок.
Кроме того, API-тестирование позволяет быстро проверить негативные сценарии. Можно отправить некорректные данные, пропустить обязательные поля, изменить тип параметра или передать слишком длинную строку и посмотреть, насколько устойчиво приложение реагирует на подобные ситуации.
Очень часто именно такие проверки находят ошибки, которые невозможно воспроизвести через обычный интерфейс.
Или наоборот: разработчики изменили API, а фронтенд пока не успел адаптироваться.
В таких случаях тестировщик может проверить сервер напрямую, используя специальные инструменты вроде Postman или аналогичных API-клиентов.
Например, вместо того чтобы каждый раз заполнять длинную форму регистрации, достаточно отправить один HTTP-запрос и сразу увидеть ответ сервера.
Это экономит огромное количество времени, особенно если приходится выполнять десятки похожих проверок.
Кроме того, API-тестирование позволяет быстро проверить негативные сценарии. Можно отправить некорректные данные, пропустить обязательные поля, изменить тип параметра или передать слишком длинную строку и посмотреть, насколько устойчиво приложение реагирует на подобные ситуации.
Очень часто именно такие проверки находят ошибки, которые невозможно воспроизвести через обычный интерфейс.
Почему современному QA важно понимать обе стороны
Рынок постепенно меняется. Если несколько лет назад вакансии ручного тестировщика часто ограничивались проверкой пользовательского интерфейса, то сегодня работодатели все чаще ожидают понимания HTTP, REST, JSON, кодов ответов сервера, принципов работы браузера и базовых навыков проверки API.
Это вовсе не означает, что каждому QA необходимо становиться разработчиком. Но специалист, который понимает весь путь данных, от нажатия кнопки до ответа сервера, быстрее находит причины ошибок, эффективнее общается с разработчиками и способен исследовать систему значительно глубже.
Именно поэтому граница между UI- и API-тестированием постепенно стирается. На практике это уже не два разных направления, а две части одного процесса.
Чем лучше тестировщик понимает их взаимосвязь, тем меньше вероятность, что серьезная ошибка попадет в продакшен. И именно такой подход сегодня становится стандартом для большинства современных WEB-проектов.
Хотите узнать больше? Изучите другие статьи из раздела:
Это вовсе не означает, что каждому QA необходимо становиться разработчиком. Но специалист, который понимает весь путь данных, от нажатия кнопки до ответа сервера, быстрее находит причины ошибок, эффективнее общается с разработчиками и способен исследовать систему значительно глубже.
Именно поэтому граница между UI- и API-тестированием постепенно стирается. На практике это уже не два разных направления, а две части одного процесса.
Чем лучше тестировщик понимает их взаимосвязь, тем меньше вероятность, что серьезная ошибка попадет в продакшен. И именно такой подход сегодня становится стандартом для большинства современных WEB-проектов.
Хотите узнать больше? Изучите другие статьи из раздела:
