Обновить

Тестирование

Сначала показывать
Порог рейтинга
Уровень сложности

Как я сделал утилиту для автоматизации ручных тестов

Уровень сложностиПростой
Время на прочтение15 мин
Охват и читатели2.5K

Привет, меня зовут Алексей и я C# разработчик. Однажды передо мной стояла задача написать утилиту для взаимодействия с различными UI-элементами в Windows и во всех популярных браузерах. Сама утилита не была связана с тестированием, но вполне годилась для автоматизации некоторых действий на машине, так как была простой в управлении и интуитивно понятной. Мне понравилось работать в этом направлении и возникла идея создания инструмента, который не будет перегружен широким функционалом RPA решений, но возьмёт от них всё что нужно для тестирования интерфейсов, чтобы получился действительно полезный инструмент-помощник для QA с низким порогом входа.

Читать далее

Новости

Параметризация в JUnit 5 и Allure Report

Уровень сложностиПростой
Время на прочтение3 мин
Охват и читатели4.8K

Статья — перевод англоязычного руководства

При написании автотестов мы часто используем параметризацию — запуск одного и того же теста с разными данными. В этой статье мы разберём, какие задачи решает параметризация, как она реализована в JUnit, и как с ней работать в Allure Report.

Читать далее

Как измерить скорость интернета?

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели5.4K

Почему в одних и тех же условиях — в одной точке сети, на одном смартфоне — разные приложения для измерения скорости показывают совершенно разные результаты?

Мы привыкли: нажал кнопку — получил замер скорости. Но за этими цифрами — десятки скрытых переменных: от географии сервера до количества потоков TCP и алгоритмов борьбы с потерями пакетов.

UDP или TCP? 3 потока или 10? BBR или CUBIC?

Разбираем как протоколы, алгоритмы и серверы влияют на скорость, какие существуют подводные камни тестов, а также посмотрим какие сервисы измерения сейчас работают в России после запрета популярного сервиса Ookla Speedtest.

Читать далее

5 распространенных ошибок новичка в E2E-тестах

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели9.7K

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.

Разобрать ошибки

«They did a blow job on the sidewalk» и другие ляпы айтишников в английском на международке

Время на прочтение4 мин
Охват и читатели8.6K

Я не стала ходить вокруг да около. Взяла и спросила ребят из IT в запрещенных соц. сетях: за какие ляпы на английском им до сих пор стыдно перед международной командой?

И вот что у нас получилось:

Читать далее

Вы неправильно тестируете асинхронный код: тест проходит раньше, чем выполняется проверка

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели7.6K

В статье разберём, как именно раннер решает, что тест прошёл, почему .then без return выполняется уже после теста, почему try/catch в async‑тесте — частый источник ложного зелёного, что не так с forEach и setTimeout внутри тестов и какие инструменты не дают тесту соврать. Примеры на Jest, но контракт у Mocha, vitest и прочих тот же.

Читать далее

GPT-шорткаты: что работает, а что нет

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели11K

Привет! Разобрал популярные шорткаты GPT вроде EL5, /REDTEAM, /BULLET — какие реально выручают каждый день, какие работают через раз, а какие лучше не тратить время.
Смотри шпаргалку! 🚀

Читать далее

Мы пытались заменить QA нейросетью. Не получилось

Время на прочтение10 мин
Охват и читатели16K

Мы попытались построить MCP-сервер, который сам читает спеки, пишет автотесты и коммитит код. На практике выяснилось, что токены — не главная проблема, а QA — это не «делатели тестов», а носители контекста и ответственности.

Читать далее

AI-агент действительно ловит баги? Пусть докажет на бенчмарке

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели13K

Привет! Это снова Михаил Федоров. В первой статье — архитектура QA Assist: 11 AI-агентов от декомпозиции требований до готовых автотестов. Во второй — как «4 часа подключения» превращаются в неделю корпоративной реальности. В третьей — почему пирамида тестирования ломается, когда тест-дизайнером работает LLM. Сегодня — про то, как я решил наконец-то перестать оценивать агента «на глаз» и собрал отдельный проект-бенчмарк, на котором можно честно сравнивать прогоны: версии агента, отдельные «улучшалки», даже эксперименты с моделями. В качестве бонуса покажу все артефакты, которые агент готовит за один прогон пайплайна. И бенчмарк, и артефакты — в публичном доступе, ссылки в конце статьи. Обсудить всё это можно в Telegram-группе.

Читать далее

Могут ли LLM находить flaky‑тесты по одному только коду теста? Разбор одного исследования

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели9.9K

Flaky‑тесты сложно ловить даже привычными инженерными методами: они ломают CI, подрывают доверие к автотестам и часто воспроизводятся только тогда, когда уже никто не понимает почему. Кажется логичным поручить такую задачу LLM: показать модели код теста и попросить определить, насколько он подозрительный.

В статье разбираем исследование, где этот подход проверили на практике, и смотрим, почему хорошие метрики на датасете ещё не означают, что модель действительно понимает природу flaky‑поведения.

Читать разбор

В логах Kibana лежат тест-кейсы. Вот CLI, чтобы их достать. С auth, заскрабленным по умолчанию

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели8.7K

Каждый спринт мы экспортируем JSON из Kibana, листаем сотни записей и говорим себе, что потом превратим их в тест-кейсы, но потом никогда не наступает.

Логи содержат реальные API-вызовы. Настоящие endpoint’ы, реальные payload’ы, настоящие статус-коды из продакшна. Это ближайшее к спецификации описание того, как система ведёт себя на самом деле. И почти ничего из этого не становится автотестом. Потому что переводить вручную дольше, чем идёт спринт.

Я устал от «потом», написал secure-log2test, CLI-инструмент, который читает экспорт Kibana и генерирует готовый pytest-файл. Одна команда. Работающие тесты.

Главное ограничение, которое определило весь дизайн: никакие данные не покидают машину. Никаких вызовов LLM API. Никакого облака, всё локально.

Читать далее

Синергия E2E и скриншотных тестов: создание надежной системы тестирования iOS с помощью XCTest

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели6.4K

Всем привет! Меня зовут Артур Поляков, я инженер по тестированию в отделе мобильной разработки в компании iSpring. Наша команда работает над iSpring LMS — мобильным приложением для дистанционного обучения сотрудников.

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

Читать далее

Ты QA и у тебя баги. Какие из них блокируют релиз?

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели12K

Пятница, до релиза осталось два часа, а на финальной проверке всплывают баги: зависание после оплаты, профиль без обязательного телефона, расхождение в отчёте на несколько рублей. Для QA в такой момент важна не паника и не формальное «блокер/не блокер», а быстрая оценка последствий: кто пострадает, что сломается, есть ли обходной путь, видит ли команда проблему в логах и можно ли безопасно откатиться.

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

Разобрать баги

Ближайшие события

Как я автоматизировал UI в Windows: UIAutomation и Win32

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели13K

Привет, меня зовут Алексей, я C# разработчик. Я разрабатывал библиотеку для автоматизации взаимодействия с различными UI‑элементами и их захвата. Одной из поддерживаемых сред в такой библиотеке обязательно должна быть Windows и в ней так же требуется: находить кнопки, поля, окна, списки, нажимать на них, читать значения, вводить текст и в целом обращаться с интерфейсом не как пользователь с мышкой, а как программа.

На первый взгляд задача звучит просто: нашли элемент, кликнули, пошли дальше. Но в реальных приложениях у элемента может не быть (считай не будет) нормального AutomationId, у нескольких окон может быть один и тот же заголовок, дерево интерфейса может прогружаться не сразу, а старое desktop‑приложение вообще не предназначено для взаимодействия с современными API для автоматизации.

В итоге в моей библиотеке появилось два основных Windows‑подхода:

Читать далее

Юнит-тестирование на уровне базы данных PostgreSQL

Время на прочтение9 мин
Охват и читатели8.4K

Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом. С помощью этих юнит-тестов мы уже нашли и исправили много ошибок в функциях на уровне БД, а также сократили загрузку ручных тестировщиков.

Привет, Хабр! В этой статье мы, старший разработчик Анастасия Цацкина и старший инженер-тестировщик Владимир Белинский из IBS, расскажем о нашем опыте внедрения юнит-тестирования на уровне БД.

Читать далее

Разбираемся в многообразии видов тестирования

Время на прочтение10 мин
Охват и читатели13K

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

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

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

Читать далее

Как приручить сервисы-моки

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели8.5K

Материал для тех, кто хочет создавать надежные и масштабируемые моки API-сервисов и любит получать удовольствие от жизни

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

Примеры и практические советы, как перейти на новый уровень покрытия тестами, если вы интегрируетесь с внешними системами

Читать далее

Apache Kafka: как настроить тестирование сообщений в топиках

Уровень сложностиПростой
Время на прочтение29 мин
Охват и читатели6.8K

Привет, Хабр! Я SDET‑инженер в SimbirSoft Александр, в этой статье я предлагаю вам:

Рассмотреть основы Kafka, ее архитектуру и как она работает.

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

— Обсудить роль Kafka в интеграционном тестировании, покажу пример интеграционного теста.

— Материал будет полезен для новичков в области тестирования ПО, как ручного, так и автоматизированного.

Читать далее

Новая эра: нагрузочное тестирование UI‑микросервисов

Время на прочтение11 мин
Охват и читатели12K

Привет, Хабр! Я Эдуард, в команде РСХБ.Цифра занимаюсь организацией проведения нагрузочного тестирования. В нашей команде инженеры НТ занимаются проверкой производительности как монолитных, так и микросервисных решений. Одно из больших направлений — это мобильное приложение «Свои финансы» от РСХБ. В этой статье расскажу о том, как мы проводим нагрузочное тестирование UI‑микросервисов и поделюсь ценными выводами на тему.

Когда идёт речь про микросервисы, большинству читателей представляется сложная архитектура связей между различными блоками, внешними системами, другими микросервисами и базой данных. То есть первым делом мы, конечно же, думаем о backend микросервисах. Действительно backend выполняет основную работу в современных приложениях, являясь двигателем всех процессов.

Читать далее

Как составить ИПР, который работает

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели7.5K

Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.   

Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.

Сейчас я работаю в Sminex и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.

Читать далее
1
23 ...