📚 ProTestingInfo 🔷 Канал по тестированию 📚 – Telegram
📚 ProTestingInfo 🔷 Канал по тестированию 📚
14.1K subscribers
1.31K photos
200 videos
232 files
1.18K links
📌Информация для начинающих и для коллег в области QA, для личного закрепления знаний.
📌Теория, тесты, практика
Ментор-Консультация - 5тр/час
Курс
@info_course_protestinginfo
https://protestinginfo.ru
Вопросы @nadin_qa
ИП
РКН: https://clck.ru/3FWD9v
Download Telegram
Пост в нельзяграме - присоединяйтесь и делитесь с коллегами.
ЧАСТЫЙ вопрос на собесе: рассказать структуру HTTP запроса. Давайте повторим.

HTTP - это протокол прикладного уровня передачи данных, по которому браузер (или другой клиент) отправляет запрос на сервер, а сервер в ответ возвращает данные. Каждый HTTP-запрос и HTTP-ответ имеют чёткую структуру, и знание этой структуры - важный навык для любого QA-инженера.
🔹 Как устроен HTTP-запрос
Запрос состоит из трёх ключевых частей:
- Request Line - первая строка запроса: метод (например, GET или POST), путь (URI), версия протокола. Например:
GET /index.html HTTP/1.1
- Headers (заголовки) - набор метаданных: тип контента, авторизация, язык, формат и другие. Заголовки пишутся в формате Имя: значение.
- Body (тело запроса) - необязательная часть, содержит данные, которые отправляет клиент (например, при POST-запросе).
Например, когда вы делаете GET тело обычно пустое. При POST тело может содержать JSON, form-data и т.п.

Как выглядит HTTP-ответ от сервера
После того как сервер получает запрос, он возвращает HTTP-ответ, тоже с несколькими частями.
- Status Line (строка состояния) - первая строка ответа. Содержит версию протокола, статус-код и фразу-описание. Например:
HTTP/1.1 200 OK
- Код 200 OK означает, что всё прошло успешно.
Response Headers (заголовки ответа) - метаданные, которые описывают свойства ответа: тип и длину контента, информацию о сервере, дату, кодировку и т.д.
- Body (тело ответа) - сама информация, которую запрашивал клиент: HTML-страница, JSON-данные, файл и т.п. Иногда тело может отсутствовать (например, при коде 204 No Content).

Еще в структурах есть пустые строки.

Необходимо:
Чтобы анализировать запросы и ответы: видеть, какой метод, какие заголовки, что отправляется и что приходит.
Чтобы находить ошибки: неправильный заголовок, отсутствующий Content-Type, пустой body, неожиданный статус-код.
Чтобы документировать и заводить дефекты с точной информацией о том, как выглядел запрос и ответ.
Чтобы работать с API, HTTP-логами, инструментами (Postman, Charles, Fiddler).

Сохраняйте информацию для подготовки на собеседование, и делись с коллегами кто изучает тестирование ПО или готовится к собеседованию.
Присоединяйтесь к @protestinginfo
500👍14💘5❤‍🔥1🆒11
Успешный DELETE-запрос возвращает статус 200 (OK) или 204 (No Content), но для последующих запросов будет возвращать какой http status code?
Anonymous Quiz
5%
410
72%
404
7%
403
16%
400
5142👍2👌1
Какой HTTP метод является неидемпотентным?
Anonymous Quiz
15%
PUT
50%
POST
17%
DELETE
18%
GET
51👍6🎄3🆒1
Безопасными HTTP методами являются
Anonymous Quiz
15%
GET, PUT, HEAD
53%
GET, HEAD
19%
PUT, POST, GET
13%
GET, POST
51👨‍💻71👌1
Имеется стек протоколов(стандартов) , который определяет как различные устройства будут обмениваться данными (сетевая модель OSI). Так вот мы обсуждаем тему HTTP/HTTPS. К какому уровню модели OSI относится HTTP/HTTPS протокол?
Anonymous Quiz
3%
Сеансовый
32%
Транспортный
23%
Сетевой
34%
Прикладной
1%
Физический
5%
Уровень представления
2%
Канальный
514💯2🦄1
🎆Сегодня День Рождения телеграмм каналу @protestinginfo!
5️⃣😚☺️😝!

2 декабря был день рождения аккаунту protestinginfo в нельзяграме!
Также присоединяйтесь. 💻

Ровно 5 лет назад я укладывала старшего сына спать (ему было 2 месяца) и думала о работе, скучала. И сейчас скучаю, хотя скоро выхожу на частичную занятость в декрете 🔥

Так вот, я думала, что начинаю забывать основы тестирования, плюс, казалось, что дни становятся однообразными, и я загорелась желанием завести блог по тестированию.
Я начала придумывать, а как же назвать мой аккаунт, первое, что пришло в голову «ND_testing» (ND - Nadezhda Dudnik), потом начала смотреть какие ещё каналы по тестированию есть, и их оказалось много, и, по наблюдению, я придумала «ProTestingInfo»😉.
Затем я начала думать, как же нарисовать мой первый логотип.

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

Я горела желанием собирать любую информацию, помогать себе и другим людям.
Мне нравится придумывать тесты, проводить вебинары, а сейчас есть не только курс по подготовке к собеседованиям и мини-программы, а курсы по тестированию бэкенда, тестированию gRPC API, GraphQL API, и хочется отдельно выразить благодарность Валерию Меньшикову за наше партнерство.
Занимаюсь менторской деятельностью, и более 40 менти получили оффер за 2025г, и до сих пор направляю людей, пока есть возможность.

🩷Хочу выразить благодарность коллегам-блогерам, которые рекомендуют мой блог, мне очень приятно и также ценю.
💚Также я хочу выразить огромную благодарность всем вам, что подписались на мой канал, я это очень ценю!🤗💜

❤️Хочу поблагодарить за то, что вы со мной. Спасибо, что читаете, поддерживаете, крепко всех обнимаю.🥰

Я также буду продолжать заниматься созданием тестов, написанием полезных постов и статей!
Делиться полезной информацией!😎

Спасибо за ваши отзывы.
Люблю свое дело🫶.

Желаю всем вам развития!❄️

Благодарю за ваши реакции, комментарии и обратную связь. Ценю.

А кто недавно на моем канале, предлагаю прочитать пост про знакомство.
Будем дальше закреплять наши знания ⚡️!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1.04K❤‍🔥33🎉31🍾5🦄4🔥21
Разбираем вопрос на собеседование: «какие уровни логирования вы знаете»
Пост в нельзяграме - присоединяйтесь 🫶🏼

Логи (лог-файлы) - это файлы, содержащие системную информацию работы сервера или компьютера, в которые заносятся определенные действия пользователя или программы, всевозможные интеграции (определение с инета)

Имеется ряд уровней логирования, начну по порядку сверху вниз (хочу отметить, что я привела в пример всех встречающихся мне уровней логирования, и эти уровни логирования могут отличаться в рамках требований по фиче)

ALL фиксируются события с уровнями: TRACE, DEBUG, INFO, WARN(ING), ERROR, CRITICAL(FATAL), OFF - происходит логирование всех событий, описание которых укажу по порядку:
⚙️TRACE - пошаговые записи процесса, полезен при локализации ошибки;
⚙️DEBUG - детальное логирование системной информации для последующего использования в отладке, запросы и ответы к внешним системам, успешная обработка записи и др.;
⚙️INFO - информация о событиях, не приводящих к ошибкам в работе модулей, общая информация о работе службы или сервиса, события переходов/запросов с минимальным набором входящих параметров;
⚙️WARN(ING) - информация о событиях, которые могут привести к ошибкам в работе модулей, получение пустого запроса от фронта, данные не найдены в справочнике, некорректный параметр запроса;
⚙️ERROR - информация об ошибках, возникших в работе модулей, интеграционные взаимодействия, при которых внешняя система вернула код ошибки;
⚙️CRITICAL - информация о критических ошибках, возникших в работе модулей;
⚙️FATAL - сбой работоспособности приложения, нет доступа к базе данных и т.д;
OFF - логирование выключено

У меня на работе есть системный журнал UI, где для каждой подсистемы есть следующие уровни логирования:
⛓️Все
⛓️TRACE
⛓️DEBUG
⛓️INFO
⛓️WARN
⛓️ERROR

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

@protestingingo

Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка на все тарифы в рамках курса. (здесь и тесты, и вебинары, и практика)
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
384🔥167👍2
Media is too big
VIEW IN TELEGRAM
Разработчик может сделать всё: создать, обновить, получить или удалить ресурс через один и тот же HTTP-метод, и оно будет работать. Просто потому что можно реализовать как угодно. Но это не значит, что так правильно 🧐

Например, метод, считающийся “безопасным”, может внезапно менять данные, а “идемпотентный” - перестаёт быть им. Поэтому на собеседованиях часто проверяют: понимает ли QA, как ВСЁ ДОЛЖНО быть по стандарту, а не «как сделано в конкретном проекте».

Разберём базовые, но частые вопросы 👇

Что делают PUT, POST и PATCH?


🔹 POST - Create
Создаёт новую сущность. Может также создавать коллекцию сущностей. Каждый вызов POST - это новая запись.

🔹 PUT - Full update
Предназначен для полного обновления ресурса или его создания, если он не существует.
💡 По стандарту PUT должен заменять всё представление ресурса, то есть если вы отправили только одно поле, остальные считаются удалёнными.

Но! На практике backend-разработчики часто реализуют PUT как частичное обновление, чтобы не приходилось передавать все поля. Например, если вы отправляете только projectName: "QA", сервер обновляет только это поле, а остальное остаётся без изменений.

Такое поведение удобно, но не соответствует канону. Это особенность реализации конкретного API, а не стандарт HTTP.

🔹 PATCH - Partial update
Этот метод специально создан для частичного обновления ресурса. Поэтому, если вам нужно изменить только часть данных, корректнее использовать PATCH.

⚙️ Из источника (MDN):
> PUT создаёт или заменяет представление ресурса данными, переданными в теле запроса.

🧠 На собеседованиях полезно упомянуть:
- PUT - по стандарту полная замена существующего ресурса или создание нового ресурса.
- PATCH - частичное обновление.
- Но в реальной жизни всё зависит от реализации со стороны разработки.

А у вас как реализовано на проекте?
PUT как полное обновление или частичное? Делитесь в комментариях 👇

Сохраните этот пост и отметьте коллегу!
Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка на все тарифы в рамках курса. (здесь и тесты, и вебинары, и практика)
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
52🔥11👍83
На собеседованиях все слышали вопрос: чем отличается верификация от валидации, но в реальной работе граница часто размывается. Разберёмся на простом примере с трубой.

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

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

Пример с трубой
Представь заказ на трубу. Верификация пройдена: труба диаметром 50 мм произведена по стандарту, полностью по чертежам и документации.
Но валидация провалена: для конкретной задачи заказчику нужна труба 100 мм, и текущий продукт не закрывает его реальную потребность.
Как это формулировать на интервью
• Верификация отвечает на вопрос: «Сделали ли мы продукт так, как было описано в требованиях?».
• Валидация отвечает на вопрос: «Подходит ли такой продукт пользователю и можно ли его реально использовать в его контексте?»

Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка на все тарифы в рамках курса. (здесь и тесты, и вебинары, и практика)
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
923❤‍🔥23👍6💘2
Разбор вопроса
Чем REST отличается от SOAP: как отвечать на собеседовании (см на 1,5х)😘
https://kinescope.io/no8bNw138jW6yAxLkGxRMa

Давайте разберем один из основных вопросов на собеседованиях: «Чем REST отличается от SOAP?». Мы рассмотрим, как лучше отвечать на этот вопрос кандидатам с разным уровнем подготовки: тем, у кого уже есть коммерческий опыт, и тем, у кого его нет (например, вы были в декрете, был долгий перерыв в карьере или вы только решили войти в сферу тестирования).
Этот вопрос могут задать любому кандидату, поэтому важно быть к нему готовым.
Ответ для кандидата без коммерческого опыта
Если у вас нет коммерческого опыта, лучше начать с теоретических основ. Главное, что нужно донести — это фундаментальное различие:
SOAP — это протокол.
REST — это архитектурный стиль.
После этого можно углубиться в детали, сравнив их по ключевым параметрам.
SOAP (Simple Object Access Protocol)
Это протокол обмена структурированными сообщениями, который используется для реализации веб-сервисов. Он считается несколько устаревающим, но все еще широко применяется в унаследованных системах, особенно в финтехе, государственных учреждениях и для обработки транзакций. Например, его частично использует PayPal.
Формат сообщений: Строго XML. Сообщения имеют четкую структуру.
Протоколы передачи: SOAP может использовать не только HTTP, но и другие протоколы, такие как SMTP (для почты) и FTP (для файлов).
HTTP-методы: При использовании HTTP, как правило, все операции отправляются через метод POST.
Описание сервиса: Для описания веб-сервисов и методов доступа к ним используется язык WSDL (Web Services Denoscription Language), который также основан на XML.
Преимущества: Встроенные стандарты безопасности (WS-Security), поддержка сложных транзакций, стандартизация, что хорошо подходит для B2B-взаимодействий.

REST (Representational State Transfer)

Это архитектурный стиль, который широко используется для создания масштабируемых и простых в использовании веб-сервисов. Большинство современных API, с которыми вы столкнетесь (например, у Ozon, Wildberries, NASA), построены по принципам REST.
Формат сообщений: Гибкий. Чаще всего используется JSON, но также поддерживаются XML, HTML, обычный текст и другие форматы. Все они хорошо отображаются в инструментах вроде Postman.
Протокол передачи: Работает исключительно поверх протокола HTTP.
HTTP-методы:
GET — для получения данных.
POST — для создания данных.
PUT / PATCH — для обновления данных.
DELETE — для удаления данных.

Описание сервиса: Для описания REST API чаще всего используется спецификация OpenAPI (ранее известная как Swagger).
Ответ для кандидата с коммерческим опытом
Если у вас есть коммерческий опыт, не начинайте с сухих определений. Начните с вашего опыта - это ценится гораздо выше.
Например, можно сказать так:
«Начинал(а) я свою работу с API именно с SOAP. На проекте [название компании, например, DHL] мы тестировали взаимодействие между двумя сервисами, которое было реализовано через SOAP API. Однако основной объем моего опыта за последние годы связан с REST API. На текущем и прошлых проектах я углубленно тестировал(а) REST-сервисы, работая с различными HTTP-методами, форматами данных и авторизацией».

Если у вас есть коммерческий опыт в тестировании, но вы не работали с API, можно сказать иначе:
«Хотя на прошлых проектах я в основном занимался(ась) тестированием фронтенда, я самостоятельно изучал(а) бэкенд и прошел(ла) практический курс по тестированию API. Меня очень заинтересовала эта тема, и я хочу развиваться именно в этом направлении. Я хорошо разобрался(разобралась) в принципах REST, работе с Postman и готов(а) применить эти знания на практике».

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

Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
752👍107🔥3🆒3
🔥 HTTP МЕТОДЫ ДЛЯ СОБЕСЕДОВАНИЯ НА QA!

Пост в нельзяграме - присоединяйся, сохраняй и поделись (очень важно для продвижения)🫶


GET • POST • PUT • DELETE
+ ТОЧНЫЕ свойства каждого!
1️⃣ GET — Получение данных
Безопасный ✓
Кэшируется ✓
Идемпотентный ✓
"GET /users" → 200 OK

2️⃣ POST — Создание ресурса
Меняет данные ✗
⚠️ Кэшируется с Cache-Control ✗
Не идемпотентный ✗
"POST /users" → 201 Created

3️⃣ PUT — Полное обновление
Меняет данные ✗
⚠️ Кэшируется с Cache-Control ✗
Идемпотентный ✓
"PUT /users/123" → 200 OK

4️⃣ DELETE — Удаление
Меняет данные ✗
Не кэшируется ✗
Идемпотентный ✓
"DELETE /users/123" → 204

💡 КЛЮЧЕВОЙ НЮАНС:
POST/PUT кэшируются ТОЛЬКО при заголовках:
Cache-Control: max-age=3600
или Expires
(по умолчанию НЕ кэшируются!)

👉 Сохрани пост
👉 Перешли junior-QA
👉 Пиши в комменты: какой метод сложнее?

Готовимся к собеседованию вместе!
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка

По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
500👍24💘421🥱1