Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Когда вы пишете end-to-end тесты, аутентификация часто становится первым барьером. Невозможно протестировать реальную функциональность приложения, не пройдя сначала экран логина. Но современные методы аутентификации могут усложнять автоматизацию, используя несколько факторов, которые трудно автоматизировать (в этом и заключается смысл 2FA).

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

Так как же правильно работать с аутентификацией?

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

ИИ-ассистенты для написания кода - Claude Code, Cursor и GitHub Copilot, - становятся частью повседневного рабочего процесса. Они читают файлы, понимают кодовую базу и помогают писать код быстрее. Но есть проблема — они также могут читать .env-файлы. В последнее время в соцсетях ходит история об этом, и я сам столкнулся с этим на практике:

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг лидер стека тестирования в компании «ТехВилл»

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы следите за сферой AI-ассистентов для программирования, то, скорее всего, заметили, насколько быстро всё развивается. Новые модели выходят каждый месяц, и все пытаются выявить «правильный способ» работы с этими инструментами. Я провёл последние пару месяцев, создавая тесты на Playwright с помощью Cursor, и, честно говоря, прошел через множество проб и ошибок. Некоторые вещи работали отлично, другие… не очень.

Я решил собрать всё, чему научился, в этом посте. Давайте разберёмся.

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг лидер стека тестирования в компании «ТехВилл»

Мы продолжаем разговор о том, как применять ИИ в тестировании. В этой статье расскажу, как мы пишем API-автотесты с помощью OpenAPI Generator, Cursor/Claude Code и автоматически считаем покрытие по Swagger через swagger-coverage.

Раньше я уже записывал большое двухчасовое видео по Cursor, где показывал в том числе, как мы генерируем автотесты. Но с тех пор подход немного изменился: мы сильнее завязались на OpenAPI-контракт, добавили Swagger Coverage, JSON-отчёты для LLM и специальные skills для генерации недостающих тестов.

Михаил Ланкин, автор статей команды ТестОпс
Оригинальная публикация

Нестабильные (flaky) тесты создают постоянные трудности для тестировщиков. Такие тесты не отражают состояния тестируемой системы и подрывают доверие к тестовому набору.

Вооружившись лучшими практиками, нестабильность можно свести к минимуму, но полностью избавиться от неё крайне трудно. Чтобы лучше её контролировать, нужны инструменты, позволяющие выявлять нестабильные тесты — например, Allure Report. В этом руководстве мы посмотрим, как Allure работает с нестабильными тестами:

• Исследуем, как устроена история тестов

• Разберёмся, как история позволяет определять нестабильные тесты

• Настроим перезапуск тестов

Эту функциональность мы рассмотрим на примере PyTest, но все те же принципы работают и с другими фреймворками.

Михаил Ланкин, автор статей команды ТестОпс
Оригинальная публикация

Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты?

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

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.

Автор: Фернандо Тексейра (Fernando Teixeira)
Оригинал статьи
Перевод: Ольга Алифанова

Облачные приложения: текущая ситуация

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

Сегодня вы можете построить приложение, на 100 процентов работающее в облаке. Наиболее популярны сейчас облачные провайдеры AWS, Google Cloud и Azure. Именно эти трое во многом обеспечивают работу большинства облачных приложений. В 2023 году компании потратили примерно 270 миллиардов долларов США на облачную инфраструктуру — на 45 миллиардов больше, чем годом ранее.

Большинство облачных провайдеров взимают плату в зависимости от объёма использования сервисов. Чем больше вы используете сервисы провайдера, тем серьезнее будет счёт в конце месяца. Как правило, провайдеры всё ещё предлагают бесплатный тариф, но при превышении определённого лимита вам всё равно придётся платить. Проблема в том, что многие компании сильно зависят от этих сервисов и активно их используют, из-за чего сложно оставаться в рамках лимитов. 49 процентов компаний испытывают трудности с контролем затрат на облако, а 33 процента превышают бюджет на облако на 40 процентов.

Меня зовут Анатолий Бобунов, и в EXANTE я SDET — Software Development Engineer in Test. В последние несколько лет я развивал тестовую архитектуру для бэкенд‑сервисов компании.

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

Со временем такие решения начали накапливаться. Разные сервисы использовали разные паттерны для HTTP‑клиентов, ретраев, подготовки данных и валидации ответов. Общие абстракции постепенно размывались, а направление зависимостей становилось менее очевидным. Дополнительно ситуацию усиливали срочные задачи, которые требовали быстрых изменений без полноценного архитектурного пересмотра. Это приводило к появлению временных решений, которые затем становились постоянными.

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

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

Автор: Анатолий Бобунов

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.