Обновить
256K+

Тестирование веб-сервисов *

Семь раз оттесть, один раз деплой

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

Как мы тестируем в Профи.ру: почему у нас нет пирамиды, зато есть ромб и матрица

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

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

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

Привет! На связи Саша Мищенко, тимлид платформенной команды, и Света Чекунова, Senior QA Auto. Нам кажется, что мы нашли этот баланс.

Читать далее

Новости

Как приоритизировать регрессионные проверки, когда сжаты сроки релиза

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

Когда до релиза остаётся день, а полная регрессия занимает три, тестировать «самое важное» уже недостаточно. Нужно быстро понять, какие проверки первыми дадут сигнал о критичных дефектах: что связано с изменениями, деньгами, данными, интеграциями, частыми пользовательскими сценариями и зонами, которые уже ломались раньше.

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

Читать далее

Пет-проект, который не умер: система бронирования устройств как полигон для AI-разработки

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

Привет, Хабр. На связи Маша Лещинская, Head of QA в Surf. Мы все любим пет-проекты, и еще больше — пет-проекты на AI. Но есть нюанс: большинство таких штук забываются через неделю, потому что их сложно и дорого поддерживать. Я сделала проект, который живёт уже третий месяц, и причина не в каких-то крутых технологиях, а в том, что цена поддержки стала минимальной.

Читать далее

Новые методы и инструменты: как мы обновили курсы по тестированию в Яндекс Практикуме

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

Привет, Хабр! Это команда Яндекс Практикума. В этом году мы переосмыслили, актуализировали и переупаковали курсы по тестированию: изменили методики и обновили программы с учётом изменений на рынке. Рассказываем самое важное.

Читать далее

Как я сократил рутину QA до пары кликов: генератор API-тестов и тест-кейсов на LLM, которым хочу поделиться

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

Привет, Хабр! Меня зовут Илья, я работаю Manual QA в команде, которая отвечает за качество продукта с большим количеством микросервисов, API и регулярными релизами. Если вы хоть раз писали тест-кейсы по тикету из Jira, потом руками собирали Postman-коллекцию по OpenAPI-спецификации, а после ревью документации обнаруживали, что половину сценариев забыли — эта статья для вас.

Я собрал инструмент, который автоматизирует три самых рутинных задачи QA-инженера: генерацию тест-кейсов, генерацию API-тестов и ревью документации. Всё это под одной крышей, с поддержкой любого OpenAI-совместимого LLM (включая локальные модели), с интеграциями в Jira, Confluence, TestRail, TestIT и Zephyr Scale.

Проект называется Test Generator Suite (TGS), и в этой статье я расскажу, какие проблемы он решает и как устроен внутри. Сразу оговорюсь: я не разработчик, я QA, и большую часть кода писал «как умею» — поэтому если в архитектурных решениях вам что-то покажется странным, я заранее согласен. Это инструмент для коллег по цеху, а не образец Python-инженерии.

Читать далее

Приоритет задач определяется не только ощущением срочности

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

Привет! Я Даша, QA в команде Смартбот. Эта статья будет о том, как мы перестали спорить о срочности обращений и багов.

Начну с краткой исторической справки. Около года назад я начала тонуть в задачах на саппорт и эскалациях. В чат прилетала карточка с названием вроде «Не работает отправка сообщений», и уже по одному заголовку казалось, что нужно бросать все и срочно фиксить. Потом я погружалась в задачу и понимала, что проблема воспроизводится только у двух пользователей, и оба сидят через Explorer.

Бывало и наоборот. Первая линия смотрела на обращение и ставила средний приоритет, а при разборе оказывалось, что кейс действительно критичный и его не стоило откладывать даже на день.

Команда у нас опытная и слаженная, я сразу понимала, что дело не в нехватке компетенций. Проблема была в том, что у нас не было зафиксированной логики, по которой обе линии поддержки смотрели бы одинаково на один и тот же случай.

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

Читать далее

Влияние AI на позиции QA в 2026 году

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

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

По данным World Quality Report 2025, 89% компаний пилотируют или внедряют Generative AI в процессы Quality Engineering. При этом только 15% сделали это на уровне всей организации. Остальные находятся в стадии осторожного эксперимента.

Читать далее

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

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

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

Читать далее

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

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

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

Читать далее

Почему ваши моки не ловят реальные баги?

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

Вы можете замокать aiohttp.ClientSession._request и получить зелёный CI. Но этот тест всё ещё не доказывает, что у вас работает timeout. И не доказывает, что клиент переживёт обрезанный JSON. И не доказывает, что retry реально делает три HTTP-запроса через сокет.

В этой статье я прогоняю один и тот же сценарий через пять уровней тестирования внешнего API — от DI-заглушки до настоящего HTTP-сервера — и показываю, где каждый уровень врёт.

Читать далее

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

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

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

Читать далее

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

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

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

Читать далее

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

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

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

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

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

Читать далее

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

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

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

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

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

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

Читать далее

Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)

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

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

Читать статью

postman2pytest: как превратить Postman-коллекцию в pytest-набор за одну команду

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

Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.

И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.

Эти две вещи мирно сосуществовали месяцами, потому что никто не хочет быть тем человеком, который вручную переписывает 40 запросов в pytest-функции. Newman, конечно, есть, но Newman гоняет тесты, а не генерирует код, который можно прочитать, отредактировать и нормально положить в систему контроля версий.

Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.

Я написал postman2pytest, чтобы их познакомить.

Читать далее

Без рук: автоматизируем нагрузочное тестирование изменений в CI

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

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.

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

В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе.

Посмотрим, к чему мы в итоге пришли.

Нагрузочное тестирование на собственных мощностях: полный гайд по k6

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

Развернём нагрузочное тестирование на своих мощностях. Без ДД (долго, дорого). k6, VPS, сценарий на JavaScript, метрики в Grafana Cloud. Полчаса на настройку и встраивание в CI/CD. Для тестировщиков, разработчиков и всех, у кого есть пет-проекты.

Читать далее

Как ручное тестирование вскрывает дефекты в логике интерфейса: 5 кейсов Modus BI

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

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

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

На примере Modus BI разберём пять багов, которые нашли с помощью ручного тестирования. Это не история про «кликнуть по кнопке и сверить текст». Каждый кейс показывает конкретный тип логической проблемы...

Читать далее

Стабилизация e2e в условиях деградирующей среды

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

У каждого автотестера, наверное, есть такая идея, которая крутится в голове годами. Ты понимаешь, что она должна работать, но всё время не до неё: текущие задачи, дедлайны, «и так сойдёт».

У меня такой идеей было реализовать вменяемое ожидание готовности страницы. Не конкретного элемента — а страницы целиком. В один прекрасный момент мне предоставилась такая возможность...

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