Методы, советы, опыт
Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.ru.
Про flaky-тесты написано много, борьбу с ними не прекращаем и мы. Но сегодня немного о другом — хочу поделиться нашим опытом минимизации неприятностей, которые наносят такие тесты. Для этого мы провели ряд экспериментов со стороны тестового фреймворка.
LLM пока не может хорошо обращаться с Е2Е автотестами потому что для этого нужно провести целый комплекс мероприятий. Сложность возникает уже на этапе запуска такого автотеста. В отличии от юнит автотестов, Е2Е автотесты почти всегда PageObject и целый проект со своей архитектурой на базе Selenium Appium Espresso и тд.
Статус 200 OK коварен своей тривиальностью.
Бэкенд-тесты «зеленые», API честно отдает данные, а веб-клиент мгновенно подхватывает изменения. Кажется, что всё в порядке, но в это же время мобильные клиенты теряют работоспособность. Приложение не выдает сетевых ошибок, оно просто не может корректно обработать обновленный DTO: клиент ожидает одну структуру данных, а получает другую.
Это не баг логики сервера, а технический разрыв между живым API и замороженным артефактом — версией приложения, которая ничего не знает о правках в схеме данных, сделанных через полгода после его релиза.
В разработке нативных приложений этот рассинхрон неизбежно приводит к «генеральскому эффекту». Когда у руководства в дороге внезапно перестаёт работать ключевая функция или во время важной презентации интерфейс ведёт себя непредсказуемо на глазах у инвесторов, даже самая детальная диагностика превращается в посмертный эпиклиз.
Мониторинг здесь работает безупречно: мы видим алерты в реальном времени и получаем подробные стек-трейсы. Но толку от этой прозрачности мало, когда сделка под угрозой, а пользователь остался с нерабочим инструментом, катастрофа уже случилась.
Я Алексей Матвеев, директор по мобильным технологиям в «Первой Форме», и в нашей компании, к сожалению, такое тоже происходит. Чтобы ловить такие расхождения до релиза, нам же был нужен прогноз совместимости до того, как изменения на бэкенде затронут пользователей. Мы создали прозрачный конвейер самодиагностики, который подсвечивает нестыковки в данных еще на этапе тестирования бэкенда, гарантируя корректную работу тех версий приложения, которые уже живут на устройствах пользователей. В статье расскажу подробно, как устроено это решение.
Рынок QA изменился: конкуренция выросла, требования стали жёстче, а старые сценарии входа больше не работают. В статье — честный разбор рынка, требований и иллюзий, которые до сих пор продают новичкам.
Знакомая история: команда полгода шлифовала функционал, тестировщики уничтожили все баги, а пользователи уходят. Аналитик разводит руками, поддержка задыхается от тикетов, маркетинг угрожает продакту, а продакт – дизайнеру. В это время CFO считает расходы и грустно вздыхает.
Больно видеть, как много появляется на рынке таких продуктов, прошедших технические проверки и проваливших испытание пользовательским опытом. Идеально работающих, но никому не нужных. Что делать, чтобы не войти в их число?
Было время принимал участие в разработке iOS приложениий в небольших продуктовых командах. Всё стандартно для такого рода разработки:
2-5 iOS разработчиков
Менеджер
Дизайнер
Тестировщик
Как видите, в списке нет DevOps, поэтому наш CI был полностью в нашем распоряжении и мы могли настраивать как нам удобно. Когда я присоединился к командам, то на CI уже всё было настроено по классике:
Mac Studio в подвале
Запуск Unit тестов
Запуск UI тестов
Сборки различных версий приложения (Firebase, TestFlight)
Всё работало как часы, я туда если честно не лазил (сначала), из разговора коллег, сама настройка CI им досталась от первых разработчиков проекта, которые больше уже не в команде и они там фундаментально после них ничего не меняли.
Время шло, задачи закрывались, релизы выпускались, в свободное время от задач расчищали беклог - в общем скукота. Так как мне нравится ковырять в носу xcodebuild через терминал, то иногда я стал замечать, что, например, тесты на CI и локально работают по-разному в плане скорости, локально вроде всё очень быстро, но на CI реально иногда надолго всё залипало - 5, 10, иногда 20 минут, хотя локально из консоли до двух раз быстрее.
После очередного закрытого спринта досрочно, осталось время на беклог, у меня закралась мысль, что что-то не так с нашим CI. Так как я знаю, что у нас на CI стоит Mac Studio, которая точно, хоть и немного, но шустрее моей машины, но по времени выполнения задач этого не скажешь.
Решил в итоге открыть ящик пондоры Fastfile и посмотреть, что же там и как это работает.
Назидательная статья, написанная в стихах и вдохновленная детскими книгами. Посвящается всем ошибкам, которые я совершал на работе — большим и маленьким.
Меня зовут Максим, я Android-разработчик в команде дизайн-системы «БКС Мир инвестиций». В 2025 году у нас шёл большой редизайн: компонентная библиотека росла, команды подключали новые Compose компоненты, а вместе с этим быстро рос и объём UI-тестов.
Для команды это быстро стало не абстрактной инженерной задачей, а вопросом скорости и стабильности разработки. Нужно было дать тестировщикам единый способ находить компоненты на экране и проверять их состояние, не заставляя разработчиков вручную поддерживать одинаковую тестовую разметку в каждом компоненте.
Эта статья про то, как мы решили задачу через Kotlin IR Compiler Plugin. Снаружи решение выглядит почти незаметно: разработчик ставит одну аннотацию, а на этапе компиляции компонент автоматически получает стабильный testTag и тестовые semantics, собранные из его state. В результате у команды стало меньше бойлерплейта в компонентах, меньше риска рассинхронизации между state и тестами, а экранные UI-тесты получили более устойчивый контракт работы с дизайн-системой.
Привет! Меня зовут Артем Русов. Около 6 лет я занимаюсь обучением будущих теcтировщиков на платформах Stepik, Udemy и YouTube. И каждый день получаю вопросы о том: что там с тестированием и стоит ли начинать его изучать сейчас?
Сам я не смогу дать однозначный ответ: да или нет. Так что предлагаю ознакомиться с этой статьей всем заинтересованным, а уже в конце для себя принять окончательное решение.
Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.
За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше.
Мне захотелось понять, как дела обстоят на самом деле: что именно выматывает в работе, где чаще всего возникают проблемы и какие решения помогут помочь. Всё самое интересное из исследования я собрала для вас в этой статье.
Redis всё чаще встречается в вакансиях для QA, и понимание его работы становится полезным навыком для тестировщика.
В статье простым языком объясняется, что такое Redis, где он используется, чем отличается от реляционных баз данных и почему он работает быстрее SQL.
Также разбираются практические случаи применения Redis в тестировании: проверка данных, ускорение тестов, подготовка нужного состояния системы и отладка.
Подойдёт для подготовки к собеседованиям и для работы на реальных проектах.
Привет, я Максим Королев из Петрович-Теха, цифрового партнера сети строительных магазинов «Петрович». Компания специализируется на продаже стройматериалов, комплектации крупных объектов и комплексном обслуживании, включая доставку и подъем на этаж. В первой статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM, во второй — как вынесли бизнес-логику «Дежурного» в CORE и подключили MAX.
Сегодня про совсем другой бот и другую задачу. Не про инциденты и дежурных, а про мобильные бригады подъёма товаров заказчику и то, как сделать их работу ещё удобнее и прозрачнее без дорогого мобильного приложения.
Недавно ISTQB выпустили новую версию сертификации Certified Tester AI Testing v2.0.
Я посмотрел обновлённый syllabus и решил разобрать, что там изменилось, куда сместился фокус и насколько новая версия действительно соответствует тому, что сейчас происходит в мире AI testing.
Это была пятница, шесть вечера. Я сидел перед монитором и чувствовал себя следователем, который зашёл в тупик.
Три часа назад я нашёл странное поведение в приложении. Открыл Jira, но пока заполнял поля — мысль ушла. На рабочем столе уже лежало 15 скриншотов с именами вроде «Снимок экрана 154312.png». Я открыл их наугад, но уже не помнил, к какому запросу какой относится.
«Я потерял контекст». Баг есть, даже помню, как воспроизвести. Но чтобы восстановить цепочку «действие → реакция сервера → скриншот → вывод» — нужен ещё час.
Знакомо? Я инженер по тестированию, работаю со сложными продуктовыми сценариями, где один баг тянет за собой цепочку из запросов, скриншотов и логов. И с этим сталкиваюсь регулярно.
Проблема не в том, чтобы найти баг. Проблема — зафиксировать ход рассуждений вместе со всеми артефактами так, чтобы через неделю не пришлось восстанавливать контекст с нуля.
Меня зовут Александр. Я перепробовал Jira, Confluence, Notion и просто папки на диске. Всё либо медленно, либо хаотично, либо зависит от интернета. Поэтому я собрал свой локальный редактор — под себя, под тестирование. Делюсь историей и кейсом.
Инструмент я выложил в открытый доступ, ссылка будет в конце. Это не продажа, не условно-бесплатно и не лидогенерация. Просто рабочий пет-проект, которым я сам пользуюсь каждый день.
В нашей компании по тестированию ПО на аутсорсе мы постоянно сталкиваемся с тем, что формат сотрудничества диктует инфраструктура заказчика. На одном проекте нас ждет построенная по всем канонам CI/CD, а на другом полное отсутствие VCS. В таких условиях легко потерять контроль над качеством нашей работы.
В этой статье я расскажу, как мы выстроили внутренний контур качества, используя собственную инфраструктурную прослойку, и почему от этого решения в итоге хорошо и нам, и заказчику.
Когда мы заходим на проект, то почти всегда встраиваемся в существующую экосистему.
Однако, при таком варианте мы теряем возможность управлять результатом нашей работы.
Работая исключительно на стороне клиента, мы не можем внедрить обязательное внутреннее ревью кода, настроить свои стандарты CI/CD-пайплайнов или, например, использовать привычные нам инструменты отчетности.
Бывает ситуации и сложнее. Например, у клиента есть CI/CD, но из-за требований безопасности им нельзя подключать внешние раннеры. Бывает случаи, когда у клиента нет своего CI/CD. Поднять его у себя они не могут (нет на это ресурсов, людей или того и другого), а использовать публичные или даже приватные облака запрещает какое-нибудь внутреннее соглашение.
Чтобы избежать таких осложнений в нашей работе, нам была необходима собственная технологическая база, которая позволила бы выполнять задачи независимо от состояния инфраструктуры на стороне заказчика.
Наш стек
Чтобы обеспечить стабильность, мы развернули внутреннюю связку: Self-hosted GitLab + GitLab CI + GitLab Pages.
Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.
В условиях существенного троттлинга WhatsApp* и Telegram, а также активного преследования VPN и proxy, имеет смысл заранее позаботиться об альтернативах. В этой статье мы рассмотрим три мессенджера, которые могут стать заменой: набирающий популярность IMO, внезапно ставший хайповым KakaoTalk и получивший недавно апгрейд Телемост.
Мы расскажем о самом приложении и его функционале, покажем актуальный интерфейс, выделим ключевые плюсы и минусы и остановимся на основных фишках каждого приложения. В конце статьи мы приведем полную сравнительную таблицу по всем трем мессенджерам.
Для объективной оценки мы выбрали единый сценарий для каждого мессенджера. Нам важно было проверить, насколько удобно в приложении было бы общаться как с друзьями, родными и близкими, так и с коллегами по работе или заказчиками.
В рамках этого сценария мы проверяли наличие самых востребованных функций:
• текстовые чаты (личные и групповые),
• отправку голосовых сообщений,
• аудио- и видеозвонки (как индивидуальные, так и групповые),
• обмен фотографиями, файлами и документами,
• использование стикеров, эмодзи и анимаций.
Помимо этого мы проверили наличие десктопных версий приложений — что важно при общении с коллегами по работе. Мы также убедились, что все три мессенджера доступны не только в российском App Store и Google Play, но и в зарубежных (возможно вы общаетесь с друзьями или заказчиками из других стран). Все три приложения были скачаны впервые. Все три приложения работают в России без VPN.
Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? UI написал «подтверждено», но UI иногда врёт — проглоченная ошибка, откаченная транзакция, очередь, которая молча дропнула сообщение.
Классическое решение некрасиво: нужно подключить ORM или низкоуровневый драйвер базы данных внутри тестового харнеса, управлять отдельными учётными данными, писать SQL-ассерты вручную и надеяться, что схема не изменится. Работает. Но это накладные расходы на поддержку, которые вы платите за каждый тест.
Сейчас есть паттерн лучше. И в нём ноль SQL с вашей стороны.
Что если один AI-агент сможет делать обе половины — управлять браузером при оформлении заказа и затем переключиться в базу данных для проверки записи — используя два MCP-сервера?
Именно это разбирается в статье:
Всем привет! Меня зовут Артем. Я Android QA Engineer в команде Банки.ру.
Было ли у вас такое, что unit-тесты в проекте есть, но на практике ими почти никто не пользуется? Разработчики их пишут, но для QA это “что-то где-то в коде”: нельзя нормально посмотреть результаты, оценить покрытие или использовать в регрессе.
В статье рассказал, как мы решили эту проблему: сделали unit-тесты видимыми через Allure, связали их с тест-кейсами и встроили в реальный процесс тестирования.
Всем привет! Меня зовут Оля Ермолаева, я работаю в сфере обеспечения качества ПО уже больше 17 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха, агротеха и ритейла. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге лет 10 назад ушла с головой в менеджмент и веду свой небольшой ТГ канал про тестирование, менеджмент и всё, что с этим связано.
В начале этого года мы с коллегами зацепились языками по вопросу соотношения тестировщиков и разработчиков в командах разработки в зависимости от разных факторов и мне стало интересно, а как вообще на рынке с этим сейчас обстоят дела. Устроив опрос по разным чатам и сообществам, я готова поделиться с вами этой информацией, погнали!