Tester | Interview Questions

🤔 Какие есть локаторы в selenium? В Selenium WebDriver локаторы используются для поиска и взаимодействия с веб-элементами на странице. Основные локаторы в Selenium: 🟠ID Использует уникальный идентификатор (id) элемента. Плюсы: Быстрый и надежный, если id уникален. Минусы: id может изменяться динамически. Пример driver.find_element(By.ID, "username 🟠Name Использует атрибут name. Плюсы: Хорош, если name уникален. Минусы: Может встречаться несколько элементов с одинаковым name. driver.find_element(By.NAME, "email") 🟠Class Name Использует значение атрибута class. Плюсы: Удобен, если класс уникален. Минусы: Встречаются элементы с одинаковым классом. driver.find_element(By.CLASS_NAME, "button-primary") 🟠Tag Name Использует имя тега (, , и т. д.). Плюсы: Можно получить список всех элементов определенного типа. Минусы: Обычно слишком общий. driver.find_elements(By.TAG_NAME, "input") 🟠Link Text Использует текст ссылки (). Плюсы: Удобно, если текст ссылки уникален. Минусы: Изменение текста ломает локатор. driver.find_element(By.LINK_TEXT, "Войти") 🟠Partial Link Text Использует часть текста ссылки. Плюсы: Работает даже при частичном совпадении. Минусы: Может найти несколько элементов. driver.find_element(By.PARTIAL_LINK_TEXT, "Подробнее") 🟠CSS Selector Позволяет находить элементы с использованием селекторов CSS. Плюсы: Гибкий и быстрый. Минусы: Сложность при написании. driver.find_element(By.CSS_SELECTOR, "div.container > input[type='text']") 🟠XPath Использует XPath для поиска элементов в DOM. Плюсы: Очень мощный, поддерживает сложные условия. Минусы: Производительность хуже, чем у CSS-селекторов. driver.find_element(By.XPATH, "//input[@name='password']") Ставь 👍 и забирай 📚 Базу знаний

🤔 Что значит Принцип скопления или кластеризация дефектов? Принцип кластеризации дефектов (Defect Clustering) — это эмпирическое правило в тестировании ПО, согласно которому большинство дефектов (80%) находятся в небольшом количестве модулей (20%). Этот принцип связан с правилом Парето (80/20): 80% багов обычно сосредоточены в 20% кода. Некоторые модули или функции содержат больше ошибок, чем другие. 🚩Почему баги "скучиваются" в одних местах? 🟠Сложный код чем сложнее код, тем больше вероятность ошибок. 🟠Частые изменения чем чаще модуль редактируется, тем выше шанс внести баги. 🟠Плохая архитектура если код написан плохо, в нем будет накапливаться больше дефектов. 🟠Отсутствие тестов модули, которые тестировались плохо или вообще не тестировались, содержат больше багов. 🚩Примеры принципа кластеризации дефектов Баги в сложных модулях Допустим, у нас есть приложение с 5 основными модулями: Часто изменяемый код → больше багов Допустим, модуль "Отчетность" за 3 месяца обновляли 10 раз, а модуль "Настройки" – только 2 раза. В "Отчетности" нашли 20 багов В "Настройках" – 3 бага 🚩Как использовать этот принцип в тестировании? 🟠Фокусироваться на "проблемных" модулях тестировать их тщательнее. 🟠Приоритизировать регрессионное тестирование в зонах, где уже находили ошибки. 🟠Анализировать историю багов если в прошлом версии баги были в определенных частях системы, они могут появиться снова. 🟠Использовать риск-ориентированное тестирование тестировать критичные и нестабильные зоны в первую очередь. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое микросервисная архитектура? Микросервисная архитектура (MSA, Microservices Architecture) – это стиль разработки ПО, в котором приложение разбивается на мелкие независимые сервисы, взаимодействующие между собой через API. 🚩Каждый микросервис Выполняет одну конкретную бизнес-задачу (например, авторизация, платежи, управление пользователями). Автономен – его можно разрабатывать, развертывать и масштабировать отдельно. Общается с другими микросервисами через HTTP (REST, gRPC) или асинхронные очереди (Kafka, RabbitMQ*. 🚩Ключевые принципы микросервисов Разделение на мелкие сервисы – нет единого монолита, каждый сервис отвечает за свою функцию. Связь через API – микросервисы общаются по HTTP (REST, GraphQL, gRPC) или через брокеры сообщений. Независимое развертывание – каждый сервис можно обновлять без остановки всей системы. Собственная база данных – каждый сервис управляет своими данными (это уменьшает зависимость между сервисами). Горизонтальное масштабирование – можно увеличить только нужные сервисы под нагрузкой. 🚩Пример микросервисной архитектуры Допустим, у нас есть интернет-магазин. В микросервисной архитектуре он может быть разделен на: User Service – отвечает за регистрацию и авторизацию. Order Service – обрабатывает заказы. Payment Service – управляет платежами. Product Service – хранит информацию о товарах. Notification Service – отправляет уведомления клиентам. 🚩Плюсы ➕Гибкость можно разрабатывать разные сервисы разными командами и технологиями. ➕Масштабируемость можно увеличить только нужные сервисы, а не всю систему. ➕Устойчивость отказ одного сервиса не ломает всю систему. ➕Быстрое развертывание можно обновлять отдельные сервисы без остановки всего приложения. 🚩Минусы ➖Сложность нужно продумывать взаимодействие сервисов, мониторинг, балансировку. ➖Задержки в коммуникации из-за работы по сети API-запросы могут выполняться медленнее, чем в монолите. ➖Сложное тестирование приходится тестировать не только сервисы по отдельности, но и их взаимодействие. Ставь 👍 и забирай 📚 Базу знаний

🤔 Техника анализа классов эквивалентности — классический пример? Классический пример: поле для ввода возраста (принимает значения от 18 до 65). Разбивается на 3 класса: - валидный класс (18–65); - класс с меньшим значением (65). Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Какие знаешь статус коды? Статусные коды HTTP представляют собой стандартизированные индикаторы, отправляемые сервером в ответ на запросы клиента, чтобы указать на результат обработки запроса. Они помогают определить, был ли запрос успешным, произошла ли ошибка и какого рода действия требуется предпринять дальше. Они разделены на пять классов: 🚩1xx: Информационные 🟠100 Continue Промежуточный ответ, указывающий, что начальная часть запроса принята и клиент может продолжать отправку данных. 🟠101 Switching Protocols Сервер соглашается переключить протоколы в соответствии с запросом клиента, отправленным в заголовке Upgrade. 🚩2xx: Успешные 🟠200 OK Стандартный ответ для успешных HTTP-запросов. Ресурс успешно обработан и передан в теле ответа. 🟠201 Created Запрос был успешно выполнен, и в результате был создан новый ресурс. 🟠204 No Content Запрос успешно обработан, но в ответе нет содержимого. 🚩3xx: Перенаправления 🟠301 Moved Permanently Запрашиваемый ресурс был окончательно перемещен на URL, указанный в заголовке Location. Клиент должен использовать этот новый URL в будущем. 🟠302 Found Запрашиваемый ресурс временно находится по другому URI, указанному в заголовке Location. 🟠304 Not Modified Ресурс не был изменен с момента последнего запроса клиента, использующего условные заголовки типа If-Modified-Since или If-None-Match. 🚩4xx: Ошибки клиента 🟠400 Bad Request Сервер не может обработать запрос из-за неверного синтаксиса. 🟠401 Unauthorized Для доступа к запрашиваемому ресурсу требуется аутентификация. 🟠403 Forbidden Сервер понял запрос, но отказывается его авторизовать. 🟠404 Not Found Запрашиваемый ресурс не найден на сервере. 🟠405 Method Not Allowed Метод, указанный в запросе, не поддерживается для данного ресурса. 🚩5xx: Ошибки сервера 🟠500 Internal Server Error Общая ошибка сервера, когда сервер сталкивается с непредвиденными обстоятельствами. 🟠501 Not Implemented Сервер не поддерживает функциональные возможности, необходимые для обработки запроса. 🟠502 Bad Gateway Сервер, выступая в роли шлюза или прокси, получил неверный ответ от вышестоящего сервера. 🟠503 Service Unavailable Сервер временно не может обработать запрос из-за перегрузки или технического обслуживания. 🟠504 Gateway Timeout Шлюз или прокси-сервер не получил вовремя ответ от вышестоящего сервера для завершения запроса. Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое респонсивная верстка? Респонсивная верстка (Responsive Web Design, RWD) — это подход к разработке веб-страниц, при котором сайт автоматически подстраивается под разные размеры экранов и устройства (десктопы, планшеты, смартфоны). 🚩Как реализуется респонсивность? 🟠Медиа-запросы (CSS Media Queries) Позволяют менять стили в зависимости от размера экрана. body { font-size: 16px; } @media (max-width: 768px) { body { font-size: 14px; } } 🟠Гибкие сетки (Flexible Grids, Flexbox, CSS Grid) Позволяют располагать элементы на странице так, чтобы они адаптировались под экран. .container { display: flex; flex-wrap: wrap; } .item { flex: 1 1 300px; /* Блоки с минимальной шириной 300px */ } 🟠Отзывчивые изображения (Responsive Images) Изображения должны подстраиваться под размер экрана. img { max-width: 100%; height: auto; } 🟠Viewport в `` Обязательный тег для адаптивности на мобильных устройствах. Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница между ошибкой и дефектом? В тестировании и разработке программного обеспечения ошибка (error) и дефект (defect) – это разные понятия, хотя они связаны между собой. 🚩Ошибка (Error) Ошибка – это неправильное действие или решение разработчика, из-за которого в коде появляется проблема. Ошибки могут быть на разных этапах Ошибки при написании кода (синтаксические, логические). Ошибки в требованиях (неправильное понимание задачи). Ошибки в дизайне (некорректная архитектура). int divide(int a, int b) { return a / b; // Ошибка: нет проверки на деление на 0 } 🚩Дефект (Defect, Bug, Issue) Дефект – это некорректное поведение программы, вызванное ошибкой в коде. Дефект – это конкретная проблема в продукте, найденная тестировщиком или пользователем. Если дефект мешает пользователям – он становится проблемой (issue). Пример дефекта: Кнопка "Войти" не работает. При вводе 0 приложение вылетает с ошибкой. Цена товара на сайте отображается неправильно. Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие есть методы проектирования? - Эквивалентное разбиение; - Анализ граничных значений; - Попарное тестирование; - Причинно-следственные графы. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Расскажи об трехуровневой клиент-серверной архитектуре( 3-Tier)? Трёхуровневая архитектура (3-Tier) – это модель построения программных систем, в которой приложение разделено на три логических уровня: Уровень представления (Presentation Tier) – интерфейс пользователя. Уровень бизнес-логики (Application/Logic Tier) – обработка данных. Уровень данных (Data Tier) – база данных. 🟠Уровень представления (Presentation Tier) – Фронтенд Это интерфейс, который пользователь видит и с которым взаимодействует. Отправляет запросы на сервер и получает данные. Веб: HTML, CSS, JavaScript, React, Angular, Vue Мобильные приложения: Swift (iOS), Kotlin (Android) Десктопные приложения: Electron, WPF fetch("Ссылка скрыта .then(response => response.json()) .then(data => console.log(data)); 🚩Уровень бизнес-логики (Application Tier) – Бэкенд Обрабатывает запросы от фронтенда. Применяет правила и бизнес-логику. Запрашивает и обновляет данные в базе. Языки: Node.js, Java, Python, PHP, C# Фреймворки: Express.js, Spring, Django, ASP.NET API: REST, GraphQL, gRPC app.get("/products", (req, res) => { const products = db.getAllProducts(); res.json(products); }); 🚩Уровень данных (Data Tier) – База данных Хранит структурированные (SQL) или неструктурированные (NoSQL) данные. Отвечает на запросы сервера (CRUD: Create, Read, Update, Delete). Примеры технологий: SQL: **PostgreSQL, MySQL, MS SQL NoSQL: MongoDB, Redis, Firebase SELECT * FROM products WHERE category = 'electronics'; 🚩Как взаимодействуют уровни? Фронтенд (UI) делает запрос к API (Ссылка скрыта Бэкенд обрабатывает запрос, запрашивает данные из БД. База данных возвращает данные бэкенду. Бэкенд отправляет ответ фронтенду. Фронтенд отображает данные пользователю. Пользователь → Нажимает "Показать товары" Фронтенд → Запрос на /products Бэкенд → Запрос к БД База данных → Отдаёт список товаров Бэкенд → Отправляет JSON-ответ Фронтенд → Показывает товары на экране Ставь 👍 и забирай 📚 Базу знаний