было?)

⏳ Эстимация в тестировании. Шпаргалка QA-инженера

Вы тестировщик. Вам дают задачу и спрашивают: "Сколько времени займёт тестирование?" Если вы растерялись или назвали "на глаз" то эта шпаргалка для вас.

Что такое эстимация?
Эстимация это оценка времени, усилий или ресурсов, необходимых для выполнения задачи.

🎯 Цель: спрогнозировать сроки с учётом реалий проекта, не быть вечно "в тестировании" и не торопиться в ущерб качеству.

Виды эстимации:
▫️Грубая (Rough Estimate): ещё нет деталей, называют вилку: 3–5 дней, неделя и т.д.
▫️Точная (Detailed Estimate): задача проработана, можно оценить каждую часть.
▫️Оценка на основе опыта (Expert Judgment): делается вручную, с опорой на прошлые задачи.
▫️Planning Poker / Wideband Delphi: командные методы, где оценки обсуждаются коллективно.

Что влияет на эстимацию?
▫️Объём и сложность фичи
▫️Доступность тестовой среды
▫️Готовность документации
▫️Время на регрессию
▫️Количество поддерживаемых платформ
▫️Интеграции с другими сервисами
▫️Риски и неопределённость
Не забывайте про багфиксы и ретесты!

Формулы и техники:

Three-Point Estimate (PERT)
Это метод оценки задач, основанный на трёх сценариях:
▫️(Optimistic) оптимистичная оценка: если всё пойдёт идеально, сколько займёт времени?
▫️(Most likely) наиболее вероятная оценка: сколько времени займёт задача при обычных условиях?
▫️(Pessimistic) пессимистичная оценка: если всё будет плохо (баги, блокеры), сколько максимум может занять?
Формула:

(O + 4×M + P) / 6

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

Пример:
Вы оцениваете задачу по тестированию фильтра товаров.
▫️(оптимистично) = 2 часа
▫️(наиболее вероятно) = 4 часа
▫️(пессимистично) = 10 часов
Estimation = (2 + 4×4 + 10) / 6 = (2 + 16 + 10) / 6 = 28 / 6 ≈ 4.67 часа

Когда использовать PERT?
▫️Когда много неопределённостей
▫️Когда нет достаточной статистики из прошлого
▫️Когда задача может зависеть от сторонних факторов (дизайн, API, баги и т.д.)

Work Breakdown Structure (WBS):
Разбиваем задачу на подзадачи → оцениваем каждую → суммируем.

Buffer (буфер):
Добавьте 15–25% времени на непредвиденные задачи, если это допустимо проектом.

Как улучшить эстимацию?
▫️Делайте разбор задачи и не оценивайте "вслепую"
▫️Уточняйте требования и тест-кейсы
▫️Учитывайте риски: нестабильность билда, баги, блокеры
▫️Ведите учёт времени и он пригодится для будущих оценок
▫️Общайтесь с командой: Dev, PM, дизайнеры, BA
▫️Документируйте свою эстимацию: что учитывали, чего нет и почему

Что НЕ стоит делать:
▫️Давать оценку, не прочитав задачу
▫️Согласовываться на словах, лучше фиксируйте эстимейт письменно
▫️Обещать закончить быстрее "на всякий случай"
▫️Игнорировать командные дедлайны и приоритеты

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

🔥Увидели обучение, которое действительно стоит внимания — делимся!

Наши коллеги из QA.GURU обновили программу авторского курса «Автоматизация тестирования на Python Advanced». Нас зацепил подход — ребята дают реальную практику с живыми задачами ⚙️

Что предлагают освоить за 4 месяца👇

— Python 3.12, разработку микросервисов на FastAPI, Docker, Postgres.
— gRPC, GraphQL, SOAP.
— Базы данных, Kafka, docker и docker-compose.
— Создать весь код с нуля. Исследовать, как работает бекенд на Python / FastApi и Java / Spring под капотом.

💡Удобный формат обучения — записи + живые консультации. Поддержка на каждом этапе.

▶️ Подробная программа курса
Оставить заявку — @qa_guru_sales4

🔔Кстати, уже в этот четверг, 24 июля, в 20:00 по МСК состоится бесплатное вводное занятие — отличный шанс убедиться, что обучение того стоит, и приобрести его со скидкой 5%.

Регистрируйтесь, если готовы к новой ступени в автоматизации.

🤖 Почему ИИ не заменит тестировщиков, а только усилит их роль?

Я лид тестирования и вижу, как активно ИИ меняет нашу работу. Расскажу коротко о ключевых изменениях:

🧪 Генерация тестов
ИИ научился генерировать сценарии из документации и требований. Даже из обычного текста. Это ускоряет создание тестов и экономит время.

🛠 Автоисправление тестов
ИИ умеет анализировать результаты и самостоятельно чинить упавшие тесты. Меньше рутины, больше смысла.

🔍 Умная регрессия
Используя ИИ-агентов, можно быстро сравнить ветки и определить затронутые компоненты. Traceability-матрица на максималках.

🔐 Тестирование безопасности промтов
ИИ создал новый вид проверок, чтобы промты не стали уязвимостью системы. Так что работы у нас теперь даже больше =)

🚀 Что это значит для нас?
ИИ не заменит тестировщиков, но серьёзно расширит наши возможности. Автоматизация рутины и анализ результатов освободят время для сложных и творческих задач.

📈 Что дальше?
ИИ будет играть всё большую роль в тестировании, помогая быстрее и качественнее выводить продукты на рынок. Это не замена специалистов, это их апгрейд.

Автор: Evgeniy Zhiltsov, Head of QA

Как продать себя на собеседовании? Советы от QA с 14 годами опыта

Я больше 14 лет проработала в EPAM. Сначала 8 лет была тестировщицей, а потом в течение 6 лет руководила учебной лабораторией. За это время я провела множество собеседований: брала людей на работу и на учёбу. Поделюсь главными правилами, которые помогут вам пройти интервью.

Читать

🚀 Как выстроить автоматизированное тестирование на проекте: пошаговый подход для Java QA Automation!

Запускать автоматизацию без стратегии — как строить дом без фундамента. Делюсь проверенным пошаговым планом:

1. Анализ и цели
Определите, зачем нужна автоматизация:
+ускорение регрессии,
+повышение стабильности,
+сокращение ручного труда?

2. Выбор стека
Инструменты зависят от технологий проекта:
Web → Playwright/Selenium,
API → RestAssured/HttpOK,
Mobile → Appium/XCUI.

3. Архитектура и структура тестов
Пишем читаемые, масштабируемые тесты.
Используем PageObject, слои абстракции, паттерны, еще можно добавить BDD Сucumber для читаемости тестов и Allure Report для отчетов.

4. Интеграция в CI/CD
Тесты должны запускаться автоматически при коммите/релизе в
Jenkins, GitHub Actions, GitLab CI — must-have.

5. Метрики и репорты
AllureReport, TestRail, custom dashboards — всё, что помогает команде видеть реальную картину результата работы тестов.

6. Поддержка и масштабирование
Автотесты — это код. Ревью, рефакторинг, документация. И регулярная чистка "мёртвых" тестов.

💡 Главное — автоматизация должна приносить ценность команде, а не просто "быть".

автор: Олег Журавлев, QA Automation в PashaPay

Привет, QA-инженеры 👋

Сегодня мы подготовили подборку из 5 классных книг для обучения soft-skills и управлению проектами:

▫️Искусство Agile-разработки
▫️Scrum. Революционный метод управления проектами
▫️Agile-трансформация. Готовый план перехода к гибкой бизнес-модели организации
▫️Эпоха Agile. Как умные компании меняются и достигают результатов
▫️Agile для всех. Создание быстрой, гибкой, клиентоориентированной компании

Эти (и многие другие книги по soft-skills и управлению проектами) вы можете найти на канале Библиотека PM. Там регулярно публикуются свежие книги на русском языке. Все книги публикуются для ознакомления.

➡️ Подписаться на Библиотеку PM

пришли к взаимопониманию)

🔐 JWT (JSON Web Token), шпаргалка для QA-инженеров

Что это такое?
JWT это компактный и безопасный способ передачи информации между участниками. Чаще всего применяется для аутентификации и авторизации в API.

Структура токена
JWT состоит из трёх частей, разделённых точками: Header.Payload.Signature

Пример:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImFkbWluIjp0cnVlfQ.sQ9e2RW7m8Jxv-cMcwBzNnSGNTHsIHoTPkWa-dkgOP4

1. Header - метаинформация:

{
 "alg": "HS256",
 "typ": "JWT"
}

2. Payload - полезная нагрузка:

{
 "user_id": 123,
 "admin": true,
 "exp": 1725650000
}

3. Signature - цифровая подпись:
Подписывается секретным ключом или приватным RSA-ключом.

Где используется
▫️Авторизация: Authorization: Bearer <токен>
▫️Обновление сессии через refresh token
▫️API-тесты в Postman, curl, автотестах

Преимущества
▫️Stateless - сервер не хранит сессии
▫️Удобен в API-авторизации
▫️Быстрая проверка токена

⚠️ Что важно проверить QA-инженеру
▫️Срок действия (exp)
▫️Просроченный токен → 401 Unauthorized
▫️Проверьте реакцию API при истечении срока
▫️Payload не зашифрован
▫️Любой может его прочитать
▫️Убедитесь, что в Payload нет паролей, токенов и личных данных
▫️Подпись токена
▫️Проверьте, что сервер её проверяет
▫️Подмена alg: none не должна быть допустима
▫️Доступ по ролям
▫️Пользователь не должен получить доступ к чужим данным
▫️Подмена Payload не должна менять права доступа

Поведение API:
▫️Без токена → 401
▫️С некорректным токеном → 401 или 403

🛠 Инструменты
▫️ jwt.io - удобный декодер и проверка подписи
▫️Postman - вставка токена в Authorization
▫️Charles/Burp - перехват токена, проверка подмены

Автор: Vladlen Tsiganenko

🚀 Не стройте ракету, пока не собрали бумажный самолёт

Один из главных рисков в запуске IT-продукта — застрять в бесконечной доработке и не выйти на рынок.

В комьюнити Короче, Капитан делают по-другому.

Челлендж: 12 запусков за 12 месяцев.

✅ Разработка и запуск — за 1 месяц
✅ Минимальные вложения (средний бюджет на продвижение — $150)
✅ Честный разбор: что получилось, а что — нет

Формула проста:
1 запуск = 1 функция = решение 1 проблемы

Три главных правила:
⚡️Проверенный спрос, а не догадки
⚡️ Быстрый запуск без перфекционизма
⚡️ Только США и ЕС — там платят за удобство

📎 Канал Короче, Капитан показывает запуск, продвижение и доход по каждому продукту в реальном времени.
🧩 Без иллюзий, без теорий — только работающие подходы и реальные цифры.

👉 Подписаться: @its_capitan

🛠 Новый тренажёр для QA: практика работы с Chrome DevTools

📍 Ссылка: https://aklimenkoschool.ru/simulators/devtools/

Если вы только начинаете тестировать web или хотите разобраться с возможностями DevTools — этот тренажёр для вас. Он поможет восполнить пробелы и научиться применять инструменты браузера в повседневной работе.

🔍 Сейчас доступны четыре вкладки:

▫️Elements — редактирование DOM и инспекция элементов
▫️Console — работа с ошибками и выполнение JS-команд
▫️Network — анализ запросов и ответов сервера
▫️Application — взаимодействие с хранилищем и куками

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

Автор: Алексей Клименко — QA Engineer в Ozon Tech

- как у вас с Excel?
- ну был год назад, но сейчас я ношу L

Бесплатные курсы Coursera по искусственному интеллекту:

🧠 Основы AI

▫️AI For Everyone от DeepLearning. AI (Andrew Ng)
Введение в ИИ, значение и применение в бизнесе и обществе. Подходит для любого уровня.

▫️Introduction to Generative AI от Google Cloud
Быстрый часовой курс, который познакомит с концепцией генеративного ИИ

▫️Generative AI for Everyone от DeepLearning. AI
Углублённый обзор возможностей GenAI: LLM, prompt engineering


💻 Prompt‑engineering и работа с LLM

▫️Prompt Engineering for ChatGPT от Vanderbilt University
Понимание подходов к формулировке запросов для высокоэффективного взаимодействия с моделями

▫️Generative AI with Large Language Models от DeepLearning. AI + AWS
Техники дообучения моделей, оценка результатов, развертывание LLM-проектов


🌐 AI в бизнесе и обществе

▫️AI, Business & the Future of Work от Lund University
Анализ влияния ИИ на бизнес-процессы, карьеру и организационные изменения

▫️Ethics of Artificial Intelligence от Политехники Милана
Этические, социальные и философские аспекты внедрения технологий ИИ

🧩 Технологические навыки

▫️Introduction to Artificial Intelligence (AI) от IBM
Обзор зон применения ИИ, знакомство с технологиями машинного обучения

Что думаете по этому поводу?

📃 Как читать логи ошибок: инструкция для QA-инженера

🔍 Шаг 1: Где искать логи?
Перед анализом нужно понять, куда приложение пишет логи:
- Файлы на сервере (обычно в /var/log/ или logs/):
- Консоль разработчика (Chrome DevTools → Console или Network)
- Специальные сервисы:
- Sentry (для ошибок в проде)
- Kibana (если логи хранятся в Elasticsearch)
- Grafana (для метрик и системных логов)

📌 Шаг 2: Понимаем структуру лога
Типичная запись в логе содержит:
[2024-02-20 14:30:45] ERROR [app.controller] Status 500: NullPointerException in UserService.java:124
Разбираем по частям:
1. Дата и время (2024-02-20 14:30:45) - когда произошла ошибка
2. Уровень логирования (ERROR) - насколько всё плохо:
- DEBUG/TRACE - техническая информация для разработчиков,
- INFO - обычные события (например, «Пользователь залогинился»),
- WARN - потенциальная проблема, но приложение работает,
- ERROR - критическая ошибка (нужно чинить)
- FATAL/CRITICAL - самая высокая степень критичности (срочно чинить в первую очередь)
3. Источник (app.controller) - где случилась ошибка (класс/модуль)
4. Сообщение (NullPointerException in UserService.java:124) - суть ошибки и строка кода

🛠 Шаг 3: Как искать причину ошибки?
1. Ищем stack trace (список вызовов функций, которые привели к определенной точке в программе, например, к возникновению ошибки)
Пример:
java.lang.NullPointerException: Cannot invoke "User.getName()" because "user" is null
at com.example.UserService.getProfile(UserService.java:124)
at com.example.UserController.showProfile(UserController.java:45)
Что важно:
- Первая строка - тип ошибки (NullPointerException) и её описание
- Следующие строки - «путь» вызова методов (где началась ошибка и как она распространялась)

2. Анализируем контекст
Ошибка может не иметь очевидной причины. Проверьте:
- Что происходило перед ошибкой? (логи за 5-10 секунд до сбоя)
- Были ли похожие ошибки раньше? (поиск по логам)

3. Используем фильтры
Если логов много, сужаем поиск:
grep "NullPointerException" error.log (только ошибки этого типа)
grep -A 5 -B 5 "ERROR" app.log (+5 строк до/после ошибки)

💡 Шаг 4: Частые ошибки и как их читать
1. NullPointerException (Java)
Проблема: Обращение к объекту, который null
Что проверить:
- Передавались ли все обязательные параметры в метод?
- Вернула ли БД null вместо объекта?

2. 500 Internal Server Error
Проблема: Ошибка на сервере
Что проверить:
- Логи сервера (например, nginx или tomcat)
- Не упала ли БД или внешний API

3. ConnectionTimeout
Проблема: Сервер не ответил за отведённое время
Что проверить:
- Доступен ли сервер? (ping или telnet)
- Не перегружен ли он? (логи нагрузки CPU/RAM)

Автор: Aleksandra Primako, QA Engineer в 2V Modules

у вас такое практикуют? 😁

Это база! Рассказываю о бесплатных функциях Google Календаря, которые упростят вашу жизнь

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

Читать

Почему автоматизаторы не заменят QA?

Когда я только начинал в автоматизации, казалось, что скоро автотесты заменят всех QA. Зачем вручную проверять, если можно написать код который быстрее и надёжнее (что не скажешь про фронтовые тесты).

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

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

Мануальщики - не кнопкодавы 😄
Хороший мануальщик - это не тот, кто просто "щёлкает по кнопочкам". Это тот, кто:
- умеет быстро находить баги там, где их не ждут,
- знает продукт вдоль и поперёк,
- ловит непредсказуемые сценарии и нестандартное поведение,
- сопровождает фичу до релиза.
И что самое важное - делает это в моменте, гибко, по ситуации.

Где автоматизация нужна?
Автотесты идеальны там, где:
- надо проверять одно и то же 100 раз (регресс, smoke),
- важна скорость и повторяемость (CI/CD),
- высокая цена ошибки, и нужен гарантированный результат.
Например, перед продом - тесты пробежались, старый функционал не сломан, всё зелёное - спокойно катимся.

Где без QA - никуда? Почти везде! Например:
- Исследовательское тестирование. Когда надо "поиграться" с новой фичей и посмотреть, как она вообще себя ведёт.
- UX-тестирование. Автотест не скажет: "а вот тут неудобно, и кнопка непонятная".
- Быстрая проверка бага с прода.
- Тестирование сложных визуальных сценариев. Привет, drag’n’drop, канвасы, таблицы и карты.

Это разные роли, а не борьба
- QA - это глаза и интуиция проекта. Это первый человек, кто скажет: "Ребят, кажется, пользователю тут будет неудобно".
- AQA - это защитник от регрессий и "уже проверенных" багов. Он покрывает логику кодом и не даёт продукту откатиться назад.
Это не замена, а синергия.
Это как повар и посудомоечная машина - ты можешь ускорить процесс, но без человека вкусный ужин не получится.

Как жить вместе?
У нас сейчас на проекте работает связка:
- QA исследуют, проверяют сложные кейсы, общаются с бизнесом.
- AQA покрывают всё, что можно автоматизировать: smoke, регресс, критичные пути.
Мы делимся знаниями, вместе пишем тест-кейсы, вместе рефачим автотесты, если вдруг нужно. И это работает.

И пока продукт делают люди для людей - ручное тестирование будет жить. А автоматизация - это не замена ручного тестирования. Это просто другой инструмент. Она рядом, чтобы не отвлекать QA на рутину и дать им возможность увидеть больше. 😊

Автор: Сергей Александров, QA Automation Engineer в AK Bars Digital

о, это я

Хороших выходных!