Тестировщик — это человек, который отвечает за то, чтобы до пользователя доехал работающий продукт, а не набор сюрпризов. Он не пишет код продукта (обычно) и не решает, что строить, — но он единственный, чья работа целиком про вопрос «а точно ли это работает так, как надо».

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

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

Работа не сводится к «потыкать кнопки». Типичный набор задач:

  • Разбирается в задаче. Читает описание новой функции, макет, требования. Задаёт вопросы, если что-то непонятно или противоречиво — часто именно на этом этапе всплывают первые проблемы, ещё до кода.
  • Придумывает проверки. Продумывает, как функцией будут пользоваться правильно и неправильно, и составляет тест-кейсы или чек-листы.
  • Проверяет. Проходит сценарии, сравнивает фактический результат с ожидаемым.
  • Заводит баги. Найденные проблемы понятно описывает в баг-репорте, чтобы разработчик смог их воспроизвести и починить.
  • Перепроверяет. Когда баг починили — убеждается, что он ушёл и что при этом ничего не сломалось рядом (регресс).
  • Общается. С разработчиками, аналитиками, менеджером. Значительная часть работы — договориться, что считать багом и что важнее чинить в первую очередь.

Зачем команде отдельный человек для этого

Возникает логичный вопрос: почему бы разработчику самому не проверять свой код? Он и проверяет — но этого мало по двум причинам.

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

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

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

QA, QC и тестирование — в чём разница

Три слова, которые новичок постоянно путает.

  • Тестирование (testing) — сам процесс проверки: прошли сценарии, нашли баги. Это конкретная деятельность.
  • QC (Quality Control, контроль качества) — проверка уже готового результата: соответствует ли продукт требованиям. Тестирование — часть QC.
  • QA (Quality Assurance, обеспечение качества) — шире: не только «проверить готовое», но и выстроить процесс так, чтобы багов становилось меньше. Например, вовремя заметить противоречие в требованиях — это уже QA, хотя ещё нечего тестировать.

На практике почти всех называют «QA» независимо от нюансов, и это нормально. Важно понимать идею: чем раньше и системнее подключается контроль качества, тем меньше проблем доедет до пользователя.

Junior, middle, senior — куда расти

Тестировщиков, как и разработчиков, делят по уровню:

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

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

Где это применяется

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

Где спотыкаются начинающие:

  • Ждут, пока всё будет готово, вместо того чтобы включаться на этапе требований, где баги дешевле всего.
  • Боятся задавать вопросы («вдруг покажусь глупым»). А именно вопросы тестировщика часто вскрывают дыры в задаче.
  • Воспринимают баги как конфликт с разработчиком. Это не «ты плохо сделал», а «давай вместе выпустим хорошее».

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