📚 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
🎆Сегодня День Рождения телеграмм каналу @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
This media is not supported in your browser
VIEW IN TELEGRAM
Как подготовиться к техническому интервью по тестированию?
Reels в нельзяграме - присоединяйтесь и делитесь с коллегами
В основном, вопросы для Middle QA, но также будет полезно всем QA
Начни с этих 20 вопросов - это база, которую интервьюеры спрашивают снова и снова.

Разбирай по одному вопросу в день: гугли, AI, выписывай ответы, проговаривай вслух.
Сохрани пост, чтобы не потерять 🔖

Топ‑20 вопросов из моего списка:

1. Что такое RESTful API и в чем его особенности?
2. Какие техники тест-дизайна вы знаете?
3. Что такое Kafka? Как она работает и какие проверки можно выполнять при тестировании?
4. Какие существуют типы авторизации?
5. Что такое JWT-токен и для чего он используется?
6. В чем разница между аутентификацией и авторизацией?
7. Какие коды ответа HTTP вы знаете и как они применяются?
8. Какие бывают HTTP-заголовки и для чего они используются?
9. Из каких частей состоит HTTP-запрос?
10. Какие существуют уровни логирования? Как определить, на каком сервисе произошла ошибка?
11. Как протестировать POST-запрос?
12. Какие проверки выполняются на фронтенде?
13. Какие виды баз данных вы знаете?
14. Как понять, что функционал полностью протестирован?
15. Какие SQL-запросы вы писали на практике?
16. Как работает запрос с JOIN? Приведите пример.
17. Какие методы HTTP вы знаете и в чем их различия?
18. Что такое идемпотентность и для каких методов она характерна?
19. Какие вкладки есть в DevTools и для чего они используются?
20. Что такое CI/CD и для чего оно используется?


👉 Делись этим постом с теми, кто тоже готовится к собесу.
А если хочешь знать ответы, то присоединяйся к моим вебинарам на курсе
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка

Вместе готовиться проще, чем в одиночку.

Небольшой анонс: заранее 8 и 22 января 2026г. планирую провести вебинары в рамках блога🐱 а какие темы, следите - скоро напишу.
@protestinginfo
Please open Telegram to view this post
VIEW IN TELEGRAM
600👍14🔥722💯2
Присоединяйся к курсу - подготовимся к офферу!
Хочешь не просто «подготовиться», а выйти на собеседования так, чтобы звучать уверенно на свой уровень и чаще доходить до оффера?
Онлайн‑курс по подготовке к собеседованиям и закреплению навыков QA (не с нуля).
Подходит, если ты:
• уже прошёл(ла) курсы и хочешь систематизировать знания + научиться проходить интервью (Junior),
• работаешь QA и хочешь перейти на следующий уровень (Middle),
• готовишься к смене компании/повышению и хочешь “докрутить” интервью и уверенность (Senior),
• или неожиданное сокращение!

Что будет на выходе:
• структурные ответы на интервью (без “плаваю и говорю хаотично”),
• прокачка ключевых тем под собес: API, SQL, тест‑дизайн, документация и др.,
• практика + разбор типовых ошибок,
• резюме, которое лучше “продаёт” твой опыт (по тарифу).

Что внутри курса:
• Живые вебинары 1 раз в месяц (вопросы, разборы, важные темы).
• Доступ к записям вебинаров + материалам (с обновлениями).
• Практика (по тарифу): ревью баг‑репортов, тест‑дизайн, API (REST, GraphQL, gRPC по запросу), SQL, инструменты (Postman, DBeaver, PostgreSQL).
• Проверка/рекомендации по резюме и помощь в составлении (по тарифу).
• Поддержка в чате на CoreApp: можно задавать вопросы и получать помощь по ходу обучения.
Доступ: 6 месяцев.
💙 Промокод PROMO20: скидка 20%.
📩 Для тех, кто уже учился:
Если вам нужно продлить доступ, напишите мне в Telegram @nadin_qa, указав свою почту. Я подберу для вас условия продления с учетом выполненных заданий.

👉 Узнать больше и выбрать тариф: https://protestinginfo.ru/#pricing
Отзывы: больше про офферы и подготовку
Канал оповещений по курсу: @info_course_protestinginfo
Вопросы: @nadin_qa


В рамках курса и блога 11 января 2026г состоится часовой вебинар по разбору технических вопросов.
Присоединиться к курсу можно сейчас.
50🔥7👍32