Обновить
256K+

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

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

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

Тест кейсы как код

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

История о том, как избавить команду от боли работы с классическими TMS и перенести тестовую документацию туда, где ей самое место - в код.

Дано:

* Растущее количество ручных тестов (иногда переваливающее за тысячи), которые сложно поддерживать.

* Отсутствие нормального переиспользования шагов в стандартных системах, из-за чего приходится постоянно дублировать общие шаги.

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

* Сложности с параллельной работой в ветках, ревью изменений и плохой аудит удалений, где один клик может снести целую группу тестов.

Найти:

* Единый источник правды для всех тестов на проекте.

* Механизм, обеспечивающий прозрачный процесс работы с разными ветками, ревью изменений и т.д.

Читать далее

Новости

Лайфхаки по быстрому написанию автотестов или пишем автотесты без боли

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

Привет, Хабр. Меня зовут Виталий Стародубцев. Я ведущий QA-инженер в СберЗдоровье — MedTech-компании №1 в России.

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

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

Читать далее

Контекст для LLM в тестировании: от калькулятора страховой премии до ТЗ на сотню страниц

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

Всем привет! Продолжаю цикл статей про применение ИИ в тестирование. Сегодня поговорим про тестирование требований, а именно про первый и самый важный этап — подготовку контекста. 

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

Читать далее

Git для QA Engineer

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

Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.

В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.

Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.

Читать далее

Моки, стабы и фейки: в чем разница и что выбрать для автотестов?

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

Разбираемся с терминологией Test Doubles без лишней воды. В чем реальная разница между Mock, Stub и Fake? В статье разберем классификацию на живых примерах: поднимем умный стаб-сервер на FastAPI, напишем мок-шпион для проверки сайд-эффектов и ускорим тесты с помощью фейковых БД.

Читать далее

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

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

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

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

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

Читать далее

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

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

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

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

Читать далее

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

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

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

Читать далее

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

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

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

Читать далее

Как я сократил рутину 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

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

Читать статью
1
23 ...