Роль тестировщика в команде разработки: кто такой QA-инженер и чем он занимается

Зачем вам это знать?

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

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

В этом уроке вы узнаете:

• кто такой QA-инженер и что означает аббревиатура QA;
• как выглядит типичная команда разработки программного обеспечения;
• какое место в ней занимает тестировщик;
• что конкретно делает QA-инженер каждый день.

После этого урока у вас будет чёткая картина профессии, в которую вы входите.

Теория

1. Что значит «QA»?

QA — это сокращение от английского Quality Assurance, что переводится как обеспечение качества.

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

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

Иногда встречают похожие термины:

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

2. Как устроена команда разработки?

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

Аналогия: строительство дома

Когда строят дом, в процессе участвуют разные люди:

• Архитектор — придумывает, каким будет дом, рисует чертежи.
• Прораб — организует работу, следит за сроками.
• Строители — возводят стены, кладут плитку, проводят электричество.
• Инспектор — проверяет, что всё построено по нормам и безопасно.

В команде разработки программного обеспечения роли похожи:

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

3. Жизнь программы: от идеи до пользователя

Программы не появляются из воздуха. Они проходят несколько этапов. Этот путь называют жизненным циклом разработки программного обеспечения (SDLC — Software Development Life Cycle).

Упрощённо он выглядит так:

Идея → Требования → Дизайн → Разработка → Тестирование → Выпуск → Поддержка

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

Но на практике хороший QA-инженер подключается намного раньше — уже на этапе требований. Об этом мы поговорим подробнее чуть ниже.

4. Что конкретно делает QA-инженер?

Многие думают, что тестировщик просто «нажимает кнопки и смотрит, работает ли». На самом деле его работа гораздо богаче. Рассмотрим основные занятия.

4.1 Изучение требований

Требования — это документ (или набор документов), где написано, как программа должна себя вести. Например: «При нажатии кнопки «Войти» система должна проверить логин и пароль. Если они верны — открыть главную страницу. Если нет — показать сообщение об ошибке».

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

Аналогия: Представьте, что вы заказали торт на день рождения, но не уточнили размер. Пекарь испёк маленький торт на 4 человека, а гостей пришло 20. Если бы кто-то заранее уточнил детали — проблемы не было бы. QA-инженер и есть тот человек, который задаёт «неудобные вопросы» заранее.

4.2 Написание тест-кейсов

Тест-кейс (или тестовый сценарий) — это пошаговая инструкция для проверки одной конкретной функции программы. В нём описывается:

• что нужно сделать (шаги),
• что ожидается в результате,
• что произошло на самом деле.

Пример тест-кейса для кнопки «Войти»:

Тест-кейс: Успешный вход с корректными данными

Предусловие: пользователь зарегистрирован с логином [email protected] и паролем Qwerty123

Шаги:
  1. Открыть страницу входа (например, https://example.com/login)
  2. Ввести в поле «Email» значение: [email protected]
  3. Ввести в поле «Пароль» значение: Qwerty123
  4. Нажать кнопку «Войти»

Ожидаемый результат:
  - Пользователь перенаправлен на главную страницу
  - В правом верхнем углу отображается имя пользователя
  - Нет сообщений об ошибках

Фактический результат: (заполняется после выполнения теста)
Статус: Пройден / Не пройден

4.3 Выполнение тестов

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

• Ручное тестирование — инженер сам открывает программу и выполняет шаги руками.
• Автоматизированное тестирование — специальная программа выполняет шаги вместо человека (этому посвящён весь наш курс!).

4.4 Нахождение и описание багов

Когда что-то работает не так, как ожидается, это называется баг (от английского bug — жучок). Легенда гласит, что в 1947 году в компьютер Harvard Mark II буквально залетела моль и вызвала сбой. С тех пор ошибки в программах называют «жучками».

Когда QA-инженер находит баг, он не просто сообщает: «Что-то сломалось». Он составляет баг-репорт — подробное описание проблемы, чтобы программист мог её воспроизвести и исправить.

Хороший баг-репорт содержит:

• Заголовок — кратко, что именно сломано.
• Шаги воспроизведения — как добраться до ошибки.
• Ожидаемый результат — что должно было произойти.
• Фактический результат — что произошло на самом деле.
• Серьёзность (severity) — насколько критична ошибка.
• Скриншот или видео — доказательство.

4.5 Перепроверка после исправлений

Когда программист говорит «я починил», работа QA-инженера не заканчивается. Он перепроверяет: действительно ли баг исправлен? Не появились ли новые проблемы рядом? Такая повторная проверка называется регрессионное тестирование.

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

4.6 Общение с командой

QA-инженер — это своего рода «связующее звено». Он общается с:

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

Умение ясно и вежливо объяснять проблемы — такой же важный навык, как и умение находить баги.

5. Чем QA-инженер НЕ занимается

Давайте развеем несколько распространённых мифов.

6. Качества хорошего QA-инженера

Для этой профессии не нужен диплом программиста. Но есть черты, которые очень помогают:

• Любопытство — желание понять, как всё устроено, и проверить нестандартные сценарии.
• Внимательность — замечать мелкие несоответствия, которые другие пропускают.
• Критическое мышление — задавать вопросы «а что если...» и «а что будет, если пользователь сделает что-то неожиданное?».
• Коммуникабельность — объяснять проблемы чётко и без обвинений.
• Усидчивость — тестирование может быть монотонным, и это нормально.
• Желание учиться — технологии меняются быстро.

Пример из жизни: один день QA-инженера

Давайте проследим за Анной — начинающим QA-инженером в небольшой компании, которая делает приложение для доставки еды.

Утро (09:00–11:00): Планирование

Анна открывает список задач. Сегодня команда закончила разработку новой функции: «Отслеживание курьера на карте». Анна читает требования к этой функции и составляет список вопросов:

• «Что показывается на карте, если курьер не двигается 10 минут?»
• «Работает ли карта, если у пользователя медленный интернет?»

Она задаёт эти вопросы разработчику в командном чате.

День (11:00–15:00): Тестирование

Анна выполняет тест-кейсы вручную — открывает приложение, оформляет тестовый заказ, следит за картой. Большинство сценариев работают. Но она замечает: если быстро переключиться между вкладками приложения, иконка курьера на карте пропадает и не возвращается.

Она пишет баг-репорт:

Заголовок: Иконка курьера исчезает при переключении вкладок и не восстанавливается

Шаги воспроизведения:
  1. Оформить заказ и дождаться статуса «Курьер в пути»
  2. Перейти на вкладку «История заказов»
  3. Вернуться на вкладку «Текущий заказ»

Ожидаемый результат: Иконка курьера отображается на карте

Фактический результат: Карта показывается, но иконка курьера отсутствует.
  Иконка не появляется даже после 2 минут ожидания.

Серьёзность: Высокая (пользователь не может отследить курьера)

Приложение: версия 2.4.1, iOS 17, iPhone 13
Скриншот: [прикреплён]

Вечер (15:00–17:00): Коммуникация и документация

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

Практика

Выполните следующие задания. Для них не нужно никаких программ — только ваше внимание и любопытство.

Задание 1: Исследуйте приложение глазами тестировщика

Возьмите любое приложение на вашем телефоне — например, калькулятор, заметки или погода.

1. Попробуйте выполнить 5 действий, которые обычный пользователь не делает: введите очень длинный текст, нажмите кнопку много раз подряд, отключите интернет и попробуйте что-то сохранить.
2. Запишите в блокнот: что произошло? Это то, что вы ожидали? Если нет — опишите несоответствие.

Цель: почувствовать разницу между «пользователем» и «тестировщиком». Тестировщик намеренно ищет нестандартные ситуации.

Задание 2: Напишите свой первый тест-кейс

Выберите простую функцию из реальной жизни — например, функцию поиска в любом приложении или на сайте (YouTube, Google, интернет-магазин).

Напишите три тест-кейса по образцу из урока:

1. Поиск с корректным запросом (например, «кот»).
2. Поиск с пустой строкой (ничего не введено, сразу нажать «Найти»).
3. Поиск с очень длинным запросом (скопируйте абзац текста и вставьте в поле поиска).

Для каждого тест-кейса запишите:

• Шаги
• Ожидаемый результат
• Фактический результат (выполните тест на реальном приложении!)

Цель: научиться структурировать проверки и замечать неожиданное поведение.

Задание 3: Составьте баг-репорт

Если в задании 1 или 2 вы нашли что-то неожиданное — опишите это как настоящий баг-репорт по структуре из урока (заголовок, шаги, ожидаемый и фактический результат, серьёзность).

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

Цель: освоить формат баг-репорта, который используется во всех IT-компаниях мира.

Задание 4 (для размышления): Найдите QA в реальном мире

Тестирование и контроль качества существуют везде, не только в IT.

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

• Кто «тестировщик»?
• Что он проверяет?
• Что является «багом» в его работе?

Пример-подсказка: корректор в издательстве проверяет текст книги перед печатью. «Баг» — опечатка или грамматическая ошибка.

Цель: понять, что мышление QA-инженера — это универсальный навык, а не только IT-специализация.

Итоги урока

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

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