QA-инженер: Путь героя от новичка до Middle в реальных проектах

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

1. Погружение в IT: Роль QA, жизненный цикл ПО и твой первый рабочий день в симуляторе

Погружение в IT: Роль QA, жизненный цикл ПО и твой первый рабочий день в симуляторе

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

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

Готов? Надевай доспехи (или удобное худи), мы начинаем.

Уровень 1: QA, QC и Тестирование — в чем разница?

Прежде чем мы возьмем в руки меч (клавиатуру), давай разберемся с терминами. В вакансиях ты часто видишь QA (Quality Assurance), но иногда встречается QC (Quality Control) или просто Тестировщик. Это одно и то же? Нет.

Представь, что мы строим автомобиль на заводе.

1. Тестирование (Testing)

Это процесс проверки конкретной детали. Работает ли двигатель? Крутится ли колесо? Загорается ли фара, если нажать кнопку?

> Тестирование — это поиск несоответствия между тем, что ожидалось, и тем, что получилось по факту.

2. Контроль качества (QC — Quality Control)

Это проверка готового продукта или его части перед тем, как отдать его покупателю. QC-специалист проверяет, соответствует ли собранный автомобиль чертежам. Он не влияет на то, как собирали машину, он лишь отсеивает брак в конце конвейера.

3. Обеспечение качества (QA — Quality Assurance)

А вот это — твой уровень, уровень Героя. QA — это выстраивание процессов так, чтобы брак не появился вовсе. QA-инженер смотрит на чертежи до начала сборки и говорит: «Ребята, если мы поставим квадратные колеса, машина не поедет. Давайте исправим это сейчас».

Итог: * Тестировщик ищет баги. * QC проверяет продукт перед выпуском. * QA налаживает процесс разработки, чтобы багов было как можно меньше.

В реальности, будучи Junior QA, ты будешь заниматься и тестированием, и элементами QC, но твоя глобальная цель — мыслить как QA.

!Визуализация вложенности понятий: Тестирование является частью QC, а QC является частью QA

Уровень 2: Жизненный цикл ПО (SDLC)

Любая программа, будь то калькулятор или Instagram, проходит путь от идеи до смерти (или вечной поддержки). Этот путь называется SDLC (Software Development Life Cycle).

Понимание этого цикла — твоя карта местности. Если ты не знаешь, где находишься, ты не сможешь найти баги.

Основные этапы SDLC:

  • Идея и Планирование (Requirements). Заказчик говорит: «Хочу приложение для доставки еды дронами». Аналитики пишут требования.
  • Дизайн (Design). Дизайнеры рисуют, как это будет выглядеть, а архитекторы решают, какие базы данных использовать.
  • Разработка (Development). Программисты пишут код. Здесь магия превращается в реальность.
  • Тестирование (Testing). Сюда вступаешь ты. Ты проверяешь, летают ли дроны в приложении или падают при запуске.
  • Развертывание (Deployment). Продукт выпускают в мир (релиз).
  • Поддержка (Maintenance). Исправление ошибок, которые нашли пользователи, и добавление новых фич.
  • !Этапы жизненного цикла программного обеспечения

    Где место QA?

    Новичок скажет: «На этапе 4, Тестирование». Профессионал скажет: «На каждом этапе».

    * На этапе Идеи ты проверяешь требования: «А что будет, если дрон врежется в дерево? Это описано?» * На этапе Дизайна ты смотришь макеты: «Кнопка 'Купить' перекрывает текст, это неудобно». * На этапе Разработки ты готовишь тест-кейсы (сценарии проверки).

    Чем раньше ты найдешь ошибку, тем дешевле ее исправить. Исправить ошибку в требованиях стоит 1 доллар. Исправить ту же ошибку, когда код уже написан — 100 долларов. Исправить её после релиза, когда пользователи потеряли деньги — бесценно (в плохом смысле).

    Уровень 3: Симулятор — Твой первый рабочий день

    Добро пожаловать в компанию «PixelBank». Мы разрабатываем мобильный банк для геймеров. Ты только что устроился на позицию Junior QA Engineer. Волнуешься? Это нормально.

    Давай проживем этот день.

    09:00 — Утренний кофе и настройка окружения

    Ты приходишь в офис (или открываешь ноутбук дома). Твоим главным оружием будет не меч, а Баг-трекер (обычно это Jira). Это система, где хранятся все задачи.

    10:00 — Daily Scrum (Стендап)

    Вся команда собирается в кружок (или в Zoom) на 15 минут. Каждый отвечает на три вопроса:
  • Что я делал вчера?
  • Что я буду делать сегодня?
  • Есть ли у меня проблемы (блокеры)?
  • Твоя очередь: «Вчера я настраивал тестовое окружение. Сегодня планирую протестировать форму авторизации. Блокеров нет».

    11:00 — Получение задачи

    Ты открываешь Jira и видишь задачу (тикет):

    > Задача: Реализовать вход в приложение по номеру телефона. > Требования: > 1. Поле принимает только цифры. > 2. Длина номера — 11 знаков. > 3. Если номер верный — переход на экран ввода СМС.

    Разработчик перевел задачу в статус "Ready for QA" (Готово к тестированию). Это значит, что код написан, и теперь твоя очередь искать уязвимости.

    12:00 — Атака на форму (Тестирование)

    Ты берешь в руки телефон с установленным приложением (тестовая сборка). Как ты будешь проверять?

    Позитивное тестирование (Путь героя): Ты вводишь правильный номер (11 цифр) и нажимаешь «Войти». Перешел на экран СМС? Отлично. Основной сценарий работает.

    Негативное тестирование (Путь хаоса): А теперь ты пытаешься сломать систему. Ты задаешь себе вопросы: * А что, если я введу буквы? * А что, если я оставлю поле пустым? * А что, если я введу 100 цифр? * А что, если я выключу интернет и нажму кнопку?

    И вдруг... БАМ! Ты вводишь спецсимволы %%%, нажимаешь «Войти», и приложение вылетает (крашится).

    14:00 — Оформление баг-репорта

    Ты нашел баг! Это твоя первая добыча. Но просто крикнуть «Оно не работает!» нельзя. Нужно оформить протокол.

    Ты создаешь баг-репорт в Jira: * Заголовок: Приложение падает при вводе спецсимволов в поле телефона. * Шаги воспроизведения: 1. Открыть приложение. 2. Ввести %%% в поле телефона. 3. Нажать «Войти». * Ожидаемый результат: Появится сообщение «Введите корректный номер». * Фактический результат: Приложение закрывается с ошибкой.

    17:00 — Общение с разработчиками

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

    Твоя задача — мягко, но твердо объяснить, что пользователь может случайно нажать не туда, и приложение не должно от этого умирать. Это и есть Soft Skills (гибкие навыки), которые для QA важны не меньше, чем умение находить ошибки.

    Итоги дня

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

    Сегодня ты узнал:

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

    Отдыхай, герой. Завтра новый бой!

    2. Мастерская документации: Создаем чек-листы и тест-кейсы на примере реального интернет-магазина

    Мастерская документации: Создаем чек-листы и тест-кейсы на примере реального интернет-магазина

    Привет, герой! В прошлой битве ты спас мобильный банк «PixelBank» от краша, просто введя спецсимволы. Это была славная победа. Но представь, что перед тобой не одно поле ввода, а огромный интернет-магазин с тысячами товаров, корзиной, личным кабинетом и системой оплаты.

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

    Сегодня мы научимся создавать два главных артефакта тестировщика: Чек-лист и Тест-кейс. Нашим полигоном будет интернет-магазин геймерского мерча «LootShop».

    Уровень 1: Чек-лист (Checklist) — Список твоих подвигов

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

    * Купить хлеб * Купить молоко * Захватить зелье маны

    В тестировании это и есть Чек-лист. Это список проверок, которые нужно выполнить. Он не говорит как именно это делать, он говорит что нужно проверить.

    Пример чек-листа для Корзины «LootShop»

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

  • Добавление товара в корзину из каталога.
  • Добавление товара в корзину из карточки товара.
  • Изменение количества товара (увеличение).
  • Изменение количества товара (уменьшение).
  • Удаление товара из корзины.
  • Отображение итоговой суммы.
  • Переход к оформлению заказа.
  • Плюсы чек-листа: * Быстро составляется. * Легко поддерживать (если изменился дизайн кнопки, чек-лист переписывать не надо).

    Минусы: * Требует знания продукта. Если ты дашь этот список новичку, он может спросить: «А где кнопка удаления?». Чек-лист не дает деталей.

    > Чек-лист — это напоминалка для опытного воина, чтобы он ничего не упустил в пылу сражения.

    Уровень 2: Тест-кейс (Test Case) — Древний свиток с инструкцией

    Иногда списка недостаточно. Если функционал сложный или его будет проверять другой человек, нужна детальная инструкция. Это и есть Тест-кейс.

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

    Анатомия Тест-кейса

    Каждый тест-кейс состоит из обязательных атрибутов. Давай разберем их на примере проверки «Добавление товара в корзину».

    | Атрибут | Описание | Пример | | :--- | :--- | :--- | | ID | Уникальный номер | TC-001 | | Заголовок (Title) | Суть проверки (Что? Где? Когда?) | Добавление товара «Футболка Witcher» в корзину из карточки товара | | Предварительные условия (Preconditions) | Что нужно сделать до начала теста | 1. Открыть сайт LootShop.<br>2. Пользователь авторизован. | | Шаги (Steps) | Пошаговая инструкция действий | 1. Перейди в раздел «Одежда».<br>2. Кликни на товар «Футболка Witcher».<br>3. Нажми кнопку «В корзину». | | Ожидаемый результат (Expected Result) | Самое важное! Как система должна отреагировать | 1. Кнопка изменилась на «В корзине».<br>2. Счетчик на иконке корзины увеличился на 1. |

    !Визуальное сравнение: Чек-лист — это просто список «что проверить», а Тест-кейс — детальная инструкция «как проверить».

    Золотые правила написания Тест-кейсов

    Чтобы твои тест-кейсы были понятны даже твоей бабушке (или джуниору, который придет после тебя), соблюдай эти правила:

  • Атомарность. Один тест-кейс — одна проверка. Не пытайся в одном кейсе проверить и добавление в корзину, и оплату, и доставку. Если тест упадет, ты не поймешь, где именно проблема.
  • Ясность. Избегай фраз «проверить, что все хорошо» или «ввести корректные данные». Пиши точно: «Ввести 5», «Ожидаем появление зеленой галочки».
  • Независимость. Тест-кейс не должен зависеть от других тестов. Не пиши: «Выполнить шаги из теста TC-005, а потом нажать ОК».
  • Уровень 3: Практика — Тестируем Промокод

    Давай применим знания. В «LootShop» появилась новая фича: поле для ввода промокода в корзине.

    Задача: Написать тест-кейс на успешное применение промокода HERO2024, который дает скидку 10%.

    Вот как это сделает профессионал:

    ID: CART-05 Заголовок: Применение валидного промокода HERO2024 в корзине Предусловия:

  • Сайт открыт.
  • В корзине лежит товар «Кружка Cyberpunk» стоимостью 1000 монет.
  • Шаги:

  • Перейди в корзину.
  • В поле «Промокод» введи HERO2024.
  • Нажми кнопку «Применить».
  • Ожидаемый результат:

  • Появилось сообщение «Промокод успешно применен».
  • Итоговая сумма пересчиталась: стала 900 монет (1000 - 10%).
  • Видишь? Мы четко описали, что вводим и какую именно цифру ждем в итоге. Если сумма станет 950, тест будет провален (Failed).

    Чек-лист VS Тест-кейс: Что выбрать?

    Ты спросишь: «Зачем мне писать подробные тест-кейсы, если это долго? Можно же просто чек-лист!»

    Давай сравним:

    | Ситуация | Что использовать? | Почему? | | :--- | :--- | :--- | | Нужно быстро протестировать новую фичу | Чек-лист | Нет времени на бюрократию, нужно искать баги здесь и сейчас. | | Сложная логика (расчет скидок, налогов) | Тест-кейс | Нужно точно знать, какие цифры вводить и что получать. В уме это не удержать. | | Тестировать будет новичок | Тест-кейс | Ему нужна инструкция, иначе он пропустит важное. | | Регрессионное тестирование (проверка старого функционала) | Чек-лист | Ты и так знаешь, как это работает, нужно просто убедиться, что ничего не сломалось. |

    Итоги уровня

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

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

    Сохрани свои свитки, герой. Они тебе понадобятся!

    3. Охота на баги: Жизненный цикл дефекта, работа в Jira и оформление идеального баг-репорта

    Охота на баги: Жизненный цикл дефекта, работа в Jira и оформление идеального баг-репорта

    Приветствую, охотник! В прошлый раз мы с тобой вооружились картами и свитками — чек-листами и тест-кейсами. Мы подготовили плацдарм для битвы в нашем интернет-магазине «LootShop». Теперь пришло время обнажить меч.

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

    Многие новички думают, что найти баг — это самое сложное. Ха! Найти баг может и случайный прохожий. Искусство QA-инженера заключается в том, чтобы грамотно оформить баг-репорт. Если ты напишешь «Кнопка не работает», разработчик вернет тебе задачу со словами «У меня всё работает» (Works on my machine). И будет прав.

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

    Уровень 1: Анатомия идеального Баг-репорта

    Баг-репорт (Bug Report) — это документ, описывающий ситуацию, когда фактический результат работы программы не совпадает с ожидаемым.

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

    Структура отчета (Твой шаблон)

    В Jira или любой другой системе (Trello, Redmine, YouTrack) у баг-репорта есть обязательные поля. Давай разберем их на примере нашего магазина «LootShop».

    #### 1. Заголовок (Summary) Это лицо твоего бага. Он должен отвечать на три вопроса: Что? Где? Когда?

    * ~~Плохо:~~ Корзина не работает. * ~~Плохо:~~ Ошибка при заказе. * Хорошо: Неверный расчет суммы заказа в Корзине при добавлении 10 товаров. * Идеально: Кнопка «Оплатить» неактивна при выборе способа оплаты «Картой» на экране оформления заказа.

    #### 2. Описание (Description) Здесь ты даешь контекст. Какая версия браузера? Какое устройство? Какая среда (Test или Production)?

    #### 3. Шаги воспроизведения (Steps to Reproduce) Это сердце репорта. Пошаговая инструкция «Делай как я».

  • Открыть сайт lootshop.com.
  • Перейти в раздел «Мерч».
  • Добавить в корзину товар «Кружка».
  • Перейти в корзину.
  • Нажать кнопку «Удалить».
  • #### 4. Фактический результат (Actual Result) Что случилось на самом деле? «Товар остался в корзине, появилась ошибка 500».

    #### 5. Ожидаемый результат (Expected Result) Как должно быть по требованиям? «Товар удален из корзины, сумма пересчитана».

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

    #### 6. Вложения (Attachments) Скриншоты, видео, логи. Один скриншот стоит тысячи слов. Обязательно выдели красным квадратом место ошибки. Мы же не хотим, чтобы разработчик играл в «Где Уолли?», разглядывая твой скриншот.

    Уровень 2: Severity и Priority — В чем разница?

    В каждом баг-репорте есть два поля, которые путают 90% новичков: Severity (Серьезность) и Priority (Приоритет).

    Severity (Серьезность)

    Это техническая характеристика. Насколько сильно баг ломает систему? Влияет ли он на основной функционал?

    Уровни Severity:

  • Blocker (Блокирующий): Система не работает вообще. (Пример: Сайт не открывается, белый экран).
  • Critical (Критический): Не работает ключевая бизнес-функция, нет обходного пути. (Пример: Нельзя оплатить заказ).
  • Major (Значительный): Функция не работает, но есть обходной путь. (Пример: Не работает поиск по названию, но работает поиск по категории).
  • Minor (Незначительный): Неудобство интерфейса, не влияет на функционал. (Пример: Текст кнопки вылезает за границы).
  • Trivial (Тривиальный): Опечатки, цвет не того оттенка.
  • Priority (Приоритет)

    Это бизнесовая характеристика. Как быстро нужно это исправить? Это решает менеджер, исходя из планов продаж и репутации.

    Уровни Priority:

  • High (Высокий): Исправить немедленно!
  • Medium (Средний): Исправить в этом релизе.
  • Low (Низкий): Можно отложить до лучших времен.
  • Классическая ловушка: Высокий приоритет при низкой серьезности

    Может ли быть такое? Да!

    Пример: На главной странице сайта в названии компании опечатка: «LootShoop» вместо «LootShop». * Severity: Trivial (или Minor). Система работает? Да. Покупки идут? Да. Ничего не сломалось. * Priority: High (или даже Highest). Это репутация! Директор увидит — уволит всех. Исправить нужно прямо сейчас.

    Обратный пример: Приложение падает (Crash), если зайти в настройки, нажать 10 раз в пустой угол и перевернуть телефон. * Severity: Critical (приложение падает!). * Priority: Low. Пользователи туда почти не заходят, а сценарий воспроизведения слишком сложный. Исправим, когда будет время.

    Уровень 3: Жизненный цикл бага (Bug Lifecycle)

    Баг не просто «висит» в Jira. Он живет своей жизнью, путешествуя между отделами. Этот путь называется Workflow.

    !Схема движения задачи по статусам в Jira

    Давай пройдем этот путь:

  • New / Open (Новый). Ты нашел баг и создал тикет. Он лежит в общей куче.
  • In Progress (В работе). Разработчик взял баг себе и чинит его.
  • Resolved / Fixed (Решен). Разработчик пишет: «Готово, проверяй!» и переводит задачу на тебя.
  • Внимание! На этом этапе баг еще НЕ исправлен окончательно. Он только заявлен* как исправленный.
  • Verification (Проверка). Ты берешь новую версию приложения и проверяешь именно этот кейс.
  • * Сценарий А (Победа): Баг исчез. Ты переводишь задачу в статус Closed (Закрыт). * Сценарий Б (Поражение): Баг все еще на месте (или разработчик починил одно, но сломал другое). Ты переводишь задачу в статус Reopened (Переоткрыт) и возвращаешь разработчику с комментарием.

    Уровень 4: Практика в Jira

    Давай оформим реальный баг для «LootShop».

    Ситуация: Ты тестируешь форму регистрации. Вводишь в поле «Email» значение test@ (без домена) и нажимаешь «Зарегистрироваться». Система создает аккаунт, хотя не должна пропускать некорректный email.

    Оформляем:

    * Summary: Регистрация проходит успешно при вводе невалидного email (без домена). * Priority: High (База данных засоряется, мы не сможем писать клиентам). * Severity: Major (Функция регистрации работает, но с нарушением логики валидации). * Environment: Google Chrome 118, Windows 10, Test Stand. * Steps to Reproduce: 1. Открыть форму регистрации lootshop.com/register. 2. Ввести имя «User». 3. Ввести email test@. 4. Ввести пароль 123456. 5. Нажать кнопку «Зарегистрироваться». * Expected Result: Появляется сообщение об ошибке «Введите корректный email». Регистрация не происходит. * Actual Result: Пользователь перенаправляется в Личный кабинет. Аккаунт создан.

    Кодекс чести QA (Soft Skills)

    Запомни, герой: Ты и Разработчик — в одной лодке. Твоя цель — не тыкнуть его носом в ошибку («Смотри, какой ты криворукий!»), а помочь сделать продукт лучше.

    Не пиши: «Ты сломал корзину»*. Пиши: «Корзина работает некорректно при таких-то условиях»*.

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

    Итоги

    Сегодня ты научился:

  • Описывать баги так, чтобы их хотели чинить.
  • Различать Severity (техническое влияние) и Priority (бизнес-срочность).
  • Управлять жизненным циклом дефекта в Jira.
  • Твой инвентарь пополнился мощным навыком. Теперь ты не просто наблюдатель, ты — охотник. В следующей статье мы погрузимся в мир API-тестирования: узнаем, как общаются программы, когда их никто не видит, и научимся посылать запросы через Postman.

    Удачной охоты!

    4. Инструментарий профи: Тестирование API в Postman, Chrome DevTools и основы SQL для проверок баз данных

    Инструментарий профи: Тестирование API в Postman, Chrome DevTools и основы SQL для проверок баз данных

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

    Но что, если я скажу тебе, что 70% магии происходит там, где ты не видишь? Сайт — это лишь красивая витрина. Настоящая работа кипит в подсобке (на сервере) и на складе (в базе данных).

    Сегодня мы наденем очки ночного видения. Ты перестанешь быть просто пользователем, который «тыкает кнопки». Ты станешь инженером, который видит систему насквозь. Твой новый инвентарь: Chrome DevTools, Postman и язык SQL.

    Готов заглянуть под капот «LootShop»? Поехали.

    Уровень 1: Chrome DevTools — Твое рентгеновское зрение

    Представь ситуацию: ты нажимаешь кнопку «Купить», а ничего не происходит. Ошибки на экране нет. Что ты напишешь в баг-репорте? «Кнопка не работает»? Разработчик вернет такой баг с пометкой «Не воспроизводится».

    Чтобы понять причину, тебе нужно открыть панель разработчика. В браузере Google Chrome нажми клавишу F12 (или правой кнопкой мыши -> «Просмотреть код»).

    Добро пожаловать в DevTools. Здесь есть три вкладки, которые нужны QA-инженеру каждый день.

    1. Elements (Элементы)

    Здесь лежит скелет сайта (HTML) и его кожа (CSS). Ты можешь видеть код каждой кнопки и текста.

    Зачем это QA? * Проверить, тот ли шрифт используется. * Узнать код цвета кнопки. Магия: Ты можешь менять текст и цвет прямо на странице, чтобы проверить, как будет выглядеть длинное имя пользователя, не создавая его в реальности. Это называется «тестирование верстки на лету»*.

    2. Console (Консоль)

    Это журнал событий. Если на сайте произошла ошибка в скриптах (JavaScript), она появится здесь красным текстом.

    Пример: Ты нажал кнопку, визуально ничего не случилось, но в консоли появилось сообщение: Uncaught TypeError: Cannot read property 'price' of undefined.

    Это джекпот! Ты копируешь этот текст в баг-репорт, и разработчик сразу понимает, где искать ошибку. Ты сэкономил ему час работы.

    3. Network (Сеть)

    Самая важная вкладка для нас. Она показывает все запросы, которые твой браузер отправляет на сервер, и ответы, которые приходят обратно.

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

    Уровень 2: API — Язык общения программ

    Чтобы понять, что мы видим во вкладке Network, нужно разобраться, как общаются программы. Это называется API (Application Programming Interface).

    Представь ресторан:

  • Ты (Клиент/Frontend): Сидишь за столиком и хочешь есть. Ты не можешь сам пойти на кухню.
  • Официант (API): Принимает твой заказ и несет его на кухню.
  • Кухня (Server/Backend): Готовит еду.
  • Ты говоришь официанту: «Дайте мне меню» или «Я хочу заказать стейк». В мире IT это называется HTTP-запросы.

    !Визуализация принципа работы клиент-серверной архитектуры через API

    Основные методы (команды официанту):

    * GET — «Дай мне информацию». (Пример: Открыть страницу товара. Мы ничего не меняем, просто смотрим). * POST — «Создай что-то новое». (Пример: Регистрация, добавление товара в корзину). * PUT — «Обнови информацию целиком». (Пример: Изменить адрес доставки в профиле). * DELETE — «Удали это». (Пример: Удалить товар из корзины).

    Коды ответов (Что ответил официант):

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

    * 2xx (Успех): * 200 OK — Всё отлично, вот твой заказ. * 201 Created — Успешно создано (например, новый пользователь). * 4xx (Ошибка клиента — Ты виноват): * 400 Bad Request — Ты передал кривые данные (например, буквы в поле возраста). * 401 Unauthorized — Ты не авторизован (не показал пропуск). * 403 Forbidden — Тебе сюда нельзя (ты авторизован, но у тебя нет прав админа). * 404 Not Found — Такого товара или страницы не существует. * 5xx (Ошибка сервера — Они виноваты): * 500 Internal Server Error — На сервере пожар, код сломался. * 502 Bad Gateway — Сервер недоступен. * 503 Service Unavailable — Сервер перегружен запросами.

    Уровень 3: Postman — Посылаем запросы вручную

    Иногда у тебя еще нет готового сайта (Frontend), а сервер (Backend) уже написан. Или ты хочешь проверить API в обход кнопок. Для этого используют инструмент Postman.

    Postman позволяет отправлять запросы на сервер напрямую, минуя браузер.

    Практика: Тестируем вход в «LootShop» через Postman

    Допустим, разработчик дал тебе адрес API для входа: https://api.lootshop.com/login.

  • Открываем Postman.
  • Создаем новый запрос (Request).
  • Выбираем метод POST (мы же отправляем данные).
  • Вводим URL: https://api.lootshop.com/login.
  • Вкладка Body -> Raw -> JSON. Здесь мы пишем данные для отправки:
  • Нажимаем Send (Отправить).
  • Внизу мы видим ответ сервера (Response).

    Сценарий 1 (Успех): Статус: 200 OK Тело ответа:

    Всё работает! Логин проходит.

    Сценарий 2 (Баг): Мы вводим верный пароль, а сервер отвечает 500 Internal Server Error. Это критический баг бэкенда. Мы нашли его даже без сайта!

    Уровень 4: SQL — Доверяй, но проверяй базу данных

    Сайт может врать. Ты нажал «Сохранить», появилось сообщение «Успешно!», но на самом деле данные не записались. Или записались с ошибкой.

    Единственный источник правды — База Данных (БД). Чтобы общаться с ней, нужен язык SQL (Structured Query Language).

    Представь БД как огромную таблицу Excel. В «LootShop» есть таблица Users (Пользователи).

    Основные заклинания SQL

    Тебе не нужно быть мастером баз данных, но ты должен уметь делать SELECT (Выборку).

    Шаблон запроса:

    SELECT — покажи мне все колонки. * FROM Users — из таблицы Пользователи. * WHERE — где...

    Примеры проверок:

    Задача 1: Ты зарегистрировал нового пользователя с email hero@test.com. Проверь, появился ли он в базе.

    Твой запрос:

    Если в ответ пришла пустая строка — баг! Регистрация на сайте прошла фиктивно.

    Задача 2: Ты проверяешь, сколько бонусов у пользователя. На сайте написано 100. А в базе?

    Твой запрос:

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

    Задача 3: Найти всех пользователей, которых заблокировали (is_banned = 1).

    Твой запрос:

    JOIN — Соединение таблиц (Для продвинутых)

    Иногда данные лежат в разных таблицах. Например, пользователи в Users, а их заказы в Orders. Чтобы найти заказы конкретного пользователя, мы «склеиваем» таблицы по общему полю (обычно это ID пользователя).

    Этот запрос покажет все заказы пользователя с указанным email.

    Итоги уровня

    Поздравляю! Теперь ты обладаешь полным арсеналом Middle QA-инженера.

  • Chrome DevTools — помогает понять, ошибка на клиенте (в браузере) или на сервере.
  • API и Postman — позволяют тестировать логику приложения отдельно от внешнего вида и находить баги на ранних этапах.
  • SQL — дает доступ к истине, позволяя проверить, сохранились ли данные на самом деле.
  • Теперь, когда ты видишь ошибку, ты не просто пишешь «Не работает». Ты пишешь: «При отправке POST-запроса на /login сервер возвращает 500 ошибку, хотя в базе данных пользователь существует».

    Такой баг-репорт — это музыка для ушей разработчика.

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

    5. Путь к Middle: Техники тест-дизайна, основы автоматизации и подготовка к реальному собеседованию

    Путь к Middle: Техники тест-дизайна, основы автоматизации и подготовка к реальному собеседованию

    Приветствую тебя, ветеран «LootShop»! Ты прошел долгий путь. Ты знаешь, как устроен жизненный цикл ПО, умеешь писать идеальные баг-репорты, заглядывать в «душу» сайта через API и проверять факты в базе данных через SQL. Твой инвентарь полон, а навыки отточены.

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

    Сегодня мы разберем стратегии оптимизации тестирования, основы магии автоматизации и подготовим тебя к битве за оффер.

    Уровень 1: Техники тест-дизайна — Искусство войны

    Представь, что в нашем магазине есть поле ввода «Количество товара», которое принимает значения от 1 до 100.

    Новичок начнет вводить: 1, 2, 3... 50... 99, 100. Это 100 тестов. А если поле принимает до миллиона? Ты состаришься, проверяя это.

    Профессионал использует Техники тест-дизайна. Это стратегии, которые позволяют проверить всё, сделав минимум тестов.

    1. Классы эквивалентности (Equivalence Partitioning)

    Идея проста: если программа обрабатывает число 5 так же, как и число 50, зачем проверять оба? Мы разбиваем все возможные данные на группы (классы).

    Пример: Поле «Возраст» для покупки игры 18+ (от 18 до 99 лет).

    Мы делим мир на три класса:

  • Невалидный (Мало): От 0 до 17. (Ожидаем отказ).
  • Валидный (Норма): От 18 до 99. (Ожидаем успех).
  • Невалидный (Много): От 100 и больше. (Ожидаем ошибку или особое сообщение).
  • Стратегия: Берем любое одно значение из каждого класса. Например: 10, 25, 150. Всего 3 теста вместо сотен!

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

    Где чаще всего ошибаются разработчики? В знаках (больше) или (больше или равно). Именно на границах классов эквивалентности живут самые коварные баги.

    Правило: Всегда проверяй границы и значения рядом с ними.

    Для нашего примера (18 - 99 лет) границы — это 18 и 99. Проверяем: * Граница: 18 (Должно пустить). * Шаг влево: 17 (Не должно пустить). * Граница: 99 (Должно пустить). * Шаг вправо: 100 (Не должно пустить).

    !Визуализация метода граничных значений на примере возрастного ограничения

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

    Представь, что ты тестируешь настройки графики в игре: * OS: Windows, Mac, Linux (3 варианта) * Browser: Chrome, Firefox, Safari (3 варианта) * Resolution: 1080p, 4k (2 варианта)

    Всего комбинаций: . А если параметров будет 10? Комбинаций станут тысячи.

    Pairwise — это математический метод, который гарантирует, что каждая пара параметров встретится хотя бы один раз. Это сокращает количество тестов в разы, находя при этом 90% багов. Для генерации таких таблиц используют инструменты, например, PICT или онлайн-генераторы.

    Уровень 2: Основы автоматизации — Призыв големов

    Ручное тестирование (Manual) — это база. Но гонять одни и те же тесты каждый день (регресс) скучно и дорого. Тут на сцену выходит Автоматизация.

    > Автоматизация — это написание кода, который проверяет другой код.

    Пирамида тестирования

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

  • Unit-тесты (Фундамент). Самые быстрые и дешевые. Их пишут разработчики. Они проверяют отдельные функции (например, функцию сложения цены). Их должно быть много (тысячи).
  • Integration-тесты (Середина). Проверяют, как модули общаются между собой (например, API и база данных). Их меньше.
  • E2E-тесты (Верхушка). End-to-End. Это робот, который открывает браузер, кликает кнопки и имитирует пользователя. Это самые медленные и хрупкие тесты. Их должно быть мало.
  • Ошибка новичка: Пытаться автоматизировать всё через UI (верхушку пирамиды). Это превращает пирамиду в «рожок мороженого», который падает и тает.

    !Пирамида тестирования Майка Кона

    Инструменты автоматизатора

    Если ты решишь качать ветку Automation QA, тебе понадобятся: * Язык программирования: Java, Python или JavaScript. * Selenium / Playwright: Библиотеки для управления браузером. * CI/CD (Jenkins, GitLab CI): Системы, которые запускают тесты автоматически, когда разработчик сохраняет код.

    Что автоматизировать в первую очередь? Рутину. То, что ты проверяешь перед каждым релизом (Регресс). Нельзя автоматизировать то, что постоянно меняется.

    Уровень 3: Собеседование — Финальный Босс

    Ты готов. Твое резюме блестит, портфолио на GitHub заполнено тест-кейсами и SQL-запросами. Впереди собеседование.

    Обычно оно состоит из двух частей: Soft Skills (Личность) и Hard Skills (Техника).

    Битва 1: Soft Skills (Адекватность)

    QA — это коммуникатор. Тебя будут проверять на стрессоустойчивость и умение общаться.

    Типичный вопрос: «Что ты будешь делать, если разработчик отказывается чинить баг?» * ~~Плохой ответ:~~ Пожалуюсь начальнику или буду спорить. * Хороший ответ: Я выясню аргументы разработчика. Если это не баг, а фича — обновлю документацию. Если это баг, но нет времени — занесу в бэклог. Если баг критичный — соберу встречу с менеджером и объясню риски для бизнеса.

    Битва 2: Hard Skills (Техника)

    Здесь тебя погоняют по теории.

  • Теория: Виды тестирования, техники тест-дизайна (расскажи про классы эквивалентности!), жизненный цикл бага.
  • Практика: Тебе дадут предмет (карандаш, лифт, форму логина) и попросят протестировать.
  • Совет:* Не начинай сразу перечислять тесты. Сначала задай вопросы! «Какой это карандаш? Для кого? В каких условиях будет использоваться?» Это покажет твой аналитический склад ума.
  • SQL и API: Попросят написать простой SELECT или рассказать, чем GET отличается от POST.
  • Секретное оружие: «Я не знаю»

    Никто не знает всего. Если тебе задали вопрос, на который ты не знаешь ответа:

  • Не ври.
  • Не молчи.
  • Скажи: «Я сейчас не знаю точного ответа, но я думаю, что это работает так... А чтобы узнать точно, я бы посмотрел в документации или использовал Google вот так...».
  • Работодателю важно не то, что ты ходячая энциклопедия, а то, как ты решаешь проблемы.

    Эпилог: Твой путь только начинается

    Поздравляю, герой! Ты прошел курс «QA-инженер: Путь героя».

    Ты узнал, что QA — это не просто «ломать», это «строить качество». Ты прошел путь от непонимания терминов до написания SQL-запросов и стратегий тестирования.

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

    Удачи в реальных проектах. Мир IT ждет тебя!