Тренажёры для Manual QA: где тренировать валидацию форм

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

▪️некорректной валидацией,
▪️необычными edge cases с датами,
▪️неинформативными сообщениями об ошибках,
▪️отсутствием ограничений (например, только цифры или пробелы в поле Email).

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

1. The Internet Heroku App – Form Authentication
Страница с формой логина для проверки сообщений об ошибках, поведения инпутов и негативных сценариев.
https://the-internet.herokuapp.com/login

2. DemoQA – Practice Form
Содержит текстовые поля, радио-кнопки, чекбоксы, календарь, загрузку файлов. Отлично подходит для практики boundary values и edge cases.
https://demoqa.com/automation-practice-form

3. SauceDemo
Позволяет протестировать полный пользовательский поток: логин, добавление товара в корзину, проверку данных в формах и checkout.
https://www.saucedemo.com/

4. PHPTravels Demo
Демо-сайт для бронирования авиабилетов, отелей и туров. Подходит для практики с формами поиска, датами и валидацией.
https://phptravels.com/demo/

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

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

🔥22 октября в 19:00 МСК на открытом уроке разберём основы проектирования бизнес-логики в микросервисной архитектуре: как декомпозировать логику по сервисам, какие паттерны использовать и как избежать хаоса при росте приложения.

Поговорим о Shared Kernel, API Composition и Saga, разберём, где должна находиться логика в сервисе, API-шлюзе или общем слое, а также рассмотрим ошибки при проектировании и кейсы декомпозиции сложной бизнес-логики.

Урок проходит в преддверии старта курса «Микросервисная архитектура» и будет полезен backend- и fullstack-разработчикам, архитекторам ПО и системным аналитикам.

⏰Зарегистрируйтесь и разберите основы проектирования бизнес-логики в микросервисной архитектуре: https://vk.cc/d2T30S
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

А что, если бы был такой фреймворк для Go-тестирования, который расширялся бы под любую задачу? Подумали в Ozon Tech, создали такой фреймворк и выложили на GitHub.

Знакомьтесь, Testo: всего один слой над testing.T, а сколько возможностей.

1. Адаптируется под разные сценарии за счёт плагинов.
2. Запускает параметризованные тесты.
3. Поддерживает параллелизацию на всех этапах.
4. Организует тесты в Suite и отдельные тесты.
5. Формирует Allure-отчёты.

Все фичи обозначены на странице фреймворка. Забирайте в работу: https://ozon.tech/testo

🧩 Шпаргалка для QA инженеров: Как тестировать интеграцию одной системы в другую
Источник: Владлен Цыганенко

🔎 1. Анализ требований
— Определите, какие системы интегрируются (API, SDK, база данных, внешние сервисы).
— Уточните цели интеграции: передача данных, авторизация, аналитика, платежи и т.д.
— Разберитесь, какие данные/события должны передаваться, в каком формате и с какой частотой.

💠 2. Проверка базовой интеграции
— Данные передаются из системы А в систему Б без ошибок.
— Формат и структура данных соответствуют спецификации (JSON/XML/CSV и т.п.).
— Обязательные поля присутствуют и корректны.

🔐 3. Валидация безопасности
— Проверить авторизацию/аутентификацию (OAuth, API key, токены).
— Проверить доступ только у разрешённых пользователей/сервисов.
— Негативные проверки: неверный токен, истёкший токен, отсутствие прав.

🌐 4. Сценарии с сетью и окружением
— Что будет при медленном интернете, потере соединения?
— Поведение при повторной отправке одного и того же запроса (идемпотентность).
— Проверка работы в разных окружениях: dev, staging, production.

🔄 5. Обработка ошибок
— Если система А отправила некорректные данные, то система Б возвращает понятный ответ?
— Ошибки логируются и доступны для анализа?
— Пользователь видит корректное сообщение об ошибке (а не «500 internal error»).

📊 6. Нагрузочное тестирование
— Как система реагирует на большой поток запросов?
— Есть ли задержки при обмене данными?
— Нет ли потери или дублирования данных?

🧪 7. Негативные кейсы
— Отправка пустых значений.
— Использование устаревших версий SDK/API.
— Несовпадение версий протоколов (например, HTTP/1.1 vs HTTP/2).

📝 8. Документация и регрессия
— Вся интеграция должна быть задокументирована.
— Проверяйте совместимость при обновлениях (новая версия SDK, новая версия API).
— Ведите чек-листы/тест-кейсы для будущих регрессий.

Инструменты
▫️Postman / Insomnia - API
▫️Charles / Fiddler - трафик
▫️Kibana / Grafana - логи и метрики
▫️Burp Suite / OWASP ZAP - безопасность
▫️Selenium / Playwright / Cypress - e2e
▫️JMeter / k6 / Locust - нагрузка
▫️Android Studio / Xcode - SDK, мобильные
▫️Firebase Test Lab / BrowserStack - устройства

ИТОГ:
QA проверяет обмен данными, учитывает краевые сценарии, оценивает безопасность, стабильность и совместимость систем.

Когда получил задачу без чётких требований. С понедельником нас всех.

📌 OAuth 2.0 и OpenID Connect простыми словами для QA

OAuth и OpenID Connect часто звучат сложно, но на практике это просто способы безопасно пускать пользователя в систему — без передачи пароля каждому сервису.

Разберёмся без криптографии и лишней теории 👇

▫️ Что такое OAuth 2.0
OAuth — это протокол авторизации.
Он отвечает на вопрос:
👉 «Можно ли этому приложению получить доступ к ресурсу пользователя?»

Пример:
Вы логинитесь в сервис через Google → сервис получает access token, но не знает ваш пароль от Google.

Важно для QA:
— OAuth не про логин, а про доступ
— Токен даёт ограниченные права (scope)
— Токен имеет срок жизни

▫️ Что такое OpenID Connect (OIDC)
OIDC — это надстройка над OAuth, которая добавляет аутентификацию.

OIDC отвечает на вопрос:
👉 «Кто этот пользователь?»

OIDC возвращает ID Token, в котором есть:
— user_id
— email
— имя
— issuer (кто подтвердил пользователя)

Проще:
OAuth → что можно делать
OIDC → кто пользователь

▫️ Типичный OAuth / OIDC flow (упрощённо)
— Пользователь нажал «Login with Google»
— Его редиректит на страницу провайдера
— Пользователь подтверждает доступ
— Приложение получает токены
— Пользователь залогинен

▫️ Основные типы токенов
— Access Token — используется в API-запросах
— Refresh Token — обновляет access token
— ID Token (OIDC) — содержит данные о пользователе

▫️ Что QA важно проверять
— Истечение срока действия access token
— Обновление refresh token
— Поведение при logout
— Доступ по ролям и scope
— Ошибки 401 / 403
— Можно ли использовать старый токен
— Что происходит при отмене доступа у провайдера

▫️ Где смотреть и тестировать
— Browser DevTools → Network / Application
— Postman — подмена токенов
— jwt.io — декодирование JWT
— Webhook.site / httpbin — проверка headers

💡 Совет:
Если не понимаете flow — просто пройдите логин шаг за шагом и смотрите Network. OAuth перестаёт быть «магией», когда видишь реальные запросы.

🔥 Приглашаем на бесплатный открытый вебинар курса «Нагрузочное тестирование»:
«Стенды для нагрузочного тестирования»

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

Что будет на вебинаре:
- Типы стендов для нагрузочного тестирования
- Основные особенности стендов для НТ
- Как выбирать стенды для нагрузочного тестирования
- Основные цели стендов и на что они влияют

В результате вебинара вы:
- Поймёте, какие стенды подходят для разных задач нагрузочного тестирования
- Научитесь учитывать особенности окружения при планировании НТ
- Сможете более осознанно выбирать стенды под свои проекты

Кому будет полезно:
Специалистам по ручному и автоматизированному тестированию, специалистам по нагрузочному тестированию, разработчикам, прикладным и системным администраторам.

👉 Зарегистрируйтесь: https://vk.cc/d34ypU

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

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Тридцатилетний ты задремал на работе. Коллеги зумеры:

⚠️ Если компания предлагает вам «разойтись по-хорошему» — не торопитесь подписывать документы.

Созвон на 15 минут без повестки, «ну что, определился?» от HR, допсоглашение до пятницы — так обычно начинаются сокращения в IT.

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

Команда «5оффер» уже несколько лет помогает IT-специалистам любых грейдов и направлений:
▪️ добиваться выгодных условий при увольнении;
▪️ сохранять работу;
▪️ решать другие трудовые вопросы.

Наши юристы специализируются на трудовом праве и знают специфику IT.

✍️ Сохрани контакт «5оффер», чтобы он был под рукой в сложной ситуации.

Телеграм-канал

🎁 По промокоду 3KONS первичная консультация — 5000 3 000 ₽.

Записаться на консультацию — @Fiveoffer_bot

Реклама. ИП Кузнецова Ирина Сергеевна. ИНН:745111070021. erid: 2W5zFJ5tGzd

📌 ТОП инструментов и подходов для тестирования авторизации и токенов

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

Собрали инструменты и практики, которые помогают QA эффективно тестировать auth-флоу:

▫️ Postman
— Проверка login/logout
— Работа с JWT, access / refresh tokens
— Подмена токенов, проверка сроков жизни
— Удобно для ручных и автотестов
🔗 https://www.postman.com

▫️ JWT.io
— Декодирование и анализ JWT
— Проверка payload, exp, iss, aud
— Удобно для быстрой ручной валидации токенов
🔗 https://jwt.io

▫️ Chrome DevTools (Application / Network)
— Просмотр cookies, localStorage, sessionStorage
— Анализ Authorization headers
— Проверка обновления токенов и ошибок 401/403
🔗 https://developer.chrome.com/docs/devtools

▫️ HTTPBin / Webhook.site
— Проверка передачи headers
— Эксперименты с токенами и cookies
— Отладка auth-запросов
🔗 https://httpbin.org
🔗 https://webhook.site

▫️ Burp Suite (Community Edition)
— Перехват и модификация auth-запросов
— Проверка уязвимостей сессий
— Повторные запросы с разными токенами
🔗 https://portswigger.net/burp/communitydownload

▫️ OWASP Juice Shop
— Практика тестирования авторизации и сессий
— Реальные уязвимости: broken auth, IDOR, token reuse
— Отлично подходит для обучения
🔗 https://owasp.org/www-project-juice-shop

▫️ Checklist для QA (что проверять)
— Истечение срока действия токена
— Обновление refresh-token
— Доступ по ролям
— Поведение при logout
— Повторное использование старого токена
— Работа в нескольких вкладках

Эти инструменты и проверки помогают находить критичные баги ещё до продакшена и повышать уровень безопасности продукта.

✉️ ТОП бесплатных инструментов для тестирования email-рассылок

Тестирование email-рассылок может включать проверку SMTP, верстки, заголовков, доставки.
Подготовили подборку бесплатных инструментов, которые будут полезны QA.

▫️Mailtrap (Free Sandbox)
Перехватывает тестовые письма в изолированную среду, позволяет проверять HTML, заголовки, вложения и работать через API.
🔗 https://mailtrap.io/email-sandbox/

▫️MailHog
Open-source локальный SMTP-сервер, который собирает все исходящие письма и позволяет просматривать их через веб-интерфейс.
🔗 https://github.com/mailhog/MailHog

▫️Swaks
CLI-инструмент для тестирования SMTP: авторизация, TLS, кастомные заголовки, тестовые письма.
🔗 https://github.com/jetmore/swaks

▫️Mail-in-a-Box
Open-source локальный почтовый сервер для локального. Позволяет тестировать реальные SMTP/IMAP-флоу.
🔗 https://mailinabox.email

▫️Mailcare
Бесплатный sandbox-SMTP: перехватывает тестовые письма, показывает HTML/текст, анализирует заголовки и spam-score. Есть свой API.
🔗 https://mailcare.io

Почему именно эти инструменты?
— безопасное тестирование рассылок без риска отправить письма реальным пользователям
— автоматизация через API — можно покрывать email-флоу тестами
— проверка SMTP-конфигураций, аутентификации, работы с вложениями
— собственная локальная инфраструктура для тестов — нет зависимости от внешних сервисов
— интеграция с CI/CD, чтобы «email-тесты» стали частью автоматизации

Какое неожиданное наблюдение. Всем хороших выходных!