🖥️ Как проверить адаптивность приложения для нестандартных разрешений экрана

При тестировании приложений часто забывают про экраны с необычными разрешениями, например, 800x600 или 5K. Эти размеры требуют отдельного подхода, чтобы убедиться, что интерфейс остаётся функциональным и красивым на всех типах устройств.

Промпт:

How can I check the responsiveness of my application for screen resolutions that are rarely used (e.g., 800x600 or 5K)? What testing tools and
methods should be applied for these screen sizes?

Чем полезен:

➡️ Проверяет, как приложение ведет себя на экранах с редкими разрешениями
➡️ Помогает выявить проблемы с отображением и интерфейсом на разных типах экранов
➡️ Рекомендует методы тестирования, включая эмуляцию и использование инструментов

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#артефакт

🔆 Когда баг не ловится

Клиент сообщает, что у него ошибка, но вы не можете её повторить. Ваши шаги?

Классическая ситуация для QA: баг «живёт» у пользователя, но у вас всё работает идеально.

🔜 Как действовать:

🔘 Собрать контекст: версия браузера, устройство, ОС, время, скрин/видео, логи.

🔘 Сравнить окружения: проверить конфигурацию продакшна, теста и staging.

🔘 Поиграть с данными: возможно, баг зависит от конкретного пользователя, роли или состояния кэша.

🔘 Записать наблюдения: даже если не воспроизводится — оформить отчёт с гипотезами и шагами.

💡 Хороший ответ звучит не как «не смог повторить», а как «исследовал, собрал данные и сузил возможные причины».

Таких специалистов ищут — не тех, кто ищет баги, а тех, кто ищет истину.

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#карьерный_трек #middle

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#прод_в_пятницу

🤯 DORA — что это и при чём тут тестировщик

Digital Operational Resilience Act — регламент ЕС, обязывающий финансовые организации доказывать, что их IT-системы устойчивы к сбоям и кибератакам. Вступил в силу в январе 2025.

5 столпов DORA:

🔵 Управление ICT-рисками — фреймворк для выявления и снижения рисков
🔵 Отчётность об инцидентах — первое уведомление за 4 часа, промежуточный отчёт за 72 часа, финальный за 30 дней
🔵 Тестирование устойчивости — регулярные тесты, включая пентест по методологии TIBER-EU
🔵 Управление рисками третьих сторон — контроль поставщиков IT-услуг
🔵 Обмен информацией — добровольный обмен данными о киберугрозах

Что это значит для QA:

— Resilience-тестирование становится обязательным, а не «хорошо бы»
— Тесты на отказоустойчивость, восстановление, failover — это теперь требование регулятора
— Нужна трейсабилити: от требования → к тест-кейсу → к результату → к отчёту
— Штрафы: до 2% годового оборота для организации, до €1 млн лично для руководителя

👍 — знал/а
🔥 — стало понятнее

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#теория_на_пальцах

📋 Чек-листы для тестировщика

В подборке — материалы с примерами и шаблонами, которые помогут составить рабочие чек-листы для ручного тестирования всех ключевых направлений.

➡️ Complete QA Process Checklist

Подробный чек-лист на весь цикл QA: от анализа требований до релизной верификации. Готовый шаблон доступен бесплатно.

➡️ QA Checklists Explained

Глубокое руководство по принципам построения чек-листов, их роли на разных этапах тестирования и где применять.

➡️ The Only Software Testing Checklist You Need

Универсальный чек-лист для ручного тестирования, охватывающий функциональность, API, UI, performance, compatibility.

➡️ Как составить чек-листы для эффективного тестирования

Пошаговый подход по категориям: «для чего чек-лист», «как разбивать на блоки», «как формулировать кейсы».

➡️ Чек-лист и шпаргалка по тест‑кейсам

Лаконичные примеры чек-листов для веб-приложений: функционал, формы, UI, сценарии. PDF-формат для скачивания.

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#release_digest

🔥 3 способа скрыть элемент, которые обязан знать каждый тестировщик

В CSS есть несколько для этого способов, и каждый ведёт себя по-своему:

— один полностью исключает элемент из потока
— другой делает его невидимым, но он остаётся в DOM
— а третий — вообще всё ещё кликается

Почему это важно:

— ломаются автотесты, если не учесть способ скрытия
— isDisplayed() и isVisible() могут врать
— доступность (a11y) зависит от метода
— критично при проверке модалок, спойлеров и выпадашек

📌 На картинке — краткая шпаргалка по трем базовым методам. Сохраните, пригодится в каждом втором UI-тесте 🎀

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#cheat_sheet

По факту 😁

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#прод_в_пятницу

😀 Как тестировать push-уведомления локально

Проверка push — это не только «пришло или нет». Чтобы тест был полноценным, важно пройти все ключевые этапы:

1️⃣ Эмулируйте реальные сценарии:

— Пользователь в онлайне / офлайне

— Браузер открыт, но вкладка в фоне

— Приложение закрыто (mobile/desktop PWA)

2️⃣ Валидируйте бизнес-логику:

— Сообщение приходит только нужным сегментам

— Нет дубликатов при повторной подписке

— Уведомление исчезает после обработки события

3️⃣ Тестируйте UX-детали:

— Заголовок влезает в одну строку

— Иконка чёткая на разных DPI

— Клик открывает нужный экран (и передаёт параметры)

4️⃣ Полезные инструменты:

— Web Push Codelab — быстро проверить контент

— DevTools → Application → Service Workers — симуляция push

— Локальный Node-сервер с web-push для кастомных payload

💡 Такой тест ловит баги, которые продакшн-проверка часто пропускает: неверная сегментация, обрезанные тексты, сбитая навигация.

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#тест_драйв

🫡 Один и тот же запрос к AI можно выполнить двумя способами — и получить совершенно разный результат.

1️⃣ способ — просто попросить написать код. Модель может сгенерировать рабочее решение, но именно на этапе проверки часто всплывают пропущенные edge case’ы, ошибки обработки или проблемы с тестами.

2️⃣ способ — дать агенту цикл Think → Act → Observe. Он не останавливается после первой попытки: планирует действия, проверяет результат и, если находит ошибку, исправляет её и пробует снова.

Самое интересное, что разница здесь не столько в модели ❕ Claude, GPT или другая LLM могут быть одинаковыми. Разницу создаёт инженерная система вокруг них.

📅 Именно это разберём 23 июля в 19:00 (МСК) на бесплатном вебинаре с Алексеем Жиряковым (Executive Director в Сбере, GenAI Data Platform, ex-CTO Stream и KION).

На живом демо покажем, как один и тот же запрос работает без агентной системы и с ней 🔥

🔗 Регистрация

🏃‍♀️ Proglib Academy

🔄 Что такое Contract Testing — и зачем он нужен, если уже есть интеграционные тесты?

Есть два сервиса: один отдаёт данные, другой их использует. По отдельности оба работают. Но после очередного релиза один сервис меняет API — и второй неожиданно перестаёт понимать ответ.

🔜 Именно для таких ситуаций существует Contract Testing. Вместо того чтобы запускать оба сервиса вместе, они заранее проверяют, соблюдают ли общий контракт.

🟠 Consumer описывает, какой ответ он ожидает: поля, типы данных и структуру JSON.
🟠 Provider автоматически проверяет, что действительно отдаёт именно такой ответ.

Если контракт нарушен, тест упадёт ещё в CI — до интеграции и выкладки в staging.

🔤 Пример:

Фронтенд ожидает:

{ "price": 12.99 }

После обновления бэкенд начинает возвращать:

{ "price": "12.99" }

Визуально разница почти незаметна, но для клиента это уже другое API. Contract test обнаружит проблему сразу.

Популярные инструменты:

— Pact
— Spring Cloud Contract

👍 — знал/а
🔥 — стало понятнее

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#теория_на_пальцах