CPU: почему он "загружен" и что вообще происходит? 🧠

Привет, коллеги 👋

Когда вы открываете диспетчер задач (надеюсь, не только я так делаю, когда комп тормозит 😅), вы видите цифру "Загрузка ЦП: 87%". И думаете:

"Ага, значит процессор работает на 87% от своих мощей"

Ну что ж, поздравляю, вы попались: тут всё не так однозначно 🤝

🤓 Что такое CPU, если объяснять нормально без духоты
CPU (центральный процессор) - это мозг компьютера (пока все просто). Он получает инструкции от программ и выполняет их миллионы раз в секунду.
Цикл примерно такой:

получил команду → расшифровал → выполнил.

И снова. И снова.

Загрузка CPU: главная метрика, которую очень многие понимают неправильно (и я тоже, здравствуйте 👋).

"Загрузка CPU: 70%" - это не означает, что процессор работает на 70% от своих возможностей. Это означает, что процессор был НЕ в режиме простоя 70% времени. То есть метрика показывает "не-idle время" - сколько процессор вообще что-то делал, а не сидел без дела

idle - безделье

❓ А зачем это ребятам из QA?
Потому что когда мы тестируем производительность приложения, мы смотрим на загрузку CPU как на одну из ключевых метрик. Если приложение "кушает" 90% процессора при открытии одной кнопки - это красный флаг 🚩.

✨ Но тут фокус:
Загрузка процессора не покажет вам, а в чем, собственно, проблема. Она покажет следствие - процессор, чем-то был занят. Но не причину - почему он был занят?

🤔 Высокая загрузка не всегда = плохо. Процессор может быть "загружен", но при этом простаивать, например, в ожидании данных из памяти.

Это как когда вы на работе "заняты", но на самом деле сидите и ждете, пока коллега дружок-пирожок ответит в чате 🕐

🎉 Так что делать с этой информацией?
Просто запомнить несколько вещей:
✅ Процессор - это сердце компьютера, без него ничего не работает
✅ Загрузка CPU - это не показатель "насколько круто работает процессор", а показатель "насколько он вообще не сидит без дела".
✅Нужно понять, чем именно он занят. Возможно он не загружен, а просто ждёт данных

❓ А вам приходилось следить за метриками производительности в своих тестах (проектах)?

⚡️ Подписаться

#Метрика

👋 ДАЙДЖЕСТ НЕДЕЛИ!

Коллеги, привет
Посты за неделю, если вдруг что-то пропустили ↘️

✔️ Что такое DNS - начали неделю с термина

✔️ Нейронный Джейсон Стетхем - поделился своей болью о том, как нейронки забирают наши идеи... и презентовал своего бота

✔️ Вопрос с собеседования про Linux - что такое 777

✔️ Метрика загрузки CPU - разбираемся, что такое процессор и как правильно смотреть за ним

Спасибо за то, что читаете. С наступающими выходными 🥳

⚡️ Подписаться

#ИтогиНедели

Чуть не забыл про пятничный мем - исправляюсь ☺️

⚡️ Подписаться

#Хиханьки

SDET тестировщик: когда ты и жнец, и на дуде игрец, и ещё код умеешь писать 👍

Коллеги, привет! 👋

💪 Сегодня хочу рассказать про профессию фулл-стек тестировщика или, как его принято называть, SDET-тестировщик

SDET (Software Development Engineer in Test) - это такой волшебный гибрид разработчика и тестировщика

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

🧠 Если совсем просто: разработчики пишут код приложения, а SDET пишет код, который проверяет код приложения.

🤔 Чем SDET отличается от обычного QA?
Вот представьте: вы классический QA - нажимаете кнопки, проверяете формы, ищете баги "руками" или автоматизируете простые тесты. А SDET работает с готовыми инструментами тестирования (например, Selenium), выполняет тест-кейсы, репортит баги. SDET создаёт сами эти инструменты и фреймворки, пишет код для автоматизации, разбирается в CI/CD, делает нагрузочное тестирование и участвует в code review. 🏋️‍♂️

По факту: SDET - это программист с душой тестировщика. Он не просто проверяет, он строит систему проверки.

Что должен уметь SDET
(Держись, список не маленький)
✅ Программирование — Java, Python, C# или другие языки на приличном уровне
✅ Автоматизация тестирования — Selenium, Appium, JMeter, Postman и другие инструменты
✅ Работа с базами данных — SQL, NoSQL, чтобы тестировать запросы и данные
✅ CI/CD — понимать, как работает непрерывная интеграция и развёртывания
✅ Фреймворки — уметь создавать и поддерживать тестовые фреймворки с нуля
✅ Софт-скиллы — критическое мышление, решение проблем, работа в команде и адаптивность

🧐 А зачем вообще становиться SDET?
✅ Деньги (естественно) - SDET зарабатывают больше, чем обычные QA, потому что требуют больше технических навыков
✅ Влияние на продукт - SDET участвует в архитектурных решениях, работает ближе к разработчикам, влияет на качество с самого начала
✅ Карьерный рост - это специализация, которая открывает двери в более серьёзные позиции

🤨 Кому это подходит?
Если вам нравится и программировать, и искать баги - добро пожаловать! Это путь для тех, кто хочет больше технической глубины, чем даёт обычный QA, но при этом не готов уйти в чистую разработку.

А вы знали о такой должности? Или вам больше нравится ручное тестирование, где можно творчески мыслить и ломать приложение?

Знаете, где поделиться своими мыслями ⬇️

⚡️ Подписаться

#Термин

🔒 Что такое "777" в linux

😅 Задолжал вам правильный ответ на вопрос про linux. Пришла пора отдавать долги

🎰 Что вообще значат эти цифры?
В Linux каждый файл имеет права доступа для трёх групп пользователей:
✅ Владелец файла (тот, кто его создал)
✅ Группа (команда пользователей)
✅ Все остальные (буквально все)

Каждая цифра в "777" - это права для одной из этих групп. А сами права считаются так:

4 = читать (read)
2 = писать (write)
1 = выполнять (execute)

Складывате их - и получаете нужную цифру 🪄

Например,

7 = 4+2+1, то есть полный доступ ко всему.

😐 Так что такое 777?
Это когда вы говорите системе:

"Пусть ВСЕ, ВСЕГДА и ВСЁ могут делать с этим файлом"

Читать, изменять, удалять, запускать... в общем, полная анархия 🤘

🤨 Звучит удобно, правда?
Вот только есть проблема. Почему это плохая идея? Любой пользователь (или программа, или хакер) может зайти, изменить ваш файл или вообще его удалить. Для сервера это катастрофа с точки зрения безопасности.

❓А что тогда использовать?
Чаще всего достаточно 755:
- Владелец может всё (7)
- Группа и остальные могут только читать и запускать (5)

Используйте три семёрки с умом (или лучше вообще не используйте) 😅

А вы сталкиваличь с проблемами прав доступа в Linux?

Пишите в комментариях (правда, не стесняйтесь)

⚡️ Подписаться

#Термин

Рекомендательные алгоритмы ютуба слишком много обо мне знают 😅

⚡️ Подписаться

#Незапланированные_Хиханьки

📍Вы учитесь не в ту сторону! Карта сокровищ для будущего (и настоящего) QA

В начале пути в IT чувствуешь себя ёжиком в тумане 🦔. Вроде надо учить теорию, а вроде все кричат про SQL. Тут ещё какой-то Docker или лучше купить подписки на все нейронки? Голова кругом, паника, хочется просто смотреть сериал 🍿

🏖 Спокойно, коллеги, я вас понимаю
У нас есть чит-код. Существует гениальный сервис roadmap.sh. Если просто - это навигатор по профессии. Он не учит вас как писать код, он показывает, что и в каком порядке учить, чтобы не сойти с ума 🪲.
Для нас самое вкусное тут:
➡️ QA Roadmap (Карта тестировщика)
(сервис доступен со сменой айпи адреса 😔)

🤔 Зачем туда идти:
- Структура. Там всё разложено по полочкам: от "Основ веба" (как работает интернет) до стратегий автоматизации.
- Интерактивность. Можно кликать по темам, читать краткие объяснения и ссылки на ресурсы.
- Эффект RPG. Вы буквально видите дерево прокачки своего персонажа. Выучили что-то - мысленно поставили галочку. Дофамин капает, самооценка растёт! 📈

🇬🇧 "Но там всё на английском!"
Вот тут - да. Но любой современный браузер (Chrome, Яндекс, Edge) умеет переводить сайты целиком и очень качественно.
Правая кнопка мыши → "Перевести на русский".
Всё - вы великолепны!

😌 Что хочется сказать в конце
Заглядывайте туда, чтобы сверить компас. Это поможет понять, где вы сейчас находитесь. Сохраняйте в избранное (не забудьте поменять айпи адрес 🙃)

👇 А вы любите учиться по плану или хаотично хватаете всё подряд?

⚡️ Подписаться

#полезное

😱ПЯТНИЧНО-ТРИНАДЦАТЫЙ ДАЙДЖЕСТ НЕДЕЛИ!

Привет 👋
Посты, какие были за неделю ⬇️

✔️ Кто такой SDET - нам всем есть, куда расти

✔️ 777 в Linux - разобрались с правами в Linux (кстати, прикольная обложка получилась - зацените ☺️)

✔️ Сервис roadmap.sh - интерактивная карта по всем направлениям в айти (и по тестированию в том числе)

Благодарю вас за эту неделю - мне было приятно провести ее в вашей компании 😊спасибо за то, что читаете.
Сегодня остерегайтесь черных кошек 😺

⚡️ Подписаться

#ИтогиНедели

🚦Ты робот? Давай, до свидания!

Признавайтесь, у кого хоть раз потели ладошки, когда сайт просил:

"Выберите все картинки с гидрантами"?

И ты сидишь, смотришь на этот пиксель в углу и думаешь: "Это считается за гидрант или я сейчас завалю тест на человечность?" 🤖

Сегодня разбираемся с CAPTCHA (КАПЧА).📝

Что это за зверь?
Аббревиатура (а это аббревиатура) расшифровывается так:

Completely Automated Public Turing test to tell Computers and Humans Apart.

По-русски это звучит как:

"Полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей".

Да, в айти любят простые названия (нет).🧠

❓ В чем суть?
Это, по сути, обратный тест Тьюринга. Обычно человек проверяет, не робот ли перед ним. А тут бездушная машина просит тебя доказать, что ты живой человек, заставляя читать кривые буквы или считать светофоры. Ирония уровня "Архитектора из Матрицы" 😅

Зачем это нужно?
Чтобы злые боты не:
- Спамили в комментариях (хотя они все равно пытаются)
- Брутфорсили (подбирали) пароли.
- Скупали все билеты на концерты Надежды Бабкиной за 0.01 секунды (мне правда как-то не досталось билета 😟)

Почему QA-инженеры страдают из-за капчи?
Потому что мы пишем автотесты - то есть, полезных роботов, которые проверяют сайт. А капча создана, чтобы убивать роботов 🗡
В итоге:
— Тест: "Я хочу залогиниться!"
— Капча: "Найди автобус".
— Тест: падает в обморок 💥

Поэтому на тестовых стендах капчу обычно отключают. Иначе это битва, которую не выиграть.

Вопрос для статистики:
Как часто вы проваливаете капчу с первого раза? Я вот недавно не нашел "пешеходный переход" и начал сомневаться в своем происхождении... - пошел пересматривать "Бегущего по лезвию" 🍿

⚡️ Подписаться

#Термин

🧐 Что спрашивают на собесах в 2026 году: разбираем статистику с 9 000 собеседований

👋 Коллеги, привет!

📎 Нашел на просторах Хабра статью: автор собрал статистику по реальным собесам разработчиков (думаю, вам тоже будет полезно) и показывает, кого сейчас чаще собеседуют, на какие позиции и какие вопросы прилетают снова и снова.

👊 По сути, это «список частых ударов» от интервьюеров: какие темы по алгоритмам, базам, системному дизайну и языкам всплывают чаще, а какие уже не актуальны.

📈 Плюс можно понять тренд: как меняется фокус требований и где уже нельзя выезжать на старых знаниях.​

🧠 Из статьи можно составить себе чек‑лист по темам и готовиться точечно, а не «учить всё подряд».

P.S.
Самый частый вопрос -

«Расскажите про себя и свой опыт»

(68 % интервью), при этом в среднем он занимает 4 минуты, то есть около 9 % времени типичного интервью 😁


🔗 Источник

⚡️ Подписаться

#Новости

😪 Почему тестировщик тупит к концу дня - и что с этим делать

Коллеги, привет! 👋

Прошу прощения за паузу в выпуске постов - приболел, уже хотел переименовывать канал в "Сопливый Айти 🤧"

Нашёл для вас статью про то, почему к 17:00 смотришь на баг и не можешь понять - это баг или ты уже сам как баг. Спойлер: это не лень. Это когнитивная перегрузка.

Автор статьи пишет, что наш мозг - это по сути оперативка с лимитом. А теперь попробуйте загрузить туда одновременно:

• 3 тестовых окружения
• 5 разных инструментов
• требования, которые поменялись вчера
• митинг через 20 минут
• и тот баг, который «не воспроизводится»

💥 В какой-то момент мозг просто зависает.

Как написано в статье, есть три типа нагрузки на мозг (не уверен, как правильно их перевести, поэтому оставлю оригинальные названия):

🔴 Intrinsic - влияние на когнитивные способности сложности самой тестируемой системы. Если тестируешь, например, микросервисы с 40 интеграциями - то тут уж пу-пу-пу 🤔

🟡 Extraneous - бесполезная нагрузка на ваш мозг. Когда вам нужно разбираться с неполной документацией, переключаться между различными инструментами, настраивать тестовое окружение, которое «вроде такое же, но не совсем». Вот это можно и нужно убирать.

🟢 Germane - полезная. Это когда ты реально думаешь, строишь модель системы, ищешь баги. Ради этого мы и работаем.

✍️ Причины перегрузки
Тестировщики перегружаются из-за переключений между инструментами, средами, задачами, неясными требованиями и давлением сроков. Это приводит к пропуску дефектов, ошибкам и выгоранию.

Автор предлагает такие решения, чтобы не чувcтвовать себя выжатым к концу дня:

✅ Упростить процессы: шаблоны, чек-листы, централизованная документация.
✅ Автоматизация всего, что не требует думать
✅ Стандартизировать инструменты, среды и дизайн тестов.
✅ Защита фокуса - закрыть рабочий чат хотя бы на час 😟

Когда тестировщик пропускает баги - это не значит, что он «плохой специалист». Это значит, что у него перегруженная головёшка. Управляйте нагрузкой на свою менталочку - и тогда баги не спрячутся 💪

❓ А вы замечали, в какое время дня у вас пик продуктивности? (а в какое пьете больше кофе)

🔗 Источник: Managing Cognitive Load for Better Software Testing

⚡️ Подписаться

#Статья

🤔 PUT vs PATCH — в чём разница?

Коллеги, привет! 👋

Сегодняшний вопрос с собеседования позволит вспомнить отличия между двумя, на первый взгляд, похожими HTTP-методами. Уверен, вы их знаете наизусть 😅

Теперь, собственно, к самому вопросу 👇

⚡️ Подписаться

#Собес

🪲 Первый баг был НАСТОЯЩИМ жуком

Коллеги, привет! 👋

Думаю, про эту историю многие слышали, но я всё-таки расскажу её 🎧

Знаете, почему ошибки в коде называют багами? Потому что первая ошибка в истории компьютеров была буквально реальным насекомым.

Представьте: включаете ноутбук, а он глючит. Разбираете - а там таракан замкнул контакты. Вот примерно это и случилось в 1947 году.

Грейс Хоппер и её команда работали на компьютере Harvard Mark II. Огромная машина размером с комнату начала выдавать ошибки. Полезли разбираться - и нашли моль, застрявшую в реле. Моль буквально вклеили в технический журнал с подписью:

«First actual case of bug being found»

«Первый реальный случай обнаружения бага».

Вообще слово «bug» использовалось и до этого — Эдисон говорил о «багах» ещё в 1870-х. Но именно этот случай стал легендой и закрепил термин в IT навсегда.

А Грейс Хоппер - вообще легенда. Она придумала первый компилятор и дослужилась до контр-адмирала ВМС США 🫡

Тот самый журнал с приклеенной молью до сих пор хранится в Смитсоновском музее в Вашингтоне. Целая комната вычислений - и одна моль всё сломала 😄

Так что когда QA находит баг - это буквально продолжение традиции 1947 года. Мы должны быть благодарны той моли за то, что у нас есть работа 😅

А какой самый смешной или нелепый баг вы встречали в работе? 👇

⚡️ Подписаться

#Факт

🤏 Дайждест этой коротенькой недели

Привет 👋
Посты, какие были за неделю ⬇️

✔️ Как не "умереть" на работе к концу дня - советы, чтобы не чувствовать себя в оврале

✔️ Put vs Patch методы - в чем отличие этих, на первый взгляд, похожих методов

✔️ Почему баг так называется - история про жука, который перевернул мир айти

Благодарю вас за то, что были со мной эту неделю - спасибо за то, что читаете 😊
Хороших выходных

⚡️ Подписаться

#ИтогиНедели