Бесплатные адвенты, «практика в реальных условиях», «с нуля до PRO», тысячи отзывов и наград. Разбираю типовую модель, по которой в 2026 году продают иллюзию входа в QA — и почему она редко приводит к реальной работе.
Когда я впервые увидел .gitlab-ci.yml, мне показалось, что это какой-то древний магический свиток. Сплошные stages, artifacts, непонятные правила... Но на самом деле всё гораздо проще — это просто рецепт: что, в каком порядке и как делать с твоим кодом.
Давайте разберём мой рабочий пайплайн по косточкам. Не как сухую документацию, а как реальный пример, который живёт у меня GitLab.
Привет, Хабр! Меня зовут Владимир, я Python-разработчик в команде IMV в Авито. Мы разрабатываем продукт, который помогает оценивать рыночную стоимость товара, будь то автомобиль, квартира или холодильник. Мы часто пишем тесты, и в этой статье я расскажу, как разные подходы к юнит-тестированию влияют на качество тестов, когда они помогают проекту, а когда — мешают, и почему само по себе наличие тестов ещё не гарантирует пользы. Статья будет полезна разработчикам, тимлидам и всем, кто пишет юнит-тесты и поддерживает код в долгоживущих проектах.
Привет, Хабр! Я написал эту статью для тех, кто с System Design особо не сталкивался. Никаких предварительных знаний не нужно — всё объясню с нуля. Если вы уже знаете, что такое load balancer — местами будет скучно, но, может, в секции про очереди или мониторинг найдёте что-то новое.
Меня зовут Лилия Урмазова, более 20 лет назад я начала работать классическим QA-инженером.
А последние пару лет специализируюсь на тестировании AI-приложений. В настоящее время — Senior Staff AI-QA Engineer/ML Evaluation Engineer в крупной международной IT-компании.
Для тех тестировщиков, кто хочет как минимум быть “в курсе” тестирования AI, я с коллегами подготовила небольшой бесплатный практический курс.
В мире тестирования программного обеспечения часто царит культ «хард скиллов». Selenium, SQL, Postman, Charles, написание автотестов — все это визитная карточка технического специалиста. Безусловно, эти навыки критически важны. Но есть загвоздка: самый совершенный скрипт не найдет баг, который требует человеческого любопытства, и не донесет критичную проблему до разработчика, который вас не слышит.
Пора признать: ключевое отличие тестировщика-исполнителя от тестировщика-аналитика и мыслителя заключается в развитых soft skills.
Уже несколько лет подряд у всех на слуху ИИ и тезисы о том, что он заменит человечество, а если и не заменит, то ускорит до немыслимых высот. Сегодня я хотела бы подискутировать на эту тему в области обеспечения качества, хотя рискую оказаться в ряду динозавров.
Всем привет, меня зовут Настя, и мне НЕ нравится, когда наши компании требуют от нас повсеместное внедрение искусственного интеллекта во все процессы.
QA-инженеры тратят значительную часть времени не на тестирование, а на анализ требований, написание баг-репортов, подготовку тестовых данных и отчёты для менеджмента.
Как превратить ChatGPT в ассистента, который берёт эту рутину на себя? В статье — 15 промптов, которые уже помогли командам ускорить процессы и освободить время для реального тестирования.
Статья будет полезна manual/automation QA, лидам и аналитикам, которые хотят систематизировать процессы и сократить рутину с помощью ИИ.
Хорошая новость: рекламы “тестирование - это легкий вход в айти” от крупных онлайн-платформ больше нет, экономика вместе с IT-наймом упали и курсы по тестированию начали закрываться.
Плохая новость: первыми закрываются курсы с уровнем трудоустройств студентов 50%.
А не те, после которых офферы в IT получают 5%.
Значит, инфоцыган пропорционально становится только больше.
Поговорим о блоксхемах.
Блоксхема — это графическое представление алгоритма. Очень мало тестировщиков использует блоксхемы в своей работе, а ведь это очень хороший инструмент для того, чтобы разложить всё по полочкам.
Когда тестов становится больше сотни, любая «красивая обертка» превращается в тыкву, если за ней нет архитектуры. Именно поэтому BDR - это не просто "красивая обертка".
Я никогда не был фанатом Cucumber. Да им даже толком не пользовался. Мне хватило просто посмотреть со стороны, сколько сил уходит у людей на поддержку всей этой магии с регулярками и текстовыми файлами. Это дорого. И технически, и по времени.
BDR (Business-Driven Reporting) — это не попытка «сделать как в Cucumber, только на TS». Это попытка выжить и не превратить 1000 тестов в ад поддержки. Сегодня разберем «железо»: слои, композицию и то, почему это работает без костылей.
1. Когда «просто оберток» мало
Скептики правы, если просто оборачивать каждый клик в BDR.step, вы получите тот же мусор, только в профиль. Масштабируемость — это про разделение ответственности.
Достаточно все поделить на три уровня абстракции. И это не «бумажные» правила, а способ не сойти с ума при рефакторинге.
Мы сравнили OpenLiteSpeed и классический LEMP для WordPress на реальных серверах. RPS, latency, TTFB, потребление CPU и RAM, поведение под нагрузкой до 500 пользователей. И вот какие итоги у нас получились.
В прошлой статье "Ваш отчет никто не читает: Как мы научили разработчиков понимать падения тестов за 30 секунд?" мы разбирали, как слой Flows и декораторы позволяют разрабам не тратить время на дебаг отчетов. Статья вызвала большой отклик, и сегодня я хочу раскрыть «фундамент», на котором строится этот подход.
Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации...
Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты.
Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting).
Почему классический BDD (Gherkin) — это ошибка?
Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.
Привет! Меня зовут Оля, и я AQA в Отелло. В тестировании с 2018 года, а технические собеседования на все QA грейды — от trainee до lead — я провожу с 2021. Когда-то давно, ещё будучи студенткой вуза, я попала в IT-компанию через стажировку. Тогда на одно место в компании претендовали 700 человек, и в итоге работу получили только четверо — я была одной из них. Поэтому я знаю не понаслышке, сколько времени и сил нужно вложить начинающему тестировщику, чтобы получить первую работу.
Своей статьёй я хочу помочь начинающим специалистам максимально продуктивно подготовиться к первым собеседованиям, не совершая типовых ошибок. Будет «многобукв», но зато вы узнаете:
• Как выбрать свою первую компанию.
• Красные флаги работодателя на собеседованиях.
• Почему сначала нужно собеседоваться в компании, в которые не хочешь.
• Как подготовиться к собеседованию с помощью AI.
• Почему не стоит приукрашивать опыт, лукавить и читерить на собеседованиях.
Утро, кофе, открываешь GitLab, а CI красный. Классика. Лезешь в отчёт, а там портянка на 5 экранов и TimeoutError где-то в недрах клика по кнопке. Селектор нормальный, data-testid="checkout-submit". Чтобы понять, что именно сломалось (может отвалилась база или фронт не отрисовал кнопку, возможно, юзер тупит), нужно лезть в код теста и дебажить глазами.
Бесит нереально. Ты или твой коллега тратите время не на фикс багов, а на расследование.
Классический POM: Как мы жили раньше?
Пока работал над флоу в статье, заметил, что некоторое количество просадок в производительности при работе с агентом вне режима авто-пилота возникает из-за тихих ожиданий. Например, ты не смотришь в IDE, читаешь что-то, а Claude Code сидит тебя ждет. Особенно это надоедает, когда агенту нужно какое-то разрешение.
Я люблю и практикую ChatOps. Поэтому решение пришло само: пусть агент мне пишет в телеге, когда я ему нужен.
На ранних этапах разработки аналитика часто оказывается в тени функциональных требований: фича работает — значит, задача выполнена. Корректность событий, логика их отправки и влияние на будущие отчеты нередко проверяют только после релиза — если вообще доходят до этой проверки. Но аналитика — это полноценный продуктовый инструмент. Именно на результатах аналитики строят гипотезы, запускают A/B-эксперименты и принимают бизнес-решения.
В этой статье Андрей Смирнов, инженер по тестированию Циан, раскроет, почему аналитика — это не «дополнение», а часть фичи, какую роль в ней играет тестировщик, а также как ревью аналитики повлияло на процессы и качество решений в нашей команде. Статья отражает опыт взаимодействия QA и аналитика внутри нашей продуктовой команды.
Привет! Меня зовут Оля, я работаю в сфере обеспечения качества ПО уже больше 17 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха, агротеха и ритейла. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге лет 10 назад ушла с головой в менеджмент.
И как-то в разговоре с Алиной Илюхиной, автором канала Багов бояться - в прод не ходить, зашла речь про развитие QA в наше непростое время. Алина ставила интересные вопросы и в итоге у нас получилось отличное пятничное чтиво, статья-интервью, которой мы решили поделиться с общественностью, чтобы, как завещал Шрек, не держать в себе.
Новый проект, первый день. Тебя добавили в Slack, кинули ссылку на Jira и PM говорит: «Вот команда, начинай». И ты начинаешь… угадывать. Когда ретро? К кому идти, если упал стенд? Почему задача висит в Review неделю?
К концу первого месяца многие понимают, что потратили половину времени на разгребание последствий элементарного незнания. Пропущенные митинги, баги в продакшене из-за несогласованного процесса и конфликты из-за нарушения неписаных правил – это классический сценарий.
Проблема не в твоей компетентности, а в отсутствии системного онбординга. Исследования показывают: QA-специалист должен начать приносить пользу (находить баги) в течение 2-4 недель. Без правильных вопросов на старте этот срок растягивается на месяцы.
Этот гайд – ваша страховка от хаоса. Мы объединили критические вопросы тимлиду и расширенный чек-лист, который поможет профессионально влиться в работу за первые 48 часов.
Что должен делать разработчик, чтобы проект, над которым он работает, не имел проблем? Очевидно — нужно просто исправить все баги и больше не писать новых.
Хорошая попытка, но в реальности и для существующего сервиса скорее всего потребуется ещё несколько шагов, чтобы радикально уменьшить количество открытых багов. В том числе нелюбимое многими разработчиками — начать писать тесты. Зачем этим должны заниматься сами программисты, почему нельзя всё переложить на AI, с чего начать и каким принципам следовать, расскажу в статье.
