Профессия QA Engineer: быстрый старт в IT с нуля

Введение в мир тестирования: кто такой QA-инженер и зачем он нужен бизнесу

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

Кто такой QA-инженер на самом деле

Многие новички ошибочно полагают, что работа тестировщика сводится к «нажиманию на кнопки и поиску ошибок». Если бы это было так, профессия называлась бы просто «искатель багов». Но в индустрии принято использовать термин QA — Quality Assurance, что в переводе означает «обеспечение качества».

Чтобы понять разницу, давайте воспользуемся аналогией с автомобильным заводом. * Тестировщик (QC — Quality Control) — это контролер в конце конвейера. Он берет уже готовую машину, хлопает дверью, проверяет, светят ли фары, и если дверь отвалилась, отправляет машину на переделку. Это работа с результатом. * QA-инженер (Quality Assurance) — это специалист, который думает о качестве еще до того, как первая деталь попала на конвейер. Он анализирует чертежи, проверяет, надежны ли поставщики металла, следит за тем, чтобы рабочие на линии не нарушали технологию, и, конечно, проверяет итоговый автомобиль.

QA-инженер — это адвокат пользователя внутри команды разработки. Его задача не просто найти «баг» (ошибку), а выстроить процесс так, чтобы ошибок было как можно меньше, а конечный продукт приносил пользу и удовольствие.

Почему бизнес готов платить за тестирование

Для коммерческой компании разработка программного обеспечения — это инвестиция. И как любая инвестиция, она сопряжена с рисками. Тестирование — это способ управления этими рисками. Давайте разберем, какие именно проблемы решает QA для бизнеса в российских реалиях.

Прямые финансовые потери

В банковском секторе или e-commerce (интернет-торговле) цена ошибки может исчисляться миллионами рублей в минуту. Если в приложении крупного ритейлера из-за сбоя цена на телевизоры станет 1 рубль вместо 50 000, и это заметят пользователи, компания понесет колоссальные убытки. QA-инженер проверяет критические пути оплаты и корректность расчетов, предотвращая финансовые катастрофы.

Репутационные риски

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

Стоимость исправления ошибки

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

Если аналитик допустил логическую ошибку в требованиях, и QA заметил это на этапе обсуждения — исправление стоит 0 рублей (просто поправить текст).

Если ошибку нашел программист в процессе написания кода — это стоит часа его работы.

Если ошибку нашел QA в готовом продукте — нужно возвращать задачу программисту, снова всё пересобирать и перепроверять. Это стоит уже в 10 раз дороже.

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

Тестирование как процесс: от идеи до релиза

Работа QA-инженера в современной IT-компании (будь то «Яндекс», «Сбер» или небольшой стартап) встроена в общую цепочку создания продукта. Она не начинается в момент, когда программист говорит: «Я закончил, проверяй».

Процесс выглядит примерно так:

Анализ требований. QA читает описание новой функции. Например: «Добавить возможность оплаты через СБП». Инженер сразу задает вопросы: «А что будет, если у пользователя нет приложения банка?», «А если пропадет интернет в момент подтверждения?», «Как система должна реагировать на отмену транзакции?».

Планирование (Тест-дизайн). Инженер составляет список проверок (чек-листы) и подробные сценарии (тест-кейсы). Это похоже на составление маршрута для путешествия: нужно предусмотреть все повороты и возможные тупики.

Выполнение тестов. Когда программисты передают готовую часть кода, QA проходит по своим сценариям. Он проверяет и «позитивные» случаи (когда всё работает как надо), и «негативные» (когда пользователь делает что-то не так).

Регистрация дефектов. Если найдена ошибка, QA оформляет баг-репорт. Это не просто сообщение «не работает», а подробная инструкция: что сделать, что ожидалось и что получилось на самом деле.

Повторная проверка (Re-test). Когда программист исправляет баг, QA проверяет его снова, а также убеждается, что исправление не сломало то, что раньше работало (это называется регрессионным тестированием).

Виды тестирования: краткий обзор

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

По объекту тестирования

* Функциональное тестирование: проверяем, ЧТО делает система. Работает ли кнопка? Уходит ли письмо? Считается ли скидка? * Нефункциональное тестирование: проверяем, КАК система это делает. Быстро ли загружается страница (производительность)? Удобно ли пользоваться приложением одной рукой (юзабилити)? Защищены ли данные (безопасность)?

По уровню доступа к коду

* Метод «Черного ящика» (Black Box): мы не знаем, как устроена программа внутри. Мы видим только интерфейс (кнопки, поля). Большинство ручных тестировщиков начинают именно с этого. * Метод «Белого ящика» (White Box): мы видим код и понимаем внутреннюю логику. Это уровень разработчиков и автоматизаторов.

По уровню автоматизации

* Ручное тестирование (Manual): человек сам проходит по шагам сценария. Это незаменимо при проверке интерфейсов и логики, которую сложно формализовать. * Автоматизированное тестирование (Auto): пишутся специальные программы (скрипты), которые проверяют другие программы. Это экономит время при частых повторных проверках.

Мифы о профессии QA

Вокруг тестирования сложилось много стереотипов, которые могут сбить с толку тех, кто только пришел в IT.

Миф №1: Тестировщик — это «недопрограммист» Это в корне неверно. У QA и разработчика разные склады ума. Программист нацелен на созидание: «Как заставить это работать?». Тестировщик нацелен на критический анализ: «Где это может сломаться?». Хороший QA-инженер — это полноценный партнер разработчика, а не его помощник.

Миф №2: Тестирование — это скучно и однообразно Если вы представляете себе человека, который 8 часов в день нажимает на одну и ту же кнопку — вы ошибаетесь. Каждый день приносит новые задачи. Сегодня вы разбираетесь в тонкостях банковских переводов, завтра тестируете интеграцию с картами, а послезавтра изучаете, почему приложение падает на старых моделях iPhone. Это работа для тех, кто любит докапываться до сути вещей.

Миф №3: В QA можно зайти без знаний, просто «с улицы» Лет 10 назад это было отчасти правдой. Сегодня порог входа вырос. Нужно понимать теорию, уметь работать с базами данных, знать, как устроены веб-сайты и мобильные приложения. Однако, это всё еще один из самых доступных путей в IT для людей с гуманитарным или техническим бэкграундом из других сфер.

Портрет идеального QA-инженера

Какими качествами нужно обладать, чтобы преуспеть в этой профессии?

Внимательность к деталям. Вы должны замечать, что шрифт на одной кнопке на 1 пиксель отличается от другой, или что сообщение об ошибке содержит опечатку.

Любопытство и «деструктивное мышление». Вам должно быть интересно: «А что будет, если я введу в поле для имени 1000 символов?» или «А если я нажму "Оплатить" и сразу выключу Wi-Fi?».

Коммуникабельность. QA постоянно общается. Нужно уметь вежливо объяснить программисту, что в его коде ошибка, и аргументированно доказать менеджеру, что продукт еще рано выпускать на рынок.

Стрессоустойчивость. Перед релизом нагрузка всегда возрастает. Нужно уметь сохранять спокойствие и холодную голову, когда сроки «горят».

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

Специфика работы в РФ

Российский IT-рынок имеет свои особенности. Во-первых, у нас очень сильная школа финтеха (банковских технологий) и e-commerce. Такие гиганты, как «Сбер», «Тинькофф», Ozon или Wildberries, нанимают сотни тестировщиков.

Во-вторых, в России популярны гибкие методологии разработки (Agile, Scrum). Это значит, что вы будете работать в небольших командах, где голос каждого участника важен. QA-инженер в такой команде — это не просто исполнитель, а человек, который может влиять на то, каким будет продукт.

В-третьих, зарплаты. Начинающий Junior QA в Москве или при удаленной работе на крупную компанию может рассчитывать на 60 000 — 90 000 руб. С опытом 2-3 года (Middle) зарплата вырастает до 150 000 — 220 000 руб. Опытные Senior-специалисты и автоматизаторы получают 300 000 руб. и выше.

Инструментарий: с чем придется работать

Хотя мы подробно разберем инструменты позже, вот ваш будущий «стартовый набор»:

* Системы управления тестированием (TMS): например, Test IT или Jira с плагинами. Здесь хранятся ваши тест-кейсы. * Баг-трекеры: Jira, YouTrack. Здесь вы будете заводить отчеты об ошибках. * Инструменты разработчика в браузере (DevTools): «подзорная труба», позволяющая заглянуть внутрь сайта. * Postman: инструмент для проверки «внутренностей» программ без графического интерфейса (API). * SQL: язык для общения с базами данных.

Жизненный пример: Тестирование формы регистрации

Давайте на практике разберем, как мыслит QA-инженер. Перед вами простая форма: «Имя», «Телефон», кнопка «Зарегистрироваться».

Обычный человек введет имя, телефон и нажмет кнопку. Если всё сработало — «оно работает». QA-инженер проведет десятки проверок:

Позитивная: Ввести корректное имя («Иван») и правильный номер. Регистрация успешна.

Пустые поля: Нажать кнопку, ничего не вводя. Должны появиться понятные предупреждения.

Некорректный телефон: Ввести буквы вместо цифр, ввести слишком короткий номер или слишком длинный.

Спецсимволы в имени: Что будет, если имя — это цифры или иероглифы? А если имя содержит 200 букв?

Повторная регистрация: Попробовать зарегистрироваться на тот же номер второй раз.

Прерывание процесса: Нажать кнопку и быстро закрыть вкладку. Что произойдет в базе данных? Создастся ли «битый» аккаунт?

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

Почему это лучший момент для старта

Сейчас индустрия проходит через этап трансформации. Компании осознали, что качество — это не роскошь, а условие выживания. Спрос на квалифицированных QA-инженеров стабильно превышает предложение.

Выбирая путь тестировщика, вы получаете: * Низкий (относительно программирования) порог входа. * Возможность работать удаленно из любой точки мира. * Понятный карьерный трек: от ручного тестирования к автоматизации или управлению командой. * Причастность к созданию продуктов, которыми пользуются миллионы людей.

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

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

Жизненный цикл разработки ПО (SDLC) и роль тестировщика на каждом этапе

Представьте, что вы решили построить загородный дом. Вряд ли вы начнете с того, что приедете в чистое поле с охапкой кирпичей и начнете их складывать. Сначала вы обсудите проект с архитектором, затем инженер проверит почву, строители заложат фундамент, и только потом начнется возведение стен. Если на этапе фундамента совершить ошибку, то когда вы дойдете до крыши, дом может просто рухнуть. Исправление такой ошибки на финише будет стоить дороже, чем весь дом.

Создание программного обеспечения (ПО) подчиняется тем же законам. Процесс превращения идеи заказчика в работающее приложение называется SDLC (Software Development Life Cycle) — жизненный цикл разработки программного обеспечения. Для тестировщика понимание SDLC — это не просто теоретическое знание, а карта местности. Если QA-инженер включается в работу только в самом конце, когда «дом уже построен», он обречен находить критические дефекты, которые потребуют колоссальных затрат на исправление.

Фундамент процесса: что такое SDLC и зачем он нужен

Жизненный цикл разработки — это последовательность этапов, через которые проходит программный продукт от момента возникновения идеи до его вывода из эксплуатации. Главная цель SDLC — создать качественный продукт в рамках установленного бюджета и сроков.

В индустрии существует множество моделей SDLC (например, каскадная модель Waterfall или гибкая методология Agile), но все они состоят из набора базовых этапов. Независимо от того, разрабатывает ли компания мобильный банк для «Сбера» или небольшое приложение для доставки еды, процесс всегда будет включать:

Сбор и анализ требований.

Проектирование (дизайн системы).

Разработку (написание кода).

Тестирование.

Внедрение (релиз).

Поддержку и сопровождение.

Главная проблема новичков в тестировании — убеждение, что их работа начинается на четвертом этапе. На самом деле, современный подход QA (Quality Assurance) подразумевает участие тестировщика с самого первого дня.

Этап 1: Сбор и анализ требований

Все начинается с идеи. Заказчик приходит к команде разработки и говорит: «Я хочу приложение, где люди смогут обмениваться фотографиями котов». На этом этапе бизнес-аналитики (BA) и менеджеры проектов (PM) собирают требования.

Требования бывают двух видов:

Функциональные: что система должна делать (например, «пользователь должен иметь возможность загрузить фото в формате JPEG»).

Нефункциональные: как система должна работать (например, «страница со списком котов должна загружаться не дольше 2 секунд при 1000 одновременных пользователей»).

Роль тестировщика на этапе требований

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

> Профилактика болезни всегда дешевле её лечения. В разработке ПО это правило работает буквально: ошибка, найденная в тексте требований, стоит условно 1 долл. Та же ошибка, найденная в коде, стоит 10 долл., а обнаруженная пользователями после релиза — 100 долл. и выше.

Пример из практики: В требованиях написано: «Система должна позволять пользователю вводить номер телефона для регистрации». Тестировщик задает уточняющие вопросы:

Номера каких стран поддерживаются?

Нужно ли вводить «+7» или можно начинать с «8»?

Что произойдет, если пользователь введет буквы вместо цифр?

Есть ли ограничение по количеству символов?

Если эти вопросы не задать сейчас, программист напишет код «как понял», а тестировщик потом создаст десяток баг-репортов, которые придется исправлять, переписывая уже готовый функционал.

Этап 2: Проектирование и дизайн

Когда требования утверждены, архитекторы и системные дизайнеры начинают планировать, как приложение будет устроено внутри. Выбирается база данных, определяются языки программирования, рисуются макеты интерфейса (UI/UX).

Роль тестировщика на этапе проектирования

QA-инженер анализирует макеты и архитектурные решения на предмет тестопригодности (testability).

Удобно ли будет пользователю нажимать на эту кнопку?

Не перекрывает ли всплывающее окно важную информацию?

Предусмотрены ли в системе «крючки», за которые потом сможет зацепиться автотест?

Также на этом этапе начинается планирование самого тестирования. QA-лид или опытный тестировщик пишет Тест-план (Test Plan) — документ, который отвечает на вопросы: что мы тестируем, когда, какими инструментами и кто за это отвечает.

Этап 3: Разработка (Coding)

Это этап, где магия превращается в код. Программисты пишут модули системы, настраивают интеграции и создают интерфейс.

Роль тестировщика на этапе разработки

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

Кроме того, в продвинутых командах тестировщики на этом этапе могут помогать разработчикам в написании Unit-тестов (модульных тестов), которые проверяют маленькие кусочки кода в изоляции.

Этап 4: Тестирование (Execution)

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

Как проходит этот этап

Smoke-тестирование (Дымовое): Проверка самых критических функций. Если приложение даже не запускается или кнопка «Войти» не нажимается — билд «заворачивают» обратно разработчикам. Нет смысла тратить время на глубокие проверки, если база сломана.

Функциональное тестирование: Проверка соответствия приложения требованиям. Мы проходим по заранее написанным тест-кейсам.

Регрессионное тестирование: Самая объемная часть. Когда разработчик исправил баг в одном месте, он мог случайно сломать что-то в другом. Мы перепроверяем старый функционал, чтобы убедиться, что он все еще работает.

Фиксация багов: Каждый найденный дефект оформляется в баг-репорт.

Нюанс: Тестирование — это не только поиск ошибок, но и предоставление информации о состоянии продукта. Тестировщик говорит не «программа плохая», а «в программе найдено 5 критических ошибок, риск выпуска — высокий».

Этап 5: Внедрение и релиз (Deployment)

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

Роль тестировщика на этапе релиза

В момент релиза QA-инженер проводит Sanity-тестирование на реальной среде. Это быстрая проверка того, что при переносе кода с тестового сервера на рабочий ничего не потерялось, конфиги настроены верно и пользователи не увидят «белый экран».

В крупных российских компаниях, таких как Ozon или Wildberries, релизы могут происходить десятки раз в день. В таких условиях роль тестировщика смещается в сторону контроля автоматизированных пайплайнов — систем, которые сами прогоняют тесты перед выпуском кода.

Этап 6: Поддержка и сопровождение

После релиза жизнь продукта не заканчивается. Пользователи начинают находить специфические ошибки, которые не были выявлены в лаборатории (например, баг проявляется только на редкой модели китайского смартфона при слабом 3G-интернете в метро).

Роль тестировщика на этапе поддержки

Воспроизведение багов: Техподдержка присылает жалобу клиента, а тестировщик должен понять, как повторить эту ошибку у себя, чтобы передать её разработчику.

Тестирование обновлений: Любое исправление или новая фича запускает цикл заново (анализ требований -> разработка -> тестирование).

---

Сравнение моделей SDLC: Waterfall vs Agile

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

| Характеристика | Waterfall (Каскад) | Agile (Гибкая разработка) | | :--- | :--- | :--- | | Структура | Линейная: этапы строго друг за другом. | Итерационная: циклы по 2-4 недели (спринты). | | Когда начинается тестирование | В самом конце, после завершения всей разработки. | С первой итерации, параллельно с разработкой. | | Гибкость | Низкая. Изменения в требованиях стоят очень дорого. | Высокая. Можно менять приоритеты на ходу. | | Роль QA | «Контролер» на выходе. Часто становится «бутылочным горлышком». | Полноценный участник команды, участвует в планировании. |

В современных российских IT-реалиях 90% компаний работают по Agile (Scrum или Kanban). Это значит, что жизненный цикл сжимается до двухнедельного отрезка. За эти две недели команда должна успеть и обсудить задачу, и написать код, и протестировать его. Это требует от QA-инженера высокой скорости реакции и умения расставлять приоритеты.

Математика качества: Закон стоимости ошибки

Важно понимать, почему мы так стремимся «сдвинуть тестирование влево» (принцип Shift Left Testing), то есть начать его как можно раньше.

Рассмотрим условную формулу стоимости исправления дефекта:

где:

— итоговая стоимость исправления (Cost);

— базовая стоимость (затраты времени программиста на правку одной строки кода);

— порядковый номер этапа SDLC (1 — требования, 4 — тестирование, 5 — релиз).

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

Граничные случаи: когда SDLC идет не по плану

В реальности путь ПО не всегда такой гладкий. Тестировщик должен быть готов к ситуациям «Hotfix» (хотфикс).

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

Разработчик правит код за 15 минут.

Тестировщик за 5 минут проверяет только это исправление и самое важное рядом (Regression).

Код немедленно заливается на сервер.

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

Взаимодействие в команде: кто есть кто

Жизненный цикл ПО — это командная игра. Тестировщик постоянно взаимодействует с другими участниками:

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

С аналитиками: проясняет непонятные моменты в требованиях.

С дизайнерами: указывает на неудобства интерфейса.

С DevOps-инженерами: настраивает тестовые стенды и автоматизацию релизов.

Понимание SDLC делает вас не просто «человеком, который ищет баги», а инженером, который понимает бизнес-процессы. Вы начинаете видеть не просто кнопки и окна, а цепочку создания ценности для клиента.

В российских компаниях (таких как «Яндекс», «Тинькофф» или VK) процессы выстроены очень четко. Там ценят QA-специалистов, которые умеют мыслить на опережение: не ждать, пока прилетит задача «потыкай тут», а прийти на встречу по обсуждению новой фичи и сразу сказать: «Ребята, этот вариант не сработает, потому что он конфликтует с нашей системой лояльности, давайте переделаем требования сейчас».

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

Техники тест-дизайна: как проектировать эффективные проверки и находить скрытые дефекты

Представьте, что вам нужно проверить надежность обычного лифта в 25-этажном доме. В нем есть кнопки этажей, кнопки «отмена», «вызов диспетчера», датчики веса и фотоэлементы в дверях. Если вы решите проверить абсолютно все комбинации — например, нажатие кнопки 5-го этажа при условии, что в лифте стоит человек весом 72 кг, а на 10-м этаже в это время нажали кнопку вызова — количество тестов станет бесконечным. У тестировщика в IT-проекте ситуация идентичная: программный код содержит миллионы логических ветвлений. Если проверять всё подряд, релиз продукта не случится никогда.

Здесь на сцену выходит тест-дизайн — дисциплина, которая позволяет отобрать 10–20 самых эффективных проверок, способных выявить 99% критических ошибок, вместо того чтобы проводить тысячи бессмысленных тестов.

Искусство выбора: что такое тест-дизайн и почему он критичен

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

В условиях реальной разработки в российских компаниях (будь то крупный банк или небольшой стартап) ресурсы всегда ограничены. У вас есть два дня до релиза и приложение с сотней полей ввода. Без техник тест-дизайна вы либо пропустите критический баг, либо не успеете закончить проверку вовремя.

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

Классификация техник: от «черного ящика» до интуиции

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

Основные техники, которые составляют базу ежедневной работы:

Эквивалентное разделение (Equivalence Partitioning).

Анализ граничных значений (Boundary Value Analysis).

Таблица принятия решений (Decision Table).

Тестирование переходов состояний (State Transition Testing).

Попарное тестирование (Pairwise Testing).

Предугадывание ошибки (Error Guessing).

Рассмотрим каждую из них подробно, с примерами и нюансами, которые часто встречаются на собеседованиях и в реальных задачах.

Эквивалентное разделение: борьба с избыточностью

Суть этой техники в том, чтобы разделить все возможные входные данные на группы (классы), внутри которых программа ведет себя одинаково. Если мы проверим одно значение из группы и оно сработает верно, мы с высокой долей вероятности можем утверждать, что и все остальные значения из этой группы сработают так же.

> Эквивалентный класс — это набор данных, обработка которых программой приводит к одному и тому же логическому результату.

Рассмотрим пример: поле ввода возраста для оформления онлайн-кредита в российском банке. По условиям бизнес-требований, кредит выдается лицам от 18 до 65 лет включительно.

Какие классы эквивалентности мы здесь видим? * Класс 1: Слишком молодые (невалидный). Значения от 0 до 17. Ожидаемый результат: отказ в кредите или сообщение об ошибке. * Класс 2: Подходящий возраст (валидный). Значения от 18 до 65. Ожидаемый результат: переход к следующему шагу анкеты. * Класс 3: Слишком пожилые (невалидный). Значения от 66 и выше (до разумного предела, например, 120). Ожидаемый результат: отказ. * Класс 4: Некорректные данные (невалидный). Отрицательные числа, дробные числа, буквы, спецсимволы.

Вместо того чтобы вводить 18, 19, 20... 65 лет, мы выберем по одному представителю из каждого класса. Например: 10, 30, 75 и «abc». Всего 4 теста вместо бесконечности.

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

Анализ граничных значений: там, где прячутся баги

Если эквивалентное разделение помогает сократить количество тестов, то анализ граничных значений (BVA) помогает найти самые «сочные» баги. Программисты — тоже люди, и они часто ошибаются в условиях циклов и сравнений. Вместо ` (больше или равно) они могут написать (строго больше). В этом случае 18-летние пользователи внезапно не смогут получить услугу.

Граничные значения — это точки на краях классов эквивалентности. Опыт показывает, что ошибки чаще всего возникают именно на границах.

Вернемся к примеру с возрастом (18–65 лет). Границы здесь — это 18 и 65. Для каждой границы в классическом тест-дизайне принято проверять три точки:

Сама граница (Boundary).

Значение на единицу меньше (Boundary - 1).

Значение на единицу больше (Boundary + 1).

Для нашего примера набор тестов будет выглядеть так: * Вокруг нижней границы (18): проверяем 17, 18, 19. * Вокруг верхней границы (65): проверяем 64, 65, 66.

Почему это важно? Проверка 17 лет подтверждает, что доступ закрыт. Проверка 18 лет подтверждает, что доступ открыт (граница включена). Проверка 19 лет подтверждает, что внутри диапазона всё работает. Аналогично с верхней границей.

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

Таблица принятия решений: логика сложных условий

Иногда поведение системы зависит не от одного поля, а от комбинации условий. Например, расчет стоимости доставки в корзине маркетплейса: * Если сумма заказа > 3000 руб. И выбран самовывоз — доставка 0 руб. * Если сумма заказа > 3000 руб. И выбрана курьерская доставка — доставка 0 руб. * Если сумма заказа руб. И выбран самовывоз — доставка 100 руб. * Если сумма заказа руб. И выбрана курьерская доставка — доставка 300 руб.

Если условий станет больше (например, добавляется статус «VIP-клиент» или «регион доставки»), запутаться в тест-кейсах очень легко. Таблица принятия решений помогает структурировать эту логику.

| Условия | Тест 1 | Тест 2 | Тест 3 | Тест 4 | | :--- | :---: | :---: | :---: | :---: | | Сумма > 3000 | Да | Да | Нет | Нет | | Самовывоз | Да | Нет | Да | Нет | | Результат (Цена) | 0 | 0 | 100 | 300 |

Каждый столбец такой таблицы — это готовый тест-кейс. Эта техника позволяет увидеть пропущенные комбинации. Например, что будет, если сумма ровно 3000? (Тут мы снова вспоминаем про граничные значения).

Тестирование переходов состояний: жизненный путь объекта

Некоторые системы ведут себя как «автоматы». Их реакция зависит от того, что происходило с ними раньше. Классический пример — статус заказа в интернет-магазине. Заказ не может сразу стать «Доставленным», он должен сначала быть «Создан», затем «Оплачен», потом «Передан в доставку».

Техника State Transition Testing визуализирует эти переходы. Мы рисуем граф (схему), где узлы — это состояния, а стрелки — действия (события). Тестировщик должен проверить:

Все валидные переходы (из «Создан» в «Оплачен»).

Невалидные переходы (попытка отменить уже «Доставленный» заказ).

Состояние объекта после перехода (действительно ли в базе данных сменился статус).

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

Попарное тестирование (Pairwise): магия комбинаторики

Представьте форму настройки фильтров в поиске жилья. У вас есть: * Тип жилья (Квартира, Дом, Комната — 3 варианта). * Количество комнат (1, 2, 3, 4+ — 4 варианта). * Тип сделки (Купля, Аренда — 2 варианта). * Наличие балкона (Да, Нет — 2 варианта).

Общее количество комбинаций: тестов. А если параметров 10? Количество тестов растет экспоненциально.

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

Техника Pairwise позволяет проверить все возможные пары значений. Для нашего примера это сократит количество тестов с 48 до примерно 12–15, при этом эффективность поиска багов останется почти такой же высокой. Для генерации таких тестов QA-инженеры обычно используют специальные инструменты (например, PICT от Microsoft или онлайн-сервисы), так как составлять такие пары вручную очень трудозатратно.

Предугадывание ошибки и исследовательское тестирование

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

Опытный QA знает, что: * Если в поле можно загрузить файл, нужно попробовать загрузить пустой файл, файл размером 0 Кб или файл на 10 Гб. * Если есть форма ввода имени, стоит попробовать ввести туда скрипт (XSS-атака) или очень длинную строку из китайских иероглифов. * Если нажать кнопку «Оплатить» дважды очень быстро, система может списать деньги два раза (проблема race condition).

Это не хаотичные действия, а структурированный подход. Тестировщик составляет список потенциально проблемных мест (Error List) и проверяет их.

Практическое применение: кейс «Форма регистрации»

Давайте соберем всё воедино на реальном примере. Нам нужно протестировать поле «Пароль» при регистрации. Требования: * Длина от 8 до 16 символов. * Должен содержать минимум одну цифру и одну заглавную букву.

Применяем тест-дизайн:

Эквивалентное разделение:

* Валидный пароль (например, Password123). * Слишком короткий (6 символов). * Слишком длинный (20 символов). * Без цифр. * Без заглавных букв.

Граничные значения (для длины):

* Нижняя граница: 7, 8, 9 символов. * Верхняя граница: 15, 16, 17 символов.

Error Guessing:

* Пароль, состоящий только из пробелов. * Вставка пароля из буфера обмена (Ctrl+V) длиной в 1000 символов. Использование спецсимволов (!@#$%^&()_+`), если про них ничего не сказано в требованиях.

В итоге вместо случайных попыток мы получаем четкий список из 10–12 тестов, которые гарантируют, что логика поля «Пароль» проверена вдоль и поперек.

Документирование результатов тест-дизайна

Проектирование тестов не заканчивается в голове тестировщика. Результаты должны быть зафиксированы. В зависимости от процессов в компании, это могут быть: * Чек-листы: краткие списки проверок («Проверить пароль 8 симв.», «Проверить пароль 16 симв.»). Подходят для быстрых проектов. * Тест-кейсы: подробные инструкции с шагами и ожидаемым результатом. Необходимы для сложных систем и регрессионного тестирования. * Матрица трассируемости (Traceability Matrix): таблица, которая связывает требования бизнеса с конкретными тест-кейсами. Она позволяет убедиться, что ни одно требование не осталось без проверки.

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

Психология и ловушки тест-дизайна

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

Поэтому техники тест-дизайна нужно применять гибко: * Регулярно пересматривать наборы тестов. * Добавлять новые проверки на основе найденных пользователями ошибок (Post-release баги). * Комбинировать техники. Нельзя полагаться только на границы, забывая о логических таблицах.

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

Роль тест-дизайна в автоматизации

Многие думают, что автоматизация — это просто написание кода. На самом деле, 70% успеха автотестов зависит от качественного тест-дизайна. Если вы автоматизируете плохие, избыточные или логически неверные тесты, вы просто будете быстрее получать бесполезные результаты.

Автоматизатор использует те же техники: * Эквивалентные классы помогают выбрать данные для Data-Driven тестирования (когда один код теста прогоняется на разных наборах данных). * Анализ переходов состояний ложится в основу тестов жизненного цикла API.

Понимание тест-дизайна — это то, что отличает «инженера по качеству» от «человека, который умеет писать на Python».

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

Артефакты тестирования: правила создания профессиональных тест-кейсов, чек-листов и баг-репортов

Представьте, что вы заказали сложный шкаф в мебельном ателье. Мастер приехал, что-то измерил «на глаз», записал на обрывке газеты и уехал. Через неделю вам привозят гору досок, которые не влезают в комнату, а дверцы открываются внутрь. На ваш резонный вопрос «Почему так?» мастер отвечает: «Я так запомнил». В IT-индустрии цена такой «памяти» исчисляется миллионами рублей и сорванными сроками. Чтобы разработка не превратилась в хаос, QA-инженер использует артефакты — специальные документы, которые фиксируют, что именно мы проверяем, как мы это делаем и какие ошибки нашли.

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

Чек-листы: быстрый старт и верхнеуровневый контроль

Чек-лист — это самый простой и лаконичный вид тестовой документации. По сути, это список того, что должно быть проверено, без подробных инструкций «как именно». Если проводить аналогию с повседневной жизнью, то чек-лист — это список покупок в супермаркете. Там написано «Молоко», но не указано: «Подойдите к холодильнику №3, протяните правую руку, возьмите пакет жирностью 3.2%». Вы и так знаете, как покупать молоко.

В тестировании чек-листы используются в ситуациях, когда:

Продукт часто меняется, и писать подробные кейсы нет смысла (они устареют завтра).

Тестировщики отлично знают продукт и им не нужны подсказки по каждому шагу.

Нужно быстро провести проверку (например, Sanity-тестирование после хотфикса).

Структура идеального чек-листа

Хороший чек-лист состоит из кратких пунктов, сформулированных в утвердительной форме или как действие. Например, вместо «Проверить логин» лучше написать «Авторизация с валидными данными» или «Логин в систему под администратором».

Основные правила оформления: * Группировка: Разделяйте пункты по смысловым блокам (например: «Форма регистрации», «Личный кабинет», «Корзина»). * Атомарность: Один пункт — одна проверка. Не стоит писать «Проверить поиск, фильтрацию и сортировку». Если поиск работает, а фильтрация — нет, какой статус вы поставите этому пункту? * Результат: У каждого пункта должен быть статус (Passed — пройдено, Failed — не пройдено, Skipped — пропущено).

> Пример чек-листа для формы восстановления пароля: > 1. Отправка письма на существующий e-mail. > 2. Отправка письма на несуществующий e-mail. > 3. Валидация поля e-mail (некорректный формат). > 4. Переход по ссылке из письма (срок действия не истек). > 5. Переход по просроченной ссылке. > 6. Установка нового пароля (соответствие требованиям сложности).

Главный риск чек-листов — субъективность. Если в команде появится новичок, пункт «Проверить интеграцию с банком» может поставить его в тупик. Именно поэтому для критически важных функций или сложных процессов мы переходим к «тяжелой артиллерии» — тест-кейсам.

Тест-кейсы: детальный сценарий проверки

Тест-кейс (Test Case) — это подробная инструкция, которая описывает совокупность условий и шагов, необходимых для проверки реализации конкретной функции. Если чек-лист — это список покупок, то тест-кейс — это сложный рецепт молекулярной кухни, где важен каждый грамм и каждая секунда.

Зачем такая детализация?

Воспроизводимость: Любой человек (даже не тестировщик) должен иметь возможность пройти по вашим шагам и получить тот же результат.

Доказательная база: В случае споров с разработчиком («У меня всё работает!»), тест-кейс служит эталоном того, как должна вести себя система.

Основа для автоматизации: Автотесты пишутся именно на базе готовых, выверенных тест-кейсов.

Анатомия профессионального тест-кейса

Профессиональный тест-кейс в таких системах, как Jira (с плагином Zephyr или Xray) или Test IT, всегда имеет четкую структуру.

ID и Заголовок (Summary): Краткое описание того, что мы проверяем. Заголовок должен отвечать на три вопроса: Что? Где? При каких условиях?

Плохо:* «Проверка корзины». Хорошо:* «Добавление товара в корзину неавторизованным пользователем из карточки товара».

Приоритет (Priority): Насколько важна эта проверка (High, Medium, Low).

Предусловия (Preconditions): Состояние системы перед началом теста. Нужно ли залогиниться? Должны ли быть деньги на счету? Какая версия приложения установлена?

Шаги (Steps): Пронумерованная последовательность действий. Пишем в повелительном наклонении: «Нажать», «Ввести», «Перейти». Избегайте лишних слов («Пожалуйста, попробуйте нажать на кнопку»).

Ожидаемый результат (Expected Result): Описание того, как система должна отреагировать на действия. Важно: ожидаемый результат пишется для каждого шага или для всего кейса в конце.

Постусловия (Postconditions): Описание того, как вернуть систему в исходное состояние (например, удалить созданный тестовый аккаунт).

Правила «хорошего тона» при написании шагов

При написании шагов важно соблюдать баланс между краткостью и понятностью. Используйте общепринятую терминологию.

Если в вашем кейсе 25 шагов, значит, вы пытаетесь проверить слишком много вещей сразу. Разбейте его на несколько маленьких кейсов. Это упростит локализацию ошибки: если тест упадет на 20-м шаге, вам придется долго разбираться, в чем именно проблема.

Пример тест-кейса: * Заголовок: Оплата заказа картой МИР при выборе курьерской доставки. * Предусловия: Пользователь авторизован, в корзине есть товар «Смартфон», баланс карты достаточен. * Шаги: 1. Перейти в корзину. 2. Нажать кнопку «Оформить заказ». 3. Выбрать способ доставки «Курьером». 4. Выбрать способ оплаты «Картой онлайн». 5. Ввести реквизиты тестовой карты МИР. 6. Нажать «Оплатить». * Ожидаемый результат: Появляется сообщение «Заказ успешно оплачен», статус заказа в личном кабинете меняется на «Оплачен».

Баг-репорты: искусство сообщать о проблемах

Если тест-кейс не прошел (фактический результат не совпал с ожидаемым), рождается баг-репорт. Это, пожалуй, самый важный документ в работе QA. От того, насколько грамотно он составлен, зависит, как быстро разработчик исправит ошибку и не возникнет ли между вами конфликта.

Баг-репорт — это техническое задание на исправление ошибки. Его главная цель: сделать так, чтобы разработчик смог воспроизвести баг на своем компьютере без лишних вопросов.

Атрибуты баг-репорта

Заголовок (Summary): Снова правило «Что? Где? Когда (при каких условиях)?».

Пример:* «Кнопка 'Купить' не активна при выборе цвета 'Красный' в карточке товара iPhone 15».

Серьезность (Severity): Влияние бага на бизнес-логику и работоспособность системы.

* Blocker: Система не работает совсем (белый экран, невозможно зайти). * Critical: Основная функция не работает, обходного пути нет (нельзя оплатить заказ). * Major: Важная функция работает неправильно, но есть сложный обходной путь. * Minor: Незначительная проблема (опечатка, съехавшая верстка). * Trivial: Почти незаметный дефект (не тот оттенок синего на иконке).

Приоритет (Priority): Очередность исправления. Обычно выставляется менеджером, но QA дает рекомендацию.

Окружение (Environment): На каком устройстве, в каком браузере и на какой операционной системе найден баг.

Пример:* Windows 11, Google Chrome v.124, Stand (тестовый сервер) №2.

Шаги воспроизведения (Steps to Reproduce): Точный алгоритм, приводящий к ошибке.

Фактический результат (Actual Result): Что произошло на самом деле.

Ожидаемый результат (Expected Result): Как должно быть согласно документации.

Вложения (Attachments): Скриншоты, видео (лонгриды никто не любит, видео на 10 секунд лучше тысячи слов) или логи сервера.

Тонкости локализации бага

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

Представьте: вы кликнули на кнопку 10 раз, перешли на другую страницу, вернулись, сменили язык, и тут приложение упало. Значит ли это, что все эти действия нужны для падения? Скорее всего, нет. Попробуйте воспроизвести баг заново, отсекая лишнее. Если баг воспроизводится просто по нажатию на кнопку — пишите только это. Разработчик скажет вам «спасибо» за сэкономленное время.

Также важно проверить воспроизводимость. Если баг случился один раз из десяти — это «плавающий» баг. Его всё равно нужно завести, но обязательно указать частоту появления (например, «воспроизводится в 30% случаев»).

Жизненный цикл бага

Баг-репорт — это «живой» документ. В системе трекинга задач (например, Jira) он проходит через несколько статусов:

New (Новый): Тестировщик только что создал баг.

Open (Открыт): Менеджер или техлид подтвердили, что это действительно баг, и он принят в работу.

In Progress (В работе): Разработчик пишет код для исправления.

Fixed (Исправлен): Разработчик утверждает, что починил баг.

Ready for QA / Re-test (Готов к проверке): Мяч снова на стороне тестировщика. Вы должны проверить исправление.

Verified / Closed (Подтвержден / Закрыт): Вы проверили, баг больше не воспроизводится.

Reopened (Переоткрыт): Вы проверили, но баг всё еще на месте. Это печальный статус для разработчика, означающий, что фикс не сработал.

> Важный нюанс: при проверке исправленного бага (Re-test) профессионал всегда делает еще и регрессионное тестирование связанных функций. Исправив кнопку в корзине, разработчик мог случайно «отломать» применение промокодов, так как они используют общий кусок кода.

Специфика документации в российских компаниях

В РФ культура работы с артефактами зависит от размера компании. В крупных корпорациях (банки, ритейл-гиганты) часто требуют строгого следования ГОСТам или внутренним регламентам. Там тест-кейсы могут быть очень формализованными.

В небольших стартапах или гибких Agile-командах предпочтение отдается чек-листам и «легким» баг-репортам. Однако, вне зависимости от размера компании, ценится единый стиль.

Несколько советов для российского рынка:

Язык: Если команда русскоязычная, пишите артефакты на русском, но используйте устоявшиеся англицизмы (логин, фича, билд, деплой). Это звучит профессиональнее, чем «входное имя» или «развертывание сборки».

Инструменты: В РФ сейчас активно внедряются отечественные системы управления тестированием (TMS), такие как Test IT или QASpace, взамен ушедших западных аналогов. Принципы работы в них идентичны, но интерфейс будет на русском языке.

Связи: Всегда привязывайте баг-репорт к конкретному тест-кейсу, а тест-кейс — к требованию в Jira. Это создает «матрицу трассируемости», о которой мы говорили в прошлой главе. Менеджер должен видеть: «Ага, у нас не покрыто тестами требование №5, а по требованию №3 висит два критических бага».

Как не превратить документацию в «кладбище знаний»

Главная проблема артефактов — их актуальность. Продукт меняется, кнопки переезжают, логика обновляется. Если ваши тест-кейсы описывают версию приложения годовой давности, они бесполезны.

Чтобы этого избежать:

Регулярная ревизия: Раз в квартал или после крупных релизов просматривайте базу тестов и удаляйте неактуальное.

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

Принцип разумной достаточности: Не описывайте очевидные вещи. Если кнопка «ОК» закрывает окно — это стандарт поведения ОС, на это не всегда нужен отдельный тест-кейс.

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

Тестирование веб-приложений: архитектура браузера и практическое применение инструментов DevTools

Вы когда-нибудь задумывались, что происходит в ту долю секунды, когда вы нажимаете кнопку «Оплатить» в интернет-магазине? Для обычного пользователя это магия: страница обновляется, и появляется надпись «Заказ принят». Для QA-инженера это сложнейший процесс обмена данными между браузером и сервером. Если на этом этапе что-то пойдет не так — например, кнопка нажмется дважды или данные карты «утекут» в открытом виде — бизнес понесет огромные убытки. Чтобы находить такие ошибки, тестировщику недостаточно просто смотреть на интерфейс. Нужно понимать, как «думает» браузер, и уметь заглядывать ему «под капот».

Как работает веб: модель клиент-серверной архитектуры

Прежде чем открывать инструменты отладки, важно разобраться в фундаменте. Любое веб-приложение — это диалог двух сторон: клиента и сервера.

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

В тестировании веба всё работает по этой же схеме:

Frontend (Фронтенд) — это всё, что вы видите в браузере. Кнопки, формы, анимации, шрифты. Это «лицо» приложения, написанное на языках HTML, CSS и JavaScript.

Backend (Бэкенд) — это логика, которая живет на удаленном сервере. Она проверяет ваш пароль, считает скидку в корзине, связывается с банком для оплаты.

HTTP-протокол — это «язык», на котором общаются клиент и сервер.

Тестировщик веба работает на стыке этих миров. Иногда баг выглядит как кривая кнопка (проблема фронтенда), а иногда как бесконечная загрузка страницы (проблема связи или бэкенда). Чтобы понять, кто виноват, нам нужен главный инструмент — Chrome DevTools.

Знакомство с Chrome DevTools: пульт управления реальностью

Chrome DevTools — это встроенный в браузер набор инструментов для разработчиков и тестировщиков. Чтобы открыть его в Google Chrome (или любом браузере на движке Chromium, например, Яндекс.Браузере), достаточно нажать F12 или Ctrl + Shift + I (Cmd + Opt + I на Mac).

Для QA-инженера это не просто панель с кодом, а «рентгеновский аппарат». Мы будем использовать его, чтобы: * Проверять верстку и стили. * Имитировать медленный интернет или мобильные устройства. * Перехватывать запросы к серверу. * Анализировать ошибки в коде JavaScript.

Рассмотрим основные вкладки, которые станут вашим рабочим местом на 80% времени.

Вкладка Elements: анатомия страницы

Здесь отображается DOM (Document Object Model) — иерархическая структура страницы. Если HTML — это чертеж здания, то DOM — это само здание, которое браузер построил в своей памяти.

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

> Важно: Любые изменения в DevTools происходят только в вашем браузере. Стоит обновить страницу — и всё вернется в исходное состояние. Это безопасно: вы не «сломаете» сайт для других пользователей, но сможете быстро проверить свою гипотезу об ошибке.

Типичный кейс для QA: Вам нужно проверить, как форма регистрации ведет себя при вводе очень длинного имени (например, 200 символов). Вместо того чтобы просить разработчика изменить код, вы находите поле ввода в Elements, временно убираете у него атрибут maxlength="50" и вставляете свой текст. Если верстка «поплыла» — вы нашли баг.

Вкладка Console: бортовой журнал

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

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

Вкладка Network: сердце тестирования

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

Когда вы открываете Network и загружаете страницу, вы видите таблицу. Каждый ряд — это отдельный файл или запрос данных. Для тестировщика критически важны следующие колонки: * Name: название ресурса (например, login или get_user_info). * Status: HTTP-код ответа. * Type: что это было (картинка, скрипт или запрос данных fetch/XHR). * Time: сколько времени заняла загрузка.

Именно в Network мы ловим баги интеграции. Например, фронтенд отправил правильные данные пользователя, а бэкенд вернул ошибку 500 Internal Server Error. Без этой вкладки вы бы просто увидели надпись «Что-то пошло не так» и не смогли бы составить качественный баг-репорт.

Глубокое погружение в Network: анализ HTTP-запросов

Чтобы эффективно использовать вкладку Network, нужно понимать структуру HTTP-запроса. Представьте его как почтовое отправление.

1. Запрос (Request)

Когда браузер обращается к серверу, он отправляет: * URL: адрес (куда идем?). * Method: метод (что делаем?). Основные методы: * GET — получить данные (например, список товаров). * POST — отправить новые данные (например, создать заказ). * PUT/PATCH — обновить данные. * DELETE — удалить что-то. * Headers (Заголовки): служебная информация (какой у нас браузер, в каком формате мы ждем ответ, есть ли у нас права доступа — токены авторизации). * Payload (Тело запроса): сами данные. Если вы регистрируетесь, в Payload будут ваш email и пароль.

2. Ответ (Response)

Сервер обрабатывает запрос и возвращает: * Status Code: статус-код (получилось или нет). * Headers: информация от сервера. * Preview/Response: тело ответа. Чаще всего это формат JSON — структурированный текст, который легко читается и машиной, и человеком.

Пример из практики: Вы тестируете поиск на сайте. Вводите слово «Смартфон», но результатов нет.

Открываете Network.

Смотрите запрос к поисковому серверу.

Видите в Payload: search_term: "Смартфон". Значит, фронтенд отработал верно.

Переходите во вкладку Response и видите: {"items": [], "total": 0}.

Вывод: данные ушли правильно, но сервер вернул пустой список. Баг на стороне бэкенда или базы данных.

Коды ответов сервера: краткий справочник QA

Статус-коды — это универсальный язык интернета. Они делятся на группы по первой цифре. Знать их — обязанность любого тестировщика.

| Группа | Значение | Примеры для QA | | :--- | :--- | :--- | | 2xx | Успех | ` — всё прошло отлично. — объект успешно создан (например, новый аккаунт). | | 3xx | Перенаправление | — страница переехала. Браузер автоматически перейдет по новому адресу. | | 4xx | Ошибка клиента | — вы отправили «кривые» данные. — забыли войти в систему. — страница не существует. | | 5xx | Ошибка сервера | — «упал» код на сервере. — сервер перегружен или на обслуживании. |

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

Эмуляция устройств и условий сети

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

В DevTools есть иконка Device Toolbar (маленький значок телефона и планшета). Она позволяет:

Выбрать модель устройства: iPhone, Samsung Galaxy, iPad. Браузер изменит размер экрана и подменит данные о себе (User-Agent).

Проверить адаптивность: как ведут себя элементы при повороте экрана (Landscape/Portrait).

Throttling (Ограничение скорости): в списке Network можно выбрать режим Fast 3G, Slow 3G или даже Offline.

Зачем это нужно? Многие баги проявляются только на медленном интернете. Например, пользователь нажимает кнопку «Оплатить», из-за медленной сети ничего не происходит, он нажимает еще пять раз... И в итоге у него списываются деньги пять раз. Хороший QA проверит этот сценарий в режиме Slow 3G и убедится, что кнопка блокируется (становится неактивной) сразу после первого нажатия.

Работа с хранилищами данных: Application

Вкладка Application позволяет заглянуть в «память» браузера. Сайт может хранить данные прямо на вашем компьютере, не отправляя их каждый раз на сервер.

Основные хранилища: * Cookies (Куки): небольшие фрагменты данных, которые сервер присылает браузеру. Чаще всего там хранится ID вашей сессии. Если вы удалите куки, сайт «забудет» вас, и придется логиниться заново. * Local Storage / Session Storage: более современные хранилища. Там могут лежать товары в корзине, выбранная темная тема или черновик статьи.

Кейс для тестировщика: Вы тестируете корзину. Добавили товар, закрыли вкладку, открыли снова — корзина пуста. Баг! Вы идете в Application -> Local Storage, смотрите на ключ cart_items и видите, что данные туда просто не записываются. Или записываются, но с ошибкой в формате. Это ценная информация для локализации дефекта.

Проверка безопасности и производительности

Хотя глубокое тестирование производительности и безопасности — это отдельные специализации, Junior QA должен знать основы.

Lighthouse: встроенный инструмент в DevTools, который делает аудит страницы. Он выставляет оценки по 100-балльной шкале за скорость загрузки, доступность (Accessibility) и SEO. Если страница грузится 10 секунд — это критический баг для бизнеса, так как пользователи просто уйдут.

Security: вкладка, которая показывает, всё ли в порядке с SSL-сертификатом (тот самый замочек в адресной строке). Если сертификат просрочен, браузер будет пугать пользователей сообщением «Ваше подключение не защищено».

Локализация бага: как понять, где ошибка?

Главный навык при работе с DevTools — это умение быстро определить «зону ответственности». Когда вы находите проблему, задайте себе три вопроса:

Вижу ли я ошибку в Console? Если да, и она касается JavaScript-файлов — скорее всего, это баг фронтенда.

Что в Network? Если запрос ушел правильный (проверьте Payload), а ответ пришел с ошибкой (500) или с неверными данными — это баг бэкенда. Если запрос вообще не ушел при нажатии кнопки — баг фронтенда.

Как это выглядит в Elements? Если функционал работает, но кнопка съехала или текст не читается — это баг верстки (CSS).

Пример сложного бага: В интернет-магазине не применяется промокод. * Вы вводите код, нажимаете «Применить». * В Network видите запрос POST /apply-promo. * В ответе сервера (Response) приходит: {"status": "success", "new_total": 1500}. * Но на экране цена по-прежнему 2000. * Диагноз: Бэкенд отработал честно, посчитал скидку и вернул её. Но фронтенд «забыл» обновить цифру в интерфейсе. Баг фронтенда.

Специфика тестирования в российских реалиях

При работе в российских компаниях (Яндекс, VK, банки, ритейл) есть свои нюансы использования DevTools: * Импортозамещение: Важно проверять работу сайтов не только в Chrome, но и в Яндекс.Браузере. У него тот же движок, но могут быть свои особенности в работе с государственными сертификатами безопасности (например, НУЦ Минцифры). * Региональность: Многие сервисы работают по всей России. В DevTools можно эмулировать разные геопозиции (Sensors -> Geolocation), чтобы проверить, правильно ли определяется город пользователя и стоимость доставки для Владивостока по сравнению с Москвой. * Медленные сети: Учитывая огромную территорию страны, тестирование в режиме Slow 3G критически важно для мобильных приложений и веб-версий, которыми будут пользоваться люди в регионах с нестабильным покрытием.

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

Освоение DevTools требует практики. Откройте любой популярный сайт, нажмите F12` и попробуйте проследить, какие запросы улетают при простом обновлении страницы. Посмотрите, как меняется DOM, когда вы открываете меню. Это и есть первый шаг к профессиональному пониманию того, как устроен современный веб.

Тестирование API: протокол HTTP и мастерство работы в Postman для проверки интеграций

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

Что такое API и почему его нельзя игнорировать

В предыдущих темах мы разбирали работу с интерфейсом (Frontend) и заглядывали «под капот» через DevTools. Однако современное приложение — это не монолитный кусок кода, а конструктор из множества сервисов. API (Application Programming Interface) — это интерфейс взаимодействия программ. Если UI (User Interface) создан для того, чтобы человек мог общаться с программой, то API создан для того, чтобы одна программа могла общаться с другой.

Для тестировщика API — это «черный ящик», у которого есть вход (запрос) и выход (ответ). Нам не обязательно знать, на каком языке написан код внутри сервера, нам важно, чтобы на конкретный запрос сервер отдавал корректные данные.

Почему тестирование API критически важно:

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

Изоляция ошибок. Если в приложении не нажимается кнопка, проблема может быть в цвете кнопки (фронтенд) или в том, что сервер не принимает данные (бэкенд). Тестируя API напрямую, мы сразу понимаем, где именно произошел сбой.

Безопасность. Часто злоумышленники обходят интерфейс и шлют запросы напрямую к API, пытаясь получить доступ к чужим данным. Тестировщик должен проверить, что API «отфутболивает» неавторизованных пользователей.

Скорость. Прогнать 100 тестов через API можно за несколько секунд, в то время как кликанье по интерфейсу займет часы.

Протокол HTTP: язык, на котором говорит интернет

Большинство современных API работают по протоколу HTTP (HyperText Transfer Protocol). Чтобы эффективно тестировать, нужно понимать анатомию HTTP-сообщения. Любое взаимодействие состоит из пары: Request (Запрос) и Response (Ответ).

Структура запроса (Request)

Когда мы отправляем запрос из Postman или браузера, он состоит из четырех ключевых элементов:

Метод (Method). Это глагол, который говорит серверу, что мы хотим сделать.

* GET — получить данные (например, список товаров). * POST — создать что-то новое (например, зарегистрировать пользователя). * PUT — заменить существующий объект целиком (обновить профиль). * PATCH — частично изменить объект (поменять только фамилию). * DELETE — удалить данные.

URL (Эндпоинт). Адрес, по которому «живет» нужная нам функция. Например, https://api.ozon.ru/v1/products.

Заголовки (Headers). Служебная информация. Здесь мы указываем, в каком формате шлем данные (например, Content-Type: application/json) или передаем токен для авторизации (Authorization: Bearer key123).

Тело запроса (Body). Сами данные. Обычно передаются в формате JSON. В GET-запросах тела обычно нет, данные передаются прямо в URL через параметры.

Структура ответа (Response)

Сервер, получив запрос, обязан ответить. Его ответ содержит:

Статус-код. Трехзначное число, которое сразу говорит о результате.

* 2xx (Success) — все хорошо. * 4xx (Client Error) — ошибка на нашей стороне (забыли поле, ошиблись в адресе). * 5xx (Server Error) — сервер «упал» или не справился.

Заголовки ответа. Информация от сервера (например, дата или тип кодировки).

Тело ответа. Данные, которые мы запрашивали, или описание ошибки.

Знакомство с Postman: ваш главный рабочий инструмент

Postman — это самая популярная программа для тестирования API. Представьте её как продвинутый браузер, который умеет отправлять любые типы запросов, сохранять их в папки, подставлять переменные и даже писать автотесты на языке JavaScript.

Коллекции и переменные

В реальной работе у вас не один запрос, а сотни. В Postman они организуются в Collections (Коллекции). Например, коллекция «Авторизация», коллекция «Корзина», коллекция «Личный кабинет».

Одна из самых мощных функций — Variables (Переменные). Представьте, что у вас есть три тестовых стенда: dev, staging и production. Чтобы не менять адрес сервера в каждом из 50 запросов вручную, вы создаете переменную {{base_url}}. При смене окружения вы просто меняете значение переменной в одном месте, и оно обновляется везде.

Работа с параметрами: Query и Path

Часто нам нужно уточнить запрос. Для этого используются параметры: * Query-параметры. Идут после знака вопроса в URL: .../products?category=electronics&sort=price_desc. Они нужны для фильтрации и сортировки. * Path-параметры. Являются частью пути: .../users/123/orders. Здесь 123 — это ID конкретного пользователя. В Postman такие параметры часто записываются через двоеточие: .../users/:userId.

Практический кейс: Тестирование интернет-магазина «Книжный червь»

Давайте разберем пошагово, как тестировщик проверяет API на конкретном примере. Наша задача — проверить создание нового заказа.

Шаг 1: Авторизация и получение токена

Прежде чем что-то купить, система должна понять, кто мы.

Создаем POST запрос на эндпоинт /api/v1/login.

В Body (в формате JSON) передаем логин и пароль:

Отправляем. В ответ сервер присылает статус 200 OK и тело с токеном:

Этот токен — наш «пропуск». Мы копируем его и вставляем в заголовки (Headers) всех последующих запросов как Authorization.

Шаг 2: Создание заказа (Позитивный сценарий)

Теперь мы хотим купить книгу.

Создаем POST запрос на /api/v1/orders.

В Headers добавляем токен.

В Body передаем ID книги и количество:

Ожидаемый результат: Статус 201 Created, в теле ответа — order_id.

Шаг 3: Тестирование негативных сценариев

Здесь начинается настоящая работа QA. Мы должны попытаться «сломать» систему. * Пустое тело. Что будет, если отправить пустой JSON? Сервер должен вернуть 400 Bad Request, а не «упасть» с пятисотой ошибкой. * Несуществующий товар. Передаем book_id: 999999. Ожидаем 404 Not Found. * Отрицательное количество. Передаем quantity: -5. Бизнес-логика должна это запрещать. Ожидаем 422 Unprocessable Entity с понятным описанием ошибки: «Количество не может быть меньше 1». * Просроченный токен. Проверяем, что если токен невалиден, сервер вернет 401 Unauthorized.

Углубление: Специфика тестирования интеграций

API — это всегда мост между двумя системами. Часто баги возникают на стыке, когда одна система ожидает данные в одном формате, а другая присылает в другом. Это называется проблемой контрактов.

Валидация схемы JSON

Когда мы получаем ответ от API, нам важно не просто увидеть цифру 200, но и убедиться, что структура данных верна. Например, что поле price — это всегда число, а не строка "100 руб", и что поле email всегда присутствует. В Postman это проверяется во вкладке Tests с помощью небольших скриптов. Например:

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

Идемпотентность методов

Это сложное слово означает важное свойство: сколько бы раз мы ни вызывали один и тот же метод, результат должен быть предсказуемым. * GET — идемпотентен. Если вы 10 раз запросите список книг, список не должен измениться (если никто другой их не удалил). * DELETE — идемпотентен. Первый раз удалили — 204 No Content. Второй раз удаляем то же самое — 404 Not Found. Система не должна ломаться от повторного удаления. * POST — НЕ идемпотентен. Если вы 5 раз нажмете «Оплатить», и API не защищено, у пользователя может списаться оплата 5 раз. Тестировщик обязан проверять защиту от дублей (так называемый Request ID или Idempotency Key).

Нюансы работы в российских компаниях

В крупных российских IT-гигантах (Сбер, Яндекс, Тинькофф, Ozon) архитектура часто строится на микросервисах. Это значит, что одно приложение состоит из сотен маленьких API, которые общаются друг с другом.

В таких условиях тестировщику часто приходится:

Работать с Swagger (OpenAPI). Это интерактивная документация. Разработчики выкладывают туда описание всех методов API. Тестировщик идет в Swagger, смотрит, какие поля обязательны, и на основе этого составляет тест-кейсы в Postman.

Использовать логи. Если API вернуло 500 Internal Server Error, в теле ответа часто нет подробностей. Вам придется идти в системы сбора логов (например, Kibana или Graylog) и искать там техническую ошибку, которую выдал сервер в момент вашего запроса.

Тестировать интеграции с внешними сервисами. Например, интеграция с платежным шлюзом или сервисом доставки (Почта России, СДЭК). Для этого часто используются «заглушки» (Mocks) — специальные программы, которые имитируют ответ внешнего сервиса, чтобы мы могли протестировать свою логику, не тратя реальные деньги на тестовые транзакции.

Автоматизация в Postman: от ручных проверок к скриптам

Postman позволяет не просто нажимать кнопку Send, но и создавать цепочки запросов. Это первый шаг к автоматизации тестирования.

Представьте сценарий:

Создать пользователя.

Извлечь его ID из ответа.

Использовать этот ID в следующем запросе на получение профиля.

Удалить пользователя.

В Postman это делается через вкладку Scripts. В первом запросе мы пишем: pm.environment.set("current_user_id", pm.response.json().id); А во втором запросе в URL пишем: {{base_url}}/users/{{current_user_id}}. Теперь вы можете запустить всю коллекцию целиком через Runner, и Postman сам выполнит все шаги, проверив статусы ответов и структуру данных. Это экономит часы рутинной работы при каждой новой сборке (билде) приложения.

Чек-лист для тестирования любого API эндпоинта

Чтобы ничего не упустить, используйте этот список при проверке новой функции:

Позитивный сценарий: запрос с валидными данными возвращает успех (200 или 201) и корректное тело.

Обязательность полей: что будет, если не передать одно из обязательных полей? (Должна быть ошибка 400).

Типы данных: передача строки вместо числа, массива вместо объекта.

Длина значений: слишком короткие или аномально длинные строки (например, имя пользователя из 10 000 символов).

Авторизация: доступ без токена, с чужим токеном, с просроченным токеном.

Спецсимволы и SQL-инъекции: попытка передать в полях ввода кавычки, скобки или команды.

Граничные значения: если поле принимает число от 1 до 100, проверьте 0, 1, 100, 101.

Замыкание мысли

Тестирование API — это переход на новый уровень профессионализма. Если ручное тестирование интерфейса — это проверка «обертки», то тестирование API — это проверка самого «двигателя». Освоив Postman и протокол HTTP, вы перестанете зависеть от визуальной части приложения и сможете находить глубокие логические ошибки, которые стоят компаниям миллионы рублей. Помните: интерфейсы меняются часто, а логика API живет годами. Став экспертом в интеграциях, вы станете незаменимым звеном в любой команде разработки, будь то гибкий стартап или огромная корпорация.

Базы данных и SQL: написание запросов для извлечения и проверки данных

Представьте, что вы тестируете крупный российский маркетплейс, например, Ozon или Wildberries. Пользователь нажимает кнопку «Оплатить», и интерфейс радостно сообщает: «Заказ успешно оформлен!». В DevTools вы видите статус-код 200, а Postman подтверждает, что API отработал корректно. Означает ли это, что тестирование завершено? Профессиональный QA скажет: «Нет». Потому что информация о заказе могла отобразиться в браузере, но не дойти до склада, не списать товар из остатков или «потерять» примененную скидку по дороге в базу данных.

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

Почему QA-инженер не может обойтись без SQL

В повседневной работе Junior QA сталкивается с базами данных в трех основных сценариях.

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

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

В-третьих, это анализ причин багов. Если приложение выдает ошибку «Что-то пошло не так», SQL поможет понять: это сервер «упал» или в базе данных просто не хватает колонки, которую забыли добавить при обновлении?

Для общения с базами данных используется язык SQL (Structured Query Language). Это не язык программирования в привычном смысле, а язык декларативных запросов. Вы не объясняете компьютеру, как перебирать строки, вы просто говорите: «Дай мне имена всех пользователей, которые зарегистрировались вчера».

Реляционные базы данных: таблицы и связи

Большинство современных IT-систем в России (от банков до сервисов доставки) используют реляционные базы данных. Самые популярные — PostgreSQL, MySQL, Oracle и MS SQL Server. Слово «реляционные» происходит от английского relation (отношение). Это значит, что данные хранятся в виде связанных между собой таблиц.

Каждая таблица состоит из: * Столбцов (полей) — они определяют тип данных (текст, число, дата). Например, в таблице Users будут столбцы id, first_name, email. * Строк (записей) — это конкретные экземпляры данных. Одна строка — один пользователь.

Ключевым понятием здесь является Первичный ключ (Primary Key). Это уникальный идентификатор строки (обычно столбец id), который не может повторяться. Как номер паспорта у человека. Если у нас есть таблица Orders (Заказы), то там будет Внешний ключ (Foreign Key) — это user_id, который указывает на id конкретного человека в таблице Users. Именно так база «понимает», какой заказ кому принадлежит.

Извлечение данных: оператор SELECT и фильтрация

Самый частый запрос в арсенале тестировщика — это выборка данных.

Здесь SELECT — команда «выбери», * — «все столбцы», FROM users — «из таблицы users». Однако на реальных проектах в таблицах могут быть миллионы строк. Выгружать их все — значит «повесить» базу данных и получить нагоняй от системных администраторов. Поэтому QA всегда использует фильтрацию.

Фильтрация через WHERE

Предположим, нам нужно найти в базе баг: пользователь жалуется, что его статус в программе лояльности не изменился после покупки.

Оператор WHERE позволяет задавать условия. Мы можем использовать математические знаки сравнения: `, (в SQL пишется как <>), , , , .

Если условий несколько, на помощь приходят логические операторы: * AND — должны выполняться оба условия (например, пользователь активен И живет в Москве). * OR — хотя бы одно из условий (например, статус заказа «Новый» ИЛИ «В обработке»). * NOT — отрицание условия.

Поиск по шаблону: LIKE и IN

Иногда мы не знаем точного значения. Например, нужно найти всех пользователей с почтой на домене yandex.ru.

Знак % — это маска, означающая «любое количество любых символов». Если поставить % в начале и в конце (%ivan%), SQL найдет всех Иванов, Ивановичей и Иванидзе.

Если же нам нужно проверить конкретный набор статусов, вместо кучи OR удобнее использовать IN:

Агрегатные функции и группировка: считаем данные

Тестировщику часто нужно проверить статистику. Совпадает ли количество заказов в админ-панели с тем, что реально лежит в базе?

Основные функции: * COUNT() — количество строк. * SUM() — сумма значений в столбце. * AVG() — среднее значение. * MIN() / MAX() — минимальное и максимальное значения.

Пример: мы хотим узнать, сколько заказов сделал пользователь с id = 505.

Если же нам нужно получить отчет по всем пользователям сразу, используется GROUP BY. Это команда «разложи по кучкам».

База данных сначала разделит все заказы по user_id, а потом внутри каждой «кучки» посчитает количество строк. Если мы хотим отфильтровать результат этой группировки (например, найти только тех, у кого больше 10 заказов), мы не можем использовать WHERE, так как WHERE работает со строками до того, как их сгруппировали. Для этого существует HAVING.

Объединение таблиц: JOIN

Это самая сложная и важная часть SQL для QA. В реальности данные разбросаны по разным таблицам. В orders лежит дата заказа, а имя клиента — в users. Чтобы увидеть их вместе, таблицы нужно «склеить».

Существует несколько видов JOIN, но в 90% случаев вы будете использовать INNER JOIN и LEFT JOIN.

INNER JOIN (Внутреннее объединение)

Возвращает только те строки, для которых нашлось соответствие в обеих таблицах. Если у пользователя нет заказов, он не попадет в выборку. Если у заказа нет пользователя (что странно, но бывает при багах), он тоже не попадет в результат.

Здесь ON users.id = orders.user_id — это условие «склейки». Мы говорим базе: «Возьми строку из пользователей и приклей к ней строку из заказов там, где их ID совпадают».

LEFT JOIN (Левое объединение)

Возвращает все строки из левой таблицы (которая указана первой) и подходящие строки из правой. Если в правой таблице соответствия нет, там будут стоять пустоты (NULL).

Для тестировщика LEFT JOIN — это идеальный инструмент для поиска «потерянных» данных. Например, найти всех пользователей, которые зарегистрировались, но так и не сделали ни одного заказа:

Если orders.id равен NULL, значит, для этого пользователя в таблице заказов ничего не нашлось. Это отличный кейс для маркетинговых проверок.

Изменение данных: INSERT, UPDATE, DELETE

Хотя основная работа QA — это чтение (SELECT), иногда на тестовых стендах нужно подправить данные вручную.

INSERT — добавление новой записи.

UPDATE — обновление существующих данных. Внимание! Всегда используйте WHERE с UPDATE. Если вы забудете написать WHERE id = 5, вы обновите данные у всех миллионов пользователей в базе. Это классическая ошибка новичка, которая может «положить» тестовый стенд на полдня.

DELETE — удаление данных. Здесь правило про WHERE еще строже. Обычно в крупных компаниях данные не удаляют физически, а просто меняют им статус на is_deleted = true (так называемое «мягкое удаление»), чтобы сохранить историю.

Нюансы работы с типами данных и NULL

В тестировании важно понимать, как база хранит информацию.

Числа vs Строки. Если вы ищете id = 10, база поймет вас. Но если вы ищете строку name = Ivan без кавычек, SQL выдаст ошибку. Текстовые значения всегда пишутся в одинарных кавычках.

NULL — это не ноль. NULL — это отсутствие значения, «пустота».

* 0 = 0 — это истина. * NULL = NULL — это ложь (или, точнее, UNKNOWN). Для проверки на пустоту в SQL используются специальные операторы IS NULL и IS NOT NULL.

Даты. Формат даты в разных базах может отличаться, но чаще всего это 'YYYY-MM-DD'. Если вы тестируете функционал, завязанный на часовых поясах (например, время доставки), обязательно проверяйте, в каком часовом поясе база сохраняет время (обычно это UTC).

Практический кейс: Тестирование системы скидок

Давайте разберем реальную задачу. Вы тестируете акцию: «Скидка 20% на первый заказ для пользователей из Санкт-Петербурга».

Ваш алгоритм проверки через SQL:

Подготовка: Вы создаете в интерфейсе нового пользователя, указываете город СПб.

Действие: Делаете первый заказ на сумму 1000 руб.

Проверка в базе:

* Сначала проверяете таблицу users: записался ли город корректно? * Затем проверяете таблицу orders: применилась ли скидка? Здесь мы использовали подзапрос — это когда результат одного запроса подставляется в другой. Если total_amount равен 800, а discount_amount — 200, тест пройден. * Негативный тест: Вы создаете второго пользователя из Москвы и проверяете, что у него скидка 0. Если база начислила скидку москвичу — вы нашли баг, который пропустил фронтенд (например, фронтенд просто скрыл иконку акции, но бэкенд все равно применил скидку).

Инструменты для работы с БД

В российских компаниях вы редко будете писать SQL в черном терминале. Обычно используются графические клиенты: * DBeaver — универсальный и бесплатный инструмент, «швейцарский нож» для QA. Поддерживает почти все виды баз. * pgAdmin — специализированная утилита для PostgreSQL. * DataGrip — мощный платный инструмент от JetBrains (создателей IntelliJ IDEA).

Работа в них выглядит просто: вы вводите данные для подключения (хост, порт, логин, пароль), которые вам дает лид или разработчик, и видите дерево таблиц слева и окно для написания запросов справа.

Безопасность и этика при работе с БД

Работа с базой данных — это большая ответственность. Даже на тестовом стенде (Staging или Pre-prod) данные могут быть «обезличенными» копиями реальных данных клиентов.

Никогда не выполняйте запросы на Production (живой базе). У Junior QA обычно и нет туда доступа, но если вдруг есть — забудьте про UPDATE и DELETE. Любая ошибка может стоить компании миллионов рублей и репутации.

Осторожно с SELECT *. Если в таблице 100 столбцов, среди которых есть тяжелые картинки или длинные тексты, такой запрос может затормозить работу всей команды. Выбирайте только нужные поля: SELECT id, status....

Транзакции. Если вам нужно выполнить несколько связанных изменений, используйте транзакции. Команда BEGIN начинает транзакцию, а COMMIT подтверждает её. Если что-то пошло не так, команда ROLLBACK` откатит все изменения назад, как будто вы ничего не делали.

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