Библиотека тестировщика | QA, тестирование, quality assurance, manual testing, autotesting, ручное тестирование, автотесты
8.79K subscribers
1.2K photos
149 videos
23 files
2.54K links
Все самое полезное для тестировщика в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/12538d6f

Работать у нас: https://job.proglib.io/

Для обратной связи: @proglibrary_feeedback_bot
Download Telegram
😎 Как тестировщики спасают продакшен

Вышел новый выпуск подкаста «QAk‑QAk — и в продакшен» с Борисом Чернышом из Т-Банка — о том, как QA справляется с инцидентами и спасает критичные системы от сбоев.

Разберемся:

➡️ Что происходит, когда падает прод

➡️ Какую роль играет тестировщик в отказоустойчивости

➡️ Почему автоматизация — это не «таблетка от всего»

➡️ Может ли AI вовремя остановить фейл

➡️ И почему баг — не всегда провал, а иногда рост

🔗 Слушать подкаст на Soundstream

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

#буст
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🥰2🤩2
😤 Пока вы думаете — остальные уже учатся строить системы, которые работают за них

24 часа до старта курса по AI-агентам. Самое время задуматься о прокачке скиллов, потому что места ограничены!

Если вы до сих пор думаете, что LLM — это просто «вызов через API», то вы рискуете очень скоро оказаться за бортом индустрии.

Модели больше не в центре. Решают те, кто умеет собирать интеллектуальные системы, а не просто «дообучать модельку».

➡️ Что вы потеряете, если не впишетесь:
— навык, который уже востребован на рынке
— понимание, как из GPT сделать полноценного помощника, агента или продукт
— шанс догнать тех, кто уже перешёл на следующий уровень

📌 Курс стартует уже завтра
— 5 вебинаров, живая практика, код, разборы, продовые кейсы
— без «посмотрите статью», только то, что реально нужно

Спикеры: Никита Зелинский (МТС), Диана Павликова, Макс Пташник, Дима Фомин — те, кто реально собирает агентные системы, а не просто про них пишет.

Старт уже завтра — забронируйте место на курсе сейчас
🤩52
🐞 Какие баги вы считаете самыми запоминающимися

В тестировании бывают баги, которые просто фиксишь — и забываешь. А бывают те, которые надолго остаются в памяти.

Вопрос от подписчика:

«Работаю в тестировании уже несколько лет. Иногда ловлю себя на мысли, что самые запоминающиеся баги — это не самые критичные, а самые странные. Например, как-то в форме на сайте имя «Тест» вызывало падение backend-а. А какие баги были у вас?»


Расскажите, с какими самыми необычными, смешными или загадочными багами вы сталкивались? Что это было и как вы их нашли?

Поделитесь историями в комментариях ⬇️

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

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

#междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
😁6🤩2🤔1
🔍 Много багов — плохой знак или хорошее покрытие

Многие команды любят цифры. Но можно ли по количеству багов судить о качестве продукта или работе тестировщика?

➡️ Когда багов много — это плохо:

— Может указывать на плохую реализацию или слабое покрытие

— Мешает команде фокусироваться: баг-трекинг превращается в свалку

— Возникает ощущение нестабильности у заказчика или менеджмента

➡️ А может, наоборот — это хорошо:

— Активная фаза тестирования, всё выкопано до релиза

— Тестировщик глубоко погружается в продукт и не «пропускает»

— Много багов ≠ плохой код, особенно на ранних этапах разработки

Реальный кейс:

На одном из проектов QA завёл 150 багов за неделю. Команда запаниковала: «У нас катастрофа?» Оказалось, что новый функционал не был покрыт даже юнитами, и тестировщик просто вытащил наружу всё, что и так было сломано.


💡 Как подойти разумно:

Считайте не количество багов, а сколько из них — критичные

Анализируйте источники: баг из-за продукта, окружения или требований

Ведите динамику: сколько дефектов уходит в прод и с какими последствиями

А вы как считаете: 200 багов — это тревога или просто хороший день у QA? Поделитесь своим мнением в комментариях! ✏️

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

#междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🥰2🤩21
🧩 Pairwise Testing — меньше тестов, больше пользы

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

➡️ Pairwise Testing Explained with Tools & Examples — описывает, как работает метод, почему он эффективен и какие инструменты (PICT, Hexawise, ACTS) можно использовать

➡️ Using Pairwise Testing to determine how many tests you need — современный подход с примерами расчёта объёма тестов и использованием AI/ML, чтобы масштабировать наборы

➡️ Pairwise тестирование — на чем основана данная техника, почему она так распространена.

➡️ Попарное тестирование — подробное видео с примером ручной и автоматической генерации через PICT

➡️ Pairwise testing за 5 минут: алгоритм построения и пример — коротко и емко про методику, подходит для быстрого освоения подхода

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

#свежак
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥63🥰2🤩1
🌸 Задача на собеседовании: проверка пользовательского ввода

На фронтенде есть форма регистрации с полем «возраст». Выше — фрагмент HTML и JS.

Вопрос:

Какие из вариантов тест-кейсов наиболее точно позволят проверить работу проверки возраста?

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

#междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6🤩3🤔21
👍 Топ-вакансий для тестировщиков за неделю

Senior QA Lead — от 350 000 ₽, офис/гибрид (Москва)

Тестировщик ПО/QA Engineer — офис (Новосибирск)

Automation QA Engineer (Python) — удаленно (Пенза)

Middle+ Тестировщик — до 330 000 ₽, удаленно (Москва)

AQA / Автоматизатор тестирования на Python — от 150 000 ₽, офис (Казань)

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

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

#свежак
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4🤩2
📌 Шпаргалка по работе с ветками и сохранению изменений в Git

В ней собраны основные команды для эффективного управления ветками и фиксации правок:

➡️ Просмотр и переключение веток

➡️ Создание и удаление веток

➡️ Слияние и тегирование

➡️ Добавление изменений и коммиты

➡️ Отмена изменений

Эта памятка поможет быстро ориентироваться в ключевых операциях Git и держать историю вашего проекта в порядке.

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

#буст
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7🤩2
🔍 Гибридные приложения — когда веб и натив встречаются

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

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

👉 Как они работают и в чём их особенность

👉 Плюсы и минусы гибридного подхода

👉 Популярные фреймворки и важные моменты для тестирования

Погружаемся в детали 💫

🐸 Библиотека тестировщика
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🥰3🤩2
⭐️ Как протестировать асинхронные экшены в Redux

Асинхронные экшены в Redux обрабатывают API-запросы и диспатчат действия по результату. Их можно проверить без UI — через мок-хранилище и анализ последовательности.

Почему важно:

📍 Проверка цепочки: запуск → результат → обработка

📍 Контроль над данными и ошибками

📍 Возможность изолировать бизнес-логику от UI

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

1. Установим зависимости:


npm install redux-mock-store redux-thunk --save-dev


2. Создадим мок-хранилища:


import configureStore from 'redux-mock-store';
import thunk from 'redux-thunk';

const store = configureStore([thunk])();


3. Пример экшена:


export const fetchData = () => async dispatch => {
dispatch({ type: 'FETCH_START' });
try {
const res = await fetch('/api/data');
const data = await res.json();
dispatch({ type: 'FETCH_SUCCESS', payload: data });
} catch (e) {
dispatch({ type: 'FETCH_ERROR', error: true });
}
};


4. Позитивный сценарий:


it('dispatches FETCH_START и FETCH_SUCCESS', async () => {
global.fetch = jest.fn(() =>
Promise.resolve({ json: () => Promise.resolve({ name: 'test' }) })
);

await store.dispatch(fetchData());

const actions = store.getActions();
expect(actions).toEqual([
{ type: 'FETCH_START' },
{ type: 'FETCH_SUCCESS', payload: { name: 'test' } }
]);
});


5. Негативный сценарий (сетевая ошибка):


it('dispatches FETCH_ERROR при сбое запроса', async () => {
global.fetch = jest.fn(() => Promise.reject('Network error'));

await store.dispatch(fetchData());

const actions = store.getActions();
expect(actions).toEqual([
{ type: 'FETCH_START' },
{ type: 'FETCH_ERROR', error: true }
]);
});


Что проверяет тестировщик:

— Последовательность действий

— Корректность переданных данных

— Обработку ошибок и fallback-поведение

— Отсутствие лишних или пропущенных экшенов

💡 Такие проверки позволяют выявлять ошибки бизнес-логики без зависимости от UI. Это удобно при регрессионном тестировании, CI и тестировании без доступа к фронту.

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

#буст
Please open Telegram to view this post
VIEW IN TELEGRAM
🤩5👍3🥰2🔥1
Первый вебинар нашего курса по AI-агентам уже прошёл!

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

Первые слушатели уже оставили фидбэки — и, кажется, мы попали в точку:
— «теперь наконец понял, как выбирать модели под задачу — раньше брал первую попавшуюся»
— «без лишнего, по делу, в лайве — кайф»
— «огонь, ожидания 100% оправданы лично у меня»

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

Ещё можно догнать и пройти всё вместе с потоком.

👉 Залетай на курс
🥰4
🖥️ Как проверить адаптивность приложения для нестандартных разрешений экрана

При тестировании приложений часто забывают про экраны с необычными разрешениями, например, 800x600 или 5K. Эти размеры требуют отдельного подхода, чтобы убедиться, что интерфейс остаётся функциональным и красивым на всех типах устройств.

Промпт:

How can I check the responsiveness of my application for screen resolutions that are rarely used (e.g., 800x600 or 5K)? What testing tools and
methods should be applied for these screen sizes?


Чем полезен:

➡️ Проверяет, как приложение ведет себя на экранах с редкими разрешениями

➡️ Помогает выявить проблемы с отображением и интерфейсом на разных типах экранов

➡️ Рекомендует методы тестирования, включая эмуляцию и использование инструментов

Дополнительно можно запросить:

— Как настроить медиа-запросы для таких разрешений

— Использование инструментов, таких как Chrome DevTools, для проверки адаптивности

— Рекомендации по улучшению интерфейса для редких экранов

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

#буст
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🤩2👍1
🕚 Почему баги в часовых поясах важнее, чем кажется

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

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

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


Были ли у вас такие проблемы с часовыми поясами? Как вы с ними справлялись?

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

#междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
8🤩3😁2