Библиотека тестировщика | QA, тестирование, quality assurance, manual testing, autotesting, ручное тестирование, автотесты

🔥 Вопрос с собеседования (финтех, Middle) Почему в платёжной системе нельзя просто повторно отправить запрос на списание, если не пришёл ответ от сервера? 👇 Правильный ответ (нажми, чтобы прочитать): Потому что это может привести к двойному списанию средств. 🔵 Почему это критично: — пользователь может заплатить дважды — деньги «зависнут» между системами — возникают финансовые расхождения — теряется доверие к продукту 🔵 Что должно быть вместо этого: — идемпотентность запросов (idempotency key) — проверка статуса операции перед повтором — безопасные ретраи — журналирование транзакций 🔵 Где чаще всего стреляют: — нестабильная сеть / таймауты — мобильные приложения (повторные клики) — интеграции с внешними платёжками — асинхронные операции 👍 — знал/а 🔥 — стало понятнее 💼 Щелкаешь такие задачи как орешки? Найди проект с достойной зарплатой тут 🐸 Библиотека тестировщика #карьерный_трек #middle

Отправь тому, кто достоин этой открытки 💓 🐸 Библиотека тестировщика #прод_в_пятницу

🚨 Логин через Google ломает импорт данных Разобрали баг в Lumo by Proton — и он бьёт прямо в onboarding:

Пытаешься импортировать данные → выбираешь Google → вводишь логин

🔤 получаешь ошибку “400. That’s an error” и процесс обрывается Что происходит: 🔵 После успешного ввода данных Google возвращает ошибку 400 🔵 Пользователь не возвращается в приложение 🔵 Импорт данных невозможен Почему это критично: — ломается ключевой сценарий onboarding (импорт данных) — пользователь не может начать работу с продуктом — выглядит как ошибка авторизации или небезопасный вход — высокий шанс дропа на старте ⚠️ Вероятная причина:

ошибка в OAuth flow — некорректный redirect / параметры запроса / обработка ответа

🔤 типичный баг интеграции с внешним провайдером 👍 — заметили бы 🔥 — полезный кейс 🔗 Источник 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #разбор_полетов

💼 Почему «закрыть всё в одном спринте» не работает Хочется, чтобы всё шло по плану: сделали задачу → протестировали → пофиксили баги → закрыли. В реальности процесс быстро начинает сбоить.

Стоит тестированию немного задержаться — разработчик уже ждёт. Баги приходят под конец — времени на фиксы не хватает. Появляются переключения между задачами — теряется контекст.

🔜 В итоге спринт превращается в попытку догнать всё в последний момент. Так происходит потому, что часть работы невозможно точно спрогнозировать: количество багов и время на их исправление каждый раз разные. 💡 Более устойчивый вариант — выстроить последовательный поток:

сделали → передали на тест → нашли баги → исправили → перепроверили

Часть этапов выходит за пределы одного спринта, и процесс при этом остаётся ровным и предсказуемым. 🔗 Источник 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #карьерный_трек

🔗 10 способов тестировать iOS-приложения: жизненный цикл и реальные сценарии Проблемы в мобильных приложениях чаще возникают при смене состояний: фон, сеть, прерывания, повторный запуск. Если их не проверять — баги уходят в прод. Ниже — базовый набор проверок ⬇️ 6️⃣ Холодный старт (Not running → Active) Запуск с нуля → корректная загрузка данных, отсутствие падений и зависаний 2️⃣ Уход в фон (Active → Background) Сворачивание приложения → активные процессы не ломаются 3️⃣ Возврат из фона Открытие после паузы → состояние и экран восстанавливаются корректно 4️⃣ Выгрузка системой (kill в фоне) Приложение принудительно завершено → данные и сессия восстанавливаются 5️⃣ Ввод данных → сворачивание Пользователь не завершил действие → данные не теряются 6️⃣ Обработка push-уведомлений Push в фоне/приостановке → корректный переход и обновление UI 7️⃣ Изменение сети Wi-Fi ↔ LTE ↔ offline → обработка ошибок, ретраи, восстановление запросов 8️⃣ Прерывания (звонки, уведомления) Внешние события → приложение не падает и сохраняет прогресс 9️⃣ Многозадачность Быстрое переключение между приложениями → навигация и состояние сохраняются 6️⃣1️⃣ Фоновые задачи Загрузка/синхронизация в фоне → корректное завершение без потери данных 🔗 Подробнее по ссылке 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #артефакт

🔥 4 привычки кодеров Вот сколько общаюсь с разработчиками, постоянно слышу убеждение, что есть какой-то правильный способ писать софт. Все ищут секретную архитектуру, вылизывают паттерны, чтобы хоба и тимлид заплакал от счастья от твоего идеального кода. но, я собрал 4 привычки адептов «чистого кода», (которые обычно все практикуют) 🤡 • Бесконечный рефакторинг рабочего кода. Кажется, что так ты делаешь продукт лучше. Итог: жестко падаешь в перфекционизм. Переписываешь функцию по три раза, а бизнес ждет релиз. Закрываешь вкладку и в голове абсолютная пустота, время потрачено, а новых фичей ноль. • Упарывание в сложную архитектуру Сеньоры на ютубе обещают золотые горы, если внедрить микросервисы куда угодно. Итог: получаешь красивый overengineering-проект для мамы и 0 запущенных продуктов в срок, пока конкуренты клепают MVP на коленке. • Душные споры на ревью Неплохо, но как итог: ты пишешь полотна текста и тратишь часы на поиск глупой придирки к стилю, потому что банально фокус сместился с реальной задачи на эго. • Ручная микро-оптимизация Классика для тех, кто любит алгоритмы из универа. Итог: убиваешь дни жизни и выжимаешь миллисекунды, хотя бизнесу нужен был просто грязный, но рабочий скрипт еще вчера. Проблема в том, что ни один из этих путей не дает самого главного - скорости и проверки гипотез. Реальному рынку плевать на твой идеальный код за 3 дня. Бизнес предпочтет код от ИИ-агента за 5 минут, который уже завтра начнет приносить деньги. Хочешь обкатанный на нас лично и 100х учениках метод, как перестать кодить руками и начать делегировать задачи автономным системам? 👉 Заходи сюда, но у нас осталось всего 4 места, набор идет до завтрашнего дня. P. S. Если интересно еще что-нибудь почитать от меня, то заходите в «Азбуку Айтишника», там я рассказываю об айти-базе, также у меня там есть бесплатный гайд на 15 глав по ии-агентам

🚬 Как понять, что вы переросли свой уровень Вот сигналы, на которые стоит обратить внимание:

— вы закрываете задачи быстрее, чем от вас ожидают — в работе стало мало «непонятного» — всё делаете по накатанному — начинаете видеть проблемы раньше, чем они проявляются — чаще предлагаете решения, а не просто находите баги — замечаете слабые места в процессе, а не только в продукте

И главный маркер: 🔤 Вам становится скучно, а не сложно Это означает, что текущий уровень уже не даёт роста. 💡 Что дальше: — брать более сложные задачи (API, архитектура, автотесты) — влезать в смежные зоны (DevOps, аналитика, продукт) — участвовать в решениях, а не только в проверке Рост начинается там, где снова появляется «не понимаю». 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #карьерный_трек

🔥 Топ-вакансий недели для тестировщиков Автотестировщик на Kotlin в крауд-тестирование — до 88 000 ₽, удаленно (Москва) Senior QA Engineer — 200 000 —‍ 250 000 ₽, офис (Москва) QA Automation Engineer (SDET) — от 88 000 до 145 000 ₽, удаленно (Тбилиси) ➡️ Больше офферов в канале: @testerrjob 🐸 Библиотека тестировщика

🚀 Тренажёр для практики тестирования веб-элементов ToolsQA — это демо-сайт с набором типичных UI- и API-кейсов, на котором удобно отрабатывать как ручное тестирование, так и автотесты. Что можно потренировать:

🔘 Elements — кнопки, чекбоксы, инпуты, dropdown’ы 🔘 Forms — формы и валидация полей 🔘 Alerts, Frames & Windows — попапы, фреймы, вкладки 🔘 Widgets — datepicker, таблицы, тултипы, аккордеоны 🔘 Interactions — drag’n’drop, сортировка, выбор списков 🔘 Book Store — API, авторизация, CRUD

Удобно для практики реальных сценариев без подготовки окружения. 🔗 Ссылка 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #тест_драйв

💡 Chrome DevTools умеет эмулировать фокус страницы Иногда баг есть, но нормально посмотреть его не получается: открываете DevTools — и dropdown, tooltip или menu сразу исчезает. В таких случаях помогает Emulate focused page во вкладке Rendering — страница остаётся в фокусе, и можно разбирать элементы, завязанные на hover/focus. Что это даёт на практике:

— удобно проверять исчезающие элементы — проще анализировать баги в выпадающих списках и меню — можно разбирать нестабильные overlay-компоненты — меньше времени уходит на попытки поймать нужное состояние

🔜 Полезно для кейсов, где проблема есть, но воспроизвести и изучить её в обычном режиме неудобно. ✔️ Небольшое напоминание: на курс по ИИ-агентам осталось 4 места. Набор до 30 апреля. 🔜 Регистрация здесь 🐸 Библиотека тестировщика #тест_драйв

🗓️ Уже через пару часов стартует вебинар! Тема:

Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены

Ждем вас сегодня в 19:00 по московскому времени. Не пропустите начало, будет много практики! 👉 Успей занять место

✅ Правильный ответ — Ответ валиден с точки зрения GraphQL В GraphQL ошибки обрабатываются иначе, чем в REST. Даже если что-то пошло не так, сервер может вернуть 200 OK, а детали ошибки будут в поле errors. При этом data может быть: — полностью null — или частично заполнено В этом примере: — user: null → объект не найден — errors → объясняет причину Такой ответ валиден по спецификации GraphQL: ошибки возвращаются в теле ответа, а не только через HTTP-коды. В GraphQL проверяют и data, и errors, а не только статус ответа 💡 ⚡️ Кстати, на курс по ИИ-агентам осталось всего 4 места. Набор закрывается 30 апреля. Занять место по ссылке 🔗 🐸 Библиотека тестировщика #разбор_полетов

🤔 Вопрос с собеса по GraphQL Есть запрос 👇

query {
  user(id: 1) {
    name
    email
  }
}

И ответ:

{
  "data": {
    "user": null
  },
  "errors": [
    {
      "message": "User not found"
    }
  ]
}

Как правильно интерпретировать такой ответ ❔ 🐸 Библиотека тестировщика #разбор_полетов

🧠 Что такое сортировка дефектов (bug triage) На проекте редко бывает один баг. Обычно их десятки — а иногда сотни. И проблема не в том, чтобы их найти, а в том, что делать с ними дальше. Чинить всё подряд — плохая стратегия. Можно потратить время на мелочи и пропустить критичный дефект. Сортировка дефектов — это момент, где команда решает:

что фиксить сейчас, что позже, а что можно вообще не трогать

QA, разработчики и менеджер собираются и смотрят на баг с позиции: насколько это влияет на пользователей и бизнес. Иногда баг в UI откладывают на потом, а проблема с оплатой уходит в работу сразу — даже если её сложнее чинить. 💡 В итоге это не просто список дефектов, а очередь решений, от которой зависит релиз. 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #теория_на_пальцах

🌐 Что такое TCP/IP Без понимания TCP/IP сложно объяснить: почему запрос не дошёл и где потерялись данные. 🔤 В этом видео разбирают на простом уровне:

как работает TCP/IP, что такое IP, порты, DNS и как всё это связано между собой

Подойдёт, если хотите лучше понимать сетевые баги и уверенно чувствовать себя в API-тестировании. 🔗 Смотреть по ссылке 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #теория_на_пальцах

🤔 Вопрос с собеса: Linux Вы тестируете сервис на Linux. Нужно быстро понять, почему API стал отвечать медленно. Что вы сделаете в первую очередь ❔ 📍 Навигация: [Вакансии] 🐸 Библиотека тестировщика #стендап_qa