Один день тестировщика: от задачи до понятного результата

В девять утра тестировщику приходит задача: «Добавили промокод на скидку 10%. Посмотри, всё ли работает». К вечеру команда хочет понять, можно ли выпускать изменение.

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

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

09:00. Задача есть, но ожидаемый результат ещё нужно уточнить

В интернет-магазине появился промокод START10. Тестировщик открывает описание и видит только «скидка 10%». Этого недостаточно, чтобы проверять расчёт.

Он спрашивает аналитика: скидка действует на все товары? Учитывается доставка? Можно ли применить код повторно? Что происходит, если после применения изменить количество товара?

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

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

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

Результат утра: фраза «скидка работает» превратилась в конкретные условия, которые можно подтвердить или опровергнуть.

10:00. Подготавливаем заказ, в котором понятна каждая сумма

Тестировщик проверяет, какая сборка установлена на учебном стенде и включена ли нужная настройка. Затем создаёт корзину: один товар за 2 000 рублей, доставка — 300 рублей. Других акций нет.

До промокода заказ стоит 2 300 рублей. После применения START10 ожидаем скидку 200 рублей и итог 2 100 рублей: 2 000 − 200 + 300.

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

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

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

11:00. Проверяем путь от промокода до оформления заказа

Тестировщик вводит код. На экране появляется 2 100 рублей — пока всё совпадает. Теперь он смотрит глубже.

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

Затем оформляет заказ на тестовом стенде. Проверяет, что заказ сохранился с той же суммой, а в тестовый платёжный контур передано 2 100 рублей. Если по контракту сумма передаётся в копейках, ожидается 210000. Реальные деньги для этого учебного сценария не нужны.

Для проверки сохранённых данных использует разрешённый доступ к тестовой БД или диагностический API. Конкретная архитектура может отличаться; смысл один — связать корзину, заказ и платёжную попытку по их идентификаторам.

Результат: подтверждено не только появление надписи «скидка», но и согласованность суммы на всём обычном пути покупки.

12:00. Изменяем корзину и находим расхождение

На новой тестовой корзине QA повторяет применение кода, а затем увеличивает количество товара с одного до двух.

Теперь товары стоят 4 000 рублей. Скидка должна составить 400 рублей, а заказ с доставкой — 3 900 рублей. Но приложение показывает 4 100: скидка осталась прежней, 200 рублей.

Тестировщик не останавливается на скриншоте. Он проверяет запрос изменения количества и видит, что новое количество отправлено правильно. Затем смотрит ответ API: там тоже скидка 200 рублей и итог 4 100. При оформлении именно этот итог сохраняется в заказе.

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

Пользовательское последствие: при выполнении согласованных условий покупатель заплатил бы на 200 рублей больше ожидаемого.

Состав заказа одинаковый. Слева скидка осталась от одного товара, справа пересчитана на два. Именно это расхождение увеличивает сумму заказа на 200 рублей.

13:00. Передаём ошибку так, чтобы её можно было повторить

Вместо «промокод неправильно считает» тестировщик создаёт описание:

После увеличения количества товара скидка START10 не пересчитывается.

Условия: тестовая сборка, товар за 2 000 рублей, доставка 300 рублей, других акций нет.

Шаги: добавить один товар → применить START10 → увеличить количество до двух → оформить заказ.

Ожидается: товары 4 000, скидка 400, доставка 300, итог 3 900 рублей.

Фактически: скидка 200, итог 4 100 рублей — в ответе API, интерфейсе и сохранённом заказе.

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

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

Результат: команда получила воспроизводимый дефект с понятными последствиями и данными для расследования.

15:00. Исправление приехало — проверяем его и соседние сценарии

Предположим, разработчик нашёл причину и выпустил новую тестовую сборку. Сначала QA убеждается, что проверяет именно её, затем на свежих данных повторяет шаги ошибки.

После увеличения количества скидка стала 400 рублей, итог — 3 900. Эти суммы совпали в API, интерфейсе и заказе. Исходный дефект больше не воспроизводится.

Но исправление затронуло пересчёт, поэтому тестировщик проверяет и соседние случаи:

• уменьшает количество обратно до одного — ожидает итог 2 100 рублей;
• повторно применяет код — скидка не складывается сама с собой;
• вводит неверный код в корзине без скидки — итог остаётся 2 300 рублей;
• оформляет заказ без промокода — обычный расчёт не сломан.

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

Результат: отдельно подтверждены исправление конкретной ошибки и несколько связанных сценариев. Границы проверки остаются видимыми.

17:00. Объясняем команде, с чем заканчиваем день

На вопрос «Ну что, всё работает?» тестировщик не отвечает одним словом. Он даёт короткую сводку, по которой можно действовать:

На новой тестовой сборке проверены применение START10, повторное применение, неверный код, изменение количества и оформление заказа. Суммы сопоставлены в API, интерфейсе и сохранённом заказе; обычный путь проверен с тестовым платёжным контуром.

Ошибка пересчёта после изменения количества исправлена и повторно проверена. Связанные проверки на уменьшение количества и заказ без скидки прошли.

Совместимость с другими акциями и другие валюты не проверялись. Если они входят в релиз, нужны дополнительные сценарии и согласованные правила.

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

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

Путь задачи за день: понять правило, проверить поведение, исследовать расхождение и передать результат. Зелёная отметка относится к проверенным условиям, а не ко всему продукту сразу.

Что тестировщик сделал за этот день

Утром у команды была короткая просьба «посмотреть промокод». К вечеру появились согласованные правила, подтверждённый путь заказа, исправленная ошибка расчёта и понятный список непроверенных условий.

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

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

Попробуйте на своей учебной задаче

Возьмите изменение с понятными числами: скидку, стоимость доставки или лимит заказа. Уточните правила, подготовьте известные входные данные и рассчитайте результат до запуска проверки. Затем проследите его от запроса до сохранённой операции.

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