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

Зачем этот урок важен

Представьте, что вы учились водить машину: сначала изучали правила дорожного движения, потом отдельно тренировали параллельную парковку, потом трогание с места на горке. Но всё это имеет смысл только тогда, когда вы садитесь за руль и едете по настоящей дороге от начала до конца.

Этот урок — ваша первая самостоятельная «поездка».

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

Ключевое слово урока — «сквозное тестирование» (end-to-end testing, или E2E-тестирование). Это значит, что мы проверяем не отдельные кнопки, а весь путь пользователя — так же, как покупатель использует магазин в реальной жизни.

Теория

Часть 1. Что такое учебный интернет-магазин и зачем он нужен

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

Для этого существуют учебные (демо) приложения — специально созданные сайты или программы, которые имитируют настоящие продукты. Один из самых популярных — Swag Labs (также известный как SauceDemo), доступный по адресу https://www.saucedemo.com. Это простой интернет-магазин с товарами, корзиной и формой оформления заказа. Именно его мы будем использовать в этом уроке.

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

Часть 2. Тест-план: карта нашего путешествия

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

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

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

Пример тест-плана для нашего проекта

# Тест-план: SauceDemo — базовое тестирование

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

## Область тестирования (scope)
- Страница входа (login)
- Каталог товаров
- Карточка товара
- Корзина
- Форма оформления заказа
- Страница подтверждения заказа

## Что НЕ тестируем (out of scope)
- Производительность и нагрузочное тестирование
- Мобильные устройства (только браузер на ПК)
- Оплата (в демо-версии не реализована)

## Подход
- Ручное тестирование
- Проверяем happy path (успешный сценарий)
- Проверяем негативные сценарии (неверный логин, пустые поля)

## Тестовое окружение
- Браузер: Google Chrome последней версии
- ОС: Windows 10 / macOS
- URL: https://www.saucedemo.com

## Критерии завершения
- Все тест-кейсы выполнены
- Все найденные баги задокументированы

Часть 3. Что такое Happy Path и зачем он нужен

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

Аналогия: когда вы учите ребёнка переходить дорогу, сначала вы показываете правильный способ — дойти до зебры, дождаться зелёного света, посмотреть по сторонам, перейти. Это и есть happy path. Только после этого вы объясняете, что нельзя делать.

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

Часть 4. Основной пользовательский сценарий SauceDemo

Наш happy path состоит из следующих шагов:

1. Открыть сайт https://www.saucedemo.com
2. Войти с корректными данными
3. Просмотреть каталог товаров
4. Открыть карточку товара
5. Добавить товар в корзину
6. Перейти в корзину
7. Проверить содержимое корзины
8. Нажать кнопку "Checkout" (оформить заказ)
9. Заполнить форму с именем и почтовым индексом
10. Подтвердить заказ
11. Убедиться, что появилась страница "Order Complete"

Данные для входа в SauceDemo:

• Логин: standard_user
• Пароль: secret_sauce

Эти данные официально опубликованы на самом сайте — специально для практики.

Часть 5. Структура тест-кейса: вспоминаем и углубляем

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

Для нашего проекта мы будем писать тест-кейсы по следующей структуре:

Часть 6. Набор тест-кейсов для нашего проекта

Ниже приведены тест-кейсы, которые мы будем выполнять. Обратите внимание: они охватывают как happy path, так и несколько негативных сценариев.

TC-001: Успешный вход в систему

**ID:** TC-001
**Название:** Успешный вход с валидными данными

**Предусловия:**
- Открыт браузер Chrome
- Загружена страница https://www.saucedemo.com

**Шаги:**
1. В поле "Username" ввести: standard_user
2. В поле "Password" ввести: secret_sauce
3. Нажать кнопку "Login"

**Ожидаемый результат:**
Пользователь перенаправлен на страницу каталога товаров.
В заголовке страницы отображается текст "Swag Labs".
Список товаров виден на странице.

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

TC-002: Вход с неверным паролем

**ID:** TC-002
**Название:** Вход с неверным паролем — проверка сообщения об ошибке

**Предусловия:**
- Открыт браузер Chrome
- Загружена страница https://www.saucedemo.com

**Шаги:**
1. В поле "Username" ввести: standard_user
2. В поле "Password" ввести: wrongpassword
3. Нажать кнопку "Login"

**Ожидаемый результат:**
Пользователь НЕ перенаправлен в каталог.
На странице отображается сообщение об ошибке:
"Username and password do not match any user in this service"

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

TC-003: Вход с пустыми полями

**ID:** TC-003
**Название:** Попытка входа с пустыми полями

**Предусловия:**
- Открыт браузер Chrome
- Загружена страница https://www.saucedemo.com

**Шаги:**
1. Оставить поля "Username" и "Password" пустыми
2. Нажать кнопку "Login"

**Ожидаемый результат:**
Форма не отправляется.
Отображается сообщение об ошибке, указывающее на обязательность полей.

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

TC-004: Добавление товара в корзину

**ID:** TC-004
**Название:** Добавление одного товара в корзину из каталога

**Предусловия:**
- Пользователь выполнил вход (TC-001 — Pass)
- Отображается страница каталога товаров

**Шаги:**
1. На странице каталога найти товар "Sauce Labs Backpack"
2. Нажать кнопку "Add to cart" рядом с этим товаром

**Ожидаемый результат:**
- Кнопка "Add to cart" изменилась на "Remove"
- В иконке корзины (правый верхний угол) появилась цифра "1"

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

TC-005: Просмотр корзины

**ID:** TC-005
**Название:** Проверка содержимого корзины после добавления товара

**Предусловия:**
- TC-004 выполнен — товар добавлен в корзину

**Шаги:**
1. Нажать на иконку корзины в правом верхнем углу

**Ожидаемый результат:**
- Открылась страница корзины
- В корзине отображается товар "Sauce Labs Backpack"
- Указано количество (1) и цена товара

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

TC-006: Оформление заказа

**ID:** TC-006
**Название:** Успешное оформление заказа (happy path)

**Предусловия:**
- TC-005 выполнен — пользователь находится в корзине с товаром

**Шаги:**
1. Нажать кнопку "Checkout"
2. В поле "First Name" ввести: Анна
3. В поле "Last Name" ввести: Иванова
4. В поле "Zip/Postal Code" ввести: 123456
5. Нажать кнопку "Continue"
6. Проверить страницу с итогами заказа (Order Overview)
7. Нажать кнопку "Finish"

**Ожидаемый результат:**
- Отображается страница подтверждения
- На странице есть текст "Thank you for your order!" 
  или "THANK YOU FOR YOUR ORDER"

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

TC-007: Оформление заказа с пустым полем имени

**ID:** TC-007
**Название:** Оформление заказа без указания имени

**Предусловия:**
- TC-005 выполнен — пользователь нажал кнопку "Checkout"
- Открыта форма ввода данных покупателя

**Шаги:**
1. Оставить поле "First Name" пустым
2. В поле "Last Name" ввести: Иванова
3. В поле "Zip/Postal Code" ввести: 123456
4. Нажать кнопку "Continue"

**Ожидаемый результат:**
Форма не принята.
Отображается сообщение об ошибке, что поле "First Name" обязательно.

**Фактический результат:** (заполнить при выполнении)
**Статус:** (Pass / Fail)

Часть 7. Как описывать баги

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

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

Стандартная структура баг-репорта:

Severity vs Priority — важное различие!

Severity (серьёзность) — насколько сильно баг влияет на работу программы. Например, кнопка «Оплатить» не работает — это Critical.

Priority (приоритет) — как быстро его нужно исправить. Например, опечатка на главной странице сайта имеет низкую severity (Minor), но высокий priority — потому что её видят все пользователи.

Пример баг-репорта

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

**ID:** BUG-001
**Название:** Пользователь locked_out_user не может войти в систему —
отображается некорректное сообщение об ошибке

**Severity:** Major
**Priority:** High

**Шаги воспроизведения:**
1. Открыть https://www.saucedemo.com
2. В поле "Username" ввести: locked_out_user
3. В поле "Password" ввести: secret_sauce
4. Нажать кнопку "Login"

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

**Фактический результат:**
Отображается техническое сообщение на английском языке:
"Sorry, this user has been locked out."
Сообщение не переведено и не объясняет пользователю дальнейшие действия.

**Окружение:**
- Браузер: Google Chrome 124
- ОС: Windows 10

**Скриншот:** [прикрепить скриншот]

Часть 8. Как делать скриншоты для баг-репорта

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

Как сделать скриншот:

• Windows: нажмите клавишу Print Screen (или PrtScn) для снимка всего экрана. Или Win + Shift + S для выбора области.
• macOS: нажмите Cmd + Shift + 4 для выбора области экрана.

Советы по хорошим скриншотам для баг-репорта:

• На снимке должна быть видна сама ошибка
• Укажите стрелкой или обведите красным прямоугольником проблемное место (можно в Paint или Preview)
• Сохраняйте скриншоты с понятными именами: BUG-001-locked-user-error.png

Часть 9. Чек-лист vs тест-кейс: когда что использовать

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

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

Чек-лист для быстрой проверки SauceDemo:

## Чек-лист: базовая проверка SauceDemo

### Страница входа
- [ ] Форма входа отображается при открытии сайта
- [ ] Вход с валидными данными работает
- [ ] Ошибка при неверном пароле отображается
- [ ] Ошибка при пустых полях отображается
- [ ] Поле пароля скрывает введённые символы (отображает точки/звёздочки)

### Каталог товаров
- [ ] После входа отображается список товаров
- [ ] У каждого товара есть название, описание и цена
- [ ] Кнопка "Add to cart" присутствует у каждого товара
- [ ] Сортировка товаров работает (по цене, по имени)

### Корзина
- [ ] Добавленный товар отображается в корзине
- [ ] Цена в корзине совпадает с ценой в каталоге
- [ ] Можно удалить товар из корзины

### Оформление заказа
- [ ] Форма принимает корректные данные
- [ ] Поля обязательны для заполнения
- [ ] После подтверждения отображается страница успеха
- [ ] После завершения заказа корзина пуста

Пример: полный сквозной тест (E2E)

Ниже — полный пример того, как выглядит выполненный тест-кейс после реального тестирования SauceDemo. Это то, что вы должны получить по итогам работы.

**ID:** TC-006
**Название:** Успешное оформление заказа (happy path)

**Предусловия:**
- TC-005 выполнен — пользователь находится в корзине с товаром

**Шаги:**
1. Нажать кнопку "Checkout"
2. В поле "First Name" ввести: Анна
3. В поле "Last Name" ввести: Иванова
4. В поле "Zip/Postal Code" ввести: 123456
5. Нажать кнопку "Continue"
6. Проверить страницу с итогами заказа (Order Overview)
7. Нажать кнопку "Finish"

**Ожидаемый результат:**
Отображается страница подтверждения с текстом
"THANK YOU FOR YOUR ORDER"

**Фактический результат:**
Отображается страница подтверждения.
Текст: "THANK YOU FOR YOUR ORDER" присутствует.
Под заголовком — картинка с велосипедом и текст
"Your order has been dispatched..."

**Статус:** ✅ PASS

**Примечания:**
Текст "Your order has been dispatched, and will arrive
just as fast as the pony can get there!" выглядит неформально
для делового магазина — возможно, стоит обсудить с командой.

Обратите внимание: хороший тестировщик не только фиксирует Pass/Fail, но и добавляет наблюдения, которые могут быть полезны команде — даже если формально это не баг.

Практика

Упражнение 1: Создайте свой тест-план

Откройте любой текстовый редактор (Notepad, Google Docs, Word — что удобнее). Составьте тест-план для SauceDemo по шаблону из этого урока. Заполните все разделы своими словами. Это не должен быть идеальный документ — важно, чтобы вы прошли через процесс мышления «что именно я собираюсь проверять».

Что проверить у себя:

• Есть ли в вашем тест-плане цель?
• Написали ли вы, что не будете тестировать (out of scope)?
• Указали ли браузер и URL?

Упражнение 2: Выполните все 7 тест-кейсов

Откройте браузер, перейдите на https://www.saucedemo.com и выполните все тест-кейсы из этого урока (TC-001 по TC-007) по очереди.

Для каждого тест-кейса:

1. Запишите фактический результат (что произошло на самом деле)
2. Поставьте статус: Pass или Fail
3. Сделайте скриншот для каждого Fail (или для интересных наблюдений)

Подсказка: Если тест-кейс зависит от предыдущего (например, TC-005 требует выполнения TC-004), выполняйте их по порядку, не закрывая браузер.

Упражнение 3: Найдите и опишите 2 бага

В SauceDemo есть намеренно «сломанные» пользователи. Попробуйте войти с этими данными и посмотрите, что произойдёт:

• Логин: problem_user / Пароль: secret_sauce
• Логин: performance_glitch_user / Пароль: secret_sauce

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

Оформите минимум 2 баг-репорта по шаблону из урока с полями: ID, название, severity, priority, шаги воспроизведения, ожидаемый и фактический результат, окружение.

Упражнение 4: Дополните чек-лист

В разделе теории есть чек-лист для SauceDemo. Пройдитесь по нему и:

1. Отметьте каждый пункт: ✅ (работает), ❌ (не работает) или ⚠️ (работает с замечаниями)
2. Добавьте в чек-лист минимум 3 новых пункта, которые вы считаете важными, но которых нет в списке

Пример новых пунктов:

• Можно ли добавить несколько одинаковых товаров?
• Что происходит, если нажать «Назад» в браузере после оформления заказа?
• Отображается ли имя пользователя после входа?

Краткие итоги урока

• Сквозное тестирование (E2E) — это проверка полного пути пользователя от начала до конца, а не отдельных элементов по отдельности.
• Тест-план — это карта тестирования: что, как и зачем мы проверяем, что намеренно пропускаем и когда считаем работу завершённой.
• Happy path — сценарий, когда всё идёт правильно. Начинать тестирование всегда нужно с него.
• Тест-кейс включает: предусловия, шаги, ожидаемый и фактический результат, статус Pass/Fail.
• Баг-репорт должен быть настолько точным, чтобы разработчик мог воспроизвести ошибку, не задавая дополнительных вопросов.
• Severity (серьёзность) и Priority (приоритет) — разные вещи: баг может быть мелким, но требовать срочного исправления — и наоборот.
• Чек-лист — упрощённая альтернатива тест-кейсу, удобная для быстрых проверок.
• Учебные приложения вроде SauceDemo — безопасный способ получить реальный опыт тестирования без риска навредить настоящему продукту.
• Результаты этого мини-проекта (тест-план, тест-кейсы, баг-репорты) — это первые артефакты вашего портфолио.