Телеграм канал «QA-Логия»

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

Давай разберем шесть классических идиотских ошибок при настройке GitLab Runner. И главное — как самому найти это узкое место, пока твоя команда не смирилась с двадцатиминутными сборками и не начала ставить чайник при старте.

Читать далее
Habr

👉 QA-логия

⁣Как отвечать на вопрос «Какие книги по тестированию вы читали?» и не потерять баллы на собеседовании даже без списка литературы

Вопрос «Какие книги по тестированию вы читали?» - ловушка. Не потому что интервьюер хочет проверить начитанность, а потому что проверяет твоё отношение к профессии.

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

В чём суть вопроса? На собеседовании (middle и выше) это проверка: интересуешься ли профессией вне работы, способен ли структурировать знания, умеешь ли учиться у опыта других.

Как отвечать, если книг не читал? Худшее: сказать «нет» и замолчать. Лучшее: честно признать и объяснить, как учишься иначе.

Шаблон ответа:
- честность - «Книг от корки до корки не прочитал, это моя зона роста, но я компенсирую это другими способами»
- альтернативы - «Читаю статьи и доклады на Хабре или YouTube по конкретным проблемам. Например, при внедрении API-тестов изучил кейсы коллег. Прохожу курсы с домашкой - это даёт структуру»
- конкретика - «Из книг открывал «Как тестируют в Google» и «Путь к изучению тестирования» по ситуациям. Планирую изучить «Тестирование ДОТКОМ» Криспина для agile-контекста»
- рефрейминг - «Для тестировщика важнее умение задавать вопросы и критическое мышление. При тесте нового функционала я сначала разбираюсь в бизнес-логике, а не в техниках из книги»

Почему работает? Показываешь осознанность: не читал, но знаешь о книгах. Даёшь равноценную замену: практика, статьи, курсы. Уходишь от обороны в диалог.

Типичная ошибка - врать. Опытный интервьюер легко прощупает: спросит детали, и ты поплывёшь. Лучше честно признать пробел и показать его осознание.

Совет: прочитай хотя бы одну прикладную книгу. Например, «Тестирование программного обеспечения» Савина. Не целиком, главу про техники тест-дизайна, чтобы привести живой пример.

Книги не самоцель. Цель - системное мышление и желание расти. Если книг нет, покажи, как растёшь иначе. Честность плюс аргументация дают контроль над мячом.

А вы сталкивались с таким вопросом? Как отвечали?

Как я вкатился в Bug Bounty в 2026-м: чему меня выучил Black Box-анализ веб-морды одного IT-гиганта

Поделюсь ламповой историей про собственный опыт в багбаунти в 2026 году. В чем суть: как я влез в эту движуху, какой урок вынес из Black Box-анализа веб-приложения крупной конторы и что в итоге получилось.

👉 QA-логия

Вырастил своего агента, так сказать, получилось 🥲

👉 QA-логия

OpenAI выкатывает GPT-5.6 Sol, Terra и Luna — уже завтра!

Кое-кто уже получил ранний доступ по всему миру, так что погнали чекать. Вот это я понимаю — утро удалось

Подробнее: x.com/openai/status/2074704958419792299?s=46

👉 QA-логия

Anthropic выкатили в Х гайд по лупам для агентов — разбирайтесь, пока не прилетело

Там расписали четыре типа: агентный, целевой, временной (который по расписанию гоняет) и полностью автономные. Еще показали, как чекать результат, выставлять условия для остановки и не сливать токены вхолостую.

Тащи в закладки, если хочешь прокачать агентный код

👉 QA-логия

⁣Почему опытные тестировщики перестают жалеть разработчиков и как это делает их сильнее

Когда я только начинал в QA, я реально жалел разработчиков. «Они же пашут, сроки горят, продукт сложный, а я тут ещё баги нахожу — ну как они всё успевают?» Знакомо, наверное.

Проходит полгода-год. И замечаешь одну и ту же картину: один и тот же разраб раз за разом делает одинаковые ошибки, требования не читает, граничные случаи не проверяет, а потом искренне удивляется багу. Моя жалость сначала превратилась в раздражение. А потом — в холодное понимание: жалость просто убивает качество.

Вот что происходит, когда перестаёшь жалеть разработчиков и начинаешь относиться к ним как к равным профессионалам.

Первое. Уходит синдром спасателя. Раньше я мог промолчать, если видел, что задача недоделана, но дедлайн уже завтра. «Ну, старался человек, пусть потом патчем поправит». И что? Баг уходит в прод, мы получаем инцидент, страдает репутация QA. Когда я перестал жалеть, я начал говорить прямо: «Вот ошибка. Исправляй сейчас, иначе не приму». Разработчик злится? Бывает. Но продакшн становится стабильнее.

Второе. Развивается профессиональная жёсткость. Жалость — это эмоция. А QA — про факты. Когда жалеешь, начинаешь придумывать оправдания за другого. Опытный тестировщик вместо этого анализирует: «Почему баг вообще появился? Что в процессе пошло не так?» Так разговор переходит из плоскости «кто виноват» в «как исправить процесс». И вот тут ты становишься сильнее — ты не просто ищешь баги, а строишь систему, которая их предотвращает.

Третье. Перестаёшь бояться конфликтов. Многие джуны боятся обидеть разработчика — пишут баг-репорты в стиле «возможно, тут есть небольшая неточность». Опытный QA пишет: «Ожидаемое: А. Фактическое: Б. Приоритет — Critical». Без эмоций и извинений. И если разработчик начинает ныть: «Это не баг, это фича», ты спокойно открываешь требования и показываешь разницу. Жалость уходит, уважение приходит.

Типичная ошибка: путать профессионализм с грубостью. Перестать жалеть — не значит стать мудаком. Это значит уважать чужое и своё время.

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

Как это делает тебя сильнее. Ты перестаёшь быть мальчиком или девочкой для битья — тебя начинают слушать. Ты учишься отстаивать свою экспертную позицию, а это ключевой навык для middle и senior. Ты начинаешь видеть системные проблемы, а не только единичные баги. И перестаёшь выгорать от чувства вины за «лишние» баги.

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

Жалость — это скрытая форма неуважения к профессионализму коллеги. Когда перестаёшь жалеть, начинаешь требовать. И команда от этого только сильнее.