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

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 "http://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.

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

#буст

🦊 Мой первый мобильный тест

Когда мне впервые дали на тест мобильное приложение, я честно думал: «Ну чё там, приложение как приложение. Потыкал кнопки, посмотрел, не крашится — и готово.»

Ага, держи карман шире.

🟣 Вот как было:

Начал с Android — вроде всё норм. Только кнопка чуть съехала. Ну, не критично же.

Потом включил iOS — и там начался цирк:

• кнопки налезают друг на друга,

• половина текста не помещается,

• скролл работает через раз,

• и на каком-то старом iPhone приложение просто решило: «я больше не с вами», и умерло.

До полуночи я бегал между эмуляторами, реальными телефонами, снимал скрины, записывал видео, заводил баги. Голова кипела. Хотелось спросить у вселенной: «Зачем столько разных экранов?! Кто вообще придумал адаптивность??»

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

И я понял:

Мобильное тестирование — оно живое. Иногда бесит, часто утомляет, но почти всегда увлекает. Это как быть таким digital-детективом. И если не ждать идеальности — даже очень прикольно.

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

Пишите, поддержим друг друга в этом безумии 🤗

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

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

📓 Автоматическое заполнение форм с помощью JavaScript в браузере

Когда вы тестируете веб-приложение с многочисленными формами и полями ввода, часто нужно вручную заполнять их для тестов. Чтобы сэкономить время, вы можете использовать простой JavaScript-код для автоматического заполнения всех полей формы на странице прямо в браузере.

Как это работает:

1️⃣ Открываем DevTools в браузере (клавиша F12).

2️⃣ Переходим на вкладку Console.

3️⃣Копируем следующий код и нажимаем Enter:

(function() {
var inputs = document.querySelectorAll('input, select, textarea');
inputs.forEach(function(input) {
if (input.type === 'text' || input.type === 'textarea') {
input.value = 'Test Value'; // Заполняем текстовые поля
} else if (input.type === 'email') {
input.value = '[email protected]'; // Заполняем email
} else if (input.type === 'password') {
input.value = 'TestPassword123'; // Заполняем пароль
} else if (input.type === 'checkbox') {
input.checked = true; // Отмечаем чекбоксы
} else if (input.type === 'radio') {
input.checked = true; // Выбираем радиокнопки
} else if (input.tagName.toLowerCase() === 'select') {
input.selectedIndex = 1; // Выбираем первый доступный элемент в списке
}
});
})();

Что происходит в коде:

📍 Этот код перебирает все элементы формы на странице (`input`, textarea, `select`).

📍 Для текстовых полей, полей ввода email, паролей, чекбоксов и радиокнопок он автоматически заполняет соответствующие данные.

📍 Для выпадающих списков (select) выбирается первый элемент.

❗️ Если на странице есть динамически изменяющиеся элементы (например, поля, которые появляются при выборе определенной опции), вы можете добавить задержку или использовать MutationObserver для отслеживания изменений.

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

#буст

😎 ИИ-тестировщик: ожидания и реальность

ИИ в тестировании звучит как магия: всё автоматизирует, ошибки сам чинит, релизы ускоряет. Но на деле — всё не так гладко. Разберёмся, где он реально помогает, а где пока только мешает.

Что он уже умеет:

➡️ Дописывать автотесты по сценарию — экономит время, если правильно натренирован.

➡️ Создавать новые тестовые модели — на основе уже написанных.

➡️ Расширять тест-покрытие — подмечает нестандартные кейсы, которые человек может упустить.

Идеально было бы: дал ИИ техзадание — получил продукт с тестами.

В реальности: ИИ накидал тест, ты час разбираешься, что он вообще имел в виду.

Какие подводные камни:

🔘 Без опыта — лучше не лезь: ИИ может нагенерить кучу мусора.

🔘 Эксперта всё равно надо: чтобы проверять, допиливать, объяснять ИИ, что не так.

🔘 Облака — это риск: многие ИИ-сервисы зарубежные, а значит — возможны утечки.

ИИ — полезный инструмент, если умеешь с ним работать. Но просто так его внедрить и сэкономить — не выйдет. Придётся учиться, настраивать и думать головой.

🔗 Оригинал статьи

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

#свежак

Хорошо, что сегодня выходной. Да, друзья? 👍

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

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

⚙️ Подборка полезного по Cypress

📍 Полное руководство по Cypress

Подробное введение в Cypress: установка, написание тестов, работа с асинхронным кодом и интеграция с CI/CD.

📍 Cucumber в Cypress: Пошаговое руководство

Интеграция Cucumber с Cypress для написания тестов в стиле BDD с использованием Gherkin.

📍 Cypress Tutorial Full Course | Learn Cypress in 5 Hrs

Полный курс по Cypress на английском языке, охватывающий основные аспекты работы с инструментом.

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

#свежак