🔆 Когда баг не ловится

Клиент сообщает, что у него ошибка, но вы не можете её повторить. Ваши шаги?

Классическая ситуация для QA: баг «живёт» у пользователя, но у вас всё работает идеально.

🔜 Как действовать:

🔘 Собрать контекст: версия браузера, устройство, ОС, время, скрин/видео, логи.

🔘 Сравнить окружения: проверить конфигурацию продакшна, теста и staging.

🔘 Поиграть с данными: возможно, баг зависит от конкретного пользователя, роли или состояния кэша.

🔘 Записать наблюдения: даже если не воспроизводится — оформить отчёт с гипотезами и шагами.

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

Таких специалистов ищут — не тех, кто ищет баги, а тех, кто ищет истину.

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

#карьерный_трек #middle

🛎 Верификация vs Валидация

Два термина, которые звучат почти одинаково, но означают разное:

ℹ️ Верификация — делаем по требованиям. Проверяем, что система работает как описано в ТЗ.

Мы сделали правильно.

ℹ️ Валидация — делаем для пользователя. Проверяем, что система решает нужную задачу.

Мы сделали то, что нужно.

📎 На картинке выше — лучший способ запомнить разницу: коротко, смешно и по делу.

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

#теория_на_пальцах

💾 Бэкап был… но не тот

История, которая случается чаще, чем кажется.

После обновления сервис лег — стандартная процедура: откат, восстановление базы из последнего бэкапа.
Через пару минут — всё работает. Все выдохнули.

А потом начали писать пользователи:
— «Почему пропали заказы за вчера?»
— «А где новые пользователи?»

Выяснилось, что «последний бэкап» — не совсем последний.
Скрипт резервного копирования упал ещё неделю назад, но CI продолжал показывать «успешно».
Файл бэкапа был, просто не тот.

В итоге — минус неделя данных, ночная ручная реконструкция заказов и один очень печальный lesson learned.

📌 Что в итоге:

— Не доверяйте надписям «Backup OK» — тестируйте восстановление реально.

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

— Раз в квартал проводите disaster recovery drill — симуляцию аварии.

— И главное: не думайте, что беда случается только у других 🙂

❓ А вы когда-нибудь проверяли, что ваш бэкап реально восстанавливается?

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

#разбор_полетов

🔥 Гайд по UI-автотестам, часть 2

Ранее мы выкладывали часть 1, где рассматривали основы настройки стека и структуры тестов.

🆖 Теперь давайте перейдём к локаторам, тестовым данным и борьбе с нестабильными тестами.

1️⃣ Локаторы:

– Используйте data-testid или data-qa, не //div[3].

– Не ставьте sleep(). Только встроенные waitForSelector() или locator.waitFor().

2️⃣ Тестовые данные:

– Не кликайте UI ради подготовки. Поднимайте данные через API или SQL.

– Каждый тест должен быть независим — без состояния от предыдущих.

– Если нужно авторизоваться — делай фикстуру для логина.

3️⃣ Устраняйте «флейки»:

– Если тест падает нестабильно, не добавляйте ретрай, найди причину.

– Тесты, которые часто ломаются, пометь @flaky и заведи задачу.

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

#тест_драйв

💰 Сколько стоит ноутбук тестировщика

Видели тут спор: одни говорят, что для тестирования хватит любого ноута за 50к, другие настаивают на топовых конфигурациях за 200k+.

🔜 Давайте соберем реальную картину — напишите:

— Что у вас сейчас (модель + конфиг)

— Сколько стоил

— Хватает ли для ваших задач

Может, наконец выясним, какое железо реально нужно QA, а где просто маркетинг? 🤔

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

💳 Чит-лист планирования тестирования

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

🆖 Подходит для разработки тест-планов, проведения тестов и оценки качества работы системы.

Сейчас на курсы Proglib действует −40%🥰

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

#артефакт

🙂😡 Positive vs Negative Testing

Два подхода, которые определяют, как мы «бьем по системе» — и делают это по‑разному:

🆚 Positive Testing — проверяем, что система делает то, что должна.

➰ Вводим правильные данные → ожидаемый результат.

Мы делаем то, что должно работать.

🆚 Negative Testing — проверяем, что система не ломается, когда пользователь ошибается.

➰ Вводим неправильные данные, неожиданные сценарии → система должна корректно обработать.

Мы проверяем «что если всё пойдет не так».

📎 На картинке выше — лучший способ запомнить: «Positive — радуем систему, Negative — проверяем её стойкость».

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

#теория_на_пальцах

🦾 Инструмент для автоматизации UI-тестирования

QF-Test — кроссплатформенное решение для автоматизированного тестирования графического интерфейса.

Что поддерживает:

➕ Java- веб-, Windows- и мобильные приложения.

Ключевые особенности:

🟡 Record & Replay — создание тестов без программирования

🟡 Low-code подход — удобен для тестировщиков и аналитиков

🟡 Поддержка скриптов (Python/Jython, JavaScript, Groovy)

🟡 Кроссбраузерное тестирование (Chrome, Firefox, Edge, Safari)

➕ Доступна бесплатная триал-версия без ограничений (по запросу)

🔗 Ссылка на инструмент

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

#тест_драйв

📌 Шпаргалка по ручному тестированию

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

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

#артефакт

🤌 Тестирование на старте разработки

Когда начинается тестирование? На старте разработки или уже в процессе? Оценим, как раннее вовлечение QA влияет на результат.

❓ Как вы считаете, стоит ли тестировать сразу:

👍 — Да, чем раньше, тем лучше

❤️ — Нет, тесты должны быть в конце разработки

Сейчас на курсы Proglib действует −40%🥰

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

#стендап_qa