Основы тестирования ПО: Путь с нуля до Junior QA

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

1. Введение в профессию: жизненный цикл ПО, цели тестирования и психология QA-инженера

Введение в профессию: жизненный цикл ПО, цели тестирования и психология QA-инженера

Добро пожаловать в курс «Основы тестирования ПО: Путь с нуля до Junior QA»! Вы стоите на пороге увлекательной профессии, которая сочетает в себе аналитику, творчество, технические навыки и детективное чутьё.

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

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

QA, QC и Testing: Давайте разберемся в терминах

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

!Иерархия понятий обеспечения качества

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

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

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

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

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

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

> QA — это про процесс. QC — это про продукт. Тестирование — это про конкретные проверки.

Жизненный цикл программного обеспечения (SDLC)

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

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

!Основные этапы жизненного цикла разработки ПО

Этапы SDLC:

  • Сбор и анализ требований (Requirements Analysis)
  • На этом этапе заказчик говорит: «Я хочу интернет-магазин для продажи котов». Аналитики превращают это «хочу» в техническую документацию. Роль QA: Тестирование требований. Да, документы тоже можно тестировать! Мы ищем логические противоречия еще до того, как написана первая строчка кода.

  • Дизайн и проектирование (Design)
  • Архитекторы решают, на каком языке писать, какая будет база данных. Дизайнеры рисуют макеты интерфейса. Роль QA: Проверка макетов на удобство использования (Usability) и полноту.

  • Разработка (Development/Coding)
  • Программисты пишут код. Это самый длительный этап. Роль QA: Написание тестовой документации (чек-листов, тест-кейсов), подготовка тестовых данных. Иногда — модульное тестирование.

  • Тестирование (Testing)
  • Звездный час QA. Мы получаем готовую сборку (билд) и начинаем проверять её по нашим сценариям. Найденные ошибки (баги) оформляются в отчеты и отправляются разработчикам на исправление.

  • Развертывание и поддержка (Deployment & Maintenance)
  • Продукт выходит в «прод» (продакшн) — становится доступен реальным пользователям. Роль QA: Проверка того, что обновление встало корректно, и помощь техподдержке в разборе жалоб пользователей.

    Цена ошибки: Почему тестировать нужно рано?

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

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

    * Если QA нашел это на этапе требований: Аналитик просто дописывает одну строчку в Word. Цена: 5 минут работы. * Если ошибку нашли на этапе дизайна: Дизайнеру нужно перерисовывать макеты состояний кнопки. Цена: 1 час работы. * Если ошибку нашли на этапе разработки: Программисту нужно переписывать логику. Цена: 4 часа работы. * Если ошибку нашли после релиза: Пользователи не могут купить товар, бизнес теряет деньги, репутация падает, нужно срочно выпускать патч (исправление). Цена: Тысячи долларов и нервы всей команды.

    !Экспоненциальный рост стоимости ошибки

    Цели тестирования

    Зачем мы вообще это делаем? «Чтобы найти баги» — самый популярный, но не единственный ответ.

    Основные цели тестирования:

  • Предоставление информации о качестве. Мы — глаза и уши бизнеса. Мы говорим: «Продукт работает вот так, а вот тут есть риски».
  • Обнаружение дефектов. Конечно, мы ищем несоответствия между тем, что есть, и тем, что должно быть.
  • Предотвращение дефектов. Помните про тестирование требований? Лучший баг — тот, который не был написан в коде.
  • Снижение рисков. Мы гарантируем, что критически важный функционал работает, и компания не обанкротится из-за сбоя в день релиза.
  • > Важно: Цель тестирования — не доказать, что багов нет (это невозможно), а показать наличие багов и снизить неопределенность.

    Психология QA-инженера

    Хороший тестировщик отличается от плохого не знанием инструментов, а складом ума.

    1. Деструктивное vs Конструктивное мышление

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

    2. Критическое мышление

    Не верьте на слово. — «Я починил этот баг, проверяй», — говорит разработчик. — «Я проверю», — думает QA, и проверяет не только этот баг, но и то, не сломалось ли что-то соседнее.

    3. Дипломатия и коммуникация

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

    Правила хорошего тона QA: * Критикуй продукт, а не личность. Не «Ты допустил ошибку», а «В модуле авторизации найдена ошибка». * Будь объективен. Оперируй фактами, логами и скриншотами, а не эмоциями. * Мы в одной лодке. Разработчик и Тестировщик — не враги. У вас одна цель: качественный продукт.

    4. Любопытство

    Хороший QA — это ребенок, который спрашивает «А почему?». Почему программа ведет себя так? А что если я введу сюда -1? А если я отключу интернет в момент загрузки?

    Резюме

    Сегодня мы заложили первый камень в фундамент вашего образования.

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

    В следующей статье мы погрузимся в виды тестирования и узнаем, чем «Черный ящик» отличается от «Белого», и почему не всё можно автоматизировать.

    2. Тестовая документация: создание чек-листов, тест-кейсов и оформление баг-репортов в Jira

    Тестовая документация: создание чек-листов, тест-кейсов и оформление баг-репортов в Jira

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

    В мире IT существует поговорка: «Если это не записано, этого не было».

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

    Сегодня мы научимся писать три главных документа тестировщика: Чек-лист, Тест-кейс и Баг-репорт, а также познакомимся с инструментом Jira.

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

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

  • Сначала вам нужен общий план (Стратегия/Тест-план).
  • Затем — подробные чертежи для каждой комнаты (Тест-кейсы).
  • И, наконец, список недоделок, которые нужно исправить прорабу (Баг-репорты).
  • Мы сосредоточимся на уровне «чертежей» и «списка недоделок», так как именно с этого начинает любой Junior QA.

    Чек-лист (Checklist): Искусство краткости

    Чек-лист — это список проверок, которые нужно выполнить. Он отвечает на вопрос «Что тестируем?», но не расписывает подробно, как именно это делать.

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

    Структура чек-листа

    Хороший чек-лист состоит из пунктов, каждый из которых подразумевает одно действие или проверку.

    Пример чек-листа для формы логина: * Проверить ввод верного логина и пароля. * Проверить ввод неверного пароля. * Проверить кнопку «Забыли пароль?». * Проверить вход через Google.

    !Пример того, как выглядит простой чек-лист проверок.

    Когда использовать чек-лист?

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

    > Плюс: Быстро писать и легко поддерживать. > Минус: Новичок может не понять, как именно выполнить проверку, если там написано просто «Проверить оплату».

    Тест-кейс (Test Case): Детальная инструкция

    Тест-кейс — это подробное описание проверки. В отличие от чек-листа, он отвечает не только на вопрос «Что?», но и «Как?».

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

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

    У любого тест-кейса есть три обязательных элемента (Святая Троица QA):

  • Preconditions (Предусловия): Что должно быть сделано до начала теста. Например, «Пользователь зарегистрирован и находится на главной странице».
  • Steps (Шаги): Конкретные действия. Куда нажать, что ввести.
  • Expected Result (Ожидаемый результат): Что должно произойти после выполнения шагов.
  • Пример оформления тест-кейса

    Название: Успешная авторизация существующим пользователем

    | Элемент | Описание | | :--- | :--- | | Предусловия | Открыта страница авторизации site.com/login. Пользователь user@test.com с паролем 1234 существует в базе. | | Шаг 1 | Ввести user@test.com в поле «Email». | | Шаг 2 | Ввести 1234 в поле «Пароль». | | Шаг 3 | Нажать кнопку «Войти». | | Ожидаемый результат | Происходит редирект в Личный кабинет. В правом верхнем углу отображается имя пользователя. |

    Правила хорошего тест-кейса:

    * Атомарность: Один кейс — одна проверка. Не пытайтесь в одном тесте проверить и регистрацию, и покупку, и смену пароля. * Ясность: Избегайте фраз «ввести корректные данные» (какие именно?) или «убедиться, что все хорошо» (что такое хорошо?). * Независимость: Тест-кейс не должен зависеть от выполнения предыдущего кейса (по возможности).

    !Визуализация структуры тест-кейса: от подготовки до проверки результата.

    Баг-репорт (Bug Report): Хроника происшествия

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

    Плохой баг-репорт: «Кнопка не работает». Хороший баг-репорт: «Кнопка 'Купить' неактивна при добавлении товара из категории 'Распродажа'».

    Структура идеального баг-репорта

  • Summary (Заголовок): Краткая суть проблемы. Должен отвечать на вопросы: Что? Где? Когда?
  • Плохо:* Ошибка в корзине. Хорошо:* Неверный расчет суммы (Что?) в корзине (Где?) при добавлении двух одинаковых товаров (Когда?).

  • Description (Описание): Шаги для воспроизведения (Steps to Reproduce).
  • * Шаг 1: Открыть сайт. * Шаг 2: Добавить товар Х. * Шаг 3: Перейти в корзину.

  • Actual Result (Фактический результат): Что произошло на самом деле. (Например: «Сумма равна 0»).
  • Expected Result (Ожидаемый результат): Как должно было быть. (Например: «Сумма должна быть равна цене товара»).
  • Severity (Серьезность) и Priority (Приоритет):
  • * Severity — насколько технически сильно баг ломает систему (S1 - Блокирующий, S2 - Критический, S3 - Значительный, S4 - Незначительный). * Priority — как срочно нужно чинить (P1 - Высокий, P2 - Средний, P3 - Низкий).

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

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

    В современном мире никто не ведет баги в Excel (хотя бывает всякое). Стандартом индустрии является Jira (или аналоги: YouTrack, Redmine, Trello).

    Jira — это система отслеживания задач (Task Tracker).

    В Jira каждый баг или тест-кейс — это Issue (Задача/Тикет). У тикета есть жизненный цикл (Workflow):

  • Open (Открыт): Вы нашли баг и завели задачу.
  • In Progress (В работе): Разработчик начал чинить.
  • Resolved/Fixed (Решено): Разработчик говорит, что починил.
  • In Testing / Ready for QA: Мяч снова на вашей стороне. Вы проверяете исправление.
  • Closed (Закрыт): Если баг действительно исчез.
  • Reopened (Переоткрыт): Если разработчик сказал, что починил, а баг все еще на месте.
  • !Пример интерфейса системы отслеживания задач (баг-трекера).

    Резюме

    * Чек-лист — это список «Что проверить». Подходит для быстрых проверок и опытных команд. * Тест-кейс — это инструкция «Как проверить». Содержит Предусловия, Шаги и Ожидаемый результат. * Баг-репорт должен отвечать на вопросы «Что? Где? Когда?» и обязательно содержать сравнение Ожидаемого и Фактического результатов. * Jira — основной инструмент для ведения документации и отслеживания статуса багов.

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

    3. Виды тестирования и техники тест-дизайна: классы эквивалентности и граничные значения

    Виды тестирования и техники тест-дизайна: классы эквивалентности и граничные значения

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

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

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

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

    Классификация видов тестирования

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

    1. Тестирование черного ящика (Black Box Testing)

    Это метод, при котором тестировщик не знает, как устроена система внутри. Вы не видите код, не знаете структуру базы данных. Вы действуете как обычный пользователь.

    * Суть: Есть входные данные (Input) и выходные данные (Output). Что происходит внутри — загадка. * Пример: Вы нажимаете кнопку «Сохранить». Вам не важно, какой SQL-запрос отправился в базу. Вам важно, чтобы появилось сообщение «Сохранено успешно».

    2. Тестирование белого ящика (White Box Testing)

    Метод, при котором тестировщик знает внутреннюю структуру системы и имеет доступ к коду.

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

    3. Тестирование серого ящика (Grey Box Testing)

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

    !Визуальное сравнение методов тестирования: Черный, Белый и Серый ящик.

    Проблема исчерпывающего тестирования

    Существует аксиома: Исчерпывающее тестирование невозможно.

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

    Для этого используются техники тест-дизайна.

    Техника №1: Классы эквивалентности (Equivalence Partitioning)

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

    Принцип: Тестируем по одному значению из каждого класса.

    Пример из жизни

    Представьте турникет в метро. Билет стоит 50 рублей. Если на карте 50 рублей — проход открыт. Если 100 — открыт. Если 5000 — открыт. Нет смысла проверять отдельно 51 рубль, 52 рубля и так далее. Для системы это всё — «достаточно денег».

    Как это работает математически?

    Допустим, у нас есть поле ввода оценки за экзамен (от 1 до 5).

    Мы можем выделить следующие классы:

  • Валидный класс (Valid): Числа, которые система должна принять.
  • Где — множество допустимых значений, — вводимое число, — знак «меньше или равно».

  • Невалидные классы (Invalid): Числа, которые система должна отвергнуть.
  • * Числа меньше 1: Где — множество чисел меньше единицы. * Числа больше 5: Где — множество чисел больше пяти. * Нечисловые значения (буквы, спецсимволы).

    Итого для проверки нам нужно всего 3 теста вместо бесконечности:

  • Ввести 3 (представитель валидного класса).
  • Ввести 0 (представитель класса «слишком мало»).
  • Ввести 6 (представитель класса «слишком много»).
  • > Правило: Если тест с числом 3 прошел успешно, мы считаем, что с числами 2 и 4 тоже всё будет хорошо, так как они обрабатываются одним куском кода.

    Техника №2: Анализ граничных значений (Boundary Value Analysis)

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

    Где заканчивается «подросток» и начинается «взрослый»? В 18 лет ровно? Или в 18 лет и 1 день? А может, система считает «строго больше 18»?

    Анализ граничных значений — это техника проверки поведения системы на крайних значениях входных данных.

    Почему это важно?

    В программировании очень легко перепутать операторы сравнения: * > (строго больше) * >= (больше или равно)

    Если программист напишет if (age > 18) вместо if (age >= 18), то человек, которому сегодня исполнилось 18, не сможет купить товар. Это критический баг.

    Как выбирать границы?

    Для каждой границы мы должны проверить:
  • Саму границу.
  • Значение чуть меньше границы (-1).
  • Значение чуть больше границы (+1).
  • Вернемся к примеру с оценкой (от 1 до 5).

    Границы диапазона: 1 и 5.

    Проверки для нижней границы (1): * 0 (Граница - 1): Ожидаем ошибку. * 1 (Граница): Ожидаем успех. * 2 (Граница + 1): Ожидаем успех.

    Проверки для верхней границы (5): * 4 (Граница - 1): Ожидаем успех. * 5 (Граница): Ожидаем успех. * 6 (Граница + 1): Ожидаем ошибку.

    !Схема проверки граничных значений для диапазона от 1 до 5.

    Двухграничная и трехграничная проверка

    Иногда тестировщики спорят, нужно ли проверять «Граница + 1» для валидного значения (например, число 2 в примере выше).

    * Если вы хотите сэкономить время, проверяйте только саму границу и значение за ней (выходящее из класса). Это двухточечный анализ. * Если цена ошибки высока (например, банковское ПО), используйте трехточечный анализ (до, на границе, после).

    Комбинируем техники: Практический пример

    Давайте закрепим материал на реальной задаче.

    ТЗ (Техническое задание): Интернет-магазин предоставляет скидки в зависимости от суммы заказа. * От 0 до 1000 рублей — скидка 0%. * От 1001 до 5000 рублей — скидка 5%. * От 5001 рубля и выше — скидка 10%. * Отрицательные суммы недопустимы.

    Шаг 1. Выделяем классы эквивалентности

  • Класс 1 (Нет скидки):
  • Класс 2 (Скидка 5%):
  • Класс 3 (Скидка 10%):
  • Невалидный класс:
  • Шаг 2. Определяем граничные значения

    Нам нужно проверить стыки между классами.

    Стык 0 (Начало): * -1 (Невалидное) * 0 (Валидное, 0%)

    Стык 1000/1001: * 1000 (Валидное, 0%) * 1001 (Валидное, 5%)

    Стык 5000/5001: * 5000 (Валидное, 5%) * 5001 (Валидное, 10%)

    Итоговый список тестов (Checklist)

    Вместо того чтобы проверять каждую сумму покупки, мы проведем всего 6-7 ключевых проверок:

  • Ввод -1 -> Ошибка.
  • Ввод 0 -> Скидка 0%.
  • Ввод 500 (Тест внутри класса 1) -> Скидка 0%.
  • Ввод 1000 -> Скидка 0%.
  • Ввод 1001 -> Скидка 5%.
  • Ввод 5000 -> Скидка 5%.
  • Ввод 5001 -> Скидка 10%.
  • Этого набора достаточно, чтобы с уверенностью 99% сказать, что логика скидок работает верно.

    Частые ошибки новичков

  • Забывают про 0. Ноль — это особое число, часто являющееся границей. Всегда проверяйте его отдельно.
  • Забывают про пустой ввод. Что будет, если ничего не ввести и нажать Enter? Это отдельный класс эквивалентности (пустое значение).
  • Тестируют середину диапазона, но забывают границы. Помните: ошибки живут на краях!
  • Резюме

    * Black Box — тестируем, не зная кода. White Box — смотрим в код. * Классы эквивалентности помогают сократить количество тестов, группируя похожие данные. * Граничные значения уточняют проверку на стыках этих групп, так как там чаще всего прячутся баги. * Эффективное тестирование — это не «проверить всё», а «проверить самое важное».

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

    4. Технические основы: клиент-серверная архитектура, протокол HTTP и тестирование API через Postman

    Технические основы: клиент-серверная архитектура, протокол HTTP и тестирование API через Postman

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

    Но что происходит «под капотом», когда вы нажимаете кнопку «Войти»? Как мобильное приложение узнает погоду? Как сайт понимает, что вы ввели правильный пароль?

    Сегодня мы заглянем внутрь «Черного ящика». Мы разберем клиент-серверную архитектуру, научимся читать язык интернета — протокол HTTP, и проведем свое первое тестирование API с помощью инструмента Postman.

    Это те навыки, которые отличают простого «кликера» от настоящего инженера по тестированию.

    Клиент-серверная архитектура: Как устроен интернет

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

    Давайте представим поход в ресторан. Это лучшая аналогия для понимания процесса.

  • Клиент (Client): Это вы, посетитель ресторана. В мире IT клиентом выступает ваш браузер (Chrome, Safari), мобильное приложение или программа на компьютере. Клиент — это интерфейс, с которым взаимодействует пользователь. Он красивый, удобный, но сам по себе он не умеет готовить еду.
  • Сервер (Server): Это кухня ресторана. Там хранятся продукты (База Данных), там работают повара (Бэкенд-код), которые знают рецепты и умеют готовить блюда. Сервер — это мощный компьютер, который обрабатывает запросы и хранит информацию.
  • Запрос (Request): Вы делаете заказ официанту. Вы говорите: «Хочу пасту Карбонара».
  • Ответ (Response): Официант приносит вам тарелку с пастой или говорит: «Извините, паста закончилась».
  • !Аналогия работы клиент-серверной архитектуры через пример с рестораном.

    > Суть: Клиент всегда просит (отправляет запрос), а Сервер всегда отвечает (отправляет ответ).

    Протокол HTTP: Язык общения

    Чтобы клиент и сервер поняли друг друга, они должны говорить на одном языке. В интернете этот язык называется HTTP (HyperText Transfer Protocol — протокол передачи гипертекста).

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

    Структура URL

    Адрес, который мы вводим, называется URL (Uniform Resource Locator). Разберем его на части:

    https://example.com/users/search?name=Ivan

    * https://Протокол. Правила передачи данных (S означает Secure — защищенный). * example.comДомен (Хост). Адрес сервера (как адрес ресторана). * /users/searchПуть (Path). Конкретный ресурс или действие (как раздел меню). * ?name=IvanПараметры запроса. Уточнение (как «без лука» или «с двойным сыром»).

    Методы HTTP (Глаголы)

    В HTTP есть специальные команды, которые говорят серверу, что именно мы хотим сделать с данными. Основных методов четыре, и они часто сокращаются аббревиатурой CRUD (Create, Read, Update, Delete):

  • GET (Read) — Получить данные.
  • Пример:* Открыть страницу товара, посмотреть список друзей. Аналогия:* Попросить меню.
  • POST (Create) — Создать данные.
  • Пример:* Зарегистрироваться, отправить сообщение, создать заказ. Аналогия:* Сделать заказ.
  • PUT (Update) — Обновить данные (полностью).
  • Пример:* Изменить информацию в профиле, поменять пароль. Аналогия:* Попросить заменить блюдо.
  • DELETE (Delete) — Удалить данные.
  • Пример:* Удалить товар из корзины, отписаться от рассылки.

    Коды ответов сервера (Status Codes)

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

    Их легко запомнить по первым цифрам:

    * 2xx (Успех): «Все хорошо, я сделал то, что ты просил». * 200 OK — Самый частый ответ. Запрос выполнен успешно. * 201 Created — Успешно создано (обычно в ответ на POST).

    * 4xx (Ошибка клиента): «Ты ошибся в запросе». * 400 Bad Request — Сервер не понял запрос (кривые данные). * 401 Unauthorized — Ты не представился (нужно залогиниться). * 403 Forbidden — Тебе сюда нельзя (нет прав доступа). * 404 Not Found — Такого ресурса не существует (страница не найдена).

    * 5xx (Ошибка сервера): «Я сломался, прости». * 500 Internal Server Error — Внутренняя ошибка сервера (упала база данных, ошибка в коде). * 502 Bad Gateway — Сервер получил недействительный ответ от другого сервера. * 503 Service Unavailable — Сервер перегружен или на обслуживании.

    !Визуальная классификация кодов состояния HTTP.

    Что такое API?

    API (Application Programming Interface) — это интерфейс, который позволяет двум программам общаться друг с другом.

    Вернемся к ресторану. Меню — это документация API. Официант — это сам API. Вы не можете зайти на кухню и сами пожарить котлету (это небезопасно и негигиенично). Вы можете взаимодействовать с кухней только через официанта и только заказывая то, что есть в меню.

    Тестирование API — это проверка того, правильно ли работает «официант» и «кухня», без красивого интерьера (графического интерфейса).

    Зачем тестировать API?

    Вспоминаем правило «Цена ошибки». API — это фундамент. Если логика расчета скидки на сервере работает неверно, то неважно, насколько красивая кнопка «Купить» на сайте — сумма все равно будет неправильной.

    Тестирование API позволяет находить баги на ранних этапах, еще до того, как готов дизайн сайта.

    Формат JSON

    В современном вебе данные чаще всего передаются в формате JSON (JavaScript Object Notation). Это текстовый формат, понятный и человеку, и машине.

    Он выглядит как набор пар «Ключ: Значение» внутри фигурных скобок.

    Пример JSON-объекта (информация о пользователе):

    Практика: Тестирование через Postman

    Postman — это самый популярный инструмент для тестирования API. Он позволяет отправлять запросы на сервер так, как это делает браузер или мобильное приложение, и смотреть «сырой» ответ.

    Установка

    Скачайте и установите Postman с официального сайта. Он бесплатен для базового использования.

    Ваш первый запрос

    Для тренировки мы будем использовать открытый тестовый API: https://reqres.in.

    Сценарий 1: Получение списка пользователей (GET)

  • Откройте Postman.
  • Нажмите кнопку + или New Request.
  • В выпадающем списке слева выберите метод GET.
  • В поле URL введите: https://reqres.in/api/users?page=2.
  • Нажмите синюю кнопку Send (Отправить).
  • Что произошло? В нижней части экрана (Response Body) вы увидите ответ сервера в формате JSON. Также обратите внимание на статус код: справа должно быть написано 200 OK.

    Сценарий 2: Создание пользователя (POST)

  • Создайте новую вкладку.
  • Выберите метод POST.
  • Введите URL: https://reqres.in/api/users.
  • Теперь нам нужно передать данные. Перейдите на вкладку Body (под строкой URL).
  • Выберите тип raw, а в выпадающем списке справа — JSON.
  • Вставьте следующий код в поле ввода:
  • Нажмите Send.
  • Результат: Сервер должен ответить кодом 201 Created. В теле ответа (Response) вы увидите, что пользователю присвоился id и дата создания createdAt.

    Что проверять в Postman?

    Когда вы тестируете API, вы должны сверять фактический результат с документацией (Swagger/OpenAPI):

  • Статус код: Ожидали 200, получили 500? Баг.
  • Тело ответа: Пришли ли нужные поля? Правильные ли там данные?
  • Время ответа (Time): Если простой запрос выполняется 5 секунд — это баг производительности.
  • Резюме

    Сегодня вы сделали огромный шаг в техническую часть профессии.

    * Клиент-серверная архитектура — это основа работы веба. Клиент просит, сервер отвечает. * HTTP — это протокол общения. Он состоит из запросов (Request) и ответов (Response). * Методы HTTP: GET (читать), POST (создать), PUT (обновить), DELETE (удалить). * Коды ответов: 2xx (ОК), 4xx (Ошибка клиента), 5xx (Ошибка сервера). * Postman — инструмент, позволяющий отправлять запросы напрямую к серверу, минуя графический интерфейс.

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

    5. Базы данных и инструменты: основы SQL, работа с DevTools и подготовка к собеседованию

    Базы данных и инструменты: основы SQL, работа с DevTools и подготовка к собеседованию

    Поздравляю! Вы прошли долгий путь от понимания того, что такое баг, до отправки API-запросов через Postman. Мы разобрали, как оформлять документы, как придумывать тесты и как общаются программы в интернете.

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

    Базы данных: Где хранится истина

    В прошлой лекции мы сравнивали сервер с кухней ресторана. Если сервер — это кухня, то База Данных (БД) — это огромный холодильник и кладовая, где лежат все продукты (данные).

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

    Реляционные базы данных и SQL

    Самый популярный тип баз данных — реляционные (от англ. relation — связь). Представьте их как набор таблиц Excel, которые связаны друг с другом.

    Например, у нас есть:

  • Таблица Users (Пользователи): ID, Имя, Email.
  • Таблица Orders (Заказы): ID заказа, Дата, Сумма, ID пользователя.
  • Чтобы общаться с этими таблицами, используется язык SQL (Structured Query Language — язык структурированных запросов).

    !Визуализация связи между таблицами пользователей и заказов в реляционной базе данных.

    Основные команды SQL для тестировщика

    Тестировщику редко нужно создавать таблицы или удалять их. Чаще всего нам нужно проверить, записались ли данные верно. Для этого используется команда SELECT.

    Вот 4 главных глагола SQL, которые соответствуют операциям CRUD (Create, Read, Update, Delete):

  • INSERT (Создать) — добавить новую строку.
  • SELECT (Читать) — найти и показать данные.
  • UPDATE (Обновить) — изменить существующие данные.
  • DELETE (Удалить) — удалить строку.
  • Магия SELECT

    Это ваш главный инструмент. Синтаксис выглядит так:

    Разберем по частям: * SELECT — команда «Выбери». — означает «все столбцы» (можно указать конкретные, например SELECT name, email). * FROM Users — «из таблицы Пользователи». * WHERE — «где», условие фильтрации. * age > 18 — условие «возраст больше 18». * ; — конец запроса.

    Примеры задач QA с использованием SQL: * Вы зарегистрировали пользователя, но письмо с подтверждением не пришло. Вы идете в БД и проверяете: создалась ли запись? Правильный ли Email записан? * Вам нужно протестировать удаление товара. Вы нажимаете «Удалить» на сайте, а потом делаете SELECT в базе, чтобы убедиться, что запись действительно исчезла, а не просто скрылась с экрана.

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

    Данные часто разбросаны по разным таблицам. Чтобы узнать, что именно заказал пользователь Иван, нам нужно объединить таблицу Users и Orders.

    Этот запрос найдет Ивана в первой таблице, найдет все его заказы во второй таблице по совпадению ID и покажет нам результат.

    Chrome DevTools: Рентген для веб-сайтов

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

    Чтобы открыть её, нажмите F12 или кликните правой кнопкой мыши на любой элемент страницы и выберите «Просмотреть код» (Inspect).

    Для QA-инженера важны 4 вкладки:

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

    Здесь вы видите HTML (скелет сайта) и CSS (стили).

    Зачем это QA: * Поиск локаторов: Чтобы написать автотест, нужно найти уникальный ID кнопки. Это делается здесь. * Тестирование верстки: Вы можете прямо в коде поменять текст кнопки с «Купить» на «Купить этот замечательный товар прямо сейчас и получить скидку», чтобы проверить, не «поедет» ли верстка от длинного текста.

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

    Сюда разработчики выводят сообщения об ошибках JavaScript.

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

    3. Network (Сеть)

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

    Зачем это QA: * Вы нажали «Войти», но получили ошибку. Вкладка Network покажет, какой именно запрос ушел, какой статус-код вернулся (например, 500 или 401) и какой JSON пришел в ответе. * Это позволяет понять: проблема на клиенте (браузер отправил не то) или на сервере (сервер ответил ошибкой).

    4. Application (Приложение)

    Здесь хранятся Cookies, Local Storage и кэш.

    Зачем это QA: * Cookies: Можно проверить, записалась ли сессия авторизации. * Очистка данных: Если нужно протестировать сайт «как новый пользователь», часто достаточно нажать «Clear Storage» в этой вкладке.

    Подготовка к собеседованию

    Вы изучили теорию, инструменты и процессы. Теперь главная задача — продать эти знания работодателю.

    Собеседование на Junior QA обычно состоит из трех частей.

    Часть 1: Теория

    Вас будут гонять по определениям. Вы должны отскакивать от зубов: * В чем разница между QA и QC? * Что такое жизненный цикл бага? * Назовите виды тестирования. * Что такое классы эквивалентности и граничные значения? * Чем Severity отличается от Priority?

    > Совет: Не заучивайте определения из Википедии. Объясняйте своими словами. «Регрессионное тестирование — это проверка того, что старое не сломалось после внесения нового» звучит лучше, чем сухой академический текст.

    Часть 2: Практика и логика

    Вас попросят протестировать предмет. Карандаш, лифт, тостер или форму логина.

    Алгоритм ответа:

  • Задавайте вопросы! (Самое важное). Какой это карандаш? Для кого? В космосе или под водой?
  • Структурируйте ответ.
  • * Функциональные тесты (рисует ли?). * UI/UX (удобно ли держать, цвет). * Негативные тесты (рисует ли на мокрой бумаге?). * Нагрузочные (как быстро сломается, если давить).

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

    Часть 3: Soft Skills (Гибкие навыки)

    Junior-тестировщика нанимают не за опыт (его нет), а за адекватность и желание учиться.

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

    Заключение курса

    Мы прошли путь от «Что такое тестирование?» до SQL-запросов и консоли браузера.

    Вы узнали:

  • Что тестирование — это не просто поиск багов, а обеспечение качества.
  • Как писать понятные баг-репорты и тест-кейсы.
  • Как применять техники тест-дизайна, чтобы тестировать эффективно.
  • Как работает интернет (HTTP, API) и как смотреть внутрь сайта (DevTools, SQL).
  • Теперь дело за практикой. Установите Postman, откройте DevTools на любимом сайте, попробуйте написать тест-кейс для своего будильника. Мир IT открыт для вас. Удачи в поиске первого бага!