Кто такой QA: что тестировщик делает для качества продукта

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

Но сообщение ещё не отвечает на главный вопрос: куда ушли 500 рублей? Списались ли они один раз? Получил ли их нужный человек? Совпадает ли история операций с состоянием счетов? Что произойдёт, если ответ потеряется и пользователь нажмёт кнопку снова?

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

Сначала нужно понять, какой результат считается правильным

Анна переводит Борису 500 рублей внутри учебного банковского приложения. До перевода у Анны 2 000 рублей, у Бориса — 100. Для примера договоримся: комиссии нет, оба счёта рублёвые, перевод разрешён и должен завершиться сразу.

После успешной операции ожидаем:

у Анны — 1 500 рублей;
у Бориса — 600 рублей;
в истории обоих участников — соответствующая операция на 500 рублей;
повторная отправка того же запроса не создаёт второе списание.

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

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

1. Что действительно отправило приложение

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

Он выясняет, совпадает ли запрос с действием пользователя: нужный ли получатель, правильная ли сумма и валюта, от чьего имени выполняется операция. Например, в интерфейсе написано «500 рублей», а API принимает сумму в копейках. Значит, по согласованному контракту приложение должно передать 50000, а не 500.

Он также проверяет, что сервер определяет права по авторизованному пользователю: подмена идентификатора счёта в запросе не должна позволять списать чужие деньги.

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

2. Как запрос прошёл между сервисами

В нашей учебной системе API принимает запрос, сервис переводов проверяет возможность операции, а сервис учёта отражает движение средств. Затем информация попадает в историю и возвращается в приложение.

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

Если API вернул «принято в обработку», это ещё не означает «деньги зачислены». Нужно выяснить, какой следующий статус подтверждает завершение и как клиент его получает.

Отдельный важный случай — ответ потерялся после выполнения перевода. Приложение повторяет запрос. Тестировщик проверяет предусмотренный контрактом механизм защиты от повторов: один и тот же перевод не должен превращаться в два.

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

3. Что сохранилось в БД и куда ушли деньги

Теперь нужно сопоставить ответы сервисов с учётными данными. Если у тестировщика есть разрешённый доступ к тестовой БД, он читает записи там. Если такого доступа нет — использует диагностический API, тестовый отчёт или разбирает результат с разработчиком.

Для нашего перевода он ищет не просто строку со статусом «успешно», а согласованную картину:

Что проверяем	Что ожидаем в нашем примере	Какую проблему это помогает заметить
Участники операции	Отправитель — Анна, получатель — Борис	Деньги направлены другому человеку
Сумма и валюта	500 рублей, без комиссии	Потеря точности или неверные единицы
Учёт движения	Одно списание у Анны и одно соответствующее зачисление Борису	Повторное или незавершённое движение
Итоговые остатки	1 500 и 600 рублей	Результат не соответствует операции
Статус и история	Завершённая операция отражена у обоих участников	Экран показывает то, чего нет в учёте

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

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

Вот ответ на вопрос «куда ушли 500 рублей»: есть связанное с этой операцией списание со счёта Анны и зачисление на счёт Бориса, а итоговые данные соответствуют согласованным правилам. Одной зелёной галочки для такого вывода недостаточно.

За уведомлением об успешном переводе могут скрываться двойное списание, неверный получатель и пропуск в истории

Три возможные ошибки за одним сообщением «Успешно»: двойное списание, неверный получатель и отсутствие операции в истории. Каждую нужно проверять отдельно.

4. Что в итоге увидел пользователь

Даже правильное движение средств не завершает проверку. Анна должна увидеть понятный статус, правильную сумму и получателя. Борис — зачисление. История и остатки должны обновиться в пределах согласованного времени.

Тестировщик сверяет экран с фактическим результатом. Например, деньги уже переведены, а приложение показывает ошибку и предлагает повторить операцию. Это проблема: человек может решить, что перевод не состоялся, и отправить ещё 500 рублей уже новой операцией.

Если перевод ещё обрабатывается, интерфейс должен сообщить об этом так, чтобы пользователь понимал, что делать дальше. Конкретное поведение зависит от требований продукта, но сообщение не должно выдавать промежуточный этап за окончательный успех.

Что это даёт качеству: пользователь получает достоверную информацию о своих деньгах и не совершает лишних действий из-за ошибочного статуса.

5. Что будет, если обычный путь прервётся

Убедившись, что один перевод работает, тестировщик меняет условия. Для нашего примера полезны такие проверки:

Двойное нажатие. Не возникли ли две операции вместо одной?
Потеря ответа. Как узнать результат уже выполненного перевода и безопасно повторить запрос?
Недостаточно средств. Операция отклонена без частичного движения денег?
Сбой между этапами. Система завершает операцию или выполняет предусмотренное восстановление, не оставляя необъяснимое списание?
Подмена получателя или счёта. Сервер проверяет данные и права, а не доверяет интерфейсу?

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

Три уровня проверки перевода: расчёт суммы, обмен между сервисами и полный путь пользователя

Слева — проверка расчёта, в центре — взаимодействие через API, справа — перевод глазами отправителя и получателя. Они дополняют друг друга: успех одной проверки не подтверждает весь путь.

Зачем сохранять запросы, статусы и идентификатор операции

Представим, что Анна увидела ошибку, хотя 500 рублей уже дошли Борису. Сообщение разработчику «перевод иногда ломается» почти не помогает: неизвестно, какую попытку искать и что именно произошло.

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

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

Так что тестировщик делает для качества

На этом примере он связал намерение человека с поведением системы: уточнил правила перевода, проверил запрос, проследил взаимодействие сервисов, сопоставил учётные данные и ответ пользователю. Затем исследовал сбои и передал команде доказательства найденных проблем.

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

Качество создаёт вся команда. Тестировщик помогает ей увидеть риски и принять решение на основании фактов. Он не обещает найти все ошибки, но может ясно объяснить, какие пути проверены, что подтверждено и где ещё остаётся неопределённость.

Попробуйте пройти этот путь самостоятельно

Возьмите учебную операцию: перевод, заказ или бронирование. Нарисуйте цепочку «действие → запрос → сервисы → сохранённые данные → ответ пользователю». Для каждого звена напишите, что ожидаете увидеть и чем сможете это подтвердить. Затем выберите один сбой и проследите, как он влияет на остальные звенья.

Потренироваться с запросами в API-тренажёре можно на учебных эндпоинтах сайта. А генератор отчёта поможет оформить результаты проверки и оставшиеся ограничения.