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

🔘 Как быстро заводить баг-репорты прямо в браузере

🔘 Инструмент недели: Fiddler в нагрузочном тестировании

🔘 Подборка подкастов от TestGuild: как сэкономить на автоматизации и не проиграть ИИ

🔘 Команда дня: npx playwright

🔘 Как бороться с “flaky tests” в автоматизации: гайд, как привести их в порядок

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

#свежак

😒 Тестировать в продакшене: гениальный ход или полный треш

Сколько раз вы слышали эту фразу:

«Да нормально, все уже проверили, давайте прямо на прод!”

А потом начинаются приключения.

➡️ Что говорят те, кто за тесты на проде:

— Тестировать на реальных данных — это честно. Никакая песочница не покажет тех фокусов, которые вытворяют живые пользователи.

— Быстрее увидеть баг — быстрее починить. А если сидеть ждать идеального теста — можно пенсию встретить.

— Всё равно сто раз всё не предусмотришь. Прод — лучший краш-тест.

➡️ Что думают те, у кого сработал инстинкт самосохранения:

— Один факап на проде — и тебе потом объясняться не только перед клиентами, но и перед начальством… и юристами.

— Пользователь не должен быть тестировщиком. Он пришёл зарабатывать/покупать/играть — а не ловить баги за тебя.

— Чистый релиз — как чистая совесть. И спится спокойнее.

❓ И вот главный вопрос: тестировать в проде — это смелость или безумие?

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

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

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

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

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

🙂 Как бороться с «flaky tests» в автоматизации

Автотесты шалят – то проходят, то падают. Вот гайд, как их привести в порядок раз и навсегда:

1️⃣ Выявляем «прыгающие» тесты

Собирайте статистику падений каждого автотеста в CI, отслеживайте процент флейкиности и отмечайте сценарии с частыми сбоями (например, более 5% падений за неделю).

2️⃣ Изолируем внешние зависимости

Заменяйте реальный API и сторонние сервисы на моки и стабы (WireMock, MockServer или MSW), чтобы сбои в сети или внешних системах не портил прогоны.

3️⃣ Укрепляем локаторы

Добавляйте в HTML специальные атрибуты, например:

Войти

и в тестах ищите элемент по ним:

driver.find_element(By.CSS_SELECTOR, "[data-test-id='login-submit']")

4️⃣ Применяем адаптивные ожидания

Лучше отказаться от sleep(5) и пользоваться явными ожиданиями:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

submit = WebDriverWait(driver, 10).until(
EC.element_to_be_clickable((By.ID, "submit"))
)

5️⃣ Используем ретраи осознанно

Добавляйте 1–2 повтора только к отмеченным flaky-тестам, чтобы сгладить случайные тайм-ауты, но при этом не скрывайте настоящие ошибки.

6️⃣ Мониторим и рефакторим

Настраивайте дашборд стабильности (Allure TestOps, ReportPortal), регулярно удаляйте устаревшие проверки и упрощайте сложные сценарии, чтобы со временем слово «flaky» пропало из вашего лексикона.

С вас ❤️ за полезную инфу!

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

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

📌 Команда дня: npx playwright codegen

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

npx playwright codegen https://example.com

➡️ Откроется браузер, и всё, что ты кликаешь — превращается в готовый код автотеста.

Чем полезно:

• Быстрый старт для E2E-тестов

• Ускоряет написание скриптов

• Удобно показать джунам, как это вообще работает

➡️ Поддерживает JavaScript, TypeScript, Python и C#. Так что, хочешь — пиши на чём угодно, хоть на эльфийском, если настроишь парсер.

P.S. Да, ты потом всё равно перепишешь этот автотест руками. Но начать — станет легче. А иногда «записал и отдал в CI» — это уже победа.

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

#буст

👊 Лучшие материалы по тестированию в одной подборке

Собрали топовые материалы, которые наши подписчики сохраняют чаще всего.

Эту подборку мы будем регулярно пополнять, поэтому сохраняйте тонну пользы, чтобы не потерять!

1. Копилка обучающих материалов для QA специалистов

2. Тренажёр для тестирования API

3. Тренажер «Треугольники»

4. Элементы интерфейса

5. Practice SQL

6. Чит-листы и шпаргалки для тестирования

7. Как тестировать WebSocket API в Postman

📈 Как «ленивая разработка» захватывает IT-рынок

Пока мы выстраиваем архитектуру, пишем тесты и спорим о лучших практиках, рынок всё активнее обживают те, кто вообще не пишет код. Low-code и no-code решения не просто живы — они становятся нормой для бизнеса.

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

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

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

😇 Подборка подкастов от TestGuild

➡️ Как оптимизировать автоматизацию и CI/CD — и при этом сэкономить

Если ты работаешь с Jenkins, GitHub Actions или вообще в DevOps-среде — это видео must-see.
Гаураф (чувак, которого уважают и за AI, и за автоматизацию) делится конкретными подходами, как навести порядок в пайплайнах, уменьшить затраты и не потерять в скорости или качестве.

📍 Что вы узнаете:

• как не платить лишнего за лицензии,

• как встроить безопасность в тестовую инфраструктуру,

• и как автоматизировать «по уму», а не «потому что модно».

➡️ Как AI меняет профессию тестировщика — с Джейсоном Арбоном

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

📍 Джейсон рассказывает:

• как ИИ-платформы сами пишут и выполняют тесты,

• почему автоматизация больше не про Selenium-скрипты,

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

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

#буст

Мы или не мы? 🥹

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

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

🔍 Инструмент недели: Fiddler в нагрузочном тестировании

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

Чем может помочь:

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

😗 Можно использовать для записи последовательности действий пользователя, которые потом адаптируются в скрипты для JMeter, Gatling, k6 и других инструментов. Это повышает точность моделирования поведения пользователей.

😗 Если при нагрузке сервер отвечает нестабильно или возникают ошибки, Fiddler помогает локализовать проблему: показывает точное содержимое запросов и ответов, HTTP-коды, время ответа, редиректы и пр.

😗 Многие системы используют авторизацию, сессионные токены, cookies. Fiddler показывает, как они передаются, что упрощает их интеграцию в нагрузочные скрипты.

Пример использования:

1️⃣ Запись пользовательского сценария:

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

• Сохраним сессию в формате .saz через меню File > Save > All Sessions.

2️⃣ Настройка скрипта для повторного воспроизведения:

• Откроем Fiddler Script Editor через Rules > Customize Rules.

• Вставим кастомный скрипт, который реализует команды load и run.

• Сохраним изменения и перезапустите Fiddler.

3️⃣ Выполнение нагрузочного теста:

• Откроем QuickExec (нажмите Alt+Q).

• Выполним команду load <путь к файлу .saz>, чтобы загрузить записанную сессию.

• Выполниим команду run <интервал в миллисекундах> <количество повторов>, чтобы начать воспроизведение запросов с заданным интервалом и числом повторений.

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

📍 Полезные материалы:

— Fiddler для тестировщика / Установка и настройка

— Fiddler Everywhere для тестировщика | Как тестировать API в Fiddler

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

#буст

💼🚫 Собес провален? 8 советов, как извлечь пользу из каждого отказа

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

Однако отказ — это всего лишь один из этапов в поиске работы и не стоит воспринимать его как конец света.

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

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

Когда сроки горят, а разработчиков не хватает

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

Решение проблемы — задействовать дополнительные ресурсы на аутсорсе или аутстаффе. Например, обратиться в Proglib. Да-да, мы запустили свою студию веб-разработки!

Что мы предлагаем:

• Опытные специалисты для аутстаффа (frontend, backend, DevOps, UI/UX, PM, BA) 

• Полноценная разработка проектов под ключ 

• Гибкое масштабирование команды под потребности клиента 

• Прозрачная коммуникация и регулярная отчетность

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

Заполните форму, чтобы ускорить свою разработку 👉 https://forms.yandex.ru/u/67e548a4eb614622efa0bcb2/

🐞 Как быстро заводить баг-репорты прямо из браузера

Эта инструкция помогает упростить и ускорить процесс: баги оформляются автоматически — с видео, логами и всей нужной информацией — буквально в пару кликов.

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

1️⃣ Устанавливаем расширение в браузер

Используйте специальные расширения, которые:

• записывают экран и шаги, которые мы выполняем

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

• фиксируют данные об окружении: браузер, язык, разрешение экрана

• формируют баг-репорт, который можно отправить сразу в Jira, Trello, GitHub или просто скопировать

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

➡️ Bird Eats Bug — очень удобное расширение, подходит и для ручного, и для регресса.
Оно работает прямо в браузере, не требует установки, записывает всё: экран, действия, логи, XHR-запросы, URL.

➡️ BugReplay — если нужно больше акцента на видео.
Также сохраняет сеть и консоль. Подходит, если баг сложно воспроизвести.

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

📌 Пример:

Во время теста у нас слетает кнопка оформления заказа. Мы нажимаем “Start recording”, повторяем шаги, где проявляется баг — и останавливаем запись. Всё готово: лог, видео, действия, URL.

2️⃣ Настраиваем шаблон баг-репорта

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

• шаги воспроизведения
• описание окружения
• консольные ошибки и сетевые запросы
• ссылка на видео
• URL страницы

📌 Пример шаблона:

Проблема: кнопка не реагирует на клик
Шаги: подставлены автоматически
Видео: [ссылка]
Логи и XHR: вложены
Окружение: Chrome 123, Windows 11, 1920×1080

3️⃣ Отправляем баг сразу в систему

Отправьте баг сразу в систему, где его будут обрабатывать разработчики. Это может быть: Jira, Trello, GitHub Issues, Notion.

📌 Пример:

Баг записан. Мы нажимаем “Create bug” → выбираем Jira → баг улетает в проект с видео, логами, шагами и средой.

Как можно улучшить:

• Настроить горячую клавишу для начала записи

• Создать шаблоны под разные типы багов (UI, функционал, мобильные)

• Использовать расширение даже для нестабильных или «разовых» ошибок, которые тяжело повторить

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

#буст

🐞 Как быстро заводить баг-репорты прямо из браузера

Эта инструкция помогает упростить и ускорить процесс: баги оформляются автоматически — с видео, логами и всей нужной информацией — буквально в пару кликов.

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

1️⃣ Устанавливаем расширение в браузер

Используйте специальные расширения, которые:

• записывают экран и шаги, которые мы выполняем
• автоматически сохраняют консольные ошибки и сетевые запросы
• фиксируют данные об окружении: браузер, язык, разрешение экрана
• формируют баг-репорт, который можно отправить сразу в Jira, Trello, GitHub или просто скопировать

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

➡️ Bird Eats Bug — очень удобное расширение, подходит и для ручного, и для регресса.
Оно работает прямо в браузере, не требует установки, записывает всё: экран, действия, логи, XHR-запросы, URL.

➡️ BugReplay — если нужно больше акцента на видео.
Также сохраняет сеть и консоль. Подходит, если баг сложно воспроизвести.

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

📌 Пример:
Во время теста у нас слетает кнопка оформления заказа. Мы нажимаем “Start recording”, повторяем шаги, где проявляется баг — и останавливаем запись. Всё готово: лог, видео, действия, URL.

2️⃣ Настраиваем шаблон баг-репорта

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

• шаги воспроизведения
• описание окружения
• консольные ошибки и сетевые запросы
• ссылка на видео
• URL страницы

📌 Пример шаблона:

Проблема: кнопка не реагирует на клик
Шаги: подставлены автоматически
Видео: [ссылка]
Логи и XHR: вложены
Окружение: Chrome 123, Windows 11, 1920×1080

3️⃣ Отправляем баг сразу в систему

Отправьте баг сразу в систему, где его будут обрабатывать разработчики. Это может быть: Jira, Trello, GitHub Issues, Notion.

📌 Пример:

Баг записан. Мы нажимаем “Create bug” → выбираем Jira → баг улетает в проект с видео, логами, шагами и средой.

Как можно улучшить:

• Настроить горячую клавишу для начала записи

• Создать шаблоны под разные типы багов (UI, функционал, мобильные)

• Использовать расширение даже для нестабильных или «разовых» ошибок, которые тяжело повторить

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

#буст

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

Инженер по автоматизации тестирования — от 240 000 ₽, удаленно (Москва)

Quality Assurance Engineer (Senior) — Москва

QA Engineer (middle) — от 130 000 до 180 000 ₽, удаленно (Москва)

Senior Mobile Automation & Manual QA Engineer — гибрид (Москва/Санкт-Петербург)

Junior Продуктовый QA (без опыта) — офис (Москва)

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

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

#свежак

🌸 Вопросы с собеседований: как протестировать продукт, если требования еще не установлены

Использовать гибкую методологию, такую как Scrum:

1️⃣ Определение целей. Выполнение модульного, интеграционного, приемочного и системного тестирования, с обновлением

2️⃣ Разбиение на пользовательские истории и назначение спринтов.

3️⃣ Выполнение модульного, интеграционного, приемочного и системного тестирования, с обновлением сценариев по мере изменения требованй.

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

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

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

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

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

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

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

📍 Cypress Tutorial Full Course | Learn Cypress in 5 Hrs

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

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

#свежак

🐞 Когда баги спят… или делают вид

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#свежак

📓 Автоматическое заполнение форм с помощью 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 = 'test@example.com'; // Заполняем 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 для отслеживания изменений.

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

#буст

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

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

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

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

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

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

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

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

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

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

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

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

И я понял:

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

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

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

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

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

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

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

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.

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

#буст

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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, для автоматического поиска тайминг-уязвимостей.

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

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

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

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

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

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

#буст

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

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

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

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

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

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

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

#буст

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

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

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

#свежак

🌸 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
}

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

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

#буст

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

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

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

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

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

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

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

#свежак

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что умеет:

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

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

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

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

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

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

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

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

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

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

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

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

#свежак

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

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

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

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

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

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

#буст

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🌸 Чек-лист для тестирования 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

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

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

#буст

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

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

• Проверяем соответствия структуры данных спецификации API.

• Проводим валидацию обязательных и необязательных полей.

• Проверяем типы данных в полях.

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

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

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

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

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

• Тестируем с корректными и некорректными данными для проверки механизмов валидации.

• Проверяем реакции API на пустой JSON в теле запроса.

• Убедимся, что поле даты создания объекта заполняется корректно.

3️⃣ Тестирование GET-запросов
• Пустой список: Проверить, что при отсутствии данных API возвращает пустой массив или соответствующее сообщение.
• Заполненный список: Убедиться, что API корректно возвращает список с данными.
• Пагинация в списке:
• Параметр limit: Проверка ограничения количества возвращаемых записей.
• Параметр offset: Проверка смещения начала выборки записей.
• Некорректные значения параметров: Убедиться, что при передаче неверных значений возвращается ошибка 400 с описанием.
• Отрицательный offset: Проверка, что при отрицательном значении смещение начинается с первой позиции.
• Несуществующий offset: Убедиться, что при выходе за пределы доступных данных возвращается пустой список.
• Сортировка списка: Проверка корректности сортировки данных по различным полям.
• Запрос по валидному ID: Убедиться, что при запросе существующего ID возвращаются корректные данные.
• Запрос по несуществующему ID: Проверка, что при запросе несуществующего, но валидного ID возвращается ошибка 404.
• Запрос по невалидному ID: Убедиться, что при запросе с некорректным форматом ID возвращается ошибка 400.

4️⃣ Тестирование PUT-запросов
• Обновление с корректными данными: Проверка успешного обновления объекта при передаче валидных данных.
• Обновление по несуществующему ID: Убедиться, что при попытке обновления несуществующего объекта возвращается ошибка 404.
• Обновление по невалидному ID: Проверка, что при передаче некорректного ID возвращается ошибка 400.
• Валидация полей: Тестирование с корректными и некорректными данными для проверки механизмов валидации при обновлении.
• Частичное обновление: Убедиться, что при передаче неполного набора данных обновляются только указанные поля.

5️⃣ Тестирование DELETE-запросов
• Удаление существующего объекта: Проверка успешного удаления объекта.
• Удаление уже удаленного объекта: Убедиться, что повторное удаление возвращает соответствующую ошибку.
• Удаление по несуществующему ID: Проверка, что при попытке удаления несуществующего объекта возвращается ошибка 404.
• Удаление по невалидному ID: Убедиться, что при передаче некорректного ID возвращается ошибка 400.
• Удаление и повторное добавление сущности: Проверка, что после удаления и повторного добавления объекта с уникальными полями не возникает конфликтов.

6️⃣ Проверка статусов ответов
• Убедиться, что API возвращает корректные HTTP-статусы для каждого типа запроса и ситуации (200, 201, 400, 401, 403, 404, 500 и т.д.).

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

• Тестируем обработку API различных ошибок, включая сетевые сбои, таймауты и некорректные данные.

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

• Проверяем бизнес-логику и сложные сценарии использования API.

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

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

• Проверяем реакции API на просроченные или неверные токены доступа.
• **Защита от

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

#буст

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

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

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

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

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

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

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

grep "ERROR" application.log

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

ps aux | grep "my_app"

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

grep -ri "TODO" ./src

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

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

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

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

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

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

#буст

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

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

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

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

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

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

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

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

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

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

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

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

📍 Проверь статус коммита: зайди в 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 о статусе билда, чтобы отслеживать статус.

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

#буст

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

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

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

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

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

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

🫠 Задача: ищем ошибки в коде обработки пользовательского ввода

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

1️⃣ Найдите и опишите ошибки или уязвимости в данном коде.

2️⃣ Предложите исправленный вариант кода, устраняющий найденные проблемы.

Подсказка: обратите внимание на использование функции eval и методы обработки потенциально опасного ввода.

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

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

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

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

🔘 Промпт, который поможет найти слабые места в интерфейсе

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

🔘 Топ 7 причин отказа после стажировки: полезная статья

🔘 Горячие клавиши в IBM Perfomance Tester

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

#свежак

😱 Угадай, что ломается первым

Подсказка: когда всё вроде правильно, но тест всё равно красный.

Что за функционал зашифрован? ✏️

Пиши догадку — и не забудь проверить required=true.

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

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

Случался ли с вами подобный кейс? ❓

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

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

📚🔄 OTUS – лауреат премии «Цифровые вершины»: как подписка на обучение меняет IT-образование

​Платформа OTUS представила инновационный подход к IT-обучению, запустив сервис подписки, предоставляющий доступ к 151 курсу по ключевым направлениям индустрии. Этот формат позволяет специалистам гибко выбирать образовательные треки и проходить до трех курсов одновременно без дополнительных затрат, что значительно снижает расходы на обучение.​

В 2025 году OTUS была удостоена премии «Цифровые вершины» в номинации «Лучшее IT-решение для образования», что подтверждает эффективность и востребованность их модели обучения. Благодаря подписке, IT-специалисты могут непрерывно обновлять свои знания и навыки, оставаясь конкурентоспособными в стремительно развивающейся сфере.

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

☝️ Горячие клавиши в IBM Performance Tester

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

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

1️⃣ Сохранение теста или расписания

📍 Ctrl + S — сохранить текущий тест или расписание.

Пример использования: после внесения изменений в тестовый сценарий, нажмите Ctrl + S, чтобы сохранить изменения без необходимости переходить в меню.

2️⃣ Генерация теста из записи

📍 Alt + Shift + T, затем G — сгенерировать тест из выбранного файла записи (.recmodel).

Пример использования: выберите файл записи в Test Navigator, затем используйте указанное сочетание клавиш для быстрого создания теста на основе этой записи.

3️⃣ Создание отчета по тесту

📍 Alt + Shift + T, затем R — создать отчет по выбранному тесту.

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

4️⃣ Проверка соединения

📍 Alt + Shift + T, затем T — проверить соединение для выбранного расположения.

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

5️⃣ Запуск теста

📍 Alt + Shift + X, затем B — запустить выбранный тест.

Пример использования: после выбора теста в Test Navigator, примените данное сочетание клавиш для его немедленного запуска.

6️⃣ Запуск расписания

📍 Alt + Shift + X, затем C — запустите выбранное расписание.

Пример использования: Выберите расписание в Test Navigator и используйте указанное сочетание клавиш для его запуска.

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

#буст

💀 ТОП-7 причин отказа после стажировки

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

➡️ Что в статье:

— Почему слабые hard и soft skills могут закрыть перед тобой дверь в компанию

— Как пассивность и ожидание задач портят впечатление о стажере

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

— Какие действия (или бездействие) приводят к провалу

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

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

Работа QA - это канал с топовыми вакансии для QA специалистов.

Контент канала:
1. Junior QA вакансии
2. Вакансии с возможностью связаться с HR в телеграм
3. Подборки вакансий за неделю

Подписывайтесь и ищите работу у нас: @qajoboffer

Реклама. Киренкина Марина Дмитриевна, ИНН 345702417736. Erid 2VtzqvicnQR

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

Gherkin — язык описания поведения системы, используемый в BDD (Behavior-Driven Development). Он позволяет писать тесты, которые легко читаются всеми участниками проекта, включая заказчиков и разработчиков. Рассмотрим, как составлять тесты с помощью Gherkin.

📍 Основные компоненты:

• Feature — описание функционала системы.

• Scenario — конкретный пример использования.

• Given — начальные условия.

• When — действия пользователя.

• Then — ожидаемый результат.

• And / But — дополнительные условия.

📍 Пример теста:

Feature: Аутентификация пользователя

Scenario: Успешный вход
Given пользователь на странице входа
When он вводит правильные данные
Then он попадает на главную страницу
And видит приветственное сообщение

📍 Рекомендации:

⏩ Пишите тесты простым и понятным языком.

⏩ Каждый сценарий должен проверять одну конкретную вещь.

⏩ Используйте Background, чтобы избежать дублирования кода.

📍 Пример с Background:

Feature: Оформление заказа

Background:
Given пользователь авторизован
And добавил товар в корзину

Scenario: Оформление с успешной оплатой
When он вводит данные для оплаты
Then заказ оформлен
And получает подтверждение по email

📍 Интеграция с автоматизацией

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

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

#буст

🪄 Визуальные вычисления в Power BI: прокачиваем условное форматирование

Теперь настраивать условное форматирование в Power BI можно без сложных DAX-формул!

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

⭐️ Пора сделать отчеты действительно интерактивными!

🔗 Ссылка на статью: https://proglib.io/sh/lsb0fEuYSv

Библиотека дата-сайентиста

😠 Найди слабые места в интерфейсе

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

Промпт:

«Представь, что ты — тестировщик в команде разработки нового мобильного приложения. Твоя цель — оценить UX и выявить те моменты, которые могут создать неудобства пользователям. Внимательно посмотри на [описание функционала]. Какие элементы интерфейса могут вызвать недоразумения или затруднения при использовании? Придумай нестандартные сценарии использования, чтобы проверить устойчивость интерфейса к неожиданным действиям.»

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

▶️ Подставь функционал, например, «регистрация через социальные сети» или «поиск товаров по фильтрам».

▶️ Проведи тестирование, ориентируясь на максимально разнообразные сценарии (например, низкое качество связи или действия в неверной последовательности).

▶️ Попробуй добавить дополнительные условия — «проверь на мобильных устройствах с разными экранами» или «оцени удобство для слабовидящих пользователей».

Какие неожиданные проблемы с UX ты смог найти? Делись в комментариях! ⬇️

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

#буст

🔥 Тестировщики, нужен ваш экспертный взгляд

Собираем крутую подборку ноутов в 2025 году и ищем реальные отзывы от людей, которые в теме.

Какой ноут у вас в арсенале для тестирования и почему ❓

Расскажите все:

➡️ Что за зверь (модель, начинка)

➡️ Где жмет и где радует в ежедневной работе

➡️ На какие фишки смотреть при выборе

➡️ Как вам с ним живется

Топовые советы попадут в нашу статью!

Делитесь в комментах 🔄 Сделаем годный гайд, который реально поможет коллегам!

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

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

📹 Инструмент недели: Zephyr для Jira

Это плагин, который интегрируется непосредственно в Jira, превращая её в полноценную систему управления тестированием (TMS).

➡️ Что умеет:

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

• Выполнение тестов: предоставляет инструменты для проведения как ручного, так и автоматизированного тестирования, а также интеграцию с CI/CD-пайплайнами для автоматизации процессов.

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

➡️ В чем польза:

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

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

• Поддержка автоматизации: совместим с различными инструментами автоматизации и CI/CD-системами, что позволяет интегрировать тестирование в конвейеры непрерывной интеграции и доставки.

➡️ Рекомендации по внедрению:

• Обучение команды: обеспечьте необходимое обучение для всех членов команды, чтобы они могли эффективно использовать возможности плагина.

• Настройка процессов: адаптируйте рабочие процессы и структуры тестирования в Zephyr в соответствии с потребностями вашего проекта и команды.

• Мониторинг и улучшение: регулярно анализируйте отчёты и метрики, предоставляемые Zephyr, для выявления узких мест и постоянного улучшения процессов тестирования.

Использование Zephyr для Jira может значительно повысить эффективность процессов тестирования, обеспечить лучшее качество продукта и улучшить взаимодействие между командами разработки и тестирования.

Сохраняй себе и становись боссом по управлению тестами 👍

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

#буст

🎭 Dev Memes: 1 апреля, а баги всё те же

Сегодня день официально разрешённого троллинга — и мы не могли пройти мимо. Собрали подборку мемов для Фронтендеров, которые вызывают лёгкое желание уволиться.

👉 Всё это — из нашего мемного канала «Библиотека IT-мемов»

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

🧐 Разбираемся: FAANG — не мечта, а капкан

Раньше работа в Google или Meta казалась вершиной айтишной карьеры. Сейчас — всё чаще звучат слова «стресс», «сокращения», «выгорание».

➡️ В статье разбираем

— Почему бывшие сотрудники бегут из FAANG
— Как изменилась культура внутри Big Tech
— Где теперь искать стабильность и уважение
— Реальные комментарии от действующих инженеров
— И что на самом деле стоит за блестящей обёрткой FAANG

Если вы всё ещё решаете LeetCode ради «заветной должности» — обязательно прочитайте нашу статью.

📎 Ссылка

🔵 Включайся в обучение и устраивайся куда хочешь, тебя ждет продвинутый этап нашего курса «Алгоритмы и структуры данных»

https://t.me/proglib_academy/2652

💡 Вопросы с собеседований: тестирование поля ввода имени

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

1️⃣ Какова минимальная и максимальная длина имени, которую следует разрешить в поле ввода?

Минимальная длина: Рекомендуется разрешать имена от 2 символов, чтобы учитывать короткие имена, такие как «Ия» или «Ли».​
Максимальная длина: Ограничение в 40 символов считается достаточным для большинства случаев, однако в некоторых системах допускается длина до 100 символов. ​

2️⃣ Какие символы допустимы при вводе имени? Разрешены ли цифры, специальные символы или пробелы?

Допустимые символы: Буквы соответствующего алфавита, дефисы, апострофы и пробелы между частями составных имён.​
Недопустимые символы: Цифры и специальные символы (кроме указанных выше) обычно не разрешены. ​

3️⃣ Следует ли учитывать национальные особенности при валидации имени? Например, поддерживать буквы с диакритическими знаками или символы различных алфавитов?

Да, важно поддерживать символы различных алфавитов и диакритические знаки, чтобы пользователи могли корректно вводить свои имена в соответствии с их национальными особенностями. ​

4️⃣ Как система должна реагировать на ввод имени, содержащего подряд идущие пробелы или дефисы?

Система должна предотвращать ввод нескольких подряд идущих пробелов или дефисов, уведомляя пользователя о некорректности ввода и предлагая исправить его. ​

5️⃣ Какие сообщения об ошибках должны отображаться пользователю при некорректном вводе имени?

Сообщения должны быть чёткими и информативными, например:
• «Имя должно содержать от 2 до 40 символов.»
• «Имя может включать только буквы, пробелы, апострофы и дефисы.»
• «Недопустимо использование подряд идущих пробелов или дефисов.»


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

🔥 — 5 из 5 — Ты QA-мастер
👍 — 3-4 из 5 — Хороший результат, но есть куда расти
🤔 — 1-2 из 5 — Пора подтянуть теорию тестирования
😅 — 0 из 5 — Ну, зато узнал что-то новое

Делитесь результатами и зовите коллег на челлендж 💬

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

#буст

🕸️ Сетевая модель OSI

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

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

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

#буст

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

🔘 Шпаргалка: тестирование авторизации в API

🔘 How to: тестируем API в Postman с использованием коллекций запросов

🔘 Testcontainers: для чего используется, преимущества, примеры

🔘 Что посмотреть тестировщику: разбор Postman от А до Я

🔘 Команда дня: мастерим поиск с помощью grep: что делает, примеры использования и советы

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

#свежак

🤷‍♀️ Тестировщик — это вход в IT или полноценная профессия

Многие заходят в тестирование с мыслью:

«Начну с QA, а дальше — в разработку, аналитику или продукт. Что-то посерьёзнее.»

И да, у каждого свой путь — это нормально.
Но складывается ощущение, что QA воспринимают как временный этап, а не профессию.

На деле же всё совсем иначе.

QA — это:

📍 умение видеть продукт под разными углами — техническим, пользовательским, логическим;

📍 способность выстраивать процессы качества, а не просто «искать баги»;

📍 влияние на то, что в итоге выходит в прод, и как это будет работать у реальных людей;

📍 широкий спектр развития — от тест-дизайна и автоматизации до performance, security, интеграций, и даже UX.

Это не ступенька. Это — полноценный маршрут.

Кто-то действительно уходит дальше. А кто-то остаётся — и растёт в сильного спеца, тимлида, архитектора тестирования, эксперта по качеству.
Потому что здесь есть куда расти.

А как ты относишься к тестированию?

🌚 — Остался в QA и хочу дальше расти в этом направлении

🔥 — Пока на перепутье — не знаю, останусь ли

❤️ — Люблю QA, но раздражают стереотипы про «временность»

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

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

🔪 Не все знают, что тестировщиков обучают копаться в документации не для того, чтобы мешать лишними вопросами. (Но это не точно!)

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

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

💪 Прокачай Power BI: создаем bullet-chart для наглядного сравнения данных

🎯 Устали от вопросов типа «Ну и что это значит для бизнеса?» после презентации отчетов?

Bullet-chart — мощный инструмент, который сразу показывает, насколько фактические показатели соответствуют целевым. В этой статье разберем, как правильно читать такой график и шаг за шагом создадим его в Power BI.

Готовы визуализировать данные так, чтобы они говорили сами за себя?

🔗 Тогда поехали, ссылка на статью: https://proglib.io/sh/hcrRdAuqT5

Библиотека дата-сайентиста

😂 Команда дня: мастерим поиск с помощью grep

Grep является настоящим спасителем для тестировщиков при анализе логов и поиске нужной информации в файлах.

➡️ Что делает grep:

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

➡️ Примеры использования:

1️⃣ Поиск всех строк, содержащих слово “error” в файле application.log:

grep 'error' application.log


2️⃣ Поиск без учета регистра:
Чтобы найти слово “error” независимо от регистра (например, “Error”, “ERROR”), используйте опцию -i:

grep -i 'error' application.log


3️⃣ Вывод номеров строк с найденным текстом:
Для отображения номеров строк, в которых найдено совпадение, добавьте опцию -n:

grep -n 'error' application.log


4️⃣ Рекурсивный поиск в директории:
Чтобы искать во всех файлах внутри директории и ее поддиректориях, используйте опцию -r:

grep -r 'error' /var/logs/

Совет:

Команда grep особенно мощна в сочетании с другими командами через конвейер (pipe). Например, чтобы отследить в реальном времени появление ошибок в логе, можно использовать:

tail -f application.log | grep 'error'

Это позволит вам видеть новые строки, содержащие “error”, по мере их появления в файле лога.

Освоение команды grep значительно повысит вашу эффективность при работе с текстовыми данными и логами. Она является неотъемлемым инструментом в арсенале каждого тестировщика.

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

#буст

🦊 Альтернативы Firefox: обзор 4 лучших форков для тех, кто разочаровался в Mozilla

Приватность, скорость, расширенные функции — что выбрать? Разбираем популярные форки браузеров и их преимущества.

Что в статье:

✔️ Обзор самых популярных форков браузеров

✔️ Их ключевые фишки, плюсы и минусы

✔️ Как выбрать оптимальный вариант под ваши задачи

Браузер — это не просто окно в интернет, а инструмент, который должен соответствовать вашим требованиям. Делитесь своим опытом в комментариях! 🚀

Прочитать подробнее статью 🔗

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

Postman для тестировщика 2.0

Postman — это полноценная среда для тестирования, автоматизации и документирования API.

А для тех, кто хочет разобраться в этом без боли и бессонных ночей, на YouTube вышел обучающий курс. Подходит как для новичков, так и для тех, кто давно хотел «разложить всё по полочкам».

Что внутри курса:

🔘 Что такое Postman и зачем он нужен тестировщику

🔘 Как создавать и отправлять запросы (GET, POST, DELETE и не только).

🔘 Работа с переменными, окружениями и коллекциями.

🔘 Основы написания тестов и скриптов (Pre-request и Tests).

🔘 Как автоматизировать тест-кейсы и собрать коллекции в CI/CD.

🔘 Уловки, советы, фишки — без воды, по делу.

Ссылка на плейлист 🧷

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

#буст

👀 Ну что, мои баг-детективы…

Какой смайлик описывает вас, когда отправляете задачку на доработку?

😄 — Я не злюсь, я просто внимательный

👾 — Я баги не создаю, я их нахожу

🌚 — А кто-то говорил «всё работает»

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

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

Чемпионат для подростков по 14 направлениям от «Алабуга Политех»☺️

Программирование и Битва роботов, Экономика и Юриспруденция, 3D моделирование и Английский язык и многое другое, чтобы каждый нашел свою дисциплину.

Для участия тебе нужно☺️
☺️Оставь заявку на сайте😀
☺️Пройди заочный этап на HR-платформе: Business Cats до 1,0 по «Общению» и «Аналитике» для оплаты дороги туда и обратно😀
☺️Приезжай на чемпионат😀

Мы предлагаем тебе☺️
☺️Общий призовой фонд турнира составляет 450 000 рублей😀
☺️Проживание и дорога бесплатно😀
☺️Возможность поступить в «Алабуга Политех»😀

Участвуй в турнире от образовательного центра мирового уровня и получай призы и преимущество в поступлении☺️

Реклама. ООО "Медиа ГУРУ", ИНН 7725710297. Erid 2VtzqvpAdnG

💻 Исследование IT-аудитории Proglib 2025: зарплаты, технологии, профессии

Кем является разработчик в 2025 году? Свежий анализ IT-сферы: зарплаты, востребованные технологии, специализации и демография специалистов.

📊 Полный отчет здесь: https://proglib.io/sh/NbJAHIDRTg

Библиотека дата-сайентиста #Свежак

⭐️ Testcontainers

Testcontainers — это библиотека с открытым исходным кодом, позволяющая создавать временные, изолированные контейнеры для интеграционного тестирования.

Она поддерживает различные языки программирования, включая Java, .NET, Go, Node.js, Python и другие .

📍Для чего используется:

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

📍Преимущества:

• Изоляция окружения: каждый тест запускается в своем собственном контейнере, что предотвращает конфликты и обеспечивает чистоту состояния.

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

• Автоматизация: контейнеры автоматически создаются перед запуском тестов и удаляются после их завершения, что упрощает настройку и управление тестовым окружением.

📍Пример использования на Java:

Допустим, вы хотите протестировать взаимодействие с PostgreSQL:

import org.testcontainers.containers.PostgreSQLContainer;

public class Demo {
public static void main(String[] args) {
try (PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:15")) {
postgres.start();

String url = postgres.getJdbcUrl();
String user = postgres.getUsername();
String password = postgres.getPassword();

System.out.println("Подключение: " + url);
// Тут можно подключиться к БД и выполнить тестовые запросы

// PostgreSQL остановится автоматически при выходе из try
}
}
}

В этом примере контейнер с PostgreSQL версии 15 поднимается перед выполнением теста и автоматически завершается после его завершения .

📍Когда применять:

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

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

• Для упрощения процесса настройки и управления зависимостями в тестовом окружении.

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

#буст

☸️ CKAD 2025. Самый свежий гайд по сдаче сертификации Certified Kubernetes Application Developer

CKAD стал более строгим к деталям — без системной подготовки можно завалить даже на банальных заданиях. Если хочется разобраться, что важно для получения сертификации — эта статья сэкономит часы.

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

🐸Библиотека devops'a

🥰 Тестирование API в Postman с использованием коллекций запросов

Создание коллекции запросов и написание для каждого из них тестов позволяет быстро проверять корректность работы API и находить ошибки ещё до попадания в прод.

Как это сделать:

1️⃣ Создайте новую коллекцию в Postman

Назовите её по назначению, например, ”Product API Tests”.

2️⃣ Добавьте в коллекцию основные типы запросов:

• GET — получение информации о товаре.

Тесты: проверка статус-кода 200, структура и содержание ответа.

• POST — добавление нового товара.

Тесты: проверка статус-кода 201, наличие ID нового товара в ответе, корректность переданных данных.

• PUT — обновление информации о товаре.

Тесты: проверка статус-кода 200, соответствие обновлённого объекта ожидаемым данным.

• DELETE — удаление товара.

Тесты: статус-код 204 или 200, проверка отсутствия товара при последующем GET-запросе.

3️⃣ Добавьте тесты в каждый запрос.

В Postman можно использовать встроенный JavaScript, чтобы написать проверки:

pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

🔜 Пишите тесты на:

• Статус-коды

• Структуру и содержимое тела ответа

• Логические проверки (например, цена не может быть отрицательной)

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

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

#буст

💻 День, когда компьютеры начали думать быстрее нас

22 марта 1993 года Intel показала миру Pentium — процессор, с которого началась новая эра.

Изначально хотели назвать его просто «586» и запатентовать, но цифры патенту не поддаются.
Пришлось креативить — так появилось благородное имя Pentium (намёк на «пятое поколение»).

С ним люди поняли: мегагерцы — это не болезнь, а скорость.
Pentium стал не просто культовым — он дал старт безумной гонке за мощностью,
благодаря которой ты сейчас читаешь это мгновенно, а не ждёшь, пока загрузится каждая строчка 😎

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

#свежак

🎈 Тестируем авторизацию в API

Если в вашем проекте реализован OAuth 2.0, значит, пользователи могут входить через Google, Facebook и другие сервисы без передачи логина и пароля. Чтобы убедиться, что все работает корректно:

Нужно проверить:

🔜 Корректность редиректов и передачи токенов

🔜 Срок действия и обновление access/refresh токенов

🔜 Защиту от атак (например, CSRF)

🔜 Соответствие требованиям безопасности

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

#буст

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

🔘 Жизненный цикл ПО: этапы и что на них происходит

🔘 Шпаргалка V-модели: принципы, когда использовать

🔘 Как создать тест-кейсы для нового функционала

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

🔘 .fill() vs .type(): кого выбрать и почему это важно

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

#свежак

📊 Собес по Data Science: 10 вопросов, которые разделяют джунов от мидлов

Залетай на тест, который валит даже мидлов! Собрали для тебя 10 каверзных вопросов, которые тимлиды обожают подкидывать на собесах. Здесь нет простых задачек — только те, на которых спотыкаются 80% кандидатов. Пройди этот челлендж, чтобы быть во всеоружии на следующем интервью.

✅ Пройти тест

Библиотека мобильного разработчика #свежак

Баг в пятницу — это как гость без приглашения, который пришел с чемоданом… и настроением остаться до понедельника 🥲

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

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

👍 Тест-кейсы, которые не спасли от бага

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

В Библиотеке тестировщика мы знаем, что лучшие истории — это те, которые учат нас быть ещё внимательнее.

Делитесь своими случаями, когда ⬇️

— Все тесты пройдены, но баг оказался в неожиданном месте.
— Тест-кейсы были идеальными, но реальный пользователь нашёл дыру.
— Логика проверена, но один особенный браузер решил иначе.
— Автотесты радовались жизни, а на проде разразился ад.

Начнём с истории нашего тест-лида:

Когда-то мы тестировали обновление профиля пользователя. Форма работала идеально: валидация, кнопки, автотесты — всё чётко. Выпустили в прод, и тут посыпались жалобы, что сменить имя невозможно. Оказалось, что у некоторых пользователей были в именах эмодзи, а новый бэкенд их не пропускал. Конечно, у нас были тестовые данные, но никому не пришло в голову проверить, что кто-то реально зовёт себя "🦄✨". Первый хотфикс в моей карьере был про эмодзи.

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

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

😎 .fill() vs .type(): кого выбрать и почему это важно

Если ты до сих пор используешь .type() для ввода текста в поля — пора пересмотреть привычки.

Да, .type() симулирует «настоящий» ввод, по буквам.

Звучит реалистично, но:

➡️ медленно, особенно в больших тестах;

➡️ может сломаться, если на странице сработает автофокус, маска или задержка между символами;

➡️ анимации, валидации, вся эта магия может среагировать не так, как надо.

Лайфхак: используй .fill() вместо .type().

Пример:

// Было:
await page.type('input[name="username"]', 'QA_warrior_3000');

// Стало:
await page.fill('input[name="username"]', 'QA_warrior_3000');

Чем это лучше:

1️⃣ Быстрее.

2️⃣ Стабильнее.

3️⃣ Тесты меньше флапают (да, именно ты, flaky test, мы на тебя смотрим).

Вывод: fill() — твой новый дефолт. type() — только когда нужен эффект «печатания» от пользователя.

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

#буст

🏗 7 основных стратегий обеспечения устойчивости распределенных систем

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

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

🔗 Читать статью
🔗 Зеркало

🐸 Библиотека хакера

😱 Сломай, если сможешь

Сегодняшний промпт поможет вам находить уязвимости в системе, еще до того, как пользователи успеют их эксплуатировать.

Промпт:

«Представь, что ты хакер (но белый), который ищет самые изощренные способы сломать систему. Разбери функционал [описание функционала] и найди потенциальные уязвимости, нестандартные сценарии и неожиданные точки отказа. Также предложи стратегии тестирования, чтобы обнаружить эти слабые места раньше, чем ими воспользуется кто-то другой.»

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

1️⃣ Подставьте нужный функционал, например, «обработка платежей через сторонний сервис».

2️⃣ Прогоните промпт через ChatGPT или другой AI.

Добавьте уточнение вроде «учти баги безопасности» или «предложи хаос-тестирование», чтобы получить еще более глубокий анализ.

Какой самый коварный баг удалось найти благодаря этому методу? Делитесь в комментариях! 🔽

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

#буст

🔫🔫

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

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

💬 Как оставлять комментарии в чате нашего канала

В нашем чате работает бот Shieldy — он защищает от спама, запрашивая у новых участников решение простой капчи.

⚠️ Проблема, с которой сталкиваются многие: вы нажимаете под постом «Прокомментировать», пишете что-то, а потом получаете бан и не можете писать комментарии.

❓Почему так: Shieldy отправляет капчу в сам чат, а не в комментарии под конкретный пост. Из-за этого капчу можно не увидеть, не отправить ответ на нее, и бот автоматически заблокирует вас.

✅ Как присоединиться к чату, чтобы бот вас не забанил

— Зайдите в описание канала с телефона и нажмите кнопку Discuss / Чат
— Нажмите Join / Присоединиться
— Сразу обратите внимание на сообщение от бота Shieldy
— Решите простой пример и отправьте ответ в чат

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

❗️ Если вас все-таки забанили

— Это временная блокировка на несколько минут
— Подождите и попробуйте зайти позже, бот снова отправит вам капчу

Админы канала никак не могут ускорить процесс, бот автоматически снимает с вас блокировку через пару минут. Мы понимаем, что эта система неидеальна, и ищем более удобное решение.

👾 Спасибо, что активно участвуете в обсуждении наших постов!

📌 Как создать тест-кейсы для нового функционала

Рассмотрим детально этапы создания тест-кейсов:

1️⃣ Анализ требований

Шаги:

• Изучение документации: ознакомьтесь с техническими заданиями, спецификациями и пользовательскими историями, связанными с новым функционалом.

• Обсуждение с заинтересованными сторонами: проведите встречи с бизнес-аналитиками, разработчиками и конечными пользователями, чтобы уточнить детали и ожидания.

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

2️⃣ Определение тестируемых аспектов

Шаги:

• Приоритизация функций: Определите, какие части функционала наиболее важны для бизнеса и пользователей, и должны быть протестированы в первую очередь.

• Идентификация рисков: Оцените потенциальные риски и уязвимости, связанные с новым функционалом, чтобы уделить им особое внимание при тестировании.

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

3️⃣ Разработка тест-кейсов

Шаги:

• Создание структуры тест-кейса: Оформите тест-кейсы с обязательными атрибутами:

• Идентификатор: Уникальный номер или код теста.

• Название: Краткое и ясное описание цели теста.

• Предусловия: Условия, которые должны быть выполнены перед запуском теста.

• Шаги выполнения: Последовательность действий, которые необходимо выполнить.

• Ожидаемый результат: Описание того, что должно произойти после выполнения шагов.

• Приоритет: Степень важности теста, влияющая на порядок его выполнения.

• Фактический результат: Реальный результат после выполнения теста (заполняется после исполнения).

• Статус: Результат прохождения теста (успешно/неуспешно).

• Разработка различных типов тестов:

• Позитивные тесты: Проверяют корректную работу функционала при вводе правильных данных.

• Негативные тесты: Оценивают реакцию системы на некорректные или неожиданные данные.

• Граничные тесты: Тестируют поведение системы на границах допустимых значений.

• Использование шаблонов: Применяйте стандартизированные формы для обеспечения единообразия и полноты тест-кейсов.

4️⃣ Ревью и утверждение

Шаги:

• Проведение ревью: Организуйте совместный просмотр тест-кейсов с командой тестировщиков, разработчиками и аналитиками.

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

• Внесение корректировок: Обновите тест-кейсы с учетом полученной обратной связи, устранив выявленные недостатки.

• Утверждение тест-кейсов: После доработки представьте тест-кейсы на утверждение руководству или ответственным лицам.

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

#буст

🔥 Сколько времени нужно, чтобы войти в IT: реальные цифры

Мы спросили подписчиков, сколько у них занял переход «хочу в IT» → первая работа. Вот результаты.

🔵 38,4% справились за год
🔵 30,4% потребовалось 1-2 года
🔵 17,9% шли 2-3 года
🔵 13,4% учились и пробивались больше 4 лет

Как входили в IT
🔵 53,4% изучали самостоятельно
🔵 24,1% учились на курсах
🔵 Остальные — через вуз, наставников, стажировки

У всех путь разный, но главное — не останавливаться. Кто-то заходит в IT за 6 месяцев, кто-то — за 3 года. Но если идти — дойдёшь.

Азбука айтишника #мотивасьон

https://t.me/abc_for_it/967