📚 ProTestingInfo 🔷 Канал по тестированию 📚
Знаешь теорию тестирования, но на собесе теряешься и не можешь ответить даже на простой вопрос про регресс? Это не про незнание. Это про неумение формулировать ответы так, как ожидают интервьюеры. ❌ Почему чаще всего отказывают: - Путаница в терминологии…
Добрый вечер!
Присоединяйтесь, чтобы закрепить свои знания!
Через месяц проведу бесплатный вебинар для всех желающих, чтобы вы могли принять решение и выбрать любой из моих курсов.
Планирую разобрать ситуационные вопросы на собеседование в финтех и практические тестовые задания, приблизительно 11 января 2026г.
Если сомневаешься, какая программа подойдет – напиши «СОБЕС» @nadin_qa, помогу выбрать
Главная страница школы: https://coreapp.ai/app/showcase/638525fe5eadbe980aa42026
Присоединяйтесь, чтобы закрепить свои знания!
Через месяц проведу бесплатный вебинар для всех желающих, чтобы вы могли принять решение и выбрать любой из моих курсов.
Планирую разобрать ситуационные вопросы на собеседование в финтех и практические тестовые задания, приблизительно 11 января 2026г.
Если сомневаешься, какая программа подойдет – напиши «СОБЕС» @nadin_qa, помогу выбрать
Главная страница школы: https://coreapp.ai/app/showcase/638525fe5eadbe980aa42026
🔥8👌1🆒1
Пост в нельзяграме - присоединяйтесь и делитесь с коллегами.
ЧАСТЫЙ вопрос на собесе: рассказать структуру 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
ЧАСТЫЙ вопрос на собесе: рассказать структуру 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🆒1
Успешный DELETE-запрос возвращает статус 200 (OK) или 204 (No Content), но для последующих запросов будет возвращать какой http status code?
Anonymous Quiz
5%
410
72%
404
7%
403
16%
400
51❤4✍2👍2👌1
51👍6🎄3🆒1
Безопасными HTTP методами являются
Anonymous Quiz
15%
GET, PUT, HEAD
53%
GET, HEAD
19%
PUT, POST, GET
13%
GET, POST
51👨💻7☃1👌1
Имеется стек протоколов(стандартов) , который определяет как различные устройства будут обмениваться данными (сетевая модель OSI). Так вот мы обсуждаем тему HTTP/HTTPS. К какому уровню модели OSI относится HTTP/HTTPS протокол?
Anonymous Quiz
3%
Сеансовый
32%
Транспортный
23%
Сетевой
34%
Прикладной
1%
Физический
5%
Уровень представления
2%
Канальный
51
Что означает HTTP?😁
Anonymous Quiz
6%
HyperText Transmission Protocol
43%
HyperText Transport Protocol
49%
HyperText Transfer Protocol
1%
HyperText Tunnel Protocol
51😁7🆒1😎1
Статистика: Сколько верно ответили?
Anonymous Poll
3%
0
7%
1
18%
2
28%
3
25%
4
8%
5
3%
Позже отвечу, пока учусь
7%
Воздержусь, посмотрю ответы
51👨💻3💘2
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🔥2
Разбираем вопрос на собеседование: «какие уровни логирования вы знаете»
Пост в нельзяграме - присоединяйтесь 🫶🏼
Логи (лог-файлы) - это файлы, содержащие системную информацию работы сервера или компьютера, в которые заносятся определенные действия пользователя или программы, всевозможные интеграции (определение с инета)
Имеется ряд уровней логирования, начну по порядку сверху вниз (хочу отметить, что я привела в пример всех встречающихся мне уровней логирования, и эти уровни логирования могут отличаться в рамках требований по фиче)
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
Пост в нельзяграме - присоединяйтесь 🫶🏼
Логи (лог-файлы) - это файлы, содержащие системную информацию работы сервера или компьютера, в которые заносятся определенные действия пользователя или программы, всевозможные интеграции (определение с инета)
Имеется ряд уровней логирования, начну по порядку сверху вниз (хочу отметить, что я привела в пример всех встречающихся мне уровней логирования, и эти уровни логирования могут отличаться в рамках требований по фиче)
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🔥16❤7👍2
Media is too big
VIEW IN TELEGRAM
Разработчик может сделать всё: создать, обновить, получить или удалить ресурс через один и тот же HTTP-метод, и оно будет работать. Просто потому что можно реализовать как угодно. Но это не значит, что так правильно 🧐
Например, метод, считающийся “безопасным”, может внезапно менять данные, а “идемпотентный” - перестаёт быть им. Поэтому на собеседованиях часто проверяют: понимает ли QA, как ВСЁ ДОЛЖНО быть по стандарту, а не «как сделано в конкретном проекте».
Разберём базовые, но частые вопросы 👇
Что делают PUT, POST и PATCH?
🔹 POST - Create
Создаёт новую сущность. Может также создавать коллекцию сущностей. Каждый вызов POST - это новая запись.
🔹 PUT - Full update
Предназначен для полного обновления ресурса или его создания, если он не существует.
💡 По стандарту PUT должен заменять всё представление ресурса, то есть если вы отправили только одно поле, остальные считаются удалёнными.
Но! На практике backend-разработчики часто реализуют PUT как частичное обновление, чтобы не приходилось передавать все поля. Например, если вы отправляете только
Такое поведение удобно, но не соответствует канону. Это особенность реализации конкретного API, а не стандарт HTTP.
🔹 PATCH - Partial update
Этот метод специально создан для частичного обновления ресурса. Поэтому, если вам нужно изменить только часть данных, корректнее использовать PATCH.
⚙️ Из источника (MDN):
> PUT создаёт или заменяет представление ресурса данными, переданными в теле запроса.
🧠 На собеседованиях полезно упомянуть:
- PUT - по стандарту полная замена существующего ресурса или создание нового ресурса.
- PATCH - частичное обновление.
- Но в реальной жизни всё зависит от реализации со стороны разработки.
А у вас как реализовано на проекте?
PUT как полное обновление или частичное? Делитесь в комментариях 👇
Сохраните этот пост и отметьте коллегу!
Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка на все тарифы в рамках курса. (здесь и тесты, и вебинары, и практика)
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
Например, метод, считающийся “безопасным”, может внезапно менять данные, а “идемпотентный” - перестаёт быть им. Поэтому на собеседованиях часто проверяют: понимает ли 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👍8✍3
На собеседованиях все слышали вопрос: чем отличается верификация от валидации, но в реальной работе граница часто размывается. Разберёмся на простом примере с трубой.
Что такое верификация
Когда говорим о верификации, смотрим, насколько аккуратно продукт реализует формальные требования и спецификации. Команда читает документы, проверяет макеты и код: все ли пункты ТЗ учтены, нет ли расхождений в названиях и бизнес‑правилах.
Задача верификации – отловить несоответствия требованиям как можно раньше, пока правки не стоят дорого.
Что такое валидация
Валидация отвечает уже на другой вопрос: решает ли продукт реальные задачи пользователя и бизнеса. Здесь систему запускают, кликают по кнопкам, прогоняют сценарии, проверяют поведение и нефункциональные характеристики.
На этом этапе всплывают вещи, которые формально «по ТЗ верные», но в живом использовании оказываются бесполезными или неудобными.
Пример с трубой
Представь заказ на трубу. Верификация пройдена: труба диаметром 50 мм произведена по стандарту, полностью по чертежам и документации.
Но валидация провалена: для конкретной задачи заказчику нужна труба 100 мм, и текущий продукт не закрывает его реальную потребность.
Как это формулировать на интервью
• Верификация отвечает на вопрос: «Сделали ли мы продукт так, как было описано в требованиях?».
• Валидация отвечает на вопрос: «Подходит ли такой продукт пользователю и можно ли его реально использовать в его контексте?»
Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка на все тарифы в рамках курса. (здесь и тесты, и вебинары, и практика)
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
Что такое верификация
Когда говорим о верификации, смотрим, насколько аккуратно продукт реализует формальные требования и спецификации. Команда читает документы, проверяет макеты и код: все ли пункты ТЗ учтены, нет ли расхождений в названиях и бизнес‑правилах.
Задача верификации – отловить несоответствия требованиям как можно раньше, пока правки не стоят дорого.
Что такое валидация
Валидация отвечает уже на другой вопрос: решает ли продукт реальные задачи пользователя и бизнеса. Здесь систему запускают, кликают по кнопкам, прогоняют сценарии, проверяют поведение и нефункциональные характеристики.
На этом этапе всплывают вещи, которые формально «по ТЗ верные», но в живом использовании оказываются бесполезными или неудобными.
Пример с трубой
Представь заказ на трубу. Верификация пройдена: труба диаметром 50 мм произведена по стандарту, полностью по чертежам и документации.
Но валидация провалена: для конкретной задачи заказчику нужна труба 100 мм, и текущий продукт не закрывает его реальную потребность.
Как это формулировать на интервью
• Верификация отвечает на вопрос: «Сделали ли мы продукт так, как было описано в требованиях?».
• Валидация отвечает на вопрос: «Подходит ли такой продукт пользователю и можно ли его реально использовать в его контексте?»
Больше полезных разборов у @protestinginfo на:
Онлайн‑курсе по подготовке к собеседованиям и тестам по тестированию ПО 180 дней PROMO20 - 20% скидка на все тарифы в рамках курса. (здесь и тесты, и вебинары, и практика)
По-отдельности программы:
🎓 Онлайн-вебинары по вопросам с собеседований
🧪 API, интеграции, SQL
💻 Практика REST API + SQL
923❤🔥23👍6💘2