4717. Тестировщик нашёл: система позволяет записаться на уже занятое время. Разработчик: «Так в ТЗ — сначала выбор, потом проверка». Ваши действия?
Anonymous Quiz
2%
Согласиться с разработчиком.
75%
Уточнить у заказчика ожидаемое поведение, при необходимости скорректировать ТЗ.
1%
Закрыть баг как «не баг».
23%
Предложить добавить валидацию на фронтенде.
❌ A: слепое следование ТЗ может привести к плохому UX.
❌ C: закрытие база без анализа игнорирует потенциальную проблему.
❌ D: техническое решение без проработки требований может не соответствовать бизнес-логике.
Please open Telegram to view this post
VIEW IN TELEGRAM
4718. Для интеграционного тестирования микросервисов нужны тестовые данные. Что сделает аналитик?
Anonymous Quiz
1%
Даст доступ к production-базе.
6%
Напишет сценарии тестирования.
92%
Подготовит документацию с примерами данных, форматами и скриптами генерации по бизнес-правилам.
1%
Попросит разработчиков написать юнит-тесты.
❌ A: доступ к production нарушает безопасность и законы о персональных данных.
❌ B: написание сценариев — задача тестировщика.
❌ D: юнит-тесты не решают проблему интеграционных данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
4719. Найден критический баг, разработчик исправил, но тестировщик не может воспроизвести. Что делать аналитику?
Anonymous Quiz
1%
Закрыть как невоспроизводимый.
12%
Попросить разработчика описать условия.
86%
Организовать встречу,где разработчик покажет условия, а аналитик зафиксирует неточности тестировщику
0%
Передать тимлиду.
❌ A: закрытие база оставляет риск повторения на проде.
❌ B: устное описание часто неполно; показ точнее.
❌ D: перекладывание ответственности не решает проблему.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1
4720. Вы проектируете базу данных для магазина. В одной таблице Orders вы планируете хранить: order_id, customer_name, customer_phone, product_id, product_name, product_price, quantity, order_date. Какая проблема скорее всего возникнет при таком дизайне?
Anonymous Quiz
4%
Невозможность быстрого поиска по дате
80%
Избыточность данных и аномалии обновления
13%
Отсутствие первичного ключа
3%
Медленная вставка новых записей
Аномалии обновления: если клиент сменил телефон, придётся обновлять все его заказы.
Аномалии вставки: нельзя добавить нового клиента без заказа.
Аномалии удаления: при удалении последнего заказа потеряется информация о клиенте.
❌ A: Поиск по дате можно ускорить индексом, это не главная проблема.
❌ C: Первичный ключ (order_id) есть, его можно добавить.
❌ D: Вставка может быть не медленной, а вот обновления — да.
Вывод: Правильное проектирование требует выделения сущностей (Клиенты, Товары, Заказы) в отдельные таблицы и установления связей между ними.
Please open Telegram to view this post
VIEW IN TELEGRAM
4721. В банковской системе выполняется перевод средств со счёта A на счёт B. Операция состоит из двух шагов: списание с A и зачисление на B. После списания, но до зачисления - сбой. Какое свойство транзакции нарушено,и каким механизмом оно обеспечивается?
Anonymous Quiz
28%
Согласованность (Consistency) — через триггеры
12%
Изоляция (Isolation) — через блокировки
58%
Атомарность (Atomicity) — через журнал транзакций (WAL)
2%
Долговечность (Durability) — через резервное копирование
❌ A: Согласованность отвечает за сохранение бизнес-правил (например, баланс не становится отрицательным), но не за откат при сбое.
❌ B: Изоляция защищает от влияния параллельных транзакций, не от сбоев.
❌ D: Долговечность гарантирует, что завершённая транзакция сохранится, но не откат.
Вывод: Атомарность — фундаментальное свойство транзакций, критичное для финансовых операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
4722. В таблице Users (10 млн записей) часто выполняются запросы поиска пользователей по полю email. Какое действие даст наибольший прирост производительности?
Anonymous Quiz
65%
Создать индекс по полю email
3%
Увеличить размер оперативной памяти сервера
22%
Добавить составной индекс по полям (email, last_name)
10%
Разделить таблицу на несколько по первой букве email
❌ B: Увеличение памяти может помочь, если текущий объём недостаточен для кэширования, но это не решит проблему полного сканирования.
❌ C: Составной индекс полезен, если запросы часто используют оба поля, но для поиска только по email он будет менее эффективен (можно использовать, но он больше по размеру).
❌ D: Шардинг (горизонтальное партиционирование) — сложное архитектурное решение, которое обычно применяют при распределении нагрузки, а не для ускорения одного вида запросов. Индекс проще и дешевле.
Вывод: Индекс — базовый инструмент оптимизации запросов. Аналитик должен рекомендовать индексацию часто используемых в условиях WHERE полей.
Please open Telegram to view this post
VIEW IN TELEGRAM
4723. В системе онлайн-бронирования отелей два пользователя одновременно пытаются забронировать последний свободный номер. В результате номер забронирован дважды. Какой механизм СУБД предотвратил бы эту проблему?
Anonymous Quiz
9%
Уникальный индекс на поле room_id
17%
Триггер, проверяющий количество броней
73%
Блокировка строки при чтении (SELECT ... FOR UPDATE)
1%
Журналирование всех изменений
Добавьте папку — и сразу получите доступ к закрытому каналу с подарками от экспертов: полезными гайдами, чек-листами, промокодами на карьерные консультации и т.д.
🍂 Карьерный рост — стратегии переговоров, продажи, маркетинг🍂 Удалёнка и фриланс — как находить заказчиков и работать из любой точки мира🍂 Личный бренд — создание экспертного статуса🍂 Hard и soft skills — навыки, за которые готовы платить в 2026 года🍂 Автоматизация и тайм-менеджмент — как работать меньше, а зарабатывать больше и многое другое
Добавить папку + открыть бонусы
https://t.me/addlist/ZcC3dzQ0ZJhjZjgy
(Доступ открыт 72 часа)
Присоединяйтесь: @prodvizheniye_reklama
Please open Telegram to view this post
VIEW IN TELEGRAM
❌ A: Уникальный индекс предотвращает дубликаты по ключу, но здесь уникальность не в одном поле, а в сочетании «номер + дата» (или что-то подобное). Если бы индекс был составным, он бы сработал, но в условии только room_id — не хватит.
❌ B: Триггер выполняется после попытки вставки, но не блокирует чтение, поэтому оба пользователя могут пройти проверку одновременно.
❌ D: Журналирование помогает при восстановлении после сбоя, но не решает проблему конкурентного доступа.
Вывод: Для критичных по конкуренции операций необходимо использовать явные блокировки или повышать уровень изоляции транзакции до REPEATABLE READ / SERIALIZABLE.
Please open Telegram to view this post
VIEW IN TELEGRAM