📃 Как читать логи ошибок: инструкция для QA-инженера

🔍 Шаг 1: Где искать логи?
Перед анализом нужно понять, куда приложение пишет логи:
- Файлы на сервере (обычно в /var/log/ или logs/):
- Консоль разработчика (Chrome DevTools → Console или Network)
- Специальные сервисы:
- Sentry (для ошибок в проде)
- Kibana (если логи хранятся в Elasticsearch)
- Grafana (для метрик и системных логов)

📌 Шаг 2: Понимаем структуру лога
Типичная запись в логе содержит:
[2024-02-20 14:30:45] ERROR [app.controller] Status 500: NullPointerException in UserService.java:124
Разбираем по частям:
1. Дата и время (2024-02-20 14:30:45) - когда произошла ошибка
2. Уровень логирования (ERROR) - насколько всё плохо:
- DEBUG/TRACE - техническая информация для разработчиков,
- INFO - обычные события (например, «Пользователь залогинился»),
- WARN - потенциальная проблема, но приложение работает,
- ERROR - критическая ошибка (нужно чинить)
- FATAL/CRITICAL - самая высокая степень критичности (срочно чинить в первую очередь)
3. Источник (app.controller) - где случилась ошибка (класс/модуль)
4. Сообщение (NullPointerException in UserService.java:124) - суть ошибки и строка кода

🛠 Шаг 3: Как искать причину ошибки?
1. Ищем stack trace (список вызовов функций, которые привели к определенной точке в программе, например, к возникновению ошибки)
Пример:
java.lang.NullPointerException: Cannot invoke "User.getName()" because "user" is null
at com.example.UserService.getProfile(UserService.java:124)
at com.example.UserController.showProfile(UserController.java:45)
Что важно:
- Первая строка - тип ошибки (NullPointerException) и её описание
- Следующие строки - «путь» вызова методов (где началась ошибка и как она распространялась)

2. Анализируем контекст
Ошибка может не иметь очевидной причины. Проверьте:
- Что происходило перед ошибкой? (логи за 5-10 секунд до сбоя)
- Были ли похожие ошибки раньше? (поиск по логам)

3. Используем фильтры
Если логов много, сужаем поиск:
grep "NullPointerException" error.log (только ошибки этого типа)
grep -A 5 -B 5 "ERROR" app.log (+5 строк до/после ошибки)

💡 Шаг 4: Частые ошибки и как их читать
1. NullPointerException (Java)
Проблема: Обращение к объекту, который null
Что проверить:
- Передавались ли все обязательные параметры в метод?
- Вернула ли БД null вместо объекта?

2. 500 Internal Server Error
Проблема: Ошибка на сервере
Что проверить:
- Логи сервера (например, nginx или tomcat)
- Не упала ли БД или внешний API

3. ConnectionTimeout
Проблема: Сервер не ответил за отведённое время
Что проверить:
- Доступен ли сервер? (ping или telnet)
- Не перегружен ли он? (логи нагрузки CPU/RAM)

Автор: Aleksandra Primako, QA Engineer в 2V Modules

у вас такое практикуют? 😁

Это база! Рассказываю о бесплатных функциях Google Календаря, которые упростят вашу жизнь

Google-календарь — это не просто место, где удобно записывать личные и рабочие дела. А ещё и мощный инструмент, который упростит вашу жизнь. Поделюсь моими любимыми функциями.

Читать

Почему автоматизаторы не заменят QA?

Когда я только начинал в автоматизации, казалось, что скоро автотесты заменят всех QA. Зачем вручную проверять, если можно написать код который быстрее и надёжнее (что не скажешь про фронтовые тесты).

Эта тема много где бурно обсуждалась и начинающим QA советовали сразу погружаться в автоматизацию. Но побывав на 4х разных проектах, везде с разными QA, решил написать свое мнение из увиденного.

Автотесты хороши, когда чётко знаешь, что и как должно работать. Но они не чувствуют, что "что-то не так" в поведении. Автотест - это как робот-пылесос - отлично справляется с рутиной, но если где-то пролилось кофе - зовите человека.

Мануальщики - не кнопкодавы 😄
Хороший мануальщик - это не тот, кто просто "щёлкает по кнопочкам". Это тот, кто:
- умеет быстро находить баги там, где их не ждут,
- знает продукт вдоль и поперёк,
- ловит непредсказуемые сценарии и нестандартное поведение,
- сопровождает фичу до релиза.
И что самое важное - делает это в моменте, гибко, по ситуации.

Где автоматизация нужна?
Автотесты идеальны там, где:
- надо проверять одно и то же 100 раз (регресс, smoke),
- важна скорость и повторяемость (CI/CD),
- высокая цена ошибки, и нужен гарантированный результат.
Например, перед продом - тесты пробежались, старый функционал не сломан, всё зелёное - спокойно катимся.

Где без QA - никуда? Почти везде! Например:
- Исследовательское тестирование. Когда надо "поиграться" с новой фичей и посмотреть, как она вообще себя ведёт.
- UX-тестирование. Автотест не скажет: "а вот тут неудобно, и кнопка непонятная".
- Быстрая проверка бага с прода.
- Тестирование сложных визуальных сценариев. Привет, drag’n’drop, канвасы, таблицы и карты.

Это разные роли, а не борьба
- QA - это глаза и интуиция проекта. Это первый человек, кто скажет: "Ребят, кажется, пользователю тут будет неудобно".
- AQA - это защитник от регрессий и "уже проверенных" багов. Он покрывает логику кодом и не даёт продукту откатиться назад.
Это не замена, а синергия.
Это как повар и посудомоечная машина - ты можешь ускорить процесс, но без человека вкусный ужин не получится.

Как жить вместе?
У нас сейчас на проекте работает связка:
- QA исследуют, проверяют сложные кейсы, общаются с бизнесом.
- AQA покрывают всё, что можно автоматизировать: smoke, регресс, критичные пути.
Мы делимся знаниями, вместе пишем тест-кейсы, вместе рефачим автотесты, если вдруг нужно. И это работает.

И пока продукт делают люди для людей - ручное тестирование будет жить. А автоматизация - это не замена ручного тестирования. Это просто другой инструмент. Она рядом, чтобы не отвлекать QA на рутину и дать им возможность увидеть больше. 😊

Автор: Сергей Александров, QA Automation Engineer в AK Bars Digital

о, это я

Хороших выходных!

и не говорите, что работы нету 😁

❓Вопросы работодателю на собеседовании, шпаргалка для QA-инженера

Сильные кандидаты не только отвечают, но и задают вопросы. Этот список поможет быстро понять продукт, процессы и ожидания от роли. Сохраните и возьмите с собой на следующее интервью.

▫️Про продукт и пользователей
- Кто ключевые пользователи продукта и их главные сценарии?
- Какие метрики продукта сейчас важнее всего (активация, ретеншн, конверсия)?
- Как принимаются решения о фичах: на основе данных, исследований, запросов клиентов?

▫️Про процессы разработки и тестирования
- Какой процесс разработки (Scrum/Kanban/гибрид)? Длина спринта?
- Когда и как QA подключается к задаче: на этапе требований, дизайна, планирования?
- Есть ли Definition of Ready/Done для задач и багов?

▫️Про качество и метрики
- Какие метрики качества вы отслеживаете (defect leakage, escape rate, MTTR, флейки, покрытие)?
- Есть ли цель по снижению багов на проде и как её измеряете?
- Как анализируете регрессии и инциденты (post-mortems, RCA)?

▫️Про релизы и окружения
- Как часто релизитесь и есть ли релизный календарь?
- Сколько стендов (dev/test/stage/prod) и насколько они похожи на prod?
- Кто и как может откатить релиз? Есть ли фича-флаги/канареечные выкладки?

▫️Про автоматизацию и инструменты
- Где проходит граница между ручным и авто-тестированием?
- Какие стеки используете (Selenium/Playwright/Appium, CI/CD, отчётность, мониторинг)?
- Что считается «готовой» автотестовой задачей (стандарты, ревью, покрытие)?

▫️Про баги и приоритизацию
- Как приоритизируете дефекты (S1–S4/P0–P3)? Кто финально решает «критичность»?
- Как быстро исправляются S1/S2? Есть ли SLA/OLA по реакциям?
- Как боретесь с флейками и «битой» регрессией?

▫️Про роль, ожидания и рост
- Как выглядит успех на 30/60/90 дней для этой роли?
- С чем я приду в первый спринт? Какие 2–3 приоритеты?
- Есть ли менторство, бюджет на обучение/сертификации, путь роста (IC/Lead)?

▫️Про команду и культуру
- Как устроено взаимодействие QA с продактом, дизайном, бэком/фронтом, DevOps?
- Как дают обратную связь и как часто проходят 1:1?
- Как команда относится к долгам: техдолг, тестдолг, документация?

▫️Про оффер и условия (уместно на финальном этапе)
- Смена формата работы (офис/гибрид/удалёнка), график, овертаймы и компенсация за них.
- Испытательный срок, грейд/вилка, бонусы, ДМС/оборудование.
- Процесс онбординга и кто будет моим «buddy» в первые недели.

🚩 Красные флаги
- Нет тестовых окружений, релизы «по ночам», откаты «вручную».
- Отсутствие метрик качества и пост-мортемов («просто чиним»).
- QA подключается только «в конце», нет времени на регрессию.
- «Автотесты есть», но никто не может показать отчёты/стабильность.

🍭 Мини-скрипт в конце интервью
«Спасибо за ваше время. Есть ли что-то в моём фоне, что вызывает сомнения? Я буду рад прояснить сейчас».
Если ответ "да", то вы получили шанс закрыть гештальт сразу. Если "нет", то мягко уточните следующие шаги и сроки обратной связи.

Источник: Владлен Цыганенко

типичный понедельнки)

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

🇬🇧 Обучение на английском без лекций — с решением реальных IT-задач в мини-команде, как на настоящем IT-проекте.
🇺🇸 4-месячная интернатура в американской IT-компании.
🇨🇦🇺🇸🇳🇱🇵🇱🇦🇹🇭🇺🇭🇷🇷🇸🇨🇾🇮🇱🇦🇪🇬🇪🇦🇲🇰🇿🇰🇬🇦🇺 — страны, в IT-компаниях которых работают выпускники.

Конкурс 5 человек на место.
Бесплатно пройди углубленный курс-профориентацию в IT по коду GOD

Новый сезон конференции Podlodka QA Crew пройдет с 1 по 5 сентября. В фокусе — инструменты, которые делают тестирование быстрее, качественнее и удобнее.

В программе:

💡Как раскрыть потенциал Postman и ускорить обратную связь — вместе с Ариной Ладесовой (Payler).

🪄Внедрение ИИ для генерации тестов без лишней боли — с Натальей Петровской.

📱Современные инструменты мобильного тестировщика — практические кейсы от Елены Фёдоровой (Garage Eight).

🔍 Observability автотестов и мониторинг — с Кириллом Ивлиевым (Работа.ру).

Знания, которые легко применять в работе!

🔗 Подробнее и регистрация — https://podlodka.io/qacrew

🐳 Docker для тестировщиков
Источник

📚 Что такое Docker?
Docker - это платформа для контейнеризации приложений.
Контейнер - это легковесная виртуальная «коробка», куда упакованы:
- Код приложения
- Библиотеки
- Настройки окружения

В отличие от виртуальных машин, контейнеры не эмулируют всю ОС, а используют ядро хоста, что делает их быстрыми и компактными.

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

❓Зачем Docker тестировщику?
1. Идентичное окружение на всех этапа
Проблема:
«На моём ноуте тесты проходят, а на CI/CD падают!»
Решение:
Docker гарантирует, что тесты запускаются в одинаковой среде (версии Python/Java, БД)

2. Быстрый подъем инфраструктуры
Пример:
Вместо ручной установки PostgreSQL + Redis + Kafka:
docker-compose up -d

3. Тестирование в изоляции
- Можно запускать параллельные тесты в разных контейнерах
- Тесты не влияют на основную систему (например, не засоряют БД)

4. Эмуляция продакшена
- Тестирование на точной копии продакшен-окружения
- Проверка конфигов, переменных среды, сетевых правил

👁 Ключевые концепции Docker
1. Образ (Image)
Шаблон для создания контейнеров

2. Контейнер
- Изолированная «коробка» с программой внутри (например, с вашим тестовым фреймворком или базой данных)
- Можно создать/остановить/удалить

3. Dockerfile
Инструкция для сборки образа

4. Docker Compose
Инструкция для управления несколькими сервисами (БД, кеш, API)

Почему Docker стоит освоить?
▫️Стандартизация - больше никаких «на моей машине работает»
▫️Экономия времени - окружение разворачивается за минуты
▫️Гибкость - можно тестировать разные версии ПО

Docker - не панацея, но незаменимый помощник в арсенале современного тестировщика 🛠

🔥 SQL для тестировщиков: 5 полезных запросов
Источник

SQL - это язык для работы с реляционными базами данных (например, MySQL, PostgreSQL, Oracle). SQL является отличным инструментом для проверки целостности данных, анализа связей между таблицами и поиска скрытых багов.

1. Возвращаем набор данных из базы (SELECT)
Когда использовать: После регистрации, создания заказа и т.д. - проверяем, что пользователь/заказ создался, смотрим на корректность и полноту данных

Найти пользователя по email:

SELECT * (Выбираем все поля записи)
FROM users (Из таблицы users)
WHERE email = 'test@example.com'; (Где email равен указанному значению)

Проверить последний заказ:

SELECT * (Выбираем все поля записи)
FROM orders (Из таблицы orders)
ORDER BY created_at DESC (Сортируем по дате создания (новые сначала))
LIMIT 1; (Ограничиваем результат одной записью)

2. Фильтрация данных по условиям (WHERE)
Когда использовать: для поиска и анализа ошибочных записей, для выборочной проверки данных по определённым критериям

Найти неоплаченные заказы старше 3 дней:

SELECT * (Выбираем все поля заказов)
FROM orders (Из таблицы orders)
WHERE status = 'unpaid' (Где статус "неоплачен")
AND created_at < NOW() - INTERVAL 3 DAY; (И дата создания старше 3 дней от текущего момента)

Найти пользователей без подтвержденного email’a:

SELECT id, email (Выбираем только ID и email)
FROM users (Из таблицы users)
WHERE email_verified = false; (Где email не подтверждён)

3. Проверка количества записей (COUNT)
Когда использовать: для проверки массовых операций

Сколько пользователей зарегистрировалось сегодня:

SELECT COUNT(*) (Считаем общее количество записей)
FROM users (В таблице users)
WHERE DATE(created_at) = CURRENT_DATE; (Где дата регистрации = текущий день)

4. Обновление тестовых данных (UPDATE)
Важно! Используйте только в тестовых базах и всегда делайте резервную копию перед массовыми изменениями

Сбросить пароль тестового пользователя:

UPDATE users (Обновляем таблицу users)
SET password = 'test123' (Задаём новое значение для поля password)
WHERE email = 'test@example.com'; (Условие: только для пользователя с этим email)

Изменить статус заказа:

UPDATE orders (Обновляем таблицу orders)
SET status = 'completed' (Меняем статус на "completed")
WHERE id = 12345; (Условие: только заказ с ID 12345)

5. Удаление тестовых данных (DELETE)
Осторожно! Используйте только в тестовых базах и всегда делайте резервную копию перед массовыми изменениями. Всегда сначала делайте SELECT с тем же условием

Удаление тестовых заказов:

DELETE FROM orders (Удаляем записи из таблицы orders)
WHERE user_id IN ( (Где user_id соответствует…)
 SELECT id FROM users (…ID из таблицы users)
 WHERE email LIKE '%test%' (…для email с подстрокой "test»)
);

🔧 Как тренироваться?
На помощь приходят бесплатные тренажеры, например:
▫️https://sqlbolt.com/
▫️https://sqlzoo.net/
▫️https://sql-academy.org/ru/trainer

👁‍🗨 Agile vs Waterfall
Источник

Всем привет! Давайте разберёмся, в чём разница между Agile (Scrum/Kanban) и Waterfall, и как это влияет на нашу работу.

🌊 Waterfall («Водопад»)

Как работает:
1. Этапы идут строго друг за другом (как вода в водопаде):
Требования → Дизайн → Разработка → Тестирование → Внедрение → Поддержка
2. Тестирование - в самом конце (когда весь продукт уже готов)

Плюсы для QA:
▫️Чёткий план (знаем все требования заранее)
▫️Участники проекта, не задействованные на определенной фазе, могут переключаться на другие проекты
▫️Подходит для госпроектов, систем, где нельзя менять требования и для модернизации уже существующих проектов

Минусы:
▫️Если баг найден поздно - исправлять дорого
▫️Нет гибкости

🔄 Agile (Scrum, Kanban)

Как работает:
1. Разбиваем проект на маленькие кусочки (итерации по 2-4 недели)
2. Тестируем каждую фичу сразу (не ждём конца разработки)

Scrum
- Есть спринты (обычно 2 недели)
- Каждый день daily (короткая ежедневная встреча команды разработки, которая проходит в одно и то же время. На ней каждый участник команды отвечает на вопросы «Что было сделано вчера? Что буду делать сегодня? Есть ли что-то, что может помешать работе над задачами спринта?»)
- Тестировщик встроен в команду (не отдельный «отдел»)

Kanban
- Нет спринтов - гибкий поток задач
- Задачи висят на доске, их прогресс наглядно виден по колонкам статусов (To do → In Progress…)

Плюсы для QA:
▫️Быстрая обратная связь
▫️Раннее вовлечение в процесс
▫️Постепенное тестирование

Минусы:
▫️Нужно быстро адаптироваться (требования могут меняться)
▫️Много рутины (ежедневные митинги, ретроспективы)

⚖️ Что лучше для тестировщика?

- Скорость: Waterfall - медленно, Agile - быстро
- Гибкость: Waterfall - нет, Agile - да
- Риски: Waterfall - баги находятся поздно, Agile - ловим баги в процессе разработки
- Документация: Waterfall - много, Agile - минимум

отличная идея)

🎱 HTTP-коды и методы: шпаргалка для тестировщика - Часть 1

Каждый пользователь хоть раз в жизни сталкивался с ситуацией, когда заходит на сайт, а его встречает ошибка 404, сразу мысль «Ну, значит что-то не то с сайтом». Давайте поглубже разберемся в теме и посмотрим на другие ошибки, которые могут быть неочевидны для пользователей, но для нас являются важными для контроля состояния и работы сайта.

Основные HTTP-методы

1. GET - «Дай мне данные» (например, загрузка страницы)
Не требуется тело запроса!
- Пример: GET /api/users → 200 OK (получаем список пользователей)
- Ошибка: GET /api/page-not-exist → 404 Not Found (пытаемся получить что-то со страницы, которой не существует)

2. POST - «Создай что-то новое/Отправь данные» (отправка формы, регистрация)
Тело запроса используется!
- Пример: POST /api/users body:{"name": "Alex", "id": 1} → 201 Created (создание нового пользователя)
- Ошибка: POST /api/users (без тела запроса) → 400 Bad Request

3. PUT - «Полностью обнови данные» (замена всей записи)
Тело запроса используется!
- Пример: PUT /api/users/1 {name: "Alex Black"} → 200 OK
- Ошибка: PUT /api/users/999 (несуществующий ID) {name: "Alex Black"} → 404 Not Found

4. PATCH - «Частично обнови данные» (измени только имя)
Тело запроса используется!
- Пример: PATCH /api/users/1 {name: "Alex Patched"} → 200 OK
- Ошибка: PATCH /api/users/1 [name: Alex Patched] (неправильный формат данных, мы ожидали JSON в body) → 400 Bad Request

5. DELETE - «Удали ресурс»
Не требуется тело запроса!
- Пример: DELETE /api/users/1 → 204 No Content (если удаление выполнено успешно, но нет необходимости возвращать тело ответа)
- Ошибка: DELETE /api/users/999 → 404 Not Found

6. HEAD - «Покажи только заголовки» (как GET, но без тела)
Не требуется тело запроса!
- Пример: HEAD /api/users → 200 OK (но тело пустое)
- Ошибка: HEAD /api/page-not-exist → 404 Not Found (пытаемся получить заголовок страницы, которой не существует)

7. OPTIONS - «Какие методы доступны?» (запрашивает информацию о доступных методах и опциях для конкретного ресурса)
Не требуется тело запроса!
- Пример: OPTIONS /api/users → 200 OK (в заголовке Allow: GET, POST, PUT)

8. TRACE - «Покажи путь запроса» (используется для диагностики, возвращает полученный запрос)
Не требуется тело запроса!
- Пример: TRACE /api/users → 200 OK (в теле ответа - копия вашего запроса)
- Ошибка: TRACE /api/security-page → 403 Forbidden (метод запрещен из-за соображений безопасности)

P.S. Самый редкий зверь в API-тестировании - это TRACE. Встречали его когда-нибудь в работе?