20 ВОПРОСОВ ПО PYTHON AUTOMATION С СОБЕСЕДОВАНИЯ 👇

Пост в нельзяграме:
https://www.instagram.com/p/DcF8yKaDDiO/?igsh=MTJuZmswZnpsY2xqYw==&igsi=MTJuZmswZnpsY2xqYw==

Это реальные вопросы, которые задают на собеседованиях в 2026 году. Разбиты по блокам для удобной подготовки.

🐍 PYTHON CORE (1-5)
1. Чем отличается @ staticmethod от @ classmethod?
2. Какие изменяемые/неизменяемые типы данных?
3. Что такое декораторы и как их применять?
4. Как работает контекстный менеджер (with)?
5. Напишите функцию: разворот строки + поиск дубликатов

🧪 PYTEST & ТЕСТИРОВАНИЕ (6-10)
6. Какие фреймворки для автотестов на Python?
7. PyTest vs Unittest: как бы выбрали?
8. Что такое фикстуры в PyTest?
9. Как использовать фикстуры для setup/teardown?
10. Как организовать работу с отчетами?

SELENIUM & WEB AUTOMATION (11-15)
11. Как работать с Selenium WebDriver?
12. Какие локаторы (CSS, XPath) и когда использовать?
13. Как проверить отображение элемента?
14. Какие виды ожиданий (waits) в Selenium?
15. Кнопка появляется с задержкой. Как решить?

🚀 CI/CD & DEVOPS (16-20)
16. Что такое CI/CD и зачем это QA?
17. Что входит в pipeline автотестов?
18. Git: разница между pull, push и fetch?
19. Как работать с Docker в тестировании?
20. Какие метрики CI/CD важны для QA?

💻 ПРАКТИЧЕСКИЕ ЗАДАЧИ НА ЛАЙВКОДИНГ:
• Перевернуть строку задом наперед
• Найти дубликаты в списке

💡 СОВЕТ: На собеседовании важно не только решить задачу, но и объяснить ход мыслей вслух!

Подпишись на https://t.me/protestinginfo , здесь разбираю вопросы по подготовке к собеседованиям и тесты по подготовке к собеседованию, чтобы ты чувствовал(а) себя уверенно на любом собеседовании!

https://stepik.org/a/276076/pay?promo=baaaaf96a70cf20e

Какой вопрос из списка кажется тебе самым сложным? Пиши в комментариях!

#AutomationQA #Python #Pytest #тестирование #QA

Монолит vs Микросервисы: в чем разница для QA? 👇
Архитектура
Монолит
• UI, бизнес-логика и БД — единое приложение
• Общая база данных
• Компоненты тесно связаны
Микросервисы
• Каждый сервис отвечает за свою бизнес-функцию
• У каждого сервиса может быть собственная БД
• Взаимодействие через API и очереди сообщений
Что тестировать?
Монолит
✅ Функциональность приложения
✅ Бизнес-логику
✅ Интеграцию модулей
✅ Работу с общей БД
Микросервисы
✅ API между сервисами
✅ Contract testing
✅ Kafka / RabbitMQ
✅ Консистентность данных
✅ Логи, tracing и мониторинг
✅ Отказоустойчивость сервисов
Надёжность
Монолит
❌ Ошибка может повлиять на всё приложение
❌ Единая точка отказа
Микросервисы
✅ Сбой чаще локализован
✅ Остальные сервисы продолжают работать
✅ Проще масштабировать отдельные компоненты
🔄 переход из монолита в микросервисы
Для QA появляются дополнительные проверки:
• регрессия после выделения сервиса;
• совместная работа монолита и новых сервисов;
• API и контрактов между сервисами;
• очередей сообщений;
• логов, мониторинга;
• отказоустойчивости и восстановления после сбоев.
Важно
В микросервисной архитектуре нет догмы, что у каждого сервиса должна быть отдельная физическая база данных. Рекомендуемый паттерн Database per Service, где каждый сервис владеет своими данными, но это может быть отдельная схема, отдельная БД или даже выделенные таблицы. Общая база тоже встречается, особенно при миграции с монолита, но это компромисс, который усиливает связанность сервисов. Главное, не количество баз, а независимость владения данными и границами сервиса.
Многие крупные продукты годами успешно работают на монолитной архитектуре. Переход к микросервисам обычно имеет смысл тогда, когда появляются независимые команды, отдельные релизы, требования к масштабированию и высокая нагрузка.
Из моего опыта
Монолит мне довелось тестировать один раз.
А вот с микросервисами работаю регулярно, и самая интересная часть для меня - интеграционное тестирование, поиск проблем во взаимодействии сервисов, анализ логов и проверка очередей.

Что вы тестируете монолит или микросервисы?

Ставь просто ❤️, если полезно 🔥

#QA #ТестированиеПО #qaengineer#тестирование #собеседование

REST (Representational State Transfer) - это архитектурный стиль для построения распределённых систем
REST API - архитектурный стиль проектирования программных интерфейсов
RESTful API - это термин, который использует строгое следование принципам REST

1️ Клиент-Сервер (Client-Server)
Полное разделение интересов.
Клиент → UI/UX
🖥️ Сервер → Данные и логика
Зачем: Независимое развитие и масштабирование.

2️⃣ Отсутствие состояния (Stateless)
Сервер не помнит предыдущие запросы. Каждый запрос самодостаточен.
Зачем: Надежность, простота балансировки нагрузки.
⚠️ Токены передаются в каждом запросе!

3️⃣ Кэшируемость (Cacheability)
Ответы должны явно маркироваться (Cache-Control, ETag).
Зачем: Снижение нагрузки, ускорение работы.
💡 Для QA: Проверяй заголовки кэша в Network / Application!

4️⃣ Единообразие интерфейса (Uniform Interface)
Единый стандарт взаимодействия:
• Идентификация ресурсов (URI)
• Манипуляция через представления (JSON)
• Самодостаточные сообщения
• Стандартные методы (GET, POST, PUT, DELETE)
• HATEOAS (ссылки в ответе)

5️⃣ Многоуровневая система (Layered System)
Архитектура из слоев (прокси, балансировщики, серверы). Клиент видит только шлюз.
Зачем: Безопасность, гибкость инфраструктуры.

6️⃣ Код по требованию (Code on Demand)
Сервер может передать исполняемый код (JS).
⚠️ Опционально и используется редко из-за рисков безопасности.

Какой принцип самый сложный для понимания или легко запоминающийся? Пиши в комментариях 👇

Ставь ❤️, если полезно!

А завтра планирую снова тесты провести, 🔥 для завтрашнего дня