Кто такой тестировщик и чем занимается QA-инженер: профессия тестировщика простыми словами

🧪 Кто такой тестировщик?

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

Он проверяет сайты, мобильные приложения, игры, банковские системы, интернет-магазины, API и практически любое другое программное обеспечение.

Главная задача тестировщика — понять, соответствует ли продукт требованиям и нормально ли он работает в реальных сценариях.

Причём «нормально работает» — это далеко не только:

• кнопка нажалась;

• страница открылась.

Нужно проверить гораздо больше:

• что произойдёт при неправильных данных;

• что будет при плохом интернете;

• сможет ли пользователь случайно выполнить действие дважды;

• корректно ли работает приложение на разных устройствах;

• правильно ли сервер возвращает данные;

• не ломаются ли старые функции после нового обновления;

• понятно ли пользователю, что произошло при ошибке.

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

🖱️ «Но он же реально просто кликает кнопки»

Иногда — да.

Примерно так же можно сказать:

Программист просто нажимает клавиши на клавиатуре.

Технически ведь правда. 🤷‍♂️

Но ценность работы заключается не в самом клике.

Ценность — в том, почему тестировщик решил нажать именно эту кнопку именно сейчас и какой результат он ожидает получить.

Допустим, есть обычная регистрация:

Email
Пароль
Повторите пароль
[Зарегистрироваться]

Пользователь введёт:

user@mail.ru
password123
password123

и нажмёт кнопку.

Тестировщик начнёт фантазировать.

А если email такой?

user

Или такой:

user@

А пустой?

А пароль из одного символа?

А пароль из 10 000 символов?

А если пароли отличаются?

А если email уже зарегистрирован?

А если нажать кнопку регистрации десять раз подряд?

А если запрос на сервер ушёл, но интернет пропал?

А если открыть форму одновременно в двух вкладках?

И вот простая форма регистрации внезапно превращается в небольшой квест. 🎮

🧠 Главное оружие тестировщика — не мышка, а мышление

Хороший QA постоянно задаёт вопросы:

• Что должно произойти?

• Что может пойти не так?

• Какие данные пользователь может сюда отправить?

• Можно ли оказаться в состоянии, которое разработчик вообще не предусмотрел?

Поэтому тестировщик часто мыслит одновременно как:

• 👨‍💻 разработчик;

• 👤 обычный пользователь;

• 😈 пользователь, который почему-то решил сделать всё максимально неправильно.

Иногда именно третья роль оказывается самой полезной.

🐛 Что такое баг?

Баг — это ситуация, когда фактическое поведение программы отличается от ожидаемого.

Например:

Ожидание: пользователь нажимает «Удалить фотографию» → появляется подтверждение.

Фактически: пользователь нажимает кнопку → удаляется весь аккаунт.

Небольшое расхождение. 😅

Но баги бывают совершенно разными.

Некоторые просто визуальные:

• текст вылез за кнопку;

• картинка перекрывает меню;

• элемент съехал на мобильном устройстве.

А некоторые вполне способны стоить компании денег:

• пользователь может оформить заказ бесплатно;

• платёж списывается два раза;

• скидка применяется бесконечно;

• доступны данные другого пользователя;

• система неправильно рассчитывает баланс.

И чем раньше такие проблемы обнаружены, тем дешевле их исправлять.

📋 Что тестировщик делает на работе?

В реальном проекте работа QA может выглядеть примерно так.

Разработчики готовят новую функцию. Например:

«Теперь пользователь может восстановить пароль через email».

Тестировщик изучает требования и начинает продумывать проверки.

Позитивный сценарий:

Ввести зарегистрированный email
→ получить письмо
→ открыть ссылку
→ задать новый пароль
→ успешно войти

Потом идут негативные сценарии:

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

После этого обнаруженные проблемы оформляются в баг-репорты.

Хороший баг-репорт обычно содержит:

• что произошло;

• где произошло;

• как повторить;

• какой результат ожидался;

• какой результат получился;

• окружение;

• скриншоты или видео;

• логи, если они нужны.

Не:

«Что-то не работает, посмотри».

Разработчики почему-то такой уровень детализации не очень любят. 😄

🔍 Тестировщик проверяет не только интерфейс

Вот здесь миф про «кнопки» начинает окончательно разваливаться.

QA-инженеры могут работать с большим количеством технических инструментов.

API

Frontend может выглядеть нормально, но сервер возвращает неправильные данные.

Например:

GET /users/42

должен вернуть пользователя 42.

Тестировщик может проверить запрос непосредственно через API-инструменты:

• Postman;

• Insomnia;

• Swagger;

• curl.

И увидеть, что сервер вместо:

{
  "id": 42,
  "name": "Alex"
}

вернул:

{
  "id": 41,
  "name": "Ivan"
}

Интерфейс здесь вообще ни при чём. Проблема находится глубже.

🗄️ Базы данных

Иногда нужно проверить, что реально произошло с данными после действия пользователя.

Например, пользователь оплатил подписку.

На экране:

Оплата прошла успешно 🎉

Красиво.

Но в базе статус:

payment_status = failed

Поздравляем, у нас баг.

Поэтому тестировщики нередко знают SQL и могут делать запросы вроде:

SELECT *
FROM payments
WHERE user_id = 123;

То есть QA постепенно начинает подозрительно сильно напоминать технического специалиста. Потому что им и является.

🌐 DevTools, логи и сеть

Ещё один постоянный помощник тестировщика — инструменты разработчика в браузере.

Там можно посмотреть:

• запросы к серверу;

• HTTP-коды ответов;

• ошибки JavaScript;

• заголовки;

• cookies;

• localStorage;

• скорость загрузки;

• проблемы с ресурсами.

Допустим, кнопка показывает:

Ошибка. Попробуйте позже.

Пользователь на этом остановится.

Тестировщик откроет Network и обнаружит:

POST /payment
500 Internal Server Error

А потом посмотрит тело ответа, логи и отправит разработчику гораздо более полезную информацию.

🔁 Регрессионное тестирование: починили одно — сломали другое

Есть древний закон разработки:

Исправление одного бага иногда бесплатно поставляется вместе с двумя новыми.

Поэтому после изменений нужно проверять не только новую функцию.

Нужно убедиться, что старые продолжают работать.

Это называется регрессионным тестированием.

Например, разработчик изменил регистрацию.

Тестировщик может дополнительно проверить:

• авторизацию;

• восстановление пароля;

• изменение email;

• профиль пользователя;

• выход из аккаунта.

Потому что эти функции могут использовать один и тот же код.

Разработчик:

«Я вообще туда не лез».

Тестировщик:

«Тем интереснее».

🤖 А ещё существуют автотесты

Тестировать всё вручную удобно далеко не всегда.

Представьте интернет-магазин с тысячами функций.

Перед каждым релизом вручную проверять всё приложение несколько дней — сомнительное удовольствие.

Поэтому часть проверок автоматизируют.

Например:

test('user can login', async () => {
  await page.goto('/login');
  await page.fill('#email', 'user@mail.com');
  await page.fill('#password', 'password123');
  await page.click('#login');
  await expect(page).toHaveURL('/dashboard');
});

Такой тест можно запускать автоматически после изменений в проекте.

Автоматизация особенно полезна для регулярно повторяющихся проверок.

Для этого используют, например:

• Playwright;

• Cypress;

• Selenium;

• Jest;

• pytest;

• Appium.

Поэтому тестировщик вполне может писать код.

А роль специалиста, который занимается этим постоянно, часто называют QA Automation Engineer.

🧑‍💻 Manual QA и Automation QA — в чём разница

Условно тестирование можно разделить на два направления.

Manual QA

Специалист преимущественно проверяет продукт вручную.

Он работает с:

• требованиями;

• тест-кейсами;

• чек-листами;

• API;

• базами данных;

• DevTools;

• баг-репортами.

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

Automation QA

Кроме понимания тестирования специалист пишет автоматические тесты.

Здесь уже понадобится программирование.

Часто используют:

Java
Python
JavaScript
TypeScript
C#

Поэтому автоматизация тестирования находится где-то на пересечении QA и разработки.

📝 Тест-кейсы и чек-листы

QA редко тестирует продукт совершенно хаотично.

Для систематизации используются тест-кейсы.

Например:

Проверка входа с правильными данными

1. Открыть страницу авторизации
2. Ввести существующий email
3. Ввести правильный пароль
4. Нажать «Войти»
Ожидаемый результат:
пользователь попадает в личный кабинет

Или более короткие чек-листы:

✓ вход с правильным паролем
✓ неправильный пароль
✓ пустой пароль
✓ неизвестный email
✓ восстановление пароля
✓ выход из аккаунта

Так проще не забыть важные сценарии.

Особенно когда проект уже размером не с пет-проект на выходные, а с небольшой космический корабль.

🤝 QA не воюет с разработчиком

Есть старый мем:

Разработчик создаёт. Тестировщик ломает.

В реальности задача у них общая:

сделать хороший продукт.

QA не должен радоваться:

«ХА! Я НАШЁЛ БАГ!»

А разработчик не должен воспринимать сообщение о проблеме как личное оскорбление.

Баг — это проблема продукта, а не характеристика программиста.

Самые сильные команды работают примерно так:

Разработчик → реализует решение
QA → проверяет сценарии
QA → находит проблему
Разработчик → исправляет
QA → перепроверяет
Команда → выпускает продукт

Пользователь получает работающую функцию.

Все довольны.

Ну почти.

Прод всё равно иногда падает в пятницу вечером.

🎯 Можно ли войти в IT через тестирование?

Да, QA остаётся одним из понятных способов познакомиться с разработкой продукта изнутри.

Но идея:

«Пойду в тестировщики, потому что там ничего технического знать не надо»

быстро разбивается о:

HTTP
JSON
SQL
REST API
DevTools
Git
логи
CI/CD
автотесты

😅

Порог старта может быть ниже, чем в некоторых направлениях разработки, но хороший тестировщик постоянно развивается технически.

Именно поэтому сильные QA-инженеры ценятся в командах.

💙 Где практиковаться и изучать программирование?

Если хочется лучше понимать техническую сторону разработки, полезно не ограничиваться одной теорией.

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

Это особенно полезно будущим тестировщикам, которые хотят постепенно перейти от Manual QA к автоматизации и лучше понимать, что вообще происходит внутри приложения.

А в нашем Telegram-сообществе Кодика регулярно выходят короткие полезные посты, разборы, задачи и материалы по программированию. Это удобный способ повторять темы между делом и постоянно держать знания в тонусе. 🚀