🐞 Какие баги вы считаете самыми запоминающимися

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

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

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

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

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

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

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

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

🌟 В таких ситуация главное уверенно говорить: «Да, было»

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

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

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

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

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

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

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

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

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

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

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

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

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

На одном из проектов 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 и тестировании без доступа к фронту.

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

#буст

🥹🥹

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

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

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

При тестировании приложений часто забывают про экраны с необычными разрешениями, например, 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, для проверки адаптивности

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

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

#буст

🕚 Почему баги в часовых поясах важнее, чем кажется

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

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

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

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

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

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

Как относитесь к созданию своего жпт не через конструктор, а хардкорно через код?

🔥 — я своего завайбкодил

🏃‍♀️ Ссылка на курс

😏 Фишка инструмента: кэширование авторизации между тестами

Cypress позволяет сохранять и восстанавливать сессию (cookies, localStorage, sessionStorage) при помощи команды cy.session(), чтобы логин не выполнялся перед каждым it. Это ускоряет тесты и делает их стабильнее.

Что еще полезного:

✅ Ускоряет тесты — логин происходит единожды, остальные кейсы используют сохранённую сессию

✅ Удобно для крупных e2e-сценариев с авторизацией

✅ Поддерживает несколько сессий по разным ключам (пример: для разных ролей пользователя)

Как настроить:

beforeEach(() => {
  cy.session(['[email protected]', '123456'], () => {
    cy.visit('/login')
    cy.get('input[name="email"]').type('[email protected]')
    cy.get('input[name="password"]').type('123456')
    cy.get('button[type="submit"]').click()
    cy.url().should('contain', '/dashboard')
  }, {
    cacheAcrossSpecs: false
  })
  cy.visit('/dashboard')
})

➡️ cy.session() — кэширует сессию по идентификатору (массив или строка)

➡️ На следующий it Cypress восстановит сессию, минуя повторный логин

➡️ После cy.session() обязательно добавляйте cy.visit(), чтобы перейти на нужную страницу

💡 Дополнительно:

— Используйте cacheAcrossSpecs: true, чтобы сессия сохранялась между spec-файлами при запуске cypress run --browser electron (но могут быть нюансы с Chrome)

— Для валидации сессии можно добавить validate() опцию: при неуспехе — сессия пересоздаётся

— Cypress.session API позволяет отслеживать и очищать, если необходимо

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

#буст