Основы QA тестирования: Полный гид для начинающих

Введение в QA: основные понятия, принципы тестирования и роль инженера по качеству

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

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

Что такое качество и почему оно важно?

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

Представьте, что вы купили новый смартфон. Он красивый, мощный, но каждый раз, когда вы пытаетесь позвонить, приложение «Телефон» закрывается. Качественный ли это продукт? Очевидно, нет. Даже если камера снимает идеально, основная функция не работает.

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

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

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

!Схема, показывающая иерархию понятий: Тестирование является частью QC, а QC является частью QA.

Давайте разберем каждый уровень подробнее:

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

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

* Цель: Улучшить процессы, чтобы баги не появлялись вовсе. * Пример: Написание стандартов кодирования, проведение аудитов, обучение сотрудников, выбор инструментов разработки.

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

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

* Цель: Найти дефекты до того, как продукт попадет к пользователю. * Пример: Проверка кода (Code Review), запуск тестов, анализ результатов тестирования.

3. Testing — Тестирование

Это непосредственное исполнение проверок. Это процесс исследования ПО с целью получения информации о его качестве.

* Цель: Обнаружить конкретные ошибки и сбои. * Пример: Нажатие кнопок в приложении, ввод данных в формы, проверка API запросов.

Для наглядности сравним их в таблице:

| Характеристика | QA (Обеспечение качества) | QC (Контроль качества) | Testing (Тестирование) | | :--- | :--- | :--- | :--- | | Фокус | Процесс | Продукт | Исполнение | | Вопрос | «Как мы делаем продукт?» | «Что мы сделали?» | «Работает ли это?» | | Характер | Превентивный (предотвращение) | Корректирующий (обнаружение) | Исследовательский | | Активность | Планирование, улучшение процессов | Проверка соответствия требованиям | Поиск багов |

Семь принципов тестирования

Международная организация ISTQB (International Software Testing Qualifications Board) выделяет 7 фундаментальных принципов, которые должен знать каждый тестировщик. Это «заповеди» нашей профессии.

1. Тестирование демонстрирует наличие дефектов

Тестирование может показать, что дефекты есть, но не может доказать, что их нет. Даже если вы провели тысячи тестов и все они прошли успешно, это не гарантирует 100% отсутствия ошибок. Это лишь снижает вероятность их наличия.

2. Исчерпывающее тестирование невозможно

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

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

3. Раннее тестирование

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

!График, демонстрирующий, что исправление бага на этапе требований стоит 1000.

4. Скопление дефектов (Defect Clustering)

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

5. Парадокс пестицида

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок

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

Кто такой QA инженер и какова его роль?

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

Основные задачи QA инженера:

Анализ требований: Изучение документации на предмет логических противоречий и неточностей еще до начала написания кода.

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

Создание тестовой документации: Написание тест-кейсов (сценариев проверки), чек-листов и баг-репортов.

Непосредственное тестирование: Ручное или автоматизированное выполнение проверок.

Коммуникация: Общение с разработчиками, аналитиками и менеджерами. QA — это мост между технической командой и бизнесом.

Важные навыки (Hard & Soft Skills)

Для успешной работы недостаточно знать теорию. Вот что ценится в специалистах:

* Внимательность к деталям: Умение замечать мелочи, которые другие пропускают. * Критическое мышление: Способность ставить под сомнение утверждения («А что, если пользователь нажмет сюда?»). * Умение четко формулировать мысли: Баг-репорт должен быть понятен разработчику без дополнительных вопросов. * Технический бэкграунд: Понимание того, как работает веб, базы данных и API (этому мы научимся в следующих статьях).

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

Когда QA инженер находит ошибку, работа только начинается. Баг должен пройти определенный путь:

New (Новый): Баг найден и задокументирован.

Assigned (Назначен): Разработчик принял баг в работу.

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

Verified (Проверен): QA проверяет, действительно ли исправление работает и не сломало ли оно что-то другое (регрессионное тестирование).

Closed (Закрыт): Ошибка устранена окончательно.

Заключение

QA тестирование — это искусство баланса. Баланса между скоростью и качеством, между желанием проверить всё и реальными сроками. Инженер по качеству — это адвокат пользователя внутри команды разработки. Ваша задача — сделать так, чтобы конечный продукт приносил радость, а не разочарование.

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

Виды и уровни тестирования: функциональное, нефункциональное и регрессионное тестирование

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

Когда новичок открывает вакансии, он видит десятки непонятных слов: «Unit-тестирование», «Smoke», «Регресс», «Black Box», «Нагрузочное». Кажется, что это разные вселенные. На самом деле, всё тестирование можно классифицировать по нескольким понятным полочкам. Сегодня мы разберем карту тестирования, которая поможет вам ориентироваться в любом проекте.

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

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

!Классическая пирамида тестирования, показывающая иерархию проверок от кода до готового продукта.

1. Модульное тестирование (Unit Testing)

Это фундамент пирамиды. Здесь проверяются самые маленькие, неделимые части кода — «юниты» (функции, методы, классы).

* Кто делает: Обычно сами разработчики. * Суть: Проверить, правильно ли работает конкретная шестеренка в отрыве от всего механизма. * Пример: Есть функция «Сложение». Мы подаем ей на вход 2 и 2, и проверяем, что она вернула 4.

2. Интеграционное тестирование (Integration Testing)

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

* Кто делает: Разработчики или QA-автоматизаторы (иногда ручные тестировщики). * Суть: Проверить стыки и передачу данных. * Пример: Приложение отправляет запрос в базу данных. Сохранился ли пользователь? Вернулся ли правильный ответ от сервера?

3. Системное тестирование (System Testing)

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

* Кто делает: QA инженеры. * Суть: Проверка соответствия готового продукта требованиям. * Пример: Установка приложения на реальный телефон, регистрация, добавление товара в корзину и оплата.

4. Приемочное тестирование (Acceptance Testing)

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

* Кто делает: Заказчик, Product Manager или группа конечных пользователей (бета-тестирование). * Суть: Ответ на вопрос «Это то, что мы заказывали?».

Подходы к тестированию: Ящики

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

Черный ящик (Black Box)

Мы не знаем, как устроена система внутри. Мы не видим код. У нас есть только интерфейс (кнопки, поля ввода). * Принцип: «Вход -> [Неизвестный процесс] -> Выход». * Кто использует: Большинство ручных тестировщиков. Мы действуем как обычный пользователь: нажали кнопку — ждем результат.

Белый ящик (White Box)

Мы видим код, структуру базы данных и алгоритмы. Тесты пишутся с знанием внутренней логики. * Принцип: Анализ кода и путей выполнения программы. * Кто использует: Разработчики (Unit-тесты) и SDET (инженеры по автоматизации).

Серый ящик (Grey Box)

Комбинация подходов. Мы работаем через интерфейс, но можем заглянуть в базу данных или логи сервера, чтобы понять причину ошибки. * Пример: Вы нажали «Купить», получили ошибку. В «Черном ящике» вы просто напишете «Ошибка при покупке». В «Сером» вы посмотрите логи и допишете: «Ошибка 500 из-за тайм-аута базы данных».

---

Функциональное тестирование: «Что система делает?»

Это самый обширный вид тестирования. Он отвечает на вопрос: выполняет ли программа свои функции?

Если в требованиях написано «Пользователь может загрузить аватарку», функциональный тест проверяет именно возможность загрузки аватарки.

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

Smoke Testing (Дымовое тестирование):

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

Sanity Testing (Санитарное тестирование):

Узконаправленная проверка конкретной функции или исправленного бага. Это проверка «здравомыслия» системы после небольших изменений. Пример:* Починили кнопку «Корзина». Мы проверяем только корзину, не трогая остальное.

Exploratory Testing (Исследовательское тестирование):

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

Нефункциональное тестирование: «Как система работает?»

Мало сделать так, чтобы функция работала. Важно, как она работает. Нефункциональное тестирование проверяет атрибуты качества системы.

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

Основные виды нефункционального тестирования:

#### 1. Тестирование производительности (Performance Testing) Проверка скорости, отзывчивости и стабильности работы.

* Load Testing (Нагрузочное): Как ведет себя система при ожидаемой нагрузке (например, 1000 пользователей одновременно). * Stress Testing (Стрессовое): Поиск предела прочности. Что будет, если придет 100 000 пользователей? Упадет ли сервер или просто замедлится?

#### 2. Тестирование удобства использования (Usability Testing) Насколько пользователю удобно и понятно работать с продуктом. * Легко ли найти кнопку «Выход»? * Читаем ли текст? * Не слишком ли много кликов нужно для простого действия?

#### 3. Тестирование безопасности (Security Testing) Проверка системы на уязвимости. Могут ли хакеры украсть данные? Можно ли зайти в чужой аккаунт без пароля?

#### 4. Тестирование совместимости (Compatibility Testing) Корректно ли работает сайт в разных браузерах (Chrome, Safari, Firefox)? А на разных устройствах (iPhone, Android, планшет)?

| Вид тестирования | Вопрос | Пример бага | | :--- | :--- | :--- | | Функциональное | Что делает? | Кнопка «Оплатить» не нажимается. | | Нефункциональное | Как работает? | Кнопка «Оплатить» нажимается, но система думает 40 секунд. |

---

Связанное с изменениями: Регресс и Re-test

Это два понятия, которые путают 90% новичков на собеседованиях. Давайте разберем их раз и навсегда.

Когда разработчик чинит баг или добавляет новую фичу, код меняется. Любое изменение может случайно сломать то, что раньше работало идеально.

Re-testing (Повторное тестирование)

Это проверка конкретного исправления.

* Ситуация: Вы нашли баг «Не работает поиск». Разработчик сказал «Исправил». * Действие: Вы идете и проверяете именно поиск. * Цель: Убедиться, что баг устранен.

Regression Testing (Регрессионное тестирование)

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

* Ситуация: Разработчик починил поиск. Но при этом он затронул общую библиотеку работы с базой данных. * Действие: Вы проверяете не только поиск, но и фильтры, каталог и карточку товара. * Цель: Убедиться, что исправление одного места не вызвало «регресс» (ухудшение) в другом.

!Визуализация различия между проверкой исправления (Re-testing) и проверкой влияния изменений на систему (Regression).

> «Регрессионное тестирование — это как проверка всего дома после того, как вы поменяли замок во входной двери. Вы проверяете замок (Re-testing), а потом убеждаетесь, что окна не вылетели и крыша не поехала (Regression).»

Итоги

Мир тестирования огромен, но структурирован. Чтобы стать хорошим специалистом, не нужно пытаться выучить все виды сразу. Достаточно понимать логику:

Уровни: От кода (Unit) к системе (System).

Подходы: Видим код (White Box) или нет (Black Box).

Цели: Проверяем функции (Functional) или характеристики (Non-functional).

Изменения: Проверяем фикс (Re-test) и защищаемся от новых багов (Regression).

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

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

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

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

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

Чек-лист (Checklist): Список покупок для тестировщика

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

Особенности чек-листа: * Краткость: Содержит только суть проверки. * Гибкость: Легко дополнять и менять. * Скорость: Быстро пишется и быстро проходится.

Пример чек-листа для формы логина:

Проверить вход с валидными данными.

Проверить вход с неверным паролем.

Проверить вход с несуществующим логином.

Проверить восстановление пароля.

Проверить кнопку «Зарегистрироваться».

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

Тест-кейс (Test Case): Детальный рецепт

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

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

!Визуальная структура стандартного тест-кейса

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

Хороший тест-кейс всегда содержит следующие атрибуты:

ID: Уникальный номер (например, TC-001).

Заголовок (Title): Краткое и понятное описание сути проверки. Должен отвечать на вопросы: Что? Где? Когда?

Плохо:* «Проверка логина». Хорошо:* «Успешная авторизация пользователя с валидными данными на главной странице».

Предусловия (Preconditions): Что должно быть сделано до начала теста. Это подготовка окружения.

Пример:* «Пользователь зарегистрирован и находится на странице входа».

Шаги (Steps): Точная последовательность действий.

1. Ввести логин user@example.com. 2. Ввести пароль 123456. 3. Нажать кнопку «Войти».

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

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

Постусловия (Postconditions): Действия по возвращению системы в исходное состояние (необязательно, но полезно).

Пример:* «Разлогиниться, чтобы не мешать следующему тесту».

Чек-лист или Тест-кейс?

| Характеристика | Чек-лист | Тест-кейс | | :--- | :--- | :--- | | Детализация | Низкая (только идеи) | Высокая (каждый шаг расписан) | | Время на создание | Минуты | Часы | | Поддержка | Легко обновлять | Трудно поддерживать актуальность | | Для кого | Опытные сотрудники | Новички, сложная логика, автоматизация |

Баг-репорт (Bug Report): Искусство жаловаться

Когда ожидаемый результат в тест-кейсе не совпадает с фактическим — мы нашли баг! Теперь наша задача — сообщить о нем разработчику так, чтобы он захотел и смог его исправить. Этот документ называется Баг-репорт.

> «Хороший баг-репорт — это такой отчет, по которому разработчик может воспроизвести ошибку с первого раза, не задавая лишних вопросов».

Анатомия баг-репорта

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

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

Description (Описание): Более подробный контекст (версия браузера, тестовое окружение, ссылка на стенд).

Steps to Reproduce (Шаги воспроизведения): Священный грааль баг-репорта. Инструкция, как «сломать» программу.

1. Открыть главную страницу. 2. Авторизоваться. 3. Нажать на иконку «Корзина».

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

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

Attachments (Вложения): Скриншоты, видео, логи сервера. Один скриншот может заменить 1000 слов.

Severity и Priority: В чем разница?

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

#### Severity (Серьезность) Показывает, насколько сильно баг влияет на работу системы технически.

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

#### Priority (Приоритет) Показывает, как срочно нужно исправить баг с точки зрения бизнеса и менеджмента.

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

!Матрица соотношения Серьезности и Приоритета

Пример парадокса: * High Severity / Low Priority: Приложение падает (High Sev), если нажать кнопку на старом телефоне Nokia 3310, который используют 0.01% пользователей. Технически — крах, бизнесу — всё равно (Low Prio). * Low Severity / High Priority: Опечатка в названии компании на главной странице (Low Sev — всё работает), но это огромный репутационный риск (High Prio).

Жизненный цикл бага (Bug Lifecycle)

Баг не просто создается и исчезает. Он проживает целую жизнь, меняя статусы в системе трекинга задач (например, Jira).

!Схема жизненного цикла дефекта

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

Assigned (Назначен): Тимлид назначил баг на конкретного разработчика.

In Progress (В работе): Разработчик чинит баг.

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

Verified (Проверен): Тестировщик проверяет исправление.

Если работает:* переводим в Closed (Закрыт). Если НЕ работает:* переводим в Reopened (Переоткрыт) и возвращаем разработчику.

Заключение

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

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

Технические навыки: основы клиент-серверной архитектуры, тестирование API и базы данных SQL

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

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

Сегодня мы разберем три кита, на которых держится веб: Клиент-серверную архитектуру, API и Базы данных (SQL).

Клиент-серверная архитектура: как общаются программы

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

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

!Аналогия ресторана для объяснения клиент-серверной архитектуры

Давайте разберем роли:

Клиент (Client): Это заказчик. В мире IT это ваш браузер (Chrome, Safari) или мобильное приложение на телефоне. Клиент — это то, что видит пользователь (Frontend). Его задача — красиво показать информацию и отправить ваш запрос.

Сервер (Server): Это кухня. Мощный компьютер, который находится где-то в дата-центре. Он хранит данные, обрабатывает логику и «готовит» ответы. Пользователь не видит сервер, это «Backend».

Сеть (Network): Это путь, по которому бегает официант. Клиент и сервер общаются через интернет, отправляя друг другу сообщения.

Жизненный цикл запроса

Когда вы вводите адрес сайта и нажимаете Enter, происходит следующее:

Request (Запрос): Клиент формирует сообщение: «Привет, сервер! Дай мне главную страницу сайта».

Processing (Обработка): Сервер получает запрос, понимает, что от него хотят, и ищет нужные данные.

Response (Ответ): Сервер отправляет данные обратно клиенту.

Rendering (Отрисовка): Браузер получает код и превращает его в красивую картинку, которую вы видите.

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

Тестирование API: общение без посредников

Мы выяснили, что клиент и сервер общаются. Но на каком языке? Этот язык и правила общения называются API (Application Programming Interface) — программный интерфейс приложения.

Возвращаясь к ресторану: API — это меню и правила оформления заказа. Вы не можете просто крикнуть «Хочу еды!». Вы должны сказать: «Блюдо номер 5, одна порция». Если вы скажете неправильно, кухня вас не поймет.

Зачем тестировщику API?

Обычно новички тестируют через UI (пользовательский интерфейс): нажимают кнопки. Но UI — это просто красивая обертка. Под ней скрывается API.

Тестирование API позволяет: * Находить баги раньше: UI может быть еще не готов, а логика на сервере уже написана. * Локализовать проблему: Если сайт выдает ошибку, проверка API покажет, кто виноват — фронтенд (криво нарисовал) или бэкенд (прислал ошибку). * Проверять безопасность: Через API можно попытаться отправить данные, которые интерфейс не позволяет ввести (например, отрицательную цену товара).

Протокол HTTP и методы REST

В вебе самым популярным стандартом API является REST, работающий по протоколу HTTP. В нем есть 4 основных действия, которые мы совершаем с данными (CRUD — Create, Read, Update, Delete). Для каждого действия есть свой «глагол» (метод):

| Метод | Аналог в жизни | Описание | Пример | | :--- | :--- | :--- | :--- | | GET | Прочитать | Получение данных от сервера. Ничего не меняет на сервере. | Открыть страницу товара. | | POST | Создать | Отправка новых данных на сервер для создания чего-то. | Регистрация, создание поста. | | PUT | Обновить | Полное обновление существующих данных. | Изменение информации в профиле. | | 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 — Сервер перегружен или на обслуживании.

Формат JSON

Данные между клиентом и сервером чаще всего летают в формате JSON (JavaScript Object Notation). Это простой текстовый формат, понятный и человеку, и машине. Он состоит из пар «Ключ: Значение».

Пример JSON-ответа с информацией о пользователе:

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

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

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

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

!Структура реляционной таблицы базы данных

Что такое SQL?

Чтобы сервер мог взять данные со склада или положить их туда, он использует язык SQL (Structured Query Language) — язык структурированных запросов. Тестировщику SQL нужен, чтобы:

Проверить, правильно ли записались данные после регистрации.

Создать тестовые данные (например, добавить 100 товаров для теста).

Найти конкретный заказ, который потерялся в интерфейсе.

Основные команды SQL

Вам не нужно быть экспертом в проектировании БД, но 4 базовые операции знать обязательно. Они почти полностью соответствуют методам API.

#### 1. SELECT (Выбрать) Самая частая команда. Позволяет «достать» данные из таблицы.

Синтаксис: SELECT [что] FROM [откуда] WHERE [условие]

Пример: Найти email пользователя с именем 'Ivan'.

Если нам нужны все данные из таблицы, мы используем звездочку *:

#### 2. INSERT (Вставить) Добавляет новую строку в таблицу.

Пример: Добавить нового пользователя.

#### 3. UPDATE (Обновить) Изменяет существующие данные. Важно: всегда используйте условие WHERE, иначе вы обновите данные во всей таблице сразу!

Пример: Изменить возраст Марии на 26.

#### 4. DELETE (Удалить) Удаляет строки. Тоже требует осторожности с WHERE.

Пример: Удалить всех пользователей младше 18 лет.

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

Давайте соберем пазл воедино на примере регистрации пользователя:

Клиент (UI): Пользователь вводит имя и пароль, нажимает «Регистрация». Браузер собирает JSON.

API (Request): Браузер отправляет POST запрос на сервер по адресу /api/register.

Сервер: Проверяет данные. Если всё ок, он формирует SQL-запрос.

SQL: Сервер выполняет INSERT INTO Users... в базу данных.

БД: Сохраняет строку и сообщает серверу: «Успешно».

API (Response): Сервер отвечает браузеру кодом 201 Created.

Клиент (UI): Показывает пользователю сообщение «Вы успешно зарегистрировались!».

Заключение

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

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

Методологии разработки и инструменты: Agile, Scrum, Jira и введение в автоматизацию

Поздравляю! Вы уже прошли огромный путь. Вы знаете, как писать тест-кейсы, умеете «разговаривать» с базами данных на языке SQL и понимаете, как работает API. Вы уже обладаете набором навыков крепкого Junior QA инженера.

Но есть один нюанс. В современной IT-компании вы не будете сидеть в вакууме и просто писать запросы к базе данных. Вы будете частью команды. А у любой команды есть правила игры. Как мы решаем, что делать сегодня? Кто отвечает за сроки? Где хранятся задачи?

В этой статье мы разберем «правила дорожного движения» в разработке ПО (методологии) и изучим главный инструмент управления задачами — Jira. А на десерт коснемся темы, о которой мечтают все новички — автоматизации.

Как строят ПО: от Водопада к Гибкости

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

Waterfall (Каскадная модель)

Представьте строительство моста. Сначала архитекторы год рисуют чертежи. Потом инженеры рассчитывают нагрузки. Потом строители заливают бетон. Нельзя на этапе заливки бетона сказать: «А давайте перенесем мост на 500 метров левее!». Это разрушит весь проект.

Waterfall — это последовательная модель разработки. Каждый этап начинается только после завершения предыдущего.

Требования: Написали огромное ТЗ (Техническое Задание) на 300 страниц.

Дизайн: Нарисовали все макеты.

Разработка: Программисты пишут код полгода.

Тестирование: QA получают продукт только в самом конце.

Релиз: Продукт отдают пользователю.

!Визуализация каскадной модели разработки, где каждый этап следует строго за предыдущим.

Минусы Waterfall: * Если ошибка допущена в требованиях, мы узнаем о ней только через год (вспомните принцип «Раннее тестирование»). * Пока мы писали код, рынок изменился, и продукт стал не нужен.

Agile (Гибкая методология)

В 2001 году группа разработчиков собралась и решила: «Хватит это терпеть!». Они написали Agile Manifesto. Это не инструкция, а философия, набор ценностей.

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

В Agile мы не строим весь «мост» целиком. Мы строим сначала веревочную переправу, потом деревянный мостик, а потом уже бетонный хайвей. Мы выпускаем продукт маленькими кусочками и постоянно спрашиваем пользователя: «Тебе нравится?».

Scrum: Самый популярный фреймворк Agile

Agile — это философия. А Scrum — это конкретный набор правил (фреймворк), как работать по Agile. Большинство вакансий, которые вы увидите, будут содержать слово Scrum.

В Scrum работа делится на короткие отрезки времени — Спринты (Sprints). Обычно спринт длится 2 недели.

Роли в Scrum

В классическом Scrum нет начальников. Есть команда.

Product Owner (Владелец продукта): Человек от бизнеса. Он знает, что мы должны сделать. Он составляет список «хотелок» (Бэклог). Его главная задача — максимизировать ценность продукта.

Scrum Master (Скрам-мастер): Это не начальник, а «слуга-лидер». Он следит, чтобы команда соблюдала правила Scrum, помогает устранять препятствия и защищает команду от внешнего шума.

Development Team (Команда разработки): Разработчики, тестировщики, дизайнеры. Они решают, как сделать то, что хочет Product Owner.

Артефакты Scrum

* Product Backlog (Бэклог продукта): Общий список всех задач, идей и багов, которые нужно сделать когда-нибудь. * Sprint Backlog (Бэклог спринта): Список задач, которые команда обязалась выполнить в текущие 2 недели. * Increment (Инкремент): Готовый кусочек продукта в конце спринта (например, работающая кнопка «Оплатить»).

События (Ритуалы) Scrum

Жизнь в Scrum циклична. Каждый спринт состоит из встреч:

| Событие | Когда | Зачем нужно | Роль QA | | :--- | :--- | :--- | :--- | | Sprint Planning | Начало спринта | Выбрать задачи из общего бэклога на ближайшие 2 недели. | Оценить сложность тестирования задач. | | Daily Scrum (Stand-up) | Каждое утро (15 мин) | Синхронизация. Три вопроса: Что делал вчера? Что буду делать сегодня? Что мешает? | Рассказать о прогрессе проверок и найденных блокерах. | | Sprint Review (Demo) | Конец спринта | Показать заказчику готовый функционал. | Часто именно QA проводит демонстрацию, так как лучше всех знает сценарии. | | Sprint Retrospective | После Review | Обсудить процессы. Что было хорошо, а что плохо? Как работать лучше? | Поднять проблемы взаимодействия с разработчиками или нехватки времени. |

Jira: Центр управления полетами

Где хранятся все эти бэклоги и задачи? В системах управления проектами (Task Trackers). Самая популярная в мире — Atlassian Jira.

Для тестировщика Jira — это второй дом. Здесь вы будете проводить 50% рабочего времени.

Основные элементы Jira

Проект (Project): Рабочее пространство вашей команды.

Задача (Issue/Ticket): Единица работы. Это может быть новая фича (Story), техническая задача (Task) или ошибка (Bug).

Доска (Board): Визуализация процесса. Обычно выглядит как таблица с колонками.

!Типичная Канбан-доска в Jira, отображающая поток задач.

Жизненный цикл задачи глазами QA

Давайте проследим путь задачи по доске:

To Do: Задача лежит в очереди.

In Progress: Разработчик взял ее в работу.

Code Review: Разработчик написал код, его проверяют коллеги.

Ready for QA / Testing: Задача попадает к вам! Вы берете ее, тестируете.

Если нашли баг:* Возвращаете задачу в To Do или создаете новый баг-репорт и линкуете (связываете) его с задачей. Если все чисто:* Переводите задачу в Done.

Done: Задача выполнена и готова к релизу.

> Совет: Никогда не переводите задачу в Done, если вы не проверили ее на тестовом стенде. Ваше «ОК» в Jira — это ваша профессиональная подпись под качеством.

Введение в автоматизацию: Роботы наступают?

В вакансиях часто пишут: «Желательно знание Python/Java и Selenium». Многие ручные тестировщики (Manual QA) боятся, что автоматизация их заменит. Давайте разберемся, что это такое.

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

Зачем нужна автоматизация?

Главная цель автотестов — экономия времени на регрессии.

Вспомните пирамиду тестирования. Чем больше становится проект, тем больше времени нужно, чтобы проверить, не сломалось ли старое (регрессионное тестирование). Человек может проверять форму логина 5 минут. Скрипт сделает это за 2 секунды.

Что стоит автоматизировать?

Не всё можно и нужно автоматизировать. Следуйте правилу:

* Автоматизируем: * Рутинные, повторяющиеся задачи (Smoke-тесты). * Критические пути (регистрация, оплата). * Тесты с большим объемом данных (заполнить 1000 полей). * API тесты (их автоматизировать легче всего). * НЕ автоматизируем: * Новый функционал (он еще будет меняться 10 раз). * UX/UI (скрипт не поймет, красиво ли выглядит кнопка). * Одноразовые проверки.

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

Если вы решите развиваться в эту сторону (SDET — Software Development Engineer in Test), вам понадобятся:

Язык программирования: Python (самый популярный для старта), Java, JavaScript.

Фреймворки для UI: Selenium, Playwright, Cypress. Они позволяют коду управлять браузером.

Фреймворки для API: Postman (может запускать автотесты), Pytest, RestAssured.

Ручное vs Автоматизированное

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

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

Мы прошли путь от понимания философии качества до технических дебрей SQL и процессов Scrum. Теперь у вас есть полная карта местности.

Что делать дальше?

Практика: Зарегистрируйтесь на краудтестинговых платформах (utest, test.io) или тестируйте сайты друзей.

Инструменты: Скачайте Postman и попробуйте отправить запросы к публичным API. Установите Jira (у нее есть бесплатная версия) и создайте свой проект.

Резюме: Не пишите «знаю всё». Пишите: «Понимаю жизненный цикл бага, умею составлять тест-кейсы, знаю основы SQL и HTTP».

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