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

Немного о проекте

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

QA-инженер подключился к проекту уже после начала активной разработки. В этот момент мы осознанно отказались от наращивания объемной ручной тестовой документации и сделали ставку на E2E-автотесты.

Почему Е2Е?

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

Для нас автотесты стали стратегическим инструментом. Они заменили собой классический ручной регресс и со временем начали выполнять роль индикатора качества — как для команды разработки, так и для менеджмента и заказчиков.

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

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

Фразу «давайте сделаем современнее» можно услышать и от бизнеса, и внутри продуктовой команды. Обычно за ней стоит не конкретная задача, а ощущение, что интерфейс устарел и требует изменений.

Пользователь при этом не думает категориями «современно» или «устарело». Он открывает продукт с вполне прикладным ожиданием: выполнить действие и не задумываться о том, как именно устроен пользовательский интерфейс.

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

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

Контекст здесь тоже играет решающую роль:

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

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

E2E — это тестирование сквозного бизнес-процесса глазами пользователя: от входа в систему до финального действия. В этой статье мы сравним три фреймворка — Selenium, Cypress и Playwright — на основе личного опыта и технических особенностей, чтобы помочь вам сделать осознанный выбор.
 
Зачем автоматизировать UI и почему не мобилку? 

Почему UI? Веб-интерфейсы — основной канал взаимодействия для большинства корпоративных и B2C-продуктов. Их стабильность критически важна.

А почему не мобильные приложения? Автоматизация мобильного тестирования — это дорого. Нужен «зоопарк» реальных устройств или сложные симуляторы, поддержка двух платформ (iOS/Android), а стоимость и сложность поддержки часто перевешивают выгоду. Для многих проектов ручное мобильное тестирование остаётся оптимальным. Поэтому сосредоточимся на вебе.

Selenium

Самый популярный фреймворк. Это как конструктор. То есть огромная система, которую ты сам строишь и сам делаешь как надо. Единственная ее проблема в том, что поддерживать и настраивать ее довольно непросто. И для того, чтобы она работала, нам нужны драйвера (Selenium WebDriver), которые нужно периодически обновлять. Конечно, это можно обойти с помощью драйв-менеджера, но это тоже требует определенных навыков.
 
Сейчас очень популярны два фреймворка: Cypress и Playwright

В современных условиях любая растущая компания рано или поздно сталкивается с необходимостью централизованного управления доступом сотрудников к информационным системам. Какое решение выбрать в такой ситуации?

В мире информационных технологий нет ничего постоянного. Стандарты меняются: если раньше стандартом было развертывание локальных серверов и отдельных учетных записей, то сейчас фокус сместился в сторону централизованного управления идентификацией. Современным базовым стандартом для любой развитой IT-инфраструктуры стал Единый Вход или SSO (Single Sign-On).

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

Наша команда на практике прошла путь интеграции с различными SSO. Мы работали с такими решениями, как WSO2 и ADFS, и каждый раз убеждались в том, насколько SSO важен для инфраструктуры.

Этот опыт позволил определить требования к Identity Provider’у: открытость, масштабируемость и возможность адаптации под быстро меняющиеся бизнес-задачи. И здесь на первый план выходит Keycloak.

Почему именно Keycloak?

В отличие от многих аналогов, Keycloak — это решение с рядом преимуществ:

Практический гайд по внедрению requirements testing: процессы, чек-листы и измеримые результаты с реального проекта.

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

В этой статье мы расскажем о практике тестирования требований (requirements testing) — методе, который позволяет находить противоречия, неоднозначности и логические дыры еще до начала разработки. На реальных проектах это дает снижение количества багов в 2-5 раз и экономию до 30% бюджета.

Что такое тестирование требований и зачем оно нужно?

Тестирование требований — это ранняя проверка и валидация требований до начала разработки. На этом этапе оценивается их полнота, логическая целостность, непротиворечивость и проверяемость.

Основная цель — убедиться, что требования:

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

Технический долг в автотестах достиг точки, когда требовалось принимать решение. Прогоны сотен сценариев занимали больше 10 часов. Из-за этого 2-3 дня в каждом спринте попросту терялись.

Параллельно изменился пользовательский трафик: заметно выросла доля Safari на планшетах. Но автотесты были написаны на Cypress, а он технически не позволяет полноценно проверять работу в Safari на разных устройствах.

Все свелось к трем задачам:

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

Причина такого поведения оказалась в самом фундаменте: автотесты опирались на статичные, «зашитые» данные, созданные еще при первом покрытии кода. Они были разработаны более трех лет назад и для скорости были объявлены в виде констант непосредственно перед кодом теста.

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

Процесс разработки

Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта.

Bare React Native

Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:

React Native прошел путь от решения с фундаментальными архитектурными ограничениями до платформы с современным, производительным ядром. В этой статье мы разберем, как работала старая архитектура на основе Bridge, как ее заменили JSI, Fabric и Hermes, и в каких случаях React Native - оптимальный выбор для проекта.

Старая архитектура с Bridge

В основе этой архитектуры лежат асинхронный Bridge. Нативный код и JavaScript работали в отдельных потоках. Общение между ними происходило через Bridge, который передавал сообщения в формате JSON.

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

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

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

Таблицы в отчетах — это обычно строгие строки, столбцы, цифры, статусы. Их сила в структуре и предсказуемости. Но как только появляются вложения (PDF, сканы, договоры), возникает дилемма:

Делимся практическим кейсом рефракторинга автотестов учетной системы: от линейных скриптов к архитектурному подходу, который ускорил написание тестов в три раза.

Технический долг в автотестах — это катастрофа, которая нарастает незаметно. Сначала «простые и быстрые» линейные скрипты кажутся хорошим решением, но с ростом продукта они превращаются в «спагетти-код», где любое изменение в интерфейсе вызывает часовую рутину правок. Мы прошли этот путь в проекте по разработке учетной системы и нашли выход через внедрение архитектурного паттерна Page Object Model (POM).

Состояние «до» с линейными автотестами

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

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы:

В каждой крупной компании со временем накапливается огромное количество ценной информации — инструкций, регламентов, технологических карт, аналитических отчетов. Однако в большинстве случаев эти данные висят «мертвым» грузом в архивах и папках. Все необходимое где-то есть, но найти вовремя невозможно. Чтобы знания действительно начали работать на бизнес, нужен инструмент, который сможет оперативно доставить их тем, кому они нужны. И именно такую задачу решает ИИ чат-бот на основе технологии RAG (Retrieval-Augmented Generation).

Когда знаний много, но они не работают

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

Проблема не в нехватке данных — проблема в доступе к ним. Как итог:

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

Почему так происходит? И главное - что именно в таблице мешает работать с ней быстро и уверенно?

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

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

MDN Baseline badges и влияние на поддержку браузеров в Angular

Начать стоит не с самого Angular, а с важного обновления в веб-документации MDN (Mozilla Developer Network). Там появились Baseline badges (метки), которые позволяют быстро оценить, насколько целесообразно использовать новую фичу — например, часть браузерного API.

Trunk Based Development (от англ. trunk – «ствол дерева») – метод разработки кода на основе одной главной ветки. В отличие от Gitflow, TBD позволяет разработчикам добавлять новые модули сразу в master. Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни.

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

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

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

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

Некоторое время назад мы решили перестроить управление доступом к рабочему пространству мобильных команд. Изучили рынок и обнаружили, что бесплатная Google Cloud Platform вполне может составить конкуренцию платным решениям. В этой статье мы делимся своим опытом и даем инструкции по подключению.