Чем занимается тестировщик ПО: задачи, артефакты и виды тестирования

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

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

Три термина, которые часто смешивают

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

Чем занимается тестировщик: путь одной задачи

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

1. Анализ требований. Читает описание задачи и макеты, ищет пробелы и противоречия: что будет при 0 штук, есть ли верхний предел, что показать при ошибке. Вопросы задает аналитику или владельцу продукта до того, как код написан, — это самый дешевый момент для поиска ошибки.
2. Тест-дизайн. Решает, что и как проверять: классы эквивалентности, граничные значения, позитивные и негативные сценарии. Результат — чек-лист или тест-кейсы.
3. Подготовка окружения и данных. Нужный стенд, тестовые пользователи, товары с разными остатками, иногда локально поднятые сервисы.
4. Выполнение проверок. Проходит сценарии в браузере или на устройстве, смотрит запросы в DevTools, проверяет ответы API и записи в базе данных.
5. Баг-репорты. Каждое расхождение с требованием оформляет так, чтобы разработчик воспроизвел его без уточнений.
6. Ретест и регрессия. После исправления проверяет сам дефект и соседнюю функциональность, которую правка могла задеть.
7. Отчет о состоянии. Сообщает, что проверено, что нет и какие дефекты остались. Решение о выпуске обычно принимает команда или владелец продукта, тестировщик дает ему данные для решения.

Как выглядит обычный день

Расписание сильно зависит от компании, продукта и фазы спринта, поэтому таблица — пример, а не норма.

Артефакты: что тестировщик производит

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

Пример: от требования к багу

Требование: «В корзину можно положить от 1 до 99 штук одного товара включительно». Тест-дизайн дает три класса эквивалентности (меньше 1, от 1 до 99, больше 99) и граничные значения 0, 1, 2, 98, 99, 100. Ту же проверку тестировщик может пройти руками в интерфейсе, а может записать как небольшой автотест. Код ниже проверен на Python 3.14 и запускается без сторонних библиотек.

# Требование: в корзину можно положить от 1 до 99 штук одного товара включительно.

def is_valid_qty(qty: int) -> bool:
    return 1 <= qty < 99          # реализация разработчика


# Граничные значения и по одному представителю классов эквивалентности
cases = [
    (0, False),    # ниже нижней границы
    (1, True),     # нижняя граница
    (2, True),     # сразу над нижней
    (50, True),    # середина допустимого класса
    (98, True),    # сразу под верхней
    (99, True),    # верхняя граница
    (100, False),  # выше верхней границы
]

failed = 0
for qty, expected in cases:
    actual = is_valid_qty(qty)
    status = "OK  " if actual == expected else "FAIL"
    if actual != expected:
        failed += 1
    print(f"{status} qty={qty:<3} ожидали {expected}, получили {actual}")

print(f"Провалено: {failed} из {len(cases)}")

Фактический вывод: проверка «из середины» (50) проходит, а верхняя граница падает.

OK   qty=0   ожидали False, получили False
OK   qty=1   ожидали True, получили True
OK   qty=2   ожидали True, получили True
OK   qty=50  ожидали True, получили True
OK   qty=98  ожидали True, получили True
FAIL qty=99  ожидали True, получили False
OK   qty=100 ожидали False, получили False
Провалено: 1 из 7

Причина — строгое сравнение < 99 вместо <= 99. Если бы проверяли только «типичное» значение, дефект ушел бы в релиз. Тестировщик оформляет баг-репорт:

Заголовок: Корзина: нельзя добавить 99 шт. товара, хотя по требованию это допустимо
Окружение: тестовый стенд, сборка 1.8.3, Chrome
Шаги:
  1. Открыть карточку любого товара с остатком больше 99
  2. Ввести количество 99 и нажать «В корзину»
Фактический результат: ошибка «Недопустимое количество»
Ожидаемый результат: в корзине 99 шт.
Серьезность: средняя (граничный сценарий, обходится двумя заказами)

После исправления на 1 <= qty <= 99 тот же прогон печатает «Провалено: 0 из 7». Граница примера: он проверяет только целые числа. Отдельные классы для ручной проверки — пустое поле, текст, дробное число, отрицательное число, вставка из буфера обмена. Их тестировщик добавит в чек-лист, даже если в коде функции проверки типа нет.

Виды тестирования: уровни и типы

Путаница обычно возникает, потому что в одном списке смешивают два разных разреза. Уровень отвечает на вопрос «какой кусок системы проверяем», тип — «какое свойство проверяем». Любой тип можно применить на разных уровнях.

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

Инструменты по направлениям

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

Как войти: дорожная карта до портфолио

Цель — не «понять теорию», а собрать папку работ, которую можно показать на собеседовании. Срок зависит от стартовой базы и часов в неделю; ориентир в днях давать бессмысленно.

1. Разобраться в базовых понятиях: жизненный цикл дефекта, серьезность и приоритет, классы эквивалентности и граничные значения, уровни и типы тестирования.
2. Выбрать учебное приложение или демо-стенд, созданный для практики тестирования, и написать к одной его функции чек-лист на 20-30 пунктов.
3. Превратить 8-10 пунктов чек-листа в полноценные тест-кейсы с предусловиями и ожидаемым результатом.
4. Найти и оформить 3-5 баг-репортов по шаблону выше, со скриншотами и логами из DevTools.
5. Собрать коллекцию запросов к открытому учебному API и проверить коды ответов и поля.
6. Написать 5-10 SQL-запросов к учебной базе: выборки с условиями, JOIN, проверка дублей.
7. Сложить все в репозиторий или документ с кратким описанием, что и как тестировалось.

Если не получилось

Выводы

• Тестировщик ПО сравнивает фактическое поведение программы с требованиями, описывает расхождения и дает команде данные для решения о релизе.
• Работа с задачей идет от анализа требований через тест-дизайн, проверки и баг-репорты к ретесту и регрессии.
• Основные артефакты — чек-листы, тест-кейсы, баг-репорты, тест-план и отчет; хороший баг-репорт воспроизводится без уточнений.
• Виды тестирования удобно делить на уровни (что проверяем) и типы (какое свойство проверяем).
• Для входа в профессию нужен не конспект, а портфолио: чек-лист, тест-кейсы, баг-репорты, запросы к API и SQL.

Где применяется / связь с практикой

FAQ

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

Чем серьезность дефекта отличается от приоритета?
Серьезность описывает влияние на систему, приоритет — очередность исправления. Опечатка на главной странице может быть низкой серьезности, но высокого приоритета.

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