Перейти к содержимому
Учи.Онлайн Выбрать школу
Статья

Тестировщик ПО: чем занимается, какие навыки нужны и как учиться

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

Содержание

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

Рабочее место тестировщика: приложение, журнал запросов и заметки

Что делает тестировщик и какой результат от него ждут

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

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

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

Как выглядит рабочая задача

Дальше — учебный пример, собранный для объяснения, а не описание конкретного проекта.

Команда интернет-магазина добавляет промокоды на скидку. В требованиях сказано: код даёт 10 % на первый заказ, действует до конца месяца, не суммируется с другими скидками.

Тестировщик начинает не с проверки, а с разбора. Что значит «первый заказ» — первый оплаченный или первый оформленный? Что произойдёт, если заказ отменят после применения кода? Считается ли заказ первым, если пользователь удалил аккаунт и завёл новый? Три вопроса аналитику, и одно требование превращается в четыре.

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

Из этого получается чек-лист, а на критичные сценарии — тест-кейсы с описанием шагов и ожидаемого результата. Дальше — сама проверка, и вот в ней обнаруживается, что после обновления страницы скидка применяется второй раз, и товар за 3 000 рублей уходит за 2 430.

Теперь нужен баг-репорт, и от его качества зависит, починят дефект сегодня или он вернётся через неделю с пометкой «не воспроизводится». В нём: точные шаги от чистого состояния, ожидаемый и фактический результат, окружение (браузер, версия сборки, учётная запись), приложенные логи или запрос из DevTools, оценка серьёзности и приоритета. Серьёзность и приоритет — разные вещи: заметная опечатка на главной странице может иметь низкую техническую серьёзность, но высокий приоритет исправления.

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

Ручное тестирование, автоматизация и что между ними

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

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

Автоматизатор — по сути разработчик. Он пишет код на Python, Java или JavaScript, работает с фреймворками вроде pytest или JUnit, использует Selenium и Playwright для браузерных сценариев, собирает тесты в CI/CD. Если вы рассчитываете за четыре месяца с нуля выйти на позицию автотестировщика, стоит пересмотреть срок: программирование придётся осваивать всерьёз, и курс по Python здесь понадобится не меньше, чем курс по тестированию.

Соседние роли, которые путают

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

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

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

SDET (Software Development Engineer in Test) строит инфраструктуру тестирования: окружения, тестовые данные, интеграцию с CI. Название и границы этой роли зависят от компании: она может пересекаться с работой инженера по автоматизации и не является обязательной следующей ступенью.

Что нужно знать и уметь

Основа, без которой работать не получится:

  • Как устроено клиент-серверное приложение: что уходит на сервер, что возвращается, что означают коды ответа 200, 400, 403, 500.
  • Инструменты разработчика в браузере — вкладка Network и консоль; Postman для проверки API по документации; прокси вроде Charles или Fiddler, если речь о мобильных приложениях.
  • SQL на уровне уверенного SELECT с условиями и соединением таблиц: проверить, что заказ действительно записался в базу, а не только отрисовался на экране.
  • Чтение логов. Для Android — logcat в Android Studio.
  • Техники тест-дизайна: классы эквивалентности, граничные значения, таблицы решений, попарное тестирование.
  • Работа в трекере задач (чаще всего Jira) и в системе управления тестами — TestRail, Allure TestOps или аналоге.
  • Git на уровне чтения истории и веток.

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

Отдельно стоит сказать про рабочие привычки, потому что они отсеивают людей сильнее, чем незнание инструментов. Нужна дотошность в описании: «не работает оплата» — это не баг-репорт. Нужна способность воспроизвести сбой, который случился один раз, и вспомнить, что вы делали до него. И нужна готовность спокойно настаивать на своём, когда разработчик говорит «это не баг, это фича», а вы видите, что пользователь на этом месте потеряет деньги.

Что в этой работе тяжело

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

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

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

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

Как выглядит вход в профессию

Для работы тестировщиком обычно не требуется отдельная профессиональная лицензия. Требования к образованию и опыту зависят от работодателя и должности. Профессиональный стандарт «Специалист по тестированию в области информационных технологий» существует — приказ Минтруда России от 02.08.2021 № 531н, действует до 1 марта 2028 года и описывает четыре уровня квалификации с четвёртого по седьмой. Но это ориентир для работодателей при составлении должностных инструкций, а не пропуск в профессию.

Реальное препятствие другое. Начальные позиции в ИТ сейчас относятся к сегменту с избытком кандидатов: по прогнозу hh.ru на 2026 год, число соискателей на такие вакансии заметно превышает число открытых мест, а требования работодателей растут. Курс без подтверждённой практики в этой ситуации мало что даёт сам по себе.

Что реально повышает шансы:

  • Учебный проект с полным комплектом артефактов: не «я тестировал сайт», а тест-план, чек-листы, набор баг-репортов, отчёт о тестировании. Работодателю важно увидеть, как вы формулируете, а не сколько видео вы посмотрели.
  • Краудтестинг: проверка чужих продуктов по заданиям платформы даёт опыт и внешнюю оценку отчётов; наличие и размер оплаты зависят от задания. Поиск уязвимостей требует отдельной подготовки по безопасности и допустим только в пределах явно разрешённой программы.
  • Стажировка, даже короткая, — почти всегда сильнее любого сертификата.
  • Переход внутри компании. Если вы работаете в поддержке, в контент-отделе или менеджером продукта, попроситесь участвовать в приёмочном тестировании. Это самый короткий путь.

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

Что можно освоить на онлайн-курсах, а что нет

Курс хорошо передаёт то, что структурировано: терминологию, техники тест-дизайна, порядок работы с трекером, основы HTTP и SQL, приёмы работы с Postman и DevTools. Всё это можно выучить дистанционно и проверить на учебных заданиях.

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

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

Как проверить программу обучения

Смотрите не на длительность и не на обещания, а на состав.

В программе для начинающего тестировщика должны присутствовать: техники тест-дизайна (именно перечисленные по названиям, а не «основы тестирования»), тестовая документация, работа с HTTP и API, SQL, работа с логами, инструменты разработчика в браузере, мобильное тестирование хотя бы обзорно. Если программа заявляет автоматизацию, посмотрите, сколько на неё отведено и есть ли предварительный блок по языку программирования — иначе это будет знакомство, а не навык.

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

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

Нужна ли сертификация ISTQB

ISTQB — международная схема сертификации тестировщиков, базовый уровень называется Certified Tester Foundation Level. Согласно официальному описанию экзамена, актуальная версия силлабуса — 4.0.1, экзамен состоит из 40 вопросов, для сдачи нужно набрать 26 баллов, время — 60 минут, требований к опыту работы нет.

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

Куда двигаться дальше

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

Позиция QA-lead — не ступень для новичка, а управленческая роль, к которой приходят с опытом: там больше работы с процессами и людьми, чем с продуктом. Объявления, где «тестировщик с нуля» и «руководитель отдела качества» стоят в одном предложении, стоит читать критически.

Частые вопросы

Нужно ли уметь программировать, чтобы начать? Для старта в ручном тестировании — нет. Понадобится SQL и умение читать чужой код хотя бы поверхностно. Программирование станет обязательным, когда вы пойдёте в автоматизацию, и тогда это будет полноценное освоение языка, а не пара занятий.

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

Сколько времени занимает подготовка? Единого срока нет, и обещания школ здесь — маркетинговый ориентир. Считать разумнее не в месяцах, а в объёме практики: пока вы не составили несколько десятков баг-репортов, которые кто-то компетентный разобрал и раскритиковал, подготовка не закончена. При одинаковой длительности курса занятия по 10–12 часов в неделю дают совсем другой результат, чем по 3–4.