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

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

Экономическая ценность репутации в российском контексте

Деловая репутация российских компаний сегодня измеряется не только лояльностью клиентов, но и конкретными финансовыми показателями. Согласно исследованию, проведенному в 2024 году, организации с высоким уровнем доверия к своему бизнесу и клиентам демонстрируют заметно более высокую рентабельность, что подтверждено на примере финансового сектора и сферы розничной торговли. Укрепление доверия способствует увеличению прибыли и устойчивости компаний благодаря повышенной лояльности клиентов и эффективности управления. В частности, рентабельность капитала в банковском секторе в 2024 году достигала около 24%, что частично связано с ростом доверия клиентов и партнеров.

Восстановление репутации после кризиса зачастую требует значительно больших ресурсов, чем профилактика инцидентов и проблемных ситуаций. Например, после масштабного сбоя в системе онлайн-банкинга одного из крупнейших российских банков в 2023 году, банк понес многомиллионные затраты на компенсации клиентам, а также на маркетинговые и PR-кампании, направленные на восстановление доверия. По оценкам экспертов, эти затраты могли быть в 5-7 раз выше, чем стоимость превентивного тестирования и мер по предотвращению подобных инцидентов. Такие кейсы демонстрируют, что инвестиции в профилактику, безопасность и качественную подготовку инфраструктуры значительно экономят средства и помогают минимизировать репутационные риски.

Привет, меня зовут Сергей, я занимаюсь автоматизаций тестирования в компании ITFB Group, и хочу поделиться опытом внедрения AI-агентов в наши процессы.

Наверняка всем тестировщикам знакома ситуация, когда остаётся всего пара дней до релиза, а команда тестирования всё ещё работает над задачами по новым фичам и не может приступать к регрессу? Или перед передачей новой версии заказчику тестировщики успевают проверить только smoke-сценарии, засиживаясь допоздна? А до написания чек-листов и тест-кейсов по новым функциям руки дойдут вообще не скоро. У нас тоже такое нет-нет, да и случается.

Самое первое, что приходит в голову после таких авралов – нам нужна автоматизация регресса. Но как в кратчайшие сроки сделать из ручных сценариев автотесты, если никто в команде тестирования не пишет код и нужно изучать всё с нуля, и это при том, что и так ни на что не хватает времени? На помощь придёт вездесущий AI!

Привет, Хабр! Меня зовут Надежда Буртелова, я ведущая тестировщица в музыкальном сервисе Звук. В тестировании с 2014 года, с 2022 года работаю в Звуке: тестирую backend и менторю коллег. Последние два года активно пишу автотесты. 

Закончила МФТИ: факультет аэрофизики и космических исследований. 

В статье разберу причины нестабильности автотестов на бэкенде и предложу способы их стабилизации. Расскажу, как из одного «флакающего» теста сделать три стабильных, стоит ли автоматизировать изначально нестабильные сценарии и когда лучше что-то убрать из автотестов и сохранить адекватное покрытие.

Команда JavaScript for Devs подготовила перевод статьи о том, сколько трафика реально выдерживает сайт на Next.js. Автор провёл нагрузочные тесты, сравнил VPS и выделенный сервер, проверил разницу между предрендерингом и SSR и сделал вывод: для сайтов с потенциальными всплесками трафика предрендеринг — спасение, а SSR может стать бутылочным горлышком.

Привет, Хабр! Меня зовут Вадим, я уже много лет в тестировании и сейчас работаю Head of QA в Альфа-Банке (Беларусь). За эти годы я успел поработать с десятками инструментов, написать сотни тест-кейсов и... потратить неприлично много времени на рутину, которую можно было автоматизировать ещё вчера.

Знаете, есть такая особенность нашей профессии - мы автоматизируем всё вокруг, но часто забываем автоматизировать собственную боль. Сегодня хочу поделиться решением одной из таких "болей", с которой сталкивается каждый QA-инженер, работающий с ТестОпс: необходимость вручную синхронизировать тест-кейсы после каждого прогона автотестов.

На практике знание того, как НЕ писать тесты, может быть столь же важно, как и знание того, как их писать. В интернете можно найти множество материалов про “тесты с запашком”; в частности, им посвящено несколько очень полезных глав в книге Джерарда Месароша о паттернах в xUnit.

Нам показалось интересным подойти к этой проблеме не со стороны теории, а со стороны практики: какие частые ошибки можно встретить в тестах, как их исправлять, и почему именно тесты нужно писать так, а не иначе? Мы продемонстрируем всё это для стека JUnit + Selenide. 

Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как тестировать производительность через вкладку Performance. Материала набралось так много, что мне пришлось разбить его на две статьи. Сегодня мы поговорим об утилите Performance monitor, инструменте Chrome Task Manager и о том, как вывести FPS сайта на экран. Приглашаю под кат!

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

Что именно вы хотите знать о тестировании на вашем проекте? Качество продукта, эффективность тестирования, статус QA или процесс исправления багов?

В сегодняшней статье расмотрим Эффективность тестирования

Какими метриками измерить эффективность тестирования? 

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

Привет, Хабр! Меня зовут Максим Попов, я инженер по автоматизированному тестированию внутренних продуктов в Сбере — в том числе SCPL. В этой статье расскажу, как упростить настройку клиент-сервер взаимодействия в рамках фреймворка автотестирования.

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

Привет, Хабр! Я Александр Зырянов, проектный менеджер TestY TMS. В этой статье не будет традиционного среза о фичах из нового релиза, ведь TestY 2.1.1 еще не выложили в open source. Вместо него я принес интересный пользовательский кейс, который упростит поиск и изменение тестов в системе. Расскажу, как устроены фильтры и массовые операции.

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

Привет! Меня зовут Оля, я руководитель группы тестирования в 2ГИС. В QA пришла в 2016 году через переквалификацию и ещё хорошо помню, каково это — искать первую работу без опыта. Сейчас активно участвую в найме: провожу технические и финальные собеседования, много общаюсь с HR-коллегами и читаю резюме новичков.

За последние годы ситуация на рынке заметно изменилась. По данным HeadHunter и Хабр.Карьеры, в 2024 году вакансии для джунов составляли всего 10% от всех предложений, на каждую позицию претендовало около 11 человек. В 2025 году стало еще сложнее — количество входных позиций по всему миру упало на 70% (исследование Ravio).

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

Представьте себе: вы отлаживаете новый баг в сложном многослойном приложении (например, на Spring). Чтобы воспроизвести проблему, приходится взаимодействовать со всей системой end-to-end: отправлять запрос на эндпоинт или что-то кликать в UI. Юнит-теста, который бы изолировал нежелательное поведение до уровня злополучного сервиса или утилиты, нет. А хотелось бы, чтобы он был: во-первых, воспроизводить баг было бы проще (особенно если UI кликает QA, а не вы), а во-вторых, его потом можно было бы легко превратить в регрессионный и улучшить стабильность системы.

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

Сегодня расскажу о пройденном исследовательском пути, о том, как попробовать нашу экспериментальную фичу в плагине для IntelliJ IDEA, и о том, что у неё под капотом (спойлер: не только LLM).

Здравствуйте, меня зовут Ирина. Я хочу поделиться своим опытом обучения на тестировщика в 3 разных школах.

Зачем я училась в трех разных школах? — спросите Вы. Ответ очень прост. Я закончила первую школу на ручного QA, стала смотреть вакансии, чтобы выделиться среди массы ищущих работу джунов решила выучиться на AutoQA. Пошла на курс с нуля до автоматизатора. Проучилась до начала автоматизации, мне не понравилось, вернула деньги за обучение, устроилась работать ручным тестером. Узнав о бесплатном интенсиве с возможностью дальнейшего трудоустройства в известную компанию решила подать заявку и прошла отбор. Таким образом у меня получилось отучиться в трех разных школах, которые я и хочу сравнить и поделиться своим опытом.

Знакомо чувство, когда интеграционные тесты с PostgreSQL в Go работают дольше, чем хотелось бы? Каждый тест создает базу заново, применяет миграции, и большая часть времени уходит не на проверку логики, а на подготовку окружения. В этой статье я расскажу о своем open-source решении на Go, которое использует встроенные механизмы шаблонов PostgreSQL, чтобы ускорить этот процесс в полтора раза, уменьшить потребление памяти и сделать ваши тесты по-настоящему параллельными.

Всем привет! Меня зовут Данила Леньков, я руковожу платформой A/B-экспериментов Trisigma в Авито. За 7 лет мы прошли путь от небольшой внутренней команды из трёх человек до полноценного технологического продукта, который теперь доступен на B2B-рынке. В этой статье я рассказываю о четырёх ключевых проблемах, с которыми мы столкнулись на пути от десятка экспериментов в год до четырёх тысяч. Это реальный опыт масштабирования, который может быть полезен любой компании, серьезно относящейся к принятию решений на основе данных.

Airbnb недавно завершила первую крупномасштабную миграцию кода под управлением LLM: мы обновили почти 3,5 тысячи файлов тестов React-компонентов, переведя их с Enzyme на React Testing Library (RTL). По первоначальным оценкам ручная работа заняла бы 1,5 года инженерного времени, но — используя сочетание передовых моделей и надёжной автоматизации — миграция завершилась всего за 6 недель.

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

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

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

Асинхронные операции в тестах — головная боль для QA-инженеров. Awaitility упрощает ожидания: код становится надёжным и читаемым. В статье — подключение, примеры, best practices и справочник по методам.