4715. User story: смена пароля. Какие критерии приёмки сделают её проверяемой?
Anonymous Quiz
6%
Поле обязательно, кнопка работает, есть сообщение.
4%
Пароль безопасный, приходит уведомление.
90%
1. Длина ≥8, цифра и заглавная. 2. Приходит email. 3. Старый пароль не работает.
0%
Как в других банковских приложениях
❌ A: слишком размыто («работает», «сообщение» — какое?).
❌ B: отсылка к неопределённой «политике безопасности», не проверяемо.
❌ D: субъективно, невозможно проверить объективно.
Please open Telegram to view this post
VIEW IN TELEGRAM
4716. Логика скидок:
сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
Anonymous Quiz
12%
Эквивалентное разделение
40%
Таблица решений
11%
Попарное тестирование
37%
Анализ граничных значений
❌ A: эквивалентное разделение не учитывает комбинации условий.
❌ C: попарное тестирование избыточно для двух параметров и не даёт такой наглядности.
❌ D: анализ граничных значений полезен для чисел, но не проверяет комбинации условий.
Please open Telegram to view this post
VIEW IN TELEGRAM
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