Хабр
IT очищается от случайных людей. И это хорошо
Прочитал статью " Как я в 2026 году ВЫШЕЛ из айти? ". Если коротко, то там про парня, который несколько лет работал на нелюбимой работе программиста. Каждая встреча — мучение, каждая задача — мучение....
🔹 За «санацию»: «случайный» – не джун и не слабый, это тот, кто пришёл за деньгами и остался без интереса к задачам. ИИ убрал механические регрессии и шаблонный код – именно то, что держало таких людей в профессии
🔸 Против радости: экспертность существует только рядом с новичками. Нет джунов – не у кого учиться объяснять, теряется рынок знаний и смена в команде
🔹 Исторический прецедент: физики-ядерщики в 90-х были лучшими в мире – и шли дворниками, потому что общество перестало нуждаться в их экспертизе
🔸 Для QA конкретно: тестировщик без любопытства к продукту находит только то, что ищет. Но и команда без джунов – это команда без роста: некому делегировать регрессию, некому тянуться в автоматизацию рядом с тобой
🔹 Рынок 2025–2026 стал фильтром дважды: сначала выдавил «случайных», теперь давит на всех через ИИ и медленный найм
Прочти обе статьи подряд – и сам реши, по какую сторону фильтра стоит находиться.
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Карьера #ITРынок #Джуны
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2👎1
💻 N1X от Nvidia: Windows-ноутбуки, которые не стыдно сравнить с MacBook?
➡️ Представьте: вы поднимаете локальную LLM в 70B параметров прямо на ноутбуке, без облака и внешнего GPU, а батарея не тает на глазах. N1X – первый реальный шанс для Windows-парка догнать MacBook по связке «мощность + автономность», а не только по маркетинговым слайдам.
❓ Что важно знать QA и разработчикам уже сейчас:
🔹 Архитектура ARM + Nvidia Blackwell: до 20 ядер CPU и GPU с 6144 CUDA-ядрами – по уровню это близко к мобильной RTX 5070, но в формате одного SoC для тонких ноутбуков. Это значит: нагрузочные тесты, UI-тесты и локальные модели больше не цепляют внешний GPU по USB.
🔸 Память и энергоэффективность: до 128 ГБ LPDDR5X и заявленный диапазон 48–80 Вт – фокус на «долго живущем» ноутбуке, а не мини-обогревателе. Сценарий: вы гоняете регрессию + несколько LLM-инструментов, и это всё ещё формат «рабочий день от батареи», а не «2 часа от розетки».
🔹 Упор на ИИ-нагрузки: в утечках фигурирует до ~180 TOPS по ИИ, а Nvidia прямо позиционирует N1X как чип под локальные нейронки и генеративные модели. Это может изменить подход к тестам – от «валидация API в облаке» к полноценным офлайн-сценариям на ноутбуке.
🔸 Экосистема Windows на ARM: Microsoft уже подогревает тему фразой «A new era of PC» и синхронным тизером с Nvidia – это значит, что софт, драйвера и DevTools под такие машины будут развиваться не только ради энтузиастов.
🔗 Ссылка на источник
#AI #news #tools #cases #Nvidia #N1X #AI4life
🔹 Архитектура ARM + Nvidia Blackwell: до 20 ядер CPU и GPU с 6144 CUDA-ядрами – по уровню это близко к мобильной RTX 5070, но в формате одного SoC для тонких ноутбуков. Это значит: нагрузочные тесты, UI-тесты и локальные модели больше не цепляют внешний GPU по USB.
🔸 Память и энергоэффективность: до 128 ГБ LPDDR5X и заявленный диапазон 48–80 Вт – фокус на «долго живущем» ноутбуке, а не мини-обогревателе. Сценарий: вы гоняете регрессию + несколько LLM-инструментов, и это всё ещё формат «рабочий день от батареи», а не «2 часа от розетки».
🔹 Упор на ИИ-нагрузки: в утечках фигурирует до ~180 TOPS по ИИ, а Nvidia прямо позиционирует N1X как чип под локальные нейронки и генеративные модели. Это может изменить подход к тестам – от «валидация API в облаке» к полноценным офлайн-сценариям на ноутбуке.
🔸 Экосистема Windows на ARM: Microsoft уже подогревает тему фразой «A new era of PC» и синхронным тизером с Nvidia – это значит, что софт, драйвера и DevTools под такие машины будут развиваться не только ради энтузиастов.
🔗 Ссылка на источник
#AI #news #tools #cases #Nvidia #N1X #AI4life
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
🔹 Переключиться на feature-ветку и вытянуть свежие изменения перед тестированием – чтобы не гонять баги на устаревшей сборке
🔸 Смотреть diff:
git diff --name-only покажет, какие файлы вообще изменились – и уже понятно, что проверять в первую очередь🔹
git blame – быстро выяснить, кто и когда трогал кусок кода, который начал падать🔸
git stash – припарковать незаконченные изменения и быстро переключиться на другую задачу без потери работы🔹 Разрешать merge-конфликты без паники: понять маркеры
<<<<<<< HEAD и >>>>>>> branch, выбрать нужный вариант, не стереть чужое🔸 Git Flow vs Trunk Based Development – понимать, в каком workflow работает команда, чтобы тестировать правильные ветки и не путать окружения
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Git #Автоматизация #DevTools
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍3❤2
🔹 Переключиться на feature-ветку и вытянуть свежие изменения перед тестированием – чтобы не гонять баги на устаревшей сборке
🔸 Смотреть diff:
git diff --name-only покажет, какие файлы вообще изменились – и уже понятно, что проверять в первую очередь🔹
git blame – быстро выяснить, кто и когда трогал кусок кода, который начал падать🔸
git stash – припарковать незаконченные изменения и быстро переключиться на другую задачу без потери работы🔹 Разрешать merge-конфликты без паники: понять маркеры
<<<<<<< HEAD и >>>>>>> branch, выбрать нужный вариант, не стереть чужое🔸 Git Flow vs Trunk Based Development – понимать, в каком workflow работает команда, чтобы тестировать правильные ветки и не путать окружения
Возьми один реальный проект с автотестами – склонируй, переключись между несколькими ветками, посмотри историю коммитов через
git log --oneline. Уже это даст больше, чем час чтения.#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Git #Автоматизация #DevTools
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3
Хабр
62 бесплатных урока июня: Java, Docker, LLM, SRE, DWH и другие темы для роста в IT
Привет, хабровчане. В июньском дайджесте собрали 62 бесплатных открытых урока по ключевым IT‑направлениям: разработке, архитектуре, инфраструктуре, информационной безопасности,...
🎓 62 бесплатных урока в июне – есть что посмотреть QA-спецу
➡️ OTUS собрал дайджест из 62 бесплатных открытых уроков по всем IT-направлениям. Для тестировщиков там есть несколько прямых попаданий и полезное рядом – по Docker, Kafka, Linux и API.
❓ Что стоит отметить QA-инженеру:
🔹 4 июня – API под контролем: тестирование сервисов с помощью Postman
🔸 4 июня – Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git
🔹 2 июня – Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ
🔸 16 июня – ИИ в автотестах: помощник или угроза?
🔹 18 июня – Тесты, которые чинят себя сами: практика ИИ в UI-тестировании
🔸 2 июня – Введение в Docker: контейнеризация приложений – нужно знать, чтобы запускать автотесты в CI
🔹 4 июня – Продвинутый Bash – полезно для автоматизаторов, которые работают с Linux-окружениями
Все уроки бесплатные, проводят практикующие специалисты, можно задать вопросы по своим кейсам. Полный список с датами и регистрацией – в статье.
🔗 62 бесплатных урока июня от OTUS – Habr
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Обучение #OTUS #Автоматизация
❓ Что стоит отметить QA-инженеру:
🔹 4 июня – API под контролем: тестирование сервисов с помощью Postman
🔸 4 июня – Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git
🔹 2 июня – Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ
🔸 16 июня – ИИ в автотестах: помощник или угроза?
🔹 18 июня – Тесты, которые чинят себя сами: практика ИИ в UI-тестировании
🔸 2 июня – Введение в Docker: контейнеризация приложений – нужно знать, чтобы запускать автотесты в CI
🔹 4 июня – Продвинутый Bash – полезно для автоматизаторов, которые работают с Linux-окружениями
Все уроки бесплатные, проводят практикующие специалисты, можно задать вопросы по своим кейсам. Полный список с датами и регистрацией – в статье.
🔗 62 бесплатных урока июня от OTUS – Habr
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Обучение #OTUS #Автоматизация
Please open Telegram to view this post
VIEW IN TELEGRAM
✍1❤🔥1🆒1
Хабр
Моки, стабы и фейки: в чем разница и что выбрать для автотестов?
Вступление Когда заходит разговор об автоматизации тестирования, слово «мок» (mock) становится универсальным ответом на любой вопрос. Нужно заменить базу данных? «Замокаем». Внешнее API тормозит?...
🧪 Мок, стаб или фейк – ты точно знаешь разницу?
➡️ «Замокаем» – универсальный ответ на любой вопрос об автотестах. Внешний API тормозит? Замокаем. База не готова? Замокаем. В итоге тесты либо падают от любого рефакторинга, либо зелёные – а на проде всё ломается. Причина в том, что stub, mock и fake – это разные инструменты с разными задачами.
❓ В чём реальная разница:
🔹 Stub – возвращает заранее подготовленный ответ. Нужен, когда важно проверить, как система обработала контролируемый ответ зависимости. Пример: FastAPI-заглушка вместо реального сервиса склада всегда отдаёт
🔸 Mock – фиксирует историю вызовов. Нужен, когда важно не только что вернула зависимость, но и как именно система к ней обращалась: сколько раз, с какими параметрами. Пример: мок SMS-шлюза с эндпоинтом
🔹 Fake – упрощённая, но рабочая реализация. Есть состояние и логика, но не для продакшена. Пример: SQLite
🔸 Как не путаться: прописал ответ вручную – стаб. Проверяешь факт вызова – мок. Используешь лёгкую рабочую замену – фейк
🔗 Моки, стабы и фейки: в чём разница и что выбрать для автотестов – Habr
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Автоматизация #Python #Mock
🔹 Stub – возвращает заранее подготовленный ответ. Нужен, когда важно проверить, как система обработала контролируемый ответ зависимости. Пример: FastAPI-заглушка вместо реального сервиса склада всегда отдаёт
{"status": "IN_STOCK"} – и тест проверяет, как сервис заказов на это реагирует🔸 Mock – фиксирует историю вызовов. Нужен, когда важно не только что вернула зависимость, но и как именно система к ней обращалась: сколько раз, с какими параметрами. Пример: мок SMS-шлюза с эндпоинтом
/_internal/history – тест проверяет, что SMS ушло ровно один раз и без дублей🔹 Fake – упрощённая, но рабочая реализация. Есть состояние и логика, но не для продакшена. Пример: SQLite
:memory: вместо Postgres – данные реально сохраняются и читаются, без харкода ответов🔸 Как не путаться: прописал ответ вручную – стаб. Проверяешь факт вызова – мок. Используешь лёгкую рабочую замену – фейк
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Автоматизация #Python #Mock
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Привёл мужик пятилетнюю дочь на работу. Девочка с интересом огляделась вокруг и начала рыдать. Все повскакивали из-за столов, бросились к ребёнку: «Что случилось? Почему ты плачешь?» А она, повернувшись к отцу, говорит: «Папа, а где же все эти клоуны и идиоты, с которыми ты работаешь?»
#mem #юмор
#mem #юмор
😁10🤣2🤡1
🧠 Учишься много – растёшь мало
➡️ 40 сохранённых статей, пройденный курс и знание терминов – но в работе ничего не изменилось. Интервью пришло, а грамотно объяснить Selenium Grid своими словами – не получается. Это не лень. Это ловушка: рост начинается не в момент чтения, а когда знание меняет решение или подход на реальном проекте.
❓ Как использовать ИИ как тренера, а не справочник:
🔹 Опиши тему своими словами – ИИ найдёт пробелы там, где ты повторяешь заученные фразы без сути
🔸 Попроси задать 5 неудобных вопросов по теме – там, где зависаешь, они проявятся сразу
🔹 Попроси перевести знание в практику: 3 мини-упражнения на сегодня, 1 сценарий из твоей реальной задачи
🔸 Спроси критерий освоения – по какому признаку ты поймёшь, что тема действительно стала твоей
🔸 Готовый промт – скопируй и подставь свою тему:
Используй этот промт на любую тему: Playwright, API-тестирование, CI/CD, test design – и проверь, что из прочитанного реально стало твоим.
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Обучение #AITools #Саморазвитие
🔹 Опиши тему своими словами – ИИ найдёт пробелы там, где ты повторяешь заученные фразы без сути
🔸 Попроси задать 5 неудобных вопросов по теме – там, где зависаешь, они проявятся сразу
🔹 Попроси перевести знание в практику: 3 мини-упражнения на сегодня, 1 сценарий из твоей реальной задачи
🔸 Спроси критерий освоения – по какому признаку ты поймёшь, что тема действительно стала твоей
🔸 Готовый промт – скопируй и подставь свою тему:
Ты — мой ИИ-методист по глубинному обучению и переносу знаний в практику.
Контекст:
Я изучаю тему: [ТЕМА].
Моя цель: [ЗАЧЕМ МНЕ ЭТО].
Мой уровень: [НОВИЧОК/СРЕДНИЙ/ПРОДВИНУТЫЙ].
Где хочу применять: [РАБОТА/БИЗНЕС/ЖИЗНЬ].
Вот что я уже понял своими словами:
[МОЙ ПЕРЕСКАЗ]
Задача:
1. Оцени, где у меня поверхностное понимание, путаница или заученные фразы без сути.
2. Задай 5 точных вопросов, которые вскроют пробелы.
3. После моих ответов объясни тему просто, но без упрощенчества.
4. Преврати знание в практику:
- 3 мини-упражнения на сегодня,
- 1 способ применить это в реальной задаче,
- 1 критерий, по которому я пойму, что действительно освоил тему.
5. В конце собери краткий план: что повторить, что проверить, что сделать в ближайшие 24 часа.
Формат ответа:
- Сначала: "Где у тебя слабые места"
- Затем: "5 вопросов на понимание"
- Затем: "Практика на 24 часа"
- Кратко, конкретно, без воды
Используй этот промт на любую тему: Playwright, API-тестирование, CI/CD, test design – и проверь, что из прочитанного реально стало твоим.
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Обучение #AITools #Саморазвитие
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11🆒1
Он получился достаточно объёмным и содержательным. Но его выпуск планируем в ближайшие дни
Накидайте реакций. Мы стараемся делать полезный контент для вас
#тестирование #шпаргалка #основы #методичка
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15❤5
УРОК №14 планируем провести в следующую
17 июня в 12.00 по МСК.
До встречи в эфире.
И не забываем своими реакциями поддерживать нас за создание крутого курса!
#python #автоматизация #курс #урок14
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥3
🔥 8 советов, которые спасут от выгорания (автор Roman Gribanov)
1. Примите реальность: идеального тестирования не существует
Исчерпывающее тестирование невозможно в принципе – это не мои слова, это аксиома из ISTQB. Количество возможных тест-кейсов для любого реального продукта стремится к бесконечности. Поэтому перестаньте пытаться протестировать всё. Переходите на risk-based тестирование: сначала анализируете вероятность дефекта и его impact для пользователя, потом расставляете приоритеты. Чётко объясняйте команде, на чём фокусируетесь и почему. Это снимает огромную часть вины и давления.
2. Введите "Правило 80/20" для тестирования
80% усилий на критические и высокорискованные сценарии. Для них – лубокие техники: equivalence partitioning, boundary value analysis, exploratory testing. 20% остального – smoke-тесты и чек-листы. Это не снижение стандартов. Это правильное распределение ресурсов пропорционально уровню риска. Именно так работают зрелые QA-команды в Google и других топ-компаниях.
Я начал так делать – и качество продукта не упало, а моё психическое здоровье сильно улучшилось.
3. Создайте личный "Recovery Protocol"
После каждого релиза у меня теперь обязательные 2 дня низкой интенсивности. Минимум новых задач. Много exploratory testing вместо жёстких чек-листов. Ранний уход домой.
Почему это работает? Exploratory testing – это не «отдых» в кавычках. Это полноценная техника с time-boxed сессиями по 30 – 120 минут, где вы сами выбираете фокус через test charter. Она требует меньше подготовки, но часто находит дефекты, которые скриптовое тестирование пропускает.
4. Введите чёткие Exit Criteria для каждого релиза
Одна из главных причин ночных доработок – размытое понимание «когда стоп». Договоритесь с командой заранее: какие условия означают, что релиз готов. Например: 0 открытых critical-дефектов, smoke-suite пройден, не более 3 major в backlog. Это профессиональный контракт, а не попытка срезать углы. И именно он даёт право сказать «стоп» в 18:00, а не в 3 ночи.
5. Делегируйте и документируйте
Перестаньте быть единственным человеком, который «знает, где может упасть». Создавайте короткие гайды и видео. Это защитит вас, когда будет совсем тяжело. А ещё сделайте risk-анализ командным: подключайте разработчиков и PO к обсуждению рисков в начале спринта. Если решение о приоритетах тестирования принято всей командой, ответственность за пропущенный баг не лежит только на вас.
6. Используйте ИИ как личного помощника
Я генерирую тестовые данные, негативные сценарии и предварительные чек-листы через Claude и Cursor. Это экономит 30 – 40% времени на рутине. Важный нюанс: ИИ отлично генерирует варианты тест-кейсов, но финальный анализ покрытия остаётся за вами. Никакой инструмент не знает историю дефектов вашего продукта лучше, чем вы.
7. Отслеживайте свой "Батарейный уровень"
Каждую пятницу ставлю себе оценку от 1 до 10. Если ниже 6 – на следующей неделе снижаю нагрузку. Звучит просто, но работает лучше любой терапии.
Хотите сделать это более объективным? Добавьте один рабочий индикатор: если за релиз вы пропустили больше 25% плановых тест-кейсов из-за нехватки времени – это сигнал тревоги, а не норма. Фиксируйте это на ретроспективе и приходите с цифрами, а не с ощущениями.
8. Помните: вы тестировщик, а не супергерой
Самое важное. Компания переживёт один пропущенный баг. А вы можете не пережить постоянный стресс и недосып.
Мой результат:
С 2024 года я ни разу не выгорал до состояния «хочу уволиться». Хотя релизы всё так же каждые 2 недели.
Вывод:
Выгорание в Manual QA при частых релизах – это не про слабость. Это про отсутствие систем, границ и чётких договорённостей с командой.
А как вы справляетесь с частыми релизами? Поделитесь своим способом в комментариях 👇
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #ManualQA #QAжизнь #Выгорание #WorkLifeBalance #RiskBasedTesting #QAтипс #QAкарьера
1. Примите реальность: идеального тестирования не существует
Исчерпывающее тестирование невозможно в принципе – это не мои слова, это аксиома из ISTQB. Количество возможных тест-кейсов для любого реального продукта стремится к бесконечности. Поэтому перестаньте пытаться протестировать всё. Переходите на risk-based тестирование: сначала анализируете вероятность дефекта и его impact для пользователя, потом расставляете приоритеты. Чётко объясняйте команде, на чём фокусируетесь и почему. Это снимает огромную часть вины и давления.
2. Введите "Правило 80/20" для тестирования
80% усилий на критические и высокорискованные сценарии. Для них – лубокие техники: equivalence partitioning, boundary value analysis, exploratory testing. 20% остального – smoke-тесты и чек-листы. Это не снижение стандартов. Это правильное распределение ресурсов пропорционально уровню риска. Именно так работают зрелые QA-команды в Google и других топ-компаниях.
Я начал так делать – и качество продукта не упало, а моё психическое здоровье сильно улучшилось.
3. Создайте личный "Recovery Protocol"
После каждого релиза у меня теперь обязательные 2 дня низкой интенсивности. Минимум новых задач. Много exploratory testing вместо жёстких чек-листов. Ранний уход домой.
Почему это работает? Exploratory testing – это не «отдых» в кавычках. Это полноценная техника с time-boxed сессиями по 30 – 120 минут, где вы сами выбираете фокус через test charter. Она требует меньше подготовки, но часто находит дефекты, которые скриптовое тестирование пропускает.
4. Введите чёткие Exit Criteria для каждого релиза
Одна из главных причин ночных доработок – размытое понимание «когда стоп». Договоритесь с командой заранее: какие условия означают, что релиз готов. Например: 0 открытых critical-дефектов, smoke-suite пройден, не более 3 major в backlog. Это профессиональный контракт, а не попытка срезать углы. И именно он даёт право сказать «стоп» в 18:00, а не в 3 ночи.
5. Делегируйте и документируйте
Перестаньте быть единственным человеком, который «знает, где может упасть». Создавайте короткие гайды и видео. Это защитит вас, когда будет совсем тяжело. А ещё сделайте risk-анализ командным: подключайте разработчиков и PO к обсуждению рисков в начале спринта. Если решение о приоритетах тестирования принято всей командой, ответственность за пропущенный баг не лежит только на вас.
6. Используйте ИИ как личного помощника
Я генерирую тестовые данные, негативные сценарии и предварительные чек-листы через Claude и Cursor. Это экономит 30 – 40% времени на рутине. Важный нюанс: ИИ отлично генерирует варианты тест-кейсов, но финальный анализ покрытия остаётся за вами. Никакой инструмент не знает историю дефектов вашего продукта лучше, чем вы.
7. Отслеживайте свой "Батарейный уровень"
Каждую пятницу ставлю себе оценку от 1 до 10. Если ниже 6 – на следующей неделе снижаю нагрузку. Звучит просто, но работает лучше любой терапии.
Хотите сделать это более объективным? Добавьте один рабочий индикатор: если за релиз вы пропустили больше 25% плановых тест-кейсов из-за нехватки времени – это сигнал тревоги, а не норма. Фиксируйте это на ретроспективе и приходите с цифрами, а не с ощущениями.
8. Помните: вы тестировщик, а не супергерой
Самое важное. Компания переживёт один пропущенный баг. А вы можете не пережить постоянный стресс и недосып.
Мой результат:
С 2024 года я ни разу не выгорал до состояния «хочу уволиться». Хотя релизы всё так же каждые 2 недели.
Вывод:
Выгорание в Manual QA при частых релизах – это не про слабость. Это про отсутствие систем, границ и чётких договорённостей с командой.
А как вы справляетесь с частыми релизами? Поделитесь своим способом в комментариях 👇
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #ManualQA #QAжизнь #Выгорание #WorkLifeBalance #RiskBasedTesting #QAтипс #QAкарьера
1👍9
📌 МЕГА подборка ресурсов для прокачки по SQL для QA, BA, SA, DA, PM, Dev и не только
Если вы работаете в IT или только начинаете путь в QA/SA/DA/Dev — знания SQL точно пригодятся.
Вашему вниманию подборка ресурсов, где можно практиковаться, готовиться к собеседованиям и улучшать навыки работы с данными.
▫️ Практика SQL-запросов онлайн
SQLBolt — короткие уроки + интерактивные задания. Отлично для быстрого старта
Mode SQL Tutorial
LeetCode SQL Problems — «база» для подготовки к жёстким интервью
HackerRank SQL Practice — задачи от easy до hard в стиле coding interview
StrataScratch — реальные SQL-задачи из FAANG-компаний
DB-Fiddle — онлайн-песочница без установки СУБД
Codewars — тысячи «ката» на SQL, можно сравнивать решения с другими
W3Resource SQL Tutorial & Tasks — 700+ задач от простых до продвинутых
DataLemur — SQL-кейсы с оконными функциями и аналитикой
SQL-ex.ru — легендарный русскоязычный тренажёр
Online SQL Playground (siql) — минималистичная песочница
SQL Academy — интерактивные задачи от простого к сложному
SQLtest.online — практика SELECT, JOIN, GROUP BY
DBQuacks — SQL-челленджи в игровом стиле
▫️ Подготовка к техническому собеседованию
InterviewBit — SQL Interview Questions
MindMajix — Top SQL Interview Questions
DataCamp — SQL Interview Questions
GeeksforGeeks — SQL for Data Analyst
▫️ Симуляторы собеседований
Pramp — SQL Interview Practice
Exercism — SQL Track
▫️ Курсы (Stepik + другие)
Интерактивный курс SQL (Stepik)
SQL Adventure (Stepik) — геймифицированный формат для новичков
Введение в SQL (Stepik) — победитель Stepik Awards 2024
Марафон данных: SQL + Python (Stepik)
Собеседование по SQL: теория и практика (Stepik)
Яндекс Практикум — Основы SQL
▫️ YouTube-каналы
Data School — SQL для анализа данных
Alex The Analyst — SQL проекты и практика
Programming with Mosh — SQL Tutorial
▫️ Квизы и тесты
W3Schools SQL Quiz
TutorialsPoint SQL Quiz
GeeksforGeeks — SQL Quizzes
▫️ Документация и AI-инструменты
PostgreSQL Docs (postgrespro.ru) — официальная документация на русском
SQL-Translator (AI) — AI переводит текст в SQL-запросы
@QA❤️4Life
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #SQL #SQLPractice #Собеседование
Если вы работаете в IT или только начинаете путь в QA/SA/DA/Dev — знания SQL точно пригодятся.
Вашему вниманию подборка ресурсов, где можно практиковаться, готовиться к собеседованиям и улучшать навыки работы с данными.
▫️ Практика SQL-запросов онлайн
SQLBolt — короткие уроки + интерактивные задания. Отлично для быстрого старта
Mode SQL Tutorial
LeetCode SQL Problems — «база» для подготовки к жёстким интервью
HackerRank SQL Practice — задачи от easy до hard в стиле coding interview
StrataScratch — реальные SQL-задачи из FAANG-компаний
DB-Fiddle — онлайн-песочница без установки СУБД
Codewars — тысячи «ката» на SQL, можно сравнивать решения с другими
W3Resource SQL Tutorial & Tasks — 700+ задач от простых до продвинутых
DataLemur — SQL-кейсы с оконными функциями и аналитикой
SQL-ex.ru — легендарный русскоязычный тренажёр
Online SQL Playground (siql) — минималистичная песочница
SQL Academy — интерактивные задачи от простого к сложному
SQLtest.online — практика SELECT, JOIN, GROUP BY
DBQuacks — SQL-челленджи в игровом стиле
▫️ Подготовка к техническому собеседованию
InterviewBit — SQL Interview Questions
MindMajix — Top SQL Interview Questions
DataCamp — SQL Interview Questions
GeeksforGeeks — SQL for Data Analyst
▫️ Симуляторы собеседований
Pramp — SQL Interview Practice
Exercism — SQL Track
▫️ Курсы (Stepik + другие)
Интерактивный курс SQL (Stepik)
SQL Adventure (Stepik) — геймифицированный формат для новичков
Введение в SQL (Stepik) — победитель Stepik Awards 2024
Марафон данных: SQL + Python (Stepik)
Собеседование по SQL: теория и практика (Stepik)
Яндекс Практикум — Основы SQL
▫️ YouTube-каналы
Data School — SQL для анализа данных
Alex The Analyst — SQL проекты и практика
Programming with Mosh — SQL Tutorial
▫️ Квизы и тесты
W3Schools SQL Quiz
TutorialsPoint SQL Quiz
GeeksforGeeks — SQL Quizzes
▫️ Документация и AI-инструменты
PostgreSQL Docs (postgrespro.ru) — официальная документация на русском
SQL-Translator (AI) — AI переводит текст в SQL-запросы
@QA❤️4Life
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #SQL #SQLPractice #Собеседование
🔥10❤1👍1
🔹 50% веса – время с последнего прогона: кейсы без запуска более 180 дней получают максимальный приоритет; Never run виртуально сразу оказываются в топе
🔸 30% веса – история провалов за 90 дней: если кейс регулярно падает при ручном прогоне – сигнал дежурному проверять чаще
🔹 10% + 10% – частота прогонов и глобальный Success Rate: мелкие модули не вытесняются крупными, для этого частота сглаживается через квадратный корень
🔸 Штраф за повторные проверки: кейс, проходивший в последние 30 дней, автоматически понижается в рейтинге – чтобы не попадать в неделю дважды
🔹 Что обнаружилось за 3–4 месяца: 24% кейсов нашли реальные баги, 46% требовали обновления, 18% ушли в архив, 11 модулей проверили впервые
Если в твоём регрессе есть кейсы, которые не запускались больше полугода – именно там скорее всего ждёт баг.
#QA #Тестирование #Тестировщик #IT #Testing #Tester #QA4Life #Регресс #TestManagement #Yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2