BA & SA | 10000 Interview questions
10.2K subscribers
172 photos
14 videos
342 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
🧑‍🎓Объяснение:
Acceptance criteria должны быть конкретными и измеримыми. Вариант C содержит чёткие формальные правила (минимальная длина, наличие цифры и заглавной буквы), конкретные ожидаемые результаты (email, невозможность входа по старому паролю) и описание поведения при ошибке. Это позволяет разработчику точно реализовать функционал, а тестировщику — создать проверки без домыслов.
A: слишком размыто («работает», «сообщение» — какое?).
B: отсылка к неопределённой «политике безопасности», не проверяемо.
D: субъективно, невозможно проверить объективно.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4716 категория вопросов: #TESTING
4716. Логика скидок:

сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
Anonymous Quiz
12%
Эквивалентное разделение
40%
Таблица решений
11%
Попарное тестирование
37%
Анализ граничных значений
🧑‍🎓Объяснение:
Таблица решений идеально подходит для проверки комбинаций условий и соответствующих действий. Здесь два условия (сумма >5000, участие) и три результата. Таблица наглядно покрывает все 4 комбинации, гарантируя, что ни одно бизнес-правило не пропущено.
A: эквивалентное разделение не учитывает комбинации условий.
C: попарное тестирование избыточно для двух параметров и не даёт такой наглядности.
D: анализ граничных значений полезен для чисел, но не проверяет комбинации условий.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4717 категория вопросов: #TESTING
4717. Тестировщик нашёл: система позволяет записаться на уже занятое время. Разработчик: «Так в ТЗ — сначала выбор, потом проверка». Ваши действия?
Anonymous Quiz
2%
Согласиться с разработчиком.
75%
Уточнить у заказчика ожидаемое поведение, при необходимости скорректировать ТЗ.
1%
Закрыть баг как «не баг».
23%
Предложить добавить валидацию на фронтенде.
1
🧑‍🎓Объяснение:
Аналитик — арбитр между разработкой и тестированием. Он должен проверить, соответствует ли реализация истинным бизнес-ожиданиям. Для этого нужно связаться с заказчиком, уточнить, должна ли система блокировать выбор занятого времени. Если да — скорректировать требования и поставить задачу на исправление. Если нет — задокументировать это решение.
A: слепое следование ТЗ может привести к плохому UX.
C: закрытие база без анализа игнорирует потенциальную проблему.
D: техническое решение без проработки требований может не соответствовать бизнес-логике.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4718 категория вопросов: #TESTING
🧑‍🎓Объяснение:
Аналитик, зная предметную область, должен обеспечить тестировщиков всем необходимым для создания реалистичных тестовых наборов: примеры запросов и ответов, описание форматов, скрипты для генерации данных, учитывающие бизнес-правила. Это позволяет QA сосредоточиться на проверке логики, а не на придумывании данных.
A: доступ к production нарушает безопасность и законы о персональных данных.
B: написание сценариев — задача тестировщика.
D: юнит-тесты не решают проблему интеграционных данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4719 категория вопросов: #TESTING
🧑‍🎓Объяснение:
Когда баг воспроизводится только в специфических условиях, важно точно зафиксировать эти условия для проверки исправления и предотвращения регрессии. Совместная встреча разработчика и тестировщика с участием аналитика позволяет наглядно продемонстрировать шаги, а аналитику — задокументировать их и перевести на язык требований.
A: закрытие база оставляет риск повторения на проде.
B: устное описание часто неполно; показ точнее.
D: перекладывание ответственности не решает проблему.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1
№4720 категория вопросов: #DBMS
4720. Вы проектируете базу данных для магазина. В одной таблице Orders вы планируете хранить: order_id, customer_name, customer_phone, product_id, product_name, product_price, quantity, order_date. Какая проблема скорее всего возникнет при таком дизайне?
Anonymous Quiz
4%
Невозможность быстрого поиска по дате
80%
Избыточность данных и аномалии обновления
13%
Отсутствие первичного ключа
3%
Медленная вставка новых записей
🧑‍🎓Объяснение:
Описанная структура нарушает нормализацию, а именно вторую нормальную форму. Данные о клиенте (customer_name, customer_phone) и товаре (product_name, product_price) будут повторяться в каждом заказе, что приводит к избыточности. Это вызывает:

Аномалии обновления: если клиент сменил телефон, придётся обновлять все его заказы.
Аномалии вставки: нельзя добавить нового клиента без заказа.
Аномалии удаления: при удалении последнего заказа потеряется информация о клиенте.
A: Поиск по дате можно ускорить индексом, это не главная проблема.
C: Первичный ключ (order_id) есть, его можно добавить.
D: Вставка может быть не медленной, а вот обновления — да.

Вывод: Правильное проектирование требует выделения сущностей (Клиенты, Товары, Заказы) в отдельные таблицы и установления связей между ними.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4721 категория вопросов: #DBMS
4721. В банковской системе выполняется перевод средств со счёта A на счёт B. Операция состоит из двух шагов: списание с A и зачисление на B. После списания, но до зачисления - сбой. Какое свойство транзакции нарушено,и каким механизмом оно обеспечивается?
Anonymous Quiz
28%
Согласованность (Consistency) — через триггеры
12%
Изоляция (Isolation) — через блокировки
58%
Атомарность (Atomicity) — через журнал транзакций (WAL)
2%
Долговечность (Durability) — через резервное копирование
🧑‍🎓Объяснение:
Атомарность (Atomicity) гарантирует, что транзакция выполняется целиком или не выполняется вовсе (всё или ничего). В данном случае после сбоя система должна откатить списание, чтобы не возникло ситуации, когда деньги списаны, но не зачислены. Атомарность реализуется через журнал упреждающей записи (WAL): если транзакция не завершена, при восстановлении система выполняет ROLLBACK по журналу.

A: Согласованность отвечает за сохранение бизнес-правил (например, баланс не становится отрицательным), но не за откат при сбое.
B: Изоляция защищает от влияния параллельных транзакций, не от сбоев.
D: Долговечность гарантирует, что завершённая транзакция сохранится, но не откат.

Вывод: Атомарность — фундаментальное свойство транзакций, критичное для финансовых операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4722 категория вопросов: #DBMS
4722. В таблице Users (10 млн записей) часто выполняются запросы поиска пользователей по полю email. Какое действие даст наибольший прирост производительности?
Anonymous Quiz
65%
Создать индекс по полю email
3%
Увеличить размер оперативной памяти сервера
22%
Добавить составной индекс по полям (email, last_name)
10%
Разделить таблицу на несколько по первой букве email