🔍 Много багов — плохой знак или хорошее покрытие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🧩 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 минут: алгоритм построения и пример — коротко и емко про методику, подходит для быстрого освоения подхода

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

#свежак

🌸 Задача на собеседовании: проверка пользовательского ввода

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

❓ Вопрос:

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

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

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

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

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

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

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

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

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

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

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

#свежак

📌 Шпаргалка по работе с ветками и сохранению изменений в Git

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

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

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

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

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

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

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

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

#буст

⭐️ Как протестировать асинхронные экшены в 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 и тестировании без доступа к фронту.

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

#буст