🖥 Метрики эффективности сотрудника

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

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

Иногда стоит пересмотреть, как мы оцениваем эффективность. Потому что не все цифры отражают суть.

🔗 Подробности в статье

🐸 Библиотека джависта

😮 Что делать, если не появился билд

Ситуация: вы, как тестировщик, ожидаете новый билд на тестовом стенде, но его нет. Вместо паники предлагаем вам чек-лист для выявления и устранения проблемы.

➡️ Убедимся, что билд существует

📍 Проверь статус коммита: зайди в Git и посмотри, был ли пуш

git log --oneline

📍 Найди последний коммит от разработчика.

📍 Проверь, сработала ли сборка в CI:

открой GitLab/Jenkins/GitHub Actions ⏩ найди pipeline ⏩ проверь запущен ли он и как завершился ⏩ есть ли ошибки на этапе build или test

➡️ Посмотрим, прошёл ли билд автотесты

📍 CI мог завалиться на тестах: найди логи тестов

test:
script:
- pytest tests/

📍 Проверь были ли фейлы.

📍 Проверь, не отключены ли тесты: иногда девы временно комментируют автотесты. Обрати внимание на suspicious коммиты.

➡️ Убедимся, что билд вообще разворачивался

📍 CI должен иметь стадию deploy

deploy:
script:
- scp dist/ user@qa-server:/var/www/

📍 Если нет этой стадии, значит, билд никуда не уехал.

📍 Если есть ошибка на этом этапе, проверь доступы к серверу или SSH-ключи.

➡️ Найдем билд вручную

📍 Билды могут лежать:

• В CI-системе: артефакты пайплайна (в GitLab: “Job artifacts”)

• В артефакт-хранилищах: Nexus, Artifactory

• В облаке: AWS S3, GCP

• На сервере:

ssh user@qa-server
ls /var/www/

➡️ Если билда нет — задаем правильные вопросы

📍 Разработчику:

• «Ты точно запушил код?»

• «Билд собирался локально или через CI?»

• «CI зелёный? Где логи?»

📍 DevOps-у:

• «CI не может задеплоить билд. Что с сервером?»

• «Есть ли ограничения в пайплайне?»

🪔 Лайфхак

Добавь уведомления в Slack/Telegram о статусе билда, чтобы отслеживать статус.

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

#буст

Тестировщики!

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

➡️Поддержать канал: https://t.iss.one/boost/testerlib

🧪🎮 Баг или Эндермен

Кажется, багов в проекте становится больше… или это зомби в шахте? Ты уже открыл DevTools, но всё равно кликаешь по пиксельным дверям.
Ты видишь баг-репорт, а читаешь его как «записки в дневнике игрока на хардкоре».

Если regression test превратился в рейд на деревню, а Allure-отчёты выглядят как таблица зачарований — время пройти тест.

👉 Проверь, не ты ли заражён Minecraft’ом больше, чем билд CI

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

#междусобойчик

😑 Фильтруем логи как профи с командой grep

Grep ищет строки по шаблону в текстовых файлах. Звучит просто, а работает — мощно.

Как можно использовать:

➡️ Для поиска ошибок в логе:

grep "ERROR" application.log

➡️ Для поиска процессов по имени:

ps aux | grep "my_app"

➡️ Для рекурсивного поиска всех TODO в проекте (игнорируя регистр):

grep -ri "TODO" ./src

Какие флаги стоит знать:

📍 -i — игнорирует регистр

📍 -r — ищет во всех подпапках

📍 -n — показывает номер строки

Когда лог — это тысячи строк мусора, grep помогает быстро найти нужное. Меньше времени на ручной анализ — больше точности в баг-репорте и стабильности в продукте.

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

#буст

Реальному опыту сеньора уже никто не удивится 🥱

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

#развлекалово

🌸 Чек-лист для тестирования API

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

1️⃣ Корректность структуры данных

• Сопоставляем структуру данных с API-спецификацией

• Валидируем обязательные и необязательные поля

• Сверяем типы данных с ожидаемыми

2️⃣ Тестирование POST-запросов

• Отправляем запрос с полным набором валидных данных и отслеживаем корректный результат

• Отправляем минимально необходимый набор данных для успешного создания

• Имитируем отправку без обязательных полей и получаем соответствующую ошибку

• Подаём запрос без тела и фиксируем корректную обработку ошибки

• Подставляем как корректные, так и ошибочные данные для проверки валидации

• Отправляем пустой JSON и анализируем ответ

• Проверяем автозаполнение даты создания объекта

3️⃣ Тестирование GET-запросов

• Запрашиваем список при отсутствии данных и получаем пустой результат

• Получаем список с данными и сверяем корректность

• Прогоняем пагинацию с limit и offset, включая пограничные значения

• Передаём некорректные параметры и анализируем ошибки 400

• Выполняем запрос по валидному ID и убеждаемся в правильности возвращаемых данных

• Подаём несуществующий ID и ожидаем 404

• Используем невалидный формат ID и получаем ошибку 400.

4️⃣ Тестирование PUT-запросов

• Обновляем объект с валидными данными и отслеживаем результат

• Имитируем обновление несуществующего объекта и получаем 404

• Отправляем некорректный ID и получаем 400

• Проверяем валидацию при обновлении с ошибочными значениями

• Обновляем частично — передаём только нужные поля и убеждаемся в корректной обработке

5️⃣ Тестирование DELETE-запросов

• Удаляем существующий объект и получаем подтверждение

• Повторно удаляем уже удалённый объект и фиксируем ошибку

• Пытаемся удалить несуществующий объект и получаем 404

• Отправляем невалидный ID и убеждаемся в корректной ошибке

• Удаляем объект и заново создаём его с теми же уникальными полями — исключаем конфликт

6️⃣ Проверка статусов ответов

• Отслеживаем корректность возвращаемых статусов (200, 201, 204, 400, 401, 403, 404, 500 и т.д.) в зависимости от сценария

7️⃣ Проверка всех возможных ошибок

• Симулируем сетевые сбои, таймауты и передаём некорректные данные — отслеживаем поведение API

8️⃣ Специфичные проверки для сложной логики

• Проверяем работу сложных сценариев, зависимостей и бизнес-правил (например, нельзя удалить связанную сущность)

9️⃣ Тестирование безопасности

• Проверяем доступ к защищённым ресурсам только при наличии валидной авторизации

• Отправляем запросы с просроченными, отсутствующими и поддельными токенами — анализируем реакции API

Сохраняй себе, пригодится 📎

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

#буст

😎 Как войти в айти

Пошаговый план для старта:

➖ Изучи основы тестирования

Понимание жизненного цикла разработки ПО, видов тестирования и техник тест-дизайна — твой фундамент. Начни с книги «Тестирование Дот Ком» Романа Савина.

➖ Развивай технические навыки

Освой базовые SQL-запросы для работы с базами данных и основы одного из языков программирования (например, Python). Это расширит твои возможности в тестировании.

➖ Практикуйся на реальных проектах

Участвуй в open-source проектах на GitHub или тестируй любимые приложения. Создавай отчеты о найденных багах — это станет твоим портфолио.

➖ Пройди специализированные курсы

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

➖ Готовься к собеседованиям

Изучи типичные вопросы, попрактикуйся в рассказе о себе и своих навыках. Умение презентовать себя не менее важно, чем технические знания.

Подробную роадмпапу можно скачать из нашего прошлого поста 🌸

P.S. Если хотите задать вопрос, заполните нашу гугл-форму. Это займет 5 минут.

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

#междусобойчик

🕸️ Сети: что посмотреть, чтобы не плавать

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

➡️ Сети для тестировщика. Базовые знания сетей — видео с практическими примерами, раскрыты такие моменты, как mac-адрес, ip-адрес, DNS, DHCP и другие.

➡️ Введение в компьютерные сети для начинающих — типы, термины, модель OSI, VLAN и др.

➡️ URL, URN, IP address, DNS server, cash and cookies

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

#буст

📌 Новый инструмент для измерения покрытия API-тестов

Вышел полезный инструмент для QA-специалистов, работающих с автотестами на Python — swagger-coverage-tool. Он позволяет измерять покрытие API-тестов по спецификации Swagger (OpenAPI) и видеть, какие части контракта реально проверяются в ходе тестирования.

Что умеет:

➡️ Поддержка библиотек httpx и requests

➡️ Простая интеграция через декораторы

➡️ Поддержка микросервисной архитектуры (отдельное покрытие по каждому сервису)

➡️ Генерация отчётов в формате HTML и JSON

➡️ Удобная визуализация покрытия по методам, эндпоинтам, статус-кодам и параметрам

Что фиксирует:

1. Какие запросы были выполнены;

2. Какие статус-коды и query-параметры были покрыты;

3. Была ли проверка тела запроса и ответа;

4. Динамику покрытия по времени.

🔗 Подробная статья с настройкой

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

#свежак

Рабочий день в пятницу би лайк 🌟

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

#развлекалово

🔥 Тестировщик без кода — герой или балласт

2025 год, а ручное тестирование всё ещё живёт.
Рядом — автоматизация, CI/CD, нейросети. Но споры не утихают.

Что говорят автоматизаторы:

Без кода ты не тестировщик, а бета-тестер с зарплатой. Хочешь быть профи — учи Python, JS, хоть что-то!

Что говорят мануальщики:

Я ловлю баги, которые твой код даже не увидит. У меня чутьё. У тебя — flaky-тесты.

➡️ Давайте разложим по полочкам:

Ручное тестирование — это:

• Быстро протестировать фичу, которую вчера придумали в коридоре.

• Симулировать хаос реального пользователя, а не идеальный happy-path.

• Лучше понимать продукт, чем просто дергать API и ждать 200 OK.

➡️ Автоматизация — это:

• Один клик — и 1000 тестов в CI.

• Регрессия не проскочит, если покрытие есть.

• Без неё ты тонешь в рутине — ручками ничего не успеть.

Так где правда?

✏️Пишите, горите, спорьте. Только без if (QA != человек) { бан(); }

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

#междусобойчик

📣 Дайджест материалов за неделю

🔘 Шпаргалка по сетевой модели OSI: поможет быстро вспомнить, какой уровень за что отвечает

🔘 Инструмент недели: Zephyr для Jira — что умеет, в чем польза, рекомендации по внедрению

🔘 Промпт: как обнаружить проблемы в интерфейса, которые могут быть не так очевидны

🔘 Как составлять тест-кейсы с использованием Gherkin-нотаций: примеры теста и рекомендации

🔘 Чек-лист для тестирования API

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

#свежак

🌸 try-catch в Java: обработка исключений в тестах

Конструкция позволяет избежать аварийного завершения программы и обеспечить корректную обработку ошибок.

➡️ Что такое try-catch:

Блок try содержит код, который может вызвать исключение. Если в этом блоке возникает ошибка, управление передаётся в соответствующий блок catch, где можно обработать исключение.

Пример:

try {
int[] numbers = {1, 2, 3};
System.out.println(numbers[5]); // Попытка доступа к несуществующему индексу
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println("Ошибка: выход за пределы массива.");
}

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

➡️ Зачем использовать:

• Предотвращение сбоев: обработка исключений позволяет программе продолжить работу даже при возникновении ошибок.

• Улучшение читаемости: явная обработка ошибок делает код более понятным и поддерживаемым.

• Обработка различных типов ошибок: можно использовать несколько блоков catch для обработки разных типов исключений.

➡️ Дополнительные возможности

• Блок finally: код в этом блоке выполняется всегда, независимо от того, возникло ли исключение или нет. Это полезно для освобождения ресурсов, например, закрытия файлов или соединений.

try {
// Код, который может вызвать исключение
} catch (Exception e) {
// Обработка исключения
} finally {
// Код, который выполнится в любом случае
}

• Множественные исключения в одном блоке catch: начиная с Java 7, можно обрабатывать несколько типов исключений в одном блоке, разделяя их вертикальной чертой |.

try {
// Код, который может вызвать исключение
} catch (IOException | SQLException e) {
// Обработка IOException и SQLException
}

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

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

#буст

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

Middle QA Engineer (manual + automation java) — офис/удаленно (Новосибирск)

Тестировщик ПО / QA Engineer (стажер) — 90 000 - 140 000 ₽, удаленно (Москва)

Manual QA engineer — удаленно/Гибрид/Офис (Санкт-Петербург)

Middle QA Engineer (Fullstack) — от 180 000 до 220 000 ₽, удаленно (Нижний Новгород)

QA Engineer / Инженер по качеству — от 60 000 до 150 000 ₽, офис (Санкт-Петербург)

➡️ Еще больше топовых вакансий — в нашем канале QA jobs

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

#свежак

💡 Selenium шпаргалка: быстрый справочник по локаторам элементов

В этой шпаргалке собраны основные способы поиска элементов в Selenium: по ID, Name, XPath, CSS, LinkText и другим. Кратко, наглядно и по делу — удобно для практики и повторения при написании автотестов.

Сохраняй себе! ⬆️

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

#буст

🙃 Признаемся, что хотелось бы…

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

#развлекалово

🏃‍♀️ Тестирование веб-тайминг-атак

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

Как они работают:

➡️ Тайминг-атаки используют различия во времени отклика на запросы.

Например, если сервер медленнее обрабатывает запросы с определёнными данными, это может указывать на наличие этих данных в базе.

Пример:

➡️ На странице входа сервер может обрабатывать запрос с правильным паролем медленнее, чем с неправильным. Злоумышленник может использовать это время для анализа и получения доступа.

Как их тестировать:

1️⃣ Используйте Intruder для отправки запросов и анализа времени отклика. Если запрос с “admin” обрабатывается быстрее, это может быть уязвимостью.

2️⃣ Отслеживайте время отклика с помощью curl:

curl -w "Time: %{time_total}\n" -o /dev/null -s "https://example.com/login?user=admin&password=wrongpassword"


3️⃣ Применяйте специализированные инструменты, такие как Wbox, для автоматического поиска тайминг-уязвимостей.

Как защититься:

➡️ Обеспечьте равное время обработки запросов для скрытия различий.

➡️ Внедрите случайные задержки для маскировки.

➡️ Используйте веб-фаерволы для блокировки аномальных запросов.

➡️ Регулярно тестируйте на тайминг-уязвимости.

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

#буст

🎉🐙🐱 20 лет Git: все такой же необычный, все такой же великолепный

Легендарному Git стукнуло 20! Вспоминаем, как проект, который Линус Торвальдс называл «тупым менеджером контента», стал незаменимым инструментом для всех, кто хоть раз писал код или даже просто хранил файлы.

Погружаемся в историю, эволюцию и влияние Git на индустрию разработки.

➡️ Читать статью

🐸 Библиотека программиста

🐱 Промпт для проверки производительности системы при нагрузке

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

PROMPT:

Simulate 1000 simultaneous users attempting to log into the system. Ensure that the system responds within acceptable time limits (e.g., < 3 seconds). Monitor server load, database interactions, and UI response times during the simulation. The system should remain stable under this load, and there should be no failures or significant slowdowns.

Что это тестирует:

➡️ Проверяется, как система ведет себя при 1000 одновременных пользователей, пытающихся войти в систему.

➡️ Ожидается, что каждый запрос будет обработан за меньше чем 3 секунды.

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

➡️ Важно следить за состоянием сервера, взаимодействием с базой данных и временем отклика UI.

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

#буст