Тестировщик ПО — это специалист, который проверяет программу на соответствие требованиям и ищет дефекты до того, как их увидит пользователь. Он не исправляет код: его продукт — это воспроизводимая информация о проблеме (баг-репорт) и уверенность, что заявленное поведение работает.
Содержание
Ниже разберу, чем тестировщик занят в течение дня, какие бывают виды тестирования (с таблицами, чтобы не путать близкие понятия), какие навыки нужны на старте и как выстроить путь в профессию до первого портфолио. Зарплаты и спрос затрону нейтрально, без обещаний.
Тестирование, QC и QA — это не одно и то же
Три близких термина постоянно путают, поэтому развожу их сразу.
- Тестирование — процесс проверки конкретного продукта: прогон сценариев, сравнение фактического результата с ожидаемым.
- Контроль качества (QC, Quality Control) — проверка уже готового результата на соответствие требованиям. Тестирование — часть QC.
- Обеспечение качества (QA, Quality Assurance) — работа над процессами разработки так, чтобы дефекты не появлялись: ревью требований, критерии приемки, метрики.
На практике в вакансиях встречается должность QA-инженер, и часто под ней имеют в виду именно тестировщика. Строго говоря, QA шире тестирования, но граница в разных компаниях проходит по-разному, поэтому читать нужно текст вакансии, а не только название.
Чем тестировщик занимается в течение дня
Работа складывается из нескольких повторяющихся задач.
- Анализ требований. До кода тестировщик читает постановку задачи и ищет противоречия и пробелы: часто дефект дешевле поймать в требованиях, чем в готовой сборке.
- Тест-дизайн. Из требований выводятся проверки: что и при каких данных прогонять. Результат оформляется в тест-кейсы или чек-листы.
- Прогон проверок. Ручной прогон сценариев или запуск автотестов на стенде.
- Заведение багов. Найденное расхождение описывается так, чтобы разработчик воспроизвел его по шагам.
- Ретест и регресс. После исправления баг перепроверяется, а рядом прогоняются проверки, которые правка могла задеть.
Ключевой навык здесь — не «нажать все кнопки», а выбрать проверки, которые с наибольшей вероятностью вскроют дефект при ограниченном времени.
Виды тестирования
Виды удобнее делить по нескольким независимым признакам: по знанию внутреннего устройства, по уровню, по цели и по поводу запуска. Одна и та же проверка попадает сразу в несколько групп.
По знанию внутреннего устройства
| Подход | Что видит тестировщик | Типичный исполнитель |
|---|---|---|
| Черный ящик | Только вход и выход, код скрыт | Ручной тестировщик |
| Белый ящик | Исходный код и внутреннюю логику | Разработчик, автоматизатор |
| Серый ящик | Частично: схему БД, API, логи | Тестировщик с техническим уклоном |
По уровню (объекту проверки)
| Уровень | Что проверяем | Кто обычно пишет |
|---|---|---|
| Модульное (unit) | Отдельную функцию или класс | Разработчик |
| Интеграционное | Стыки модулей и внешних сервисов | Разработчик, автоматизатор |
| Системное | Собранный продукт целиком | Тестировщик |
| Приемочное | Соответствие бизнес-требованиям | Тестировщик, заказчик |
По цели проверки
| Группа | Вопрос, на который отвечает | Примеры |
|---|---|---|
| Функциональное | Делает ли система то, что должна | Проверка расчета скидки, регистрации |
| Нефункциональное | Как хорошо она это делает | Нагрузочное, безопасности, удобства, совместимости |
По поводу запуска
| Вид | Когда запускают | Объем |
|---|---|---|
| Дымовое (smoke) | Сразу после новой сборки | Узкий: критичные функции |
| Регрессионное | После правок и перед релизом | Широкий: ранее работавшее |
| Ретест | После исправления конкретного бага | Точечный: только этот дефект |
Важная граница: дымовое отвечает на вопрос «сборку вообще есть смысл тестировать?», а регрессионное — «не сломали ли мы то, что раньше работало?». Это разные проверки, и подменять одну другой нельзя.
Ручное и автоматизированное тестирование
Это не конкурирующие лагеря, а инструменты под разные задачи.
| Критерий | Ручное | Автоматизированное |
|---|---|---|
| Скорость первого запуска | Высокая, писать код не нужно | Низкая: сначала пишется тест |
| Стоимость повтора | Растет с числом прогонов | Близка к нулю после написания |
| Где сильнее | Новые фичи, юзабилити, исследование | Стабильный регресс, API, нагрузка |
| Слабое место | Дорогой повтор, усталость | Хрупкость при частой смене UI |
Практический вывод: разовые и исследовательские проверки обычно дешевле руками, а повторяющийся регресс выгодно автоматизировать. Автотесты не отменяют ручное тестирование — они снимают с человека рутину, освобождая время на исследование новых сценариев.
Навыки тестировщика на старте
Тест-дизайн: как выбирать проверки
Прогнать все возможные значения нельзя, поэтому применяют техники сокращения. Две базовые — разбиение на классы эквивалентности и граничные значения.
Пусть поле «возраст» принимает целые числа от 18 до 65 включительно. Наивный подход — проверить много случайных чисел внутри. Техника граничных значений говорит проверять края и соседей края, потому что ошибки чаще всего именно там (перепутаны < и <=).
| Значение | Класс | Ожидаемо |
|---|---|---|
| 17 | Ниже границы | Отклонить |
| 18 | Нижняя граница | Принять |
| 65 | Верхняя граница | Принять |
| 66 | Выше границы | Отклонить |
Четыре проверки вместо десятков случайных — и они бьют туда, где дефект вероятнее всего.
Баг-репорт: главный артефакт ручного тестировщика
Хороший баг воспроизводится разработчиком по шагам без личного общения. Минимальный набор полей:
Заголовок: Кнопка "Оплатить" неактивна при валидной карте
Окружение: Chrome 141, Windows 11, стенд staging
Предусловия: пользователь авторизован, в корзине 1 товар
Шаги воспроизведения:
1. Открыть корзину
2. Перейти к оплате
3. Ввести валидные данные тестовой карты
4. Нажать "Оплатить"
Фактический результат: кнопка остается серой, оплата не проходит
Ожидаемый результат: заказ оплачивается, открывается страница успеха
Приоритет: High; Серьезность: Critical
Здесь стоит развести два поля, которые часто смешивают. Серьезность (severity) — насколько дефект технически опасен (упало ли ядро функции). Приоритет (priority) — как срочно его чинить с точки зрения бизнеса. Опечатка в логотипе на главной может иметь низкую серьезность, но высокий приоритет.
SQL: проверка данных в базе
Тестировщику часто нужно убедиться, что действие в интерфейсе корректно изменило данные. Для этого хватает читающих запросов SELECT.
-- проверяем, что после оформления создался заказ со статусом new
SELECT id, status, total
FROM orders
WHERE user_id = 42
ORDER BY id DESC
LIMIT 1;Ожидаемый результат — одна строка со свежим id, полем status = 'new' и суммой, равной сумме корзины. Если строк нет или статус другой — это расхождение с ожиданием, то есть баг.
Безопасная граница: на рабочих стендах тестировщик работает под read-only доступом и использует только читающие запросы. UPDATE, DELETE и тем более DROP на общей базе способны испортить данные другим людям, поэтому менять состояние в чужой БД без отдельного согласования и отката нельзя.
API: проверка ответа сервиса
Часть логики живет на уровне API, до интерфейса. Проверять ее удобно прямым запросом. Простой пример — убедиться, что сервис отвечает нужным HTTP-статусом (адрес httpbin.org дан как безопасный тренировочный):
curl -s -o /dev/null -w "%{http_code}\n" https://httpbin.org/status/200Вывод:
200
На реальном сервисе тестировщик так же смотрит код ответа (200, 404, 500), а затем разбирает тело ответа: соответствует ли структура контракту, те ли значения вернулись. Основы автоматизации начинаются ровно отсюда — когда такие проверки оформляют в код, а не выполняют руками.
Путь в профессию: от нуля до первого портфолио
Тестирование — одна из частых точек входа в IT, потому что старт возможен без глубокого программирования. Ориентировочная дорожная карта до конкретного результата — первых оформленных проверок и багов в портфолио:
- Разобраться, что такое ПО, клиент-сервер и как устроен веб на базовом уровне.
- Освоить теорию: виды тестирования, техники тест-дизайна, жизненный цикл бага.
- Научиться писать тест-кейсы, чек-листы и баг-репорты.
- Освоить инструменты: баг-трекер (например, Jira), базовый SQL, работу с API (например, Postman), браузерные DevTools.
- Собрать портфолио: взять открытое приложение или учебный проект и оформить по нему набор проверок и найденные дефекты.
- Подтянуть основы автоматизации, если целитесь в автоматизатора: язык программирования плюс тест-фреймворк.
Честный ориентир по срокам: базовая теория и первые артефакты — вопрос нескольких месяцев регулярных занятий, а не «за неделю». Дальше уверенность растет только на практике.
Если что-то не получается, помогает диагностика по симптому:
- Баг не воспроизводится у разработчика — скорее всего, в репорте не хватает окружения или предусловий.
- Не понимаете, что проверять, — вернитесь к требованиям и примените техники тест-дизайна вместо перебора наугад.
- Автотест «мигает» (то падает, то проходит) — ищите неявные задержки и зависимость тестов друг от друга.
Зарплата и спрос: нейтрально
Тестирование остается востребованным направлением, но конкретные цифры дохода сильно зависят от грейда (джуниор, миддл, синьор), региона, типа тестирования (ручное или автоматизация) и компании. Актуальные вилки стоит смотреть в свежих зарплатных обзорах и агрегаторах вакансий на момент чтения, а не ориентироваться на разовые числа из старых статей. Как и в других IT-направлениях, доход заметно растет при переходе к автоматизации и техническим навыкам.
Выводы
- Тестировщик проверяет соответствие продукта требованиям и ищет дефекты, а не исправляет код; его результат — воспроизводимый баг-репорт.
- Виды тестирования делятся по независимым признакам (знание кода, уровень, цель, повод запуска), и одна проверка попадает сразу в несколько групп.
- Ручное и автоматизированное тестирование дополняют друг друга: разовое и исследовательское — руками, повторяющийся регресс — в автотестах.
- Базовые навыки старта: тест-дизайн, чистый баг-репорт, читающий SQL, проверка API; глубокое программирование на входе не обязательно.
- Путь в профессию измеряется первыми артефактами в портфолио, а не пройденной теорией; конкретные зарплаты зависят от грейда и региона.
Где применяется / связь с практикой
Освойте тему на практике
Профессия тестировщика раскрывается только на практике: тест-кейсы, баг-репорты, SQL и API отрабатываются на реальных задачах под ревью наставника, а не по описанию. Системно собрать эти навыки и довести до портфолио помогает курс QA Engineer в Otus: там разбирают виды тестирования, тест-дизайн, работу с базами данных и API, а также основы автоматизации.
Освойте тему на практике
Прежде чем оформлять учебу, полезно вживую посмотреть, как устроены занятия и разбор задач, — для этого подойдут бесплатные открытые уроки Otus, где можно задать вопросы преподавателю до старта.
FAQ
Нужно ли уметь программировать, чтобы стать тестировщиком?
Для ручного тестирования — нет, достаточно понимания логики работы приложений и техник тест-дизайна. Программирование становится обязательным при переходе в автоматизацию, где пишут тесты на языке вроде Python или Java.
Чем тестировщик отличается от QA-инженера?
Строго говоря, QA охватывает весь процесс обеспечения качества, а тестирование — только проверку готового продукта. На практике в вакансиях эти названия часто используют как синонимы, поэтому ориентироваться нужно на список обязанностей, а не на заголовок.
Что важнее для старта: сертификат курса или портфолио?
Работодателя в первую очередь интересует, умеете ли вы находить и грамотно описывать дефекты. Оформленные баг-репорты и тест-кейсы по учебному проекту говорят об этом убедительнее сертификата, поэтому портфолио стоит собирать с первых недель.
