Что делает тестировщик: задачи на примере одной фичи (2026)

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

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

Что делает тестировщик: ответ в одном абзаце

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

Это не наша вольная формулировка. В профессиональном стандарте «Специалист по тестированию в области информационных технологий» (приказ Минтруда № 531н, действует с 1 марта 2022 года до 1 марта 2028 года) основная цель профессии записана так: «оценка качества разрабатываемого программного обеспечения путем проверки соответствия программного продукта заявленным требованиям».

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

Одна задача от начала до конца: поле промокода в корзине

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

Шаг 1. Разбор требований и вопросы к аналитику

В описании задачи сказано: «Пользователь вводит промокод, скидка применяется к заказу». Для тестировщика это заготовка. Он читает её и выписывает всё, что в ней не определено.

• Учитывается ли регистр?
• Что происходит с пробелами по краям, если код скопировали из письма или мессенджера, где их часто добавляет само приложение?
• Можно ли применить два промокода одновременно?
• Действует ли скидка на товары, которые уже продаются со скидкой, и что видит покупатель в итоговой сумме?
• Какое сообщение получит человек, если код истёк вчера в 23:59?
• Пересчитывается ли скидка, когда из корзины удаляют товар и сумма падает ниже порога?

Часть таких вопросов нередко оказывается сюрпризом для самой команды. Баг, найденный в тексте требования, стоит дешевле всего: его исправляют правкой одного предложения.

Шаг 2. Тест-дизайн: сколько проверок на самом деле нужно

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

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

Граничные значения. Ошибки любят края диапазонов. Если промокод работает при сумме заказа от 3 000 рублей, проверяют 2 999, 3 000 и 3 001. Если код действует до 31 октября, проверяют последнюю минуту 31-го и первую минуту 1 ноября.

Результат этого шага: чек-лист, для промокода в нашем примере около двадцати коротких пунктов. Вот его начало:

• Действующий код в верхнем регистре применяется.
• Тот же код в нижнем регистре.
• Код с пробелом в начале и в конце.
• Несуществующий код показывает понятную ошибку и не обнуляет корзину.
• Истёкший код.
• Пустое поле и нажатие «Применить».
• Сумма заказа 2 999, 3 000 и 3 001 рубль при пороге 3 000.
• Второй промокод поверх первого.
• Удаление товара после применения кода, когда сумма опускается ниже порога.
• Скидка сохраняется после обновления страницы и при переходе к оплате.

Для самых важных сценариев тестировщик пишет подробные тест-кейсы. Так выглядит один из них:

Шаг 3. Прогон и баг-репорт

Когда фича готова, тестировщик проходит по чек-листу на тестовом стенде. Допустим, он находит, что промокод с пробелом в конце отклоняется как несуществующий. Человек скопировал код из рассылки, а сайт ему отказал. Для бизнеса это прямая потеря заказа.

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

• Заголовок: «Корзина: промокод с пробелом в конце отклоняется как несуществующий».
• Окружение: тестовый стенд, сборка от 14 октября, мобильный Chrome на Android 14; на десктопе ошибка тоже воспроизводится, значит дело не в устройстве.
• Предусловия: в корзине товар от 3 000 ₽, промокод SALE10 активен.
• Шаги: ввести «SALE10 » с пробелом и нажать «Применить».
• Фактический результат: сообщение «Промокод не найден».
• Ожидаемый результат: пробелы по краям обрезаются, скидка 10% применяется.
• Серьёзность и приоритет: major, высокий.
• Вложения: скриншот и запрос из вкладки Network.

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

Шаг 4. Ретест и регрессия

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

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

Неделя тестировщика внутри спринта

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

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

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

Отдельная часть недели, о которой редко пишут, это общение. С аналитиком тестировщик уточняет спорное поведение, с разработчиком спорит, баг это или фича. Иногда приходится объяснять менеджеру, почему релиз стоит отложить. Умение спокойно спорить с аргументами здесь не менее важно, чем внимательность.

Документы, которые остаются после тестировщика

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

Джуну чаще всего достаются чек-листы и баг-репорты, и по их качеству о нём судят в первые месяцы работы.

Какие проверки он проводит чаще всего

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

• Смоук-тестирование: быстрая проверка, что новая сборка вообще запускается и основные сценарии живы. Смоук занимает минуты, и без него нет смысла начинать подробный прогон.
• Регрессионное: проверка, что старые функции не сломались после изменений. Самый трудоёмкий вид, поэтому его автоматизируют первым.
• Тестирование API: запросы к серверу напрямую, без интерфейса, например через Postman. Позволяет найти ошибку раньше, чем готов экран.
• Кросс-браузерное и кросс-платформенное: один сценарий в разных браузерах, на разных размерах экрана и версиях Android или iOS.
• Исследовательское: проверка без заранее написанных сценариев, когда тестировщик сознательно пытается сломать продукт нестандартными действиями.
• Нагрузочное и тестирование безопасности: обычно отдельные специализации, джун с ними сталкивается редко.

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

Инструменты, с которыми работает тестировщик

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

• Трекер задач: Jira, YouTrack или их российские аналоги. Здесь живут задачи, баг-репорты и вся переписка с разработчиками по каждому дефекту, поэтому трекер открыт весь день.
• Система управления тестами: TestIT, Qase, TestRail. Хранит тест-кейсы и результаты прогонов.
• DevTools браузера: вкладки Network и Console, чтобы понять, где именно ошибка.
• Postman: запросы к API.
• Charles или Proxyman: перехват трафика мобильного приложения.
• SQL: проверить, что заказ действительно записался в базу с правильной скидкой.

Автоматизатору к этому добавляется язык программирования (чаще Python, Java или JavaScript), фреймворк вроде pytest или Playwright, Git и системы непрерывной интеграции. Подробнее о том, где проходит граница между ролями, мы писали в статье про ручное и автоматизированное тестирование.

Как меняются задачи от джуна до лида

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

• Junior выполняет проверки по чужим тест-кейсам, оформляет дефекты, проводит смоук и регресс. В терминах профстандарта это первый уровень: подготовка данных, выполнение тестирования, документирование дефектов.
• Middle сам разбирает требования, проектирует тесты для новых фич, тестирует API, часто начинает писать автотесты.
• Senior решает, что покрывать автотестами, а что оставить ручным, анализирует покрытие и участвует в архитектурных обсуждениях.
• Lead управляет командой тестирования, выстраивает процесс и отвечает за качество релизов перед руководством.

По данным отчёта Хабр Карьеры за первое полугодие 2026 года, в ручном тестировании джун получает 83 тысячи рублей, мидл 143 тысячи, сеньор около 221 тысячи, лид 267 тысяч. У автоматизаторов вилка выше на каждом шаге: 108, 197, 307 и около 372 тысяч рублей соответственно.

Разница между ручным мидлом и автоматизатором того же уровня составляет больше 50 тысяч рублей в месяц. Поэтому многие ручные тестировщики со временем переходят в автоматизацию. Сравнивать вилки на старте сложнее, чем кажется: по подсчёту автора разбора 2528 QA-вакансий за 2025 год из крупной Telegram-группы, у джунов зарплату указывают лишь примерно в 34% объявлений против примерно 86% у сеньоров.

Чем отличается работа в банке, игре и интернет-магазине

Цена ошибки в банке измеряется деньгами клиентов, а в интернет-магазине потерянными заказами, поэтому одни и те же обязанности тестировщика наполняются разным содержанием. От продукта зависит, какие сценарии проверяют первыми, сколько пишут документации и насколько строго проходит релиз. Ниже четыре самых частых типа проектов.

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

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

E-commerce и маркетплейсы. Частые релизы, иногда несколько в неделю, поэтому важны скорость и автоматизация регресса. Главные сценарии: поиск, корзина, оплата, доставка. Наш пример с промокодом взят как раз отсюда.

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

Чего тестировщик не делает

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

• Не исправляет баги. Он находит и описывает дефект, исправляет его разработчик. Хорошая локализация ошибки ценится, но код правит не тестировщик.
• Не отвечает за качество в одиночку. Если баг ушёл к пользователям, это сбой процесса всей команды. Тестирование показывает наличие дефектов, но не может доказать их отсутствие.
• Не обязательно пишет код с первого дня. Ручному тестировщику на старте достаточно понимать, как устроены клиент, сервер и запросы между ними.
• Не просто «тыкает кнопки». Бессистемное нажатие находит случайные баги, системный тест-дизайн находит закономерные, и платят за второе.

Где учат этим задачам и что проверить в программе курса

Каждый шаг из примера с промокодом можно освоить самостоятельно, курсы сокращают путь за счёт практики с проверкой и разбора баг-репортов. В каталоге SkillEdge сейчас 26 курсов по тестированию от 7 школ, цены начинаются от 12 930 ₽ и доходят до 138 573 ₽.

Сравнивая программы на SkillEdge, мы заметили простую закономерность: дешёвые и дорогие курсы ручного тестирования учат одному и тому же набору. Тест-дизайн, баг-репорты, DevTools, Postman и SQL есть почти везде. Например, «Тестировщик ПО: основы QA с нуля» в Merion стоит 12 930 ₽ и длится 4 месяца, а «Инженер по ручному тестированию с нуля» в Skillbox стоит 97 972 ₽ при длительности 4 месяца.

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

Перед покупкой проверьте в программе три вещи.

• Пишете ли вы баг-репорты на настоящем сайте или приложении, а не только на учебном стенде.
• Проверяет ли домашние задания человек, а не автоматический тест.
• Есть ли блок по API и SQL, без которого сложно пройти собеседование уже на джуна.

Курсы удобно сопоставить по цене и длительности в каталоге курсов по тестированию или в разделе сравнения курсов. Пошаговый план входа в профессию разобран в статье о том, как стать QA-инженером.

Как понять, подойдёт ли вам эта работа

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

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

Учтите и рынок. Автор обзора рынка автоматизаторов на Хабре приводит случай, когда на одну вакансию тестировщика за месяц пришло больше 2 200 откликов. Конкуренция за стартовые позиции высокая, поэтому портфолио из баг-репортов решает больше, чем сертификат. Как собрать такое портфолио, мы разбирали в гайде о том, как стать тестировщиком без опыта, а вилку зарплат и список навыков можно посмотреть на странице профессии тестировщика.