Когда человек только начинает интересоваться тестированием, у него часто появляется очень простая картинка:
Тестировщик сидит, нажимает кнопки, ищет баги и говорит разработчикам: «У вас тут всё сломалось».
В целом, что-то похожее в работе действительно есть. Кнопки мы нажимаем. Баги ищем. Разработчикам иногда пишем неприятные, но полезные вещи.
Но если остановиться только на этом, получится очень бедное понимание профессии.
- Тестирование — это не просто «потыкать сайт».
- QA — это не просто «человек, который нашёл ошибку».
- А баг, дефект и ошибка — это не всегда одно и то же, хотя в реальной работе эти слова часто используют как синонимы.
Давайте разберёмся спокойно, человеческим языком.
Что такое тестирование?
Тестирование — это проверка продукта, функции или системы, чтобы понять: работает ли она так, как должна, и какие риски есть перед тем, как этим начнут пользоваться реальные люди.
Звучит официально. Давайте проще.
Представьте, что вы заказали шкаф.
Мастер его собрал, поставил у стены и говорит:
— Всё готово.
Но вы не просто смотрите на шкаф и говорите: «Красивый, значит нормальный». Вы начинаете проверять:
открываются ли дверцы, не задевают ли они друг друга, ровно ли стоят полки, выдержит ли шкаф тяжёлые вещи, не шатается ли он, нормально ли закрываются ящики, нет ли царапин, совпадает ли цвет с тем, что вы заказывали.
Вот это и есть тестирование в бытовом смысле.
Вы не создавали шкаф, но вы проверяете, можно ли им нормально пользоваться.
В IT всё похоже.
Разработчик сделал форму регистрации. Тестировщик проверяет:
Можно ли зарегистрироваться с нормальными данными, что будет, если оставить поле пустым, можно ли ввести слишком длинный пароль, что произойдёт при неправильной почте, приходит ли письмо подтверждения, не ломается ли страница на телефоне, сохраняется ли пользователь в базе, не появляется ли ошибка на сервере.
То есть тестирование — это не хаотичное «покликал туда-сюда». Это осознанная проверка поведения системы.
Хороший тестировщик не просто нажимает кнопку «Войти». Он думает:
- «А что пользователь может сделать не так?»
- «А что будет, если интернет пропадёт?»
- «А если пользователь введёт пробел вместо имени?»
- «А если он нажмёт кнопку два раза подряд?»
- «А если это не новый пользователь, а уже зарегистрированный?»
- «А если он откроет сайт с телефона?»
Тестирование — это попытка посмотреть на продукт не глазами разработчика, который знает, как всё должно работать, а глазами реального пользователя, который может сделать что угодно.
И вот тут начинается самое интересное.
Пользователь не читает документацию. Пользователь не знает, как «правильно». Пользователь торопится, ошибается, нажимает не туда, вводит странные данные, закрывает вкладку, обновляет страницу, забывает пароль, пишет имя с дефисом, вставляет скопированный текст с лишним пробелом.
А задача тестировщика — подумать обо всём этом раньше, чем продукт попадёт к пользователю.
Тестирование не доказывает, что багов нет
Очень важная мысль: тестирование не может доказать, что продукт идеален.
Оно может показать, что в продукте есть проблемы. Может снизить риски. Может помочь команде выпустить более качественный продукт. Но нельзя честно сказать: «Мы всё протестировали, багов точно нет».
Даже в простом приложении могут быть сотни вариантов поведения. Разные браузеры, разные устройства, разные роли пользователей, разные данные, разные состояния системы.
Например, интернет-магазин.
На первый взгляд, что там проверять?
Открыл товар, положил в корзину, оплатил.
Но на практике сценариев намного больше:
Товар закончился, пока пользователь оформлял заказ; промокод применился два раза; доставка недоступна в выбранный город; пользователь оплатил, но банк не вернул подтверждение; цена изменилась после добавления в корзину; у товара есть ограничение по возрасту; пользователь ввёл индекс с ошибкой; заказ оформляется ночью, когда часть сервисов на техобслуживании.
И вот тестировщик нужен не для того, чтобы «проверить одну счастливую дорожку», где всё идеально. Он нужен для того, чтобы найти слабые места до того, как они ударят по реальным людям, деньгам и репутации компании.
Простая история из жизни
Представим, что команда делает приложение для записи к врачу.
Разработчик сделал экран записи. Пользователь выбирает врача, дату, время и нажимает «Записаться».
На демо всё выглядит отлично. Кнопка нажимается. Запись создаётся. Красота.
Но тестировщик начинает копать глубже.
Он проверяет обычный сценарий: выбрать врача, выбрать время, записаться. Всё работает.
Потом он думает:
«А что, если два человека одновременно выберут одно и то же время?»
Проверяет — и оказывается, что система записывает обоих пациентов на 10:30.
Для пользователя это катастрофа. Один придёт к врачу и узнает, что на это время уже записан другой человек. Клиника получит конфликт. Администратору придётся вручную всё разруливать.
Разработчик может сказать:
— Но у меня же кнопка работает.
И он будет прав. Кнопка действительно работает.
Но продуктовая логика сломана.
Вот почему тестирование — это не только проверка кнопок. Это проверка поведения системы в реальных условиях.
Кто такой тестировщик?
Тестировщик — это специалист, который проверяет продукт и ищет проблемы в его работе.
Чаще всего, когда говорят «тестировщик», имеют в виду человека, который занимается непосредственной проверкой:
Читает требования, составляет проверки, проходит сценарии, ищет баги, заводит баг-репорты, перепроверяет исправления, смотрит, не сломалось ли что-то после изменений.
Например, тестировщику дали задачу:
«Проверить новую форму восстановления пароля».
Он открывает требования и смотрит:
Что должно быть на форме, какие поля обязательны, какие ошибки должны появляться, как долго действует ссылка для восстановления, можно ли использовать старую ссылку повторно, что будет, если ввести почту несуществующего пользователя.
Потом он проверяет это руками или с помощью инструментов. Если находит проблему — описывает её в баг-трекере.
Условно:
Шаги:
- Открыть страницу восстановления пароля.
- Ввести зарегистрированную почту.
- Нажать «Восстановить пароль».
- Перейти по ссылке из письма.
- Задать новый пароль.
- Попробовать войти со старым паролем.
Ожидаемый результат: старый пароль больше не работает.
Фактический результат: можно войти и со старым, и с новым паролем.
Это уже серьёзная проблема безопасности.
Так работает классическое тестирование: есть продукт, есть ожидание, есть проверка, есть результат.
Кто такой QA?
QA расшифровывается как Quality Assurance — обеспечение качества.
И вот здесь важно не перепутать.
Тестирование — это часть работы с качеством.
QA — понятие шире.
Если совсем просто:
Тестировщик чаще ищет проблемы в готовой или почти готовой функции; QA думает о том, как сделать так, чтобы проблем было меньше ещё до тестирования.
То есть QA смотрит не только на сам продукт, но и на процесс его создания.
Например, в команде постоянно появляются баги из-за того, что требования написаны непонятно.
Обычный подход:
— Ну, будем тщательнее тестировать в конце.
QA-подход:
— Давайте начнём задавать вопросы на этапе требований. Добавим чек-лист для аналитика. Будем заранее уточнять спорные сценарии. Договоримся, что у каждой задачи должны быть понятные критерии приёмки. Но если честно, то в жизни обычно это не так, на этапе требований тебя даже не будет. Скорее всего, тебе дадут требования, разработчик уже напишет часть кода, ты в это время посмотришь требования, найдешь ошибку или будешь задавать вопросы, в процессе выяснится, что где-то в требованиях косяк и вы дружно будете все это исправлять, перепроверять. И к сожалению так будет по кругу.
Другой пример.
Разработчики часто забывают обработать ошибки сервера.
Обычный подход:
— Будем каждый раз находить такие баги руками.
QA-подход:
— Давайте добавим это в общий чек-лист проверки. Договоримся о едином формате ошибок. Покроем критичные сценарии автотестами. Добавим логирование, чтобы быстрее понимать причину проблемы.
QA — это не человек, который ходит с табличкой «качество» и всем мешает жить.
Хороший QA помогает команде выпускать продукт спокойнее, быстрее и надёжнее.
Чем QA отличается от тестировщика?
В реальной жизни эти названия часто смешиваются. В вакансиях можно увидеть «Младший тестировщик ПО / Junior QA Engineer», «QA/Тестировщик», «QA Engineer / Инженер по тестированию» — то есть рынок сам не всегда строго разделяет эти термины. На hh.ru такие смешанные формулировки встречаются прямо в названиях вакансий.
Но смысловая разница всё равно есть.
Тестировщик в узком понимании отвечает на вопрос:
«Есть ли проблемы в этой функции?»
QA отвечает шире:
«Почему эти проблемы появляются и как сделать так, чтобы их было меньше?»
Тестировщик может проверить готовую форму заказа.
QA может прийти раньше и спросить:
«А что будет, если товара нет в наличии?»
«А если пользователь начал оплату, но закрыл страницу?»
«А если платёж прошёл, но заказ не создался?»
«А кто будет получать уведомление о сбое?»
«А как мы поймём, что проблема произошла у реального пользователя?»
Вот в этом и разница.
Тестировщик работает с последствиями.
QA старается влиять на причины.
Конечно, на junior-позиции от человека не ждут, что он сразу построит процесс качества в большой компании. Но от него уже ждут QA-мышления: внимательности, понимания рисков, умения задавать вопросы, грамотно описывать проблемы и думать не только по инструкции.
Почему рынок сдвигается в сторону QA, а не просто тестирования?
Раньше многие представляли вход в профессию примерно так:
выучил виды тестирования, научился писать баг-репорты, немного покликал сайт — можно искать работу junior manual tester.
Сейчас этого всё чаще недостаточно.
Компании хотят не просто человека, который «нажимает кнопки». Им нужен специалист, который понимает продукт, умеет думать о рисках, разбирается в клиент-серверной логике, может посмотреть API, открыть DevTools, понять логи, написать понятный баг-репорт, пообщаться с разработчиком и не потеряться в задаче без подробной инструкции.
Даже в названиях вакансий заметно, что работодатели используют формулировки вроде QA Engineer, Manual QA Engineer, Fullstack QA, QA Automation, QA-инженер. На странице QA automation по Москве hh.ru показывает сотни вакансий, а в списке встречаются не только автоматизаторы, но и QA-инженеры, manual QA, fullstack QA и смешанные роли.
Это не значит, что ручное тестирование умерло. Нет, ручное тестирование по-прежнему нужно.
Но изменилось ожидание от специалиста.
Просто «я умею проходить тест-кейсы» — слабая позиция.
Сильнее звучит:
«Я понимаю, зачем мы тестируем, умею анализировать требования, нахожу риски, проверяю не только happy path, могу локализовать проблему, понятно описываю баги и понимаю, как моя работа влияет на качество продукта».
Для новичка это хорошая новость и плохая одновременно.
Плохая — потому что вход стал сложнее.
Хорошая — потому что можно выделиться не за счёт десяти курсов в резюме, а за счёт нормального понимания профессии.
Пример: тестировщик и QA смотрят на одну задачу
Допустим, команда делает кнопку «Отменить заказ».
Тестировщик может проверить:
кнопка отображается, при нажатии заказ отменяется, статус меняется на «Отменён», пользователь видит уведомление, деньги возвращаются, если была оплата.
Это важные проверки.
А теперь QA смотрит шире:
можно ли отменить уже доставленный заказ; что будет, если заказ уже передан курьеру; кто получит уведомление об отмене; вернутся ли бонусы; что будет с промокодом; можно ли отменить заказ два раза; что произойдёт, если пользователь нажал кнопку, а интернет пропал; как это отразится в админке; увидит ли поддержку причину отмены.
Видите разницу?
Первый подход проверяет функцию.
Второй подход проверяет ситуацию вокруг функции.
Именно поэтому QA-мышление так ценно. Пользователь не живёт внутри одного экрана. Он живёт внутри целого процесса.
Что такое баг?
Баг — это проблема в программе, из-за которой она работает не так, как ожидается. Т.е. отличие ожидаемого результата от фактического.
Например:
Кнопка не нажимается, страница падает с ошибкой, цена считается неправильно, письмо не приходит, приложение закрывается, поле принимает недопустимые данные, пользователь видит чужой заказ.
В реальной работе словом «баг» часто называют почти любую найденную проблему.
Например:
— Я нашёл баг в корзине.
— Какой?
— При удалении товара итоговая сумма не пересчитывается.
Все понимают, о чём речь.
Баг — самое бытовое и распространённое слово. Его используют разработчики, тестировщики, менеджеры, аналитики и даже пользователи.
Но для понимания профессии полезно знать, что за багом часто стоит более точная цепочка: ошибка → дефект → проявление проблемы.
Сейчас разберём.
Что такое ошибка?
Ошибка — это действие человека, из-за которого в продукте появляется проблема.
Ошибиться может кто угодно:
аналитик неправильно описал требование, дизайнер забыл важное состояние экрана, разработчик неверно написал условие, тестировщик пропустил важную проверку, менеджер не уточнил ограничение у заказчика.
Ошибка — это именно человеческий промах.
Например, аналитик пишет:
«Пользователь может отменить заказ в любое время».
Звучит просто.
Но он забыл уточнить, что заказ нельзя отменить после передачи курьеру.
Разработчик читает требование буквально и делает отмену в любое время. В итоге пользователь может отменить заказ, который уже едет к нему.
Кто ошибся?
Не только разработчик. Возможно, исходная ошибка была в требовании: оно было неполным.
Другой пример.
Разработчик пишет условие:
если сумма заказа больше 5000 рублей, доставка бесплатная.
Но случайно ставит не «больше или равно 5000», а просто «больше 5000».
В итоге при заказе ровно на 5000 рублей доставка остаётся платной.
Ошибка — это то, что сделал человек: неверно понял, неверно описал, неверно запрограммировал, не учёл сценарий.
Что такое дефект?
Дефект — это проблема, которая уже попала в продукт, код, документацию, дизайн или требования.
То есть ошибка — это действие человека.
Дефект — это результат этой ошибки внутри системы или артефакта.
Например:
человек ошибся в формуле расчёта скидки — в коде появился дефект.
аналитик не описал ограничение по отмене заказа — в требованиях появился дефект.
дизайнер не нарисовал состояние ошибки — в макете появился дефект.
разработчик не обработал пустое значение — в приложении появился дефект.
Дефект может ещё никак не проявляться для пользователя. Он может лежать в коде и ждать своего часа.
Например, в системе есть дефект: приложение неправильно обрабатывает 29 февраля.
Если сейчас обычный день, никто этого не заметит. Всё работает. Пользователи довольны.
Но в високосный год проблема внезапно проявится.
Вот почему дефект — это не всегда то, что уже увидел пользователь. Иногда это скрытая мина.
Что такое баг, дефект и ошибка на одном примере?
Давайте возьмём простой пример из жизни.
Команда делает приложение доставки еды.
Есть правило:
если заказ дороже 1500 рублей, доставка бесплатная.
Аналитик случайно написал в требованиях:
«Бесплатная доставка от 1500 рублей», но не уточнил, входит ли сама сумма 1500 в это условие.
Разработчик понял так: бесплатная доставка только если сумма больше 1500.
Он написал в коде:
«если сумма заказа > 1500, доставка бесплатная».
Пользователь собирает заказ ровно на 1500 рублей и видит, что доставка платная.
Что здесь произошло?
Ошибка — человек не уточнил или неверно понял правило.
Дефект — в требованиях или коде появилось неправильное условие.
Баг — тестировщик или пользователь увидел проблему: при заказе на 1500 рублей доставка не становится бесплатной.
В быту это всё могут назвать просто багом.
И это нормально.
Но если вы хотите расти в профессии, важно понимать глубже: мы не просто нашли «что-то сломанное», мы пытаемся понять, откуда проблема появилась и как не допустить похожих проблем дальше.
Вот это уже QA-мышление.
Ещё один пример: форма регистрации
Допустим, есть форма регистрации.
Поля:
имя, email, пароль, повтор пароля.
Требование:
пароль должен быть не короче 8 символов.
Разработчик случайно сделал проверку только на фронтенде — то есть в браузере. Если пользователь вводит пароль из 3 символов через обычную форму, сайт показывает ошибку.
На первый взгляд всё хорошо.
Но тестировщик проверяет запрос напрямую через API и отправляет пароль «123».
Сервер принимает такой пароль и создаёт пользователя.
Что здесь важно?
Для обычного пользователя форма вроде бы работает правильно.
Но система в целом работает неправильно. Если обойти интерфейс, можно создать слабый пароль.
Это хороший пример того, почему современному QA полезно понимать не только «что видно на экране», но и что происходит под капотом: запросы, ответы сервера, валидацию, базовую безопасность.
Баг на экране может быть только верхушкой айсберга.
Почему новичку важно понимать эти термины
На старте может казаться:
«Да какая разница, баг это или дефект? Главное — найти проблему».
В реальной работе разница действительно не всегда критична. Во многих командах слова «баг» и «дефект» используют как синонимы.
Но понимание терминов помогает мыслить профессиональнее.
Когда вы понимаете разницу, вы начинаете задавать правильные вопросы:
- Это проблема в коде или в требованиях?
- Пользователь уже может с этим столкнуться?
- Это единичный баг или симптом плохого процесса?
Мы просто исправим конкретное место или изменим подход, чтобы такое не повторялось?
Например, если в приложении постоянно ломаются формы, можно бесконечно заводить баги:
- «Не работает поле телефона»,
- «Не работает поле email»,
- «Не работает поле адреса».
А можно увидеть системную проблему:
У команды нет единого подхода к валидации полей.
И тогда QA может предложить:
Сделать общий чек-лист для форм, договориться о правилах ошибок, проверить одинаковое поведение на фронтенде и бэкенде, добавить автотесты на критичные поля.
Это уже не просто поиск багов. Это работа с качеством.
Главная мысль для новичка
Если вы только входите в тестирование, не заучивайте определения мёртво.
Лучше поймите смысл.
Тестирование — это не «тыкать кнопки», а исследовать продукт и искать риски.
Тестировщик — это не враг разработчика, а человек, который помогает команде увидеть проблемы раньше пользователя.
QA — это не просто модное название вакансии, а более широкий подход к качеству: думать не только о найденных багах, но и о причинах их появления.
Ошибка — это человеческий промах.
Дефект — это проблема, которая из-за этого промаха попала в продукт, код, требования или дизайн.
Баг — это то, как эту проблему обычно называют, когда она обнаружена в работе продукта.
И самое важное: хороший специалист по качеству не просто пишет «не работает».
Он умеет объяснить:
- Что именно не работает,
- При каких условиях,
- Какой ожидался результат,
- Что произошло фактически,
- Насколько это критично,
- Кого это затрагивает,
- И почему команде стоит обратить на это внимание.
Именно с этого начинается профессиональный рост в QA.
Не с идеального знания всех терминов. Не с сотни инструментов в резюме. Не с красивой должности в профиле.
А с умения думать о продукте, пользователе и рисках.
Потому что тестирование — это не про то, чтобы доказать, что всё плохо.
Тестирование — это про то, чтобы помочь сделать лучше.
Коротко закрепим
Тестирование отвечает на вопрос:
«Работает ли продукт так, как должен?»
Тестировщик ищет проблемы и проверяет поведение системы.
QA смотрит шире и думает:
«Как сделать так, чтобы проблем было меньше ещё до релиза?»
Ошибка — это действие человека.
Дефект — это проблема, попавшая в продукт или документацию.
Баг — это найденное проявление проблемы, которое нужно исправить.
Если вы это поняли, вы уже сделали первый шаг не просто к профессии тестировщика, а к нормальному QA-мышлению.