С понедельником!

Нашли интересный сайт для обучения SQL — SQL Noir — Detective SQL Game.

Этот проект представляет собой интерактивную обучающую платформу в жанре детектива, ориентированную на развитие навыков работы с базами данных. Пользователю предоставляется набор данных и краткое описание (*бриф*), в котором изложен контекст задачи, цель расследования и критерии поиска информации.

На платформе представлено шесть кейсов, каждый из которых включает полноценную базу данных с продуманной структурой. Первые задания относительно просты и интуитивно понятны, однако по мере прохождения сложность возрастает — от базовых запросов SELECT до использования JOIN и подзапросов. Таким образом, проект предоставляет эффективный и увлекательный способ практиковаться в SQL и совершенствовать аналитическое мышление в оригинальной нуарной атмосфере.

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

Вот ссылка: https://www.sqlnoir.com

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

1. Игры для практики Git-команд

▪️Oh My Git! — настольная и компьютерная игра с Git-картами.
https://ohmygit.org

▪️Git Game — консольная игра с заданиями на использование Git-команд.
https://github.com/git-game/git-game

▪️Git-It — упражнения на клонирование, push/pull и работу с GitHub.
https://github.com/jlord/git-it-electron

2. Интерактивные тренажёры

▪️Learn Git Branching — визуальный тренажёр для работы с branch, merge и rebase.
https://learngitbranching.js.org/

▪️Visualizing Git — симулятор Git-команд в реальном времени.
https://git-school.github.io/visualizing-git/

3. Практика с GitHub

▪️GitHub Skills — официальные мини-курсы от GitHub с практическими заданиями.
https://skills.github.com/

Эти ресурсы помогут прокачать навыки работы с Git и GitHub в более увлекательной и наглядной форме.

❓Вопросы работодателю на собеседовании, шпаргалка для QA-инженера

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

▫️Про продукт и пользователей
- Кто ключевые пользователи продукта и их главные сценарии?
- Какие метрики продукта сейчас важнее всего (активация, ретеншн, конверсия)?
- Как принимаются решения о фичах: на основе данных, исследований, запросов клиентов?

▫️Про процессы разработки и тестирования
- Какой процесс разработки (Scrum/Kanban/гибрид)? Длина спринта?
- Когда и как QA подключается к задаче: на этапе требований, дизайна, планирования?
- Есть ли Definition of Ready/Done для задач и багов?

▫️Про качество и метрики
- Какие метрики качества вы отслеживаете (defect leakage, escape rate, MTTR, флейки, покрытие)?
- Есть ли цель по снижению багов на проде и как её измеряете?
- Как анализируете регрессии и инциденты (post-mortems, RCA)?

▫️Про релизы и окружения
- Как часто релизитесь и есть ли релизный календарь?
- Сколько стендов (dev/test/stage/prod) и насколько они похожи на prod?
- Кто и как может откатить релиз? Есть ли фича-флаги/канареечные выкладки?

▫️Про автоматизацию и инструменты
- Где проходит граница между ручным и авто-тестированием?
- Какие стеки используете (Selenium/Playwright/Appium, CI/CD, отчётность, мониторинг)?
- Что считается «готовой» автотестовой задачей (стандарты, ревью, покрытие)?

▫️Про баги и приоритизацию
- Как приоритизируете дефекты (S1–S4/P0–P3)? Кто финально решает «критичность»?
- Как быстро исправляются S1/S2? Есть ли SLA/OLA по реакциям?
- Как боретесь с флейками и «битой» регрессией?

▫️Про роль, ожидания и рост
- Как выглядит успех на 30/60/90 дней для этой роли?
- С чем я приду в первый спринт? Какие 2–3 приоритеты?
- Есть ли менторство, бюджет на обучение/сертификации, путь роста (IC/Lead)?

▫️Про команду и культуру
- Как устроено взаимодействие QA с продактом, дизайном, бэком/фронтом, DevOps?
- Как дают обратную связь и как часто проходят 1:1?
- Как команда относится к долгам: техдолг, тестдолг, документация?

▫️Про оффер и условия (уместно на финальном этапе)
- Смена формата работы (офис/гибрид/удалёнка), график, овертаймы и компенсация за них.
- Испытательный срок, грейд/вилка, бонусы, ДМС/оборудование.
- Процесс онбординга и кто будет моим «buddy» в первые недели.

🚩 Красные флаги
- Нет тестовых окружений, релизы «по ночам», откаты «вручную».
- Отсутствие метрик качества и пост-мортемов («просто чиним»).
- QA подключается только «в конце», нет времени на регрессию.
- «Автотесты есть», но никто не может показать отчёты/стабильность.

🍭 Мини-скрипт в конце интервью
«Спасибо за ваше время. Есть ли что-то в моём фоне, что вызывает сомнения? Я буду рад прояснить сейчас».
Если ответ "да", то вы получили шанс закрыть гештальт сразу. Если "нет", то мягко уточните следующие шаги и сроки обратной связи.

Источник: Владлен Цыганенко

ИИ для тестировщика: инструменты, которые уже меняют профессию

ИИ уже генерирует тест-кейсы, создаёт тестовые данные и помогает писать автотесты. Но какие инструменты действительно экономят время QA-инженера, а какие пока остаются скорее маркетингом?

2 сентября в 20:00 МСК на открытом вебинаре OTUS вместе с Татьяной Березенцевой разберём, как использовать ИИ в ручном и автоматизированном тестировании и какие задачи уже сегодня можно передать AI-ассистентам.

На практике рассмотрим:
— генерацию тест-кейсов и тестовых данных;
— помощь ИИ при написании автотестов;
— сценарии, где AI действительно ускоряет работу тестировщика;
— возможности Testim, Mabl и GitHub Copilot;
— навыки, которые становятся особенно важными для QA-инженера в эпоху ИИ.

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

Урок проходит в преддверии старта курса «Автоматизатор тестирования на JavaScript».

👉 Регистрируйтесь: https://vk.cc/d13Wn6

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

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

🔥 ТОП-10 бесплатных расширений Chrome, которые упрощают работу QA

Собрали 10 действительно полезных расширений Chrome, которые делают работу QA гораздо проще👇

▫️ Postman Interceptor
Перехватывает HTTP-запросы из браузера и отправляет их напрямую в Postman — удобно для тестирования API.
🔗 https://www.postman.com/product/postman-interceptor

▫️ JSON Formatter
Форматирует JSON-ответы в удобную читаемую структуру — must-have для валидации API.
🔗 https://chrome.google.com/webstore/detail/json-formatter/bcjindcccaagfpapjjmafapmmgkkhgoa

▫️ SelectorGadget
Помогает быстро получать CSS-селекторы элементов — незаменимо для UI-тестирования и автоматизации.
🔗 https://selectorgadget.com

▫️ Lighthouse
Генерирует подробные отчёты о производительности, доступности и SEO прямо в браузере.
🔗 https://developer.chrome.com/docs/lighthouse/overview/

▫️ Window Resizer
Меняет размеры окна браузера — идеально для проверки адаптивности.
🔗 https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh

▫️ Checkbot
Сканирует сайт на технические ошибки: битые ссылки, SEO-проблемы, вопросы безопасности.
🔗 https://www.checkbot.io

▫️ Web Developer
Добавляет в браузер мощный набор инструментов для работы с HTML, CSS, cookies и многим другим.
🔗 https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm

▫️ Session Buddy
Сохраняет все открытые вкладки и позволяет в один клик восстановить сессию — незаменимо, если у вас «100+ вкладок» 🤯
🔗 https://sessionbuddy.com

▫️ ColorZilla
Позволяет брать цвета с любого участка страницы — удобно для проверки UI-консистентности.
🔗 https://www.colorzilla.com/chrome/

▫️ uBlock Origin Lite
Блокирует рекламу и сторонние трекеры, делая тестирование интерфейса чище и стабильнее.
🔗 https://chrome.google.com/webstore/detail/ublock-origin-lite/ddkjiahejlhfcafbddmgiahcphecmpfh

Какие расширения в Chrome помогают вам больше всего?

⏳ Эстимация в тестировании. Шпаргалка 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
▫️Документируйте свою эстимацию: что учитывали, чего нет и почему

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

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

Насколько этично и допустимо обсуждать свою ЗП, как думаете?

Как правильно отчитываться на дейли-митингах / стендапах / летучках?
Источник: Максим Азаров, Software Testing QA Lead в SAM Solutions

За много лет работы я заметил одну и ту же особенность в командах.

Есть категория людей, которые не любят долго распинаться, предпочитают говорить минимум и в общем предпочитают не отсвечивать. От них обычно слышно что-то типа «Я на автоматизации», или «Я баг проверяю», или «Я стори делаю» и всё. Ни рассказа о находках и преодолённых трудностях, ни эстимейтов, когда закончит, ни любых других интересных или познавательных деталей. Всю остальную информацию приходится вытягивать клещами и наводящими вопросами.

Есть другая категория людей, которые, наоборот, любят говорить долго, погружают всех окружающих в кучу технических деталей, рассказывают свои мысли, о том, как они думали, какие решения принимали, где ошиблись, а где, наоборот, придумали гениальные решения. Так минут на 10–15. Эти товарищи часто очень обижаются, если их прерывают и просят сформулировать статус в 2–3 предложениях. И тут обратная ситуация: идёт перегруз информацией, и человек вне контекста очень быстро теряет смысл происходящего, а у человека, собирающего статус и оценивающего общую ситуацию на проекте, начинает кипеть мозг от лишней информации.

Так нужен ли на самом деле алгоритм? И для кого на самом деле эти митинги? Для менеджера, чтобы собрать статус, или для членов команды, чтобы понимать, что вообще происходит и кто что делает на проекте?

Короткий ответ: Митинг этот для всей команды, но с разными целями для разных ролей.

Для команды (разработчиков, тестировщиков, дизайнеров и т.д.) это синхронизация:
а) Узнать, что сделали другие, чтобы не работать в вакууме.
б) Обнаружение блокеров: услышать, у кого возникли проблемы, и предложить помощь («Я сталкивался с такой ошибкой, посмотри вот в этот конфиг»).
в) Понимание контекста: увидеть общую картину движения к цели спринта.
г) Обмен знаниями: узнать о новых подходах, технологиях или проблемах, с которыми столкнулись коллеги.

Для менеджера / тимлида / скрам-мастера это:
а) Сбор статуса: получить общее представление о прогрессе.
б) Выявление рисков: увидеть препятствия, которые мешают команде, и оперативно их устранить.
в) Оценка нагрузки: понять, всё ли по плану или нужны корректировки.

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

Предположительно правильный алгоритм отчёта должен укладываться в 3-4 предложения и длиться не более 1-2 минут. Он должен содержать ответы на три ключевых вопроса:
1. Что я сделал вчера? (По отношению к цели спринта)
2. Что я планирую сделать сегодня? (Опять же, для движения по задачам)
3. С какими трудностями столкнулся? (Блокеры, риски, вопросы)

Плохо: «Я кодил, потом тестил, потом ещё покодил».

Хорошо: «Вчера я завершил разработку API для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».

А как это работает в ваших командах ?