⌨️ Словарь тестировщика, без которого сложно двигаться дальше

В QA терминология напрямую влияет на работу: как вы описываете баги, понимаете требования и общаетесь с командой. Нечёткие формулировки замедляют фиксы, создают путаницу и усложняют обсуждения.

В статье собраны ключевые термины:

♾ от базовых (bug, regression, test case) до продвинутых (CI/CD, SLA, shift-left)

Подойдёт и джунам, и тем, кто хочет систематизировать знания 👇

📎 Читать по ссылке

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

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

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

💡 Шпаргалка по REST API для начинающих

Шесть фундаментальных принципов, которые служат строительными блоками архитектуры REST API:

6️⃣ Клиент-серверная архитектура
2️⃣ Взаимодействие без сохранения состояния
3️⃣ Возможность кэширования
4️⃣ Многоуровневая система
5️⃣ Поддержка кода по требованию
6️⃣ Унифицированный интерфейс

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

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

#артефакт

💡 Что читать, чтобы прокачаться во фронтенд-тестах

Анализируем виды тестов

37 советов и приемов по написанию качественных тестов

Тестирование Frontend

7 основных тенденций в тестировании Web Front-End

Тестирование фронтенда и E2E тесты

Принципы тестирования frontend приложений

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

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

#release_notes

✔️ Что должен проверять каждый QA в API

В этой шпаргалке собран базовый набор проверок, который закрывает большинство кейсов:

➕ от response validation до edge-case сценариев

Сохраните — пригодится при написании тестов и на собеседованиях 🎀

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

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

#артефакт

🤔 Вопрос с собеса: Linux

Вы тестируете сервис на Linux. Нужно быстро понять, почему API стал отвечать медленно. Что вы сделаете в первую очередь ❔

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

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

#стендап_qa

🌐 Что такое TCP/IP

Без понимания TCP/IP сложно объяснить: почему запрос не дошёл и где потерялись данные.

🔤 В этом видео разбирают на простом уровне:

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

Подойдёт, если хотите лучше понимать сетевые баги и уверенно чувствовать себя в API-тестировании.

🔗 Смотреть по ссылке

⚡️ Пока не забыли: на курс по ИИ-агентам осталось всего 4 места. Набор закрывается 30 апреля. 🔗 Успеть на обучение

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

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

🧠 Что такое сортировка дефектов (bug triage)

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

Сортировка дефектов — это момент, где команда решает:

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

QA, разработчики и менеджер собираются и смотрят на баг с позиции: насколько это влияет на пользователей и бизнес. Иногда баг в UI откладывают на потом, а проблема с оплатой уходит в работу сразу — даже если её сложнее чинить.

💡 В итоге это не просто список дефектов, а очередь решений, от которой зависит релиз.

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

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

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

🤔 Вопрос с собеса по GraphQL

Есть запрос 👇

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

И ответ:

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

Как правильно интерпретировать такой ответ ❔

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

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

#разбор_полетов

✅ Правильный ответ — Ответ валиден с точки зрения GraphQL

В GraphQL ошибки обрабатываются иначе, чем в REST. Даже если что-то пошло не так, сервер может вернуть 200 OK, а детали ошибки будут в поле errors.

При этом data может быть:

— полностью null
— или частично заполнено

В этом примере:

— user: null → объект не найден
— errors → объясняет причину

Такой ответ валиден по спецификации GraphQL: ошибки возвращаются в теле ответа, а не только через HTTP-коды. В GraphQL проверяют и data, и errors, а не только статус ответа 💡

⚡️ Кстати, на курс по ИИ-агентам осталось всего 4 места. Набор закрывается 30 апреля. Занять место по ссылке 🔗

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

#разбор_полетов

💡 Chrome DevTools умеет эмулировать фокус страницы

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

Что это даёт на практике:

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

🔜 Полезно для кейсов, где проблема есть, но воспроизвести и изучить её в обычном режиме неудобно.

✔️ Небольшое напоминание: на курс по ИИ-агентам осталось 4 места. Набор до 30 апреля. 🔜 Регистрация здесь

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

#тест_драйв

🚀 Тренажёр для практики тестирования веб-элементов

ToolsQA — это демо-сайт с набором типичных UI- и API-кейсов, на котором удобно отрабатывать как ручное тестирование, так и автотесты.

Что можно потренировать:

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

Удобно для практики реальных сценариев без подготовки окружения.

🔗 Ссылка

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

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

#тест_драйв

🔥 Топ-вакансий недели для тестировщиков

Автотестировщик на Kotlin в крауд-тестирование — до 88 000 ₽, удаленно (Москва)

Senior QA Engineer — 200 000 —‍ 250 000 ₽, офис (Москва)

QA Automation Engineer (SDET) — от 88 000 до 145 000 ₽, удаленно (Тбилиси)

➡️ Больше офферов в канале: @testerrjob

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

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

Вот сигналы, на которые стоит обратить внимание:

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

И главный маркер:

🔤 Вам становится скучно, а не сложно

Это означает, что текущий уровень уже не даёт роста.

💡 Что дальше:

— брать более сложные задачи (API, архитектура, автотесты)
— влезать в смежные зоны (DevOps, аналитика, продукт)
— участвовать в решениях, а не только в проверке

Рост начинается там, где снова появляется «не понимаю».

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

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

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

🔥 4 привычки кодеров

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

но, я собрал 4 привычки адептов «чистого кода», (которые обычно все практикуют) 🤡

• Бесконечный рефакторинг рабочего кода.
Кажется, что так ты делаешь продукт лучше. Итог: жестко падаешь в перфекционизм. Переписываешь функцию по три раза, а бизнес ждет релиз. Закрываешь вкладку и в голове абсолютная пустота, время потрачено, а новых фичей ноль.

• Упарывание в сложную архитектуру
Сеньоры на ютубе обещают золотые горы, если внедрить микросервисы куда угодно. Итог: получаешь красивый overengineering-проект для мамы и 0 запущенных продуктов в срок, пока конкуренты клепают MVP на коленке.

• Душные споры на ревью
Неплохо, но как итог: ты пишешь полотна текста и тратишь часы на поиск глупой придирки к стилю, потому что банально фокус сместился с реальной задачи на эго.

• Ручная микро-оптимизация
Классика для тех, кто любит алгоритмы из универа. Итог: убиваешь дни жизни и выжимаешь миллисекунды, хотя бизнесу нужен был просто грязный, но рабочий скрипт еще вчера.

Проблема в том, что ни один из этих путей не дает самого главного - скорости и проверки гипотез. Реальному рынку плевать на твой идеальный код за 3 дня. Бизнес предпочтет код от ИИ-агента за 5 минут, который уже завтра начнет приносить деньги.

Хочешь обкатанный на нас лично и 100х учениках метод, как перестать кодить руками и начать делегировать задачи автономным системам?

👉 Заходи сюда, но у нас осталось всего 4 места, набор идет до завтрашнего дня.

P. S. Если интересно еще что-нибудь почитать от меня, то заходите в «Азбуку Айтишника», там я рассказываю об айти-базе, также у меня там есть бесплатный гайд на 15 глав по ии-агентам

🔗 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️⃣ Фоновые задачи
Загрузка/синхронизация в фоне → корректное завершение без потери данных

🔗 Подробнее по ссылке

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

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

#артефакт

💼 Почему «закрыть всё в одном спринте» не работает

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

Стоит тестированию немного задержаться — разработчик уже ждёт.

Баги приходят под конец — времени на фиксы не хватает.

Появляются переключения между задачами — теряется контекст.

🔜 В итоге спринт превращается в попытку догнать всё в последний момент.

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

💡 Более устойчивый вариант — выстроить последовательный поток:

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

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

🔗 Источник

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

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

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

🚨 Логин через Google ломает импорт данных

Разобрали баг в Lumo by Proton — и он бьёт прямо в onboarding:

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

🔤 получаешь ошибку “400. That’s an error” и процесс обрывается

Что происходит:

🔵 После успешного ввода данных Google возвращает ошибку 400
🔵 Пользователь не возвращается в приложение
🔵 Импорт данных невозможен

Почему это критично:

— ломается ключевой сценарий onboarding (импорт данных)
— пользователь не может начать работу с продуктом
— выглядит как ошибка авторизации или небезопасный вход
— высокий шанс дропа на старте

⚠️ Вероятная причина:

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

🔤 типичный баг интеграции с внешним провайдером

👍 — заметили бы
🔥 — полезный кейс

🔗 Источник

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

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

#разбор_полетов