QA Automation
80 задач, из них 5 на код с автопроверкой. Условие и варианты ответа открыты всем; проверка, подсказка и разбор — в клубе.
Тест-дизайн и дефекты
- Поле «возраст» принимает 18–65: какой набор значений даёт максимум информации за минимум проверок
- Билд приехал на стенд за четыре часа до конца дня: с чего начинать проверку
- Разработчик вернул дефект с резолюцией «не воспроизводится»: что менять в баг-репорте
- Опечатка в названии компании на главной странице за день до релиза: severity и приоритет
- 36 комбинаций браузер × роль × способ оплаты не влезают в регресс: как сократить набор
- Исправили расчёт скидки в сервисе заказов: какой объём проверок брать в задачу
- На груминге приносят требование «страница отчётов должна открываться быстро»: действия QA до старта разработки
- Два параллельных списания бонусов вернули 200 OK, баланс ушёл в минус: как довести находку до фикса
Тестирование REST API
- На тело с полем qty = «abc» сервис отвечает 500 и стектрейсом: дефект или ожидаемое поведение
- Автотест проверяет только статус-код 200: что он пропустит
- Позитивный сценарий применения промокода проверен: какие негативные проверки брать первыми
- Из ответа пропало поле, автотесты зелёные, мобильный клиент упал: какую проверку внедрять
- Ответ 202 и sleep(2) перед проверкой статуса отчёта: почему тест падает через раз в CI
- Повтор платёжного запроса после таймаута создал второй платёж: что проверять в API
- С токеном одного пользователя приходят транзакции другого: как квалифицировать находку
- В .proto номер удалённого поля переиспользовали под новое поле: что будет со старыми клиентами
SQL и проверка данных
- Выгрузка пользователей с заказами: почему часть зарегистрированных не попала в результат
- Сколько строк вернёт COUNT со сравнением «не равно», если в колонке есть NULL
- Автотест берёт «последний заказ» запросом с LIMIT 1 и иногда падает
- Сумма оплат по заказу в отчёте втрое больше реальной: где ошибка в запросе
- Запрос с агрегатом в WHERE не выполняется: как правильно отобрать пользователей по числу заказов
- Сверка за январь недосчитывает заказы последнего дня месяца
- Индекс по email создан, но план показывает последовательное чтение таблицы
- Фикстура вставила заказ в базу, а API отвечает 404: где искать причину
Автотесты и CI/CD
- Цикл по ролям внутри одного теста против параметризации: что меняется в результате
- 200 автотестов запускает вручную их автор перед релизом: что даст встраивание в пайплайн
- Ночной прогон уронил три теста, локально они зелёные: первый шаг разбора
- Тест проходит в одиночку и падает в общем прогоне: разбор сессионной фикстуры
- После включения восьми потоков появились падения «в корзине лишний товар»
- Красные smoke-тесты не останавливают деплой: что не так в конфигурации пайплайна
- Автоперезапуск сделал пайплайн зелёным, а два бага ушли в прод: чем реально снижать flaky
- Регресс в 40 минут на каждый merge request: как ужать до 20 без потери сигнала
Kafka и асинхронные интеграции
- Как доказать, что сервис действительно отправил событие о заказе
- После запуска автотестов сервис уведомлений перестал получать часть событий
- Автотест не находит событие, хотя kcat показывает его в топике
- Проверка события после фиксированной паузы в две секунды
- Разработчик говорит, что дубли сообщений — норма, а тестировщик завёл дефект
- Тест проверяет, что события двух заказов приходят строго по очереди
- Из события убрали поле, API-автотесты зелёные, а отчётность встала
- Как проверить обработку заведомо битого события
- Что проверять в сообщении кроме тела
- После перевода тестов на восемь параллельных потоков события «теряются»
- Регресс на стенде падает пачками после массовой загрузки данных
- Как проверить, что потребитель переживёт недоступность базы
Тестовые окружения: Docker и данные
- Стенд поднимают из образа latest, и вчерашний дефект больше не воспроизводится
- Сервис в контейнере отвечает 502, а в интерфейсе стенда пусто
- Второй прогон регресса падает на тестах регистрации
- Автотесты в контейнере не достучались до API по localhost
- Первые тесты после подъёма стенда падают, повторный запуск проходит
- Два пайплайна на одном агенте не могут поднять стенд одновременно
- Тесты в пайплайне проверяют не тот код, который поедет в прод
- Тест отчёта «за сегодня» падает только в прогонах после полуночи
- На стенде оплата проходит, в проде после релиза — нет
- Один общий стенд на пять команд: тесты падают от чужих действий
- Чем наполнять базу перед регрессом: дамп прода или сценарии подготовки
- В Kubernetes тест упал по таймауту, а под уже перезапустился
UI-автоматизация: Playwright, Selenium, Page Object
- Локатор кнопки оплаты ломается после каждой правки вёрстки
- Клик по кнопке «Сохранить» иногда не срабатывает, пока идёт загрузка формы
- Поменялся локатор поля email, и правка затронула 60 файлов с тестами
- Список нестабильных тестов по истории прогонов
- 300 UI-тестов каждый раз входят в систему через форму
- Расчёт скидки для 60 комбинаций проверяется UI-тестами в браузере
- Тест проходит на ноутбуке с видимым браузером и падает в headless на CI
- Проверка уведомления «Заказ оформлен» возвращает False, хотя на скриншоте оно есть
- Разбор цены со страницы в копейки для сравнения в автотесте
- Скриншотные тесты стабильны локально и падают на CI с различием в пару пикселей
- UI-тесты оформления заказа падают, когда тормозит сторонний виджет карты
- Ожидание условия с таймаутом, которое можно проверить без реального времени
Логи, метрики и локализация дефектов
- Как найти в Kibana логи одного неудачного запроса среди тысяч похожих
- Что приложить к дефекту «оплата падает с ошибкой 500»
- На графике в Grafana доля ошибок 5xx выросла в 14:05
- Разбор строки лога в структуру для анализа прогона
- Среднее время ответа 180 мс, а пользователи жалуются на зависания
- В логах сервиса оплаты нашлись полные номера карт
- Идентификатор запроса есть в логах шлюза, но пропадает в сервисе оплаты
- Перцентиль времени ответа по результатам прогона
- Поиск ошибок оплаты в Kibana по тексту находит только часть случаев
- Сервис перезапускается раз в шесть часов, функционально всё работает
- Под нагрузкой пропускная способность упёрлась в потолок при загрузке процессора 30%
- Сервис лежал 40 минут, а алерт так и не сработал