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

Разбираемся, как работает robots.txt, почему его часто путают с инструментами индексации и какую роль он играет в эпоху ИИ-сканеров.

Не совсем пятничное чтиво, но…

Как-то так случилось, что решил разобраться для себя лично – какие подвижки появились в вопросе внедрения искусственного интеллекта в сфере сайтостроительства. ИИ действительно показал себя неплохо в отдельных задачах, но есть у него и минусы. Всё это тема для отдельного обсуждения, но здесь – только обзор реальной картинки. Делюсь бесплатно и без SMS ))

Привет, Хабр! Меня зовут Станислав Кулагин, я ведущий инженер отдела сертификационного тестирования компании YADRO. Я разработал ATS Studio — Flask-приложение, которое позволяло запускать автотесты в TestY TMS из браузера, не проставляя статусы руками. За полгода приложение стало популярным в нашей компании теперь экономит по 40 часов в месяц коллегам из KVADRA. 

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

и как не утонуть между БКИ, Госуслугами и тремя платформами одновременно?

Один QA. Три платформы. Шесть внешних сервисов. Легаси-код. И огромное количество неопределённости — в требованиях, в поведении интеграций, в том, что вообще считать корректным результатом. Рассказываю, как выстроить тестирование сложного финансового процесса так, чтобы до релиза добиралось не более 5–7 багов — и все они были известны заранее.

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

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

Сегодня мы поговорим о нагрузочном тестировании. Той самой дисциплине, которая требуется в каждом проекте, но вспоминают о ней только тогда, когда система уже горит, а менеджеры уже успели пообещать клиенту, что «это не повторится».

Сразу — не надо так!

Мы рассмотрим базовые понятия. Без академизма, потому что трудно оставаться полностью серьёзным, когда видишь, как систему нагружают 10 тысячами пользователей, а она написана так, будто её автор рассчитывал на трёх с половиной человек и одного стажёра.

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

Дано:

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

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

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

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

Найти:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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