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

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

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

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

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

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

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

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

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

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

Почему я это пишу

Если вы какое-то время работаете тестировщиком ПО или в разработке, вы, скорее всего, сталкивались с термином «ручное тестирование». Это выражение может вызывать бурные споры.

И дело не только в разных мнениях. Сам термин часто искажает суть тестирования. В худшем случае «ручное тестирование» создает вредный водораздел, обесценивая вклад человека и чрезмерно возвышая автоматизацию. В лучшем — умаляет значимость вдумчивых усилий тестирования.

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

Читать статью полностью...

Что такое bug bash?

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

Bug bash укрепляет сотрудничество, даёт возможность выслушать разные точки зрения и помогает формировать и укреплять культуру качества. Обычно bug bash выглядит примерно так:

• Вы приглашаете кросс-функциональную команду: тестировщиков, разработчиков, продакт-оунеров, дизайнеров, стейкхолдеров. Иногда это просто продуктовая команда, а иногда — люди, которые обычно не ходят на ваши встречи – например, юристы или маркетологи. Важно пригласить и тех, кто ещё не пользовался продуктом (или не пробовал новые фичи).
• Вы задаёте общие правила тестирования продукта. Как и на обычной вечеринке, хороший хозяин должен обозначить ожидания и рамки.
• Веселитесь! Геймифицируйте тестирование (несколько идей ниже).
• В течение нескольких часов или даже нескольких сессий по паре часов команда сосредоточенно тестирует продукт, следуя заданным правилам.
• Обязательно заложите время на перерывы.
• Закуски и напитки тоже всегда приветствуются.

Читать статью полностью...

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

Читать статью полностью...

Знаете ли вы, что Chrome DevTools предназначены не только для разработчиков, но и для тестировщиков? Для QA-специалиста важно не просто находить баги — понимание первопричин их появления и умение предложить возможные решения выводит тестирование на новый уровень.

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

Чтобы максимально эффективно использовать Chrome DevTools, тестировщикам стоит иметь базовые знания HTML, CSS, DOM, JavaScript и уметь читать сетевые ответы.

Читать статью полностью...

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

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

Подход, который я долгое время использовал массово - написание юнит-тестов с использованием Mockito. В заглушки превращается любой сторонний сервис, используемый тестируемым классом. Тесты супер-быстрые, все зеленое, все супер!

Со временем я заметил, что этот подход начал изрядно напрягать. Часто на две строчки кода приходилось писать не менее 10-20 строк теста.

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

Дальше - больше. Множество зеленых галочек, появляющееся на экране при запуске тестов, не могло не радовать. Но вот ты решаешь сделать минимальный рефакторинг, оптимизировать какой-то метод. В этот момент все разваливается на куски. Куча красных тестов! Как, почему? Да просто во внутренней реализации ты перешел на использование другого метода, добавил в метод еще один параметр или что-то подобное. В результате куча тестов перестала работать. И теперь, поменяв одну строчку в процессе рефакторинга, надо поменять еще 30 строк в тестах. В какой-то момент начинаешь ловить себя на мысли - “Ни в коем случае, никаких рефакторингов больше!”

Читать статью полностью...

Когда десять лет назад я начинал свою карьеру тестировщика, я был только со школьной скамьи, и формальных подходов к тестированию не знал. Позже, работая с разработчиками в командах разного размера, я узнал о нескольких подходах, включая разработку через тестирование (TDD).

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

Читать статью полностью...

Представьте утро. Вы открываете ноутбук, заходите в Allure — и видите красное море.

Падает половина автотестов, часть — «временно», часть — «иногда». Почти каждый день начинается с одних и тех же починок, дебага и «вроде теперь стабильно».

Знакомо? Скорее всего да, иначе вы бы не открыли эту статью.

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

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

Каждый упавший тест — это не просто «флак» или «ошибка окружения». Это пропущенная проверка, потерянное доверие и часы бесполезных фиксов. Если таких тестов сотни, то со временем автотесты перестают быть инструментом качества — и превращаются в источник шума.

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

Читать статью полностью...

Для сокращения усилий тестирования или полного прекращения тестирования какой-то области может быть множество причин.

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

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

Читать статью полностью...

Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».

Читать статью полностью...

Введение в тестирование «shift-вниз»

Исследуя тестирование программного обеспечения, часто слышишь про два подхода: shift left (сдвиг тестирования на более ранние этапы разработки) и shift right (расширение тестирования до прода). Оба подхода полезны, как проверка дома во время строительства и после него. Однако существует ещё одно измерение, которое заслуживает внимания — сдвиг вниз, ближе к фундаменту кода.

Представьте, что вы строите дом. Разве вы начнёте украшать стены до того, как убедитесь, что фундамент прочен? Схожим образом в тестировании ПО (хоть мы зачастую сосредотачиваемся на проверке того, что видят конечные пользователи, на стенах и декоре) тщательное тестирование фундамента приносит огромную пользу. Здесь и приходит на помощь сдвиг тестирования вниз.

Читать статью полностью...

В этой статье я расскажу о первых впечатлениях и опыте использования инструмента low-code для автоматизации UI-тестов. Если вы незнакомы с термином «инструменты для автоматизации тестирования с низким порогом кода (low-code)», это визуальные инструменты, позволяющие пользователям автоматизировать тесты с минимальными или нулевыми знаниями программирования.

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

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

Читать статью полностью...

Привет, меня зовут Ирина, я тестировщик в продуктовой команде iSpring.

В этой статье я на реальном примере интеграции OpenSearch в LMS iSpring Learn расскажу, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Мы не только разберём базовые проверки, но и погрузимся в тестирование стемминга, релевантности, работы в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск».

Читать статью полностью...

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

Привет, я Рафаэла Азеведо! Уже 17 лет я работаю инженером по разработке и тестированию и специализируюсь на QA, тест-автоматизации, Web3, DevOps, мониторинге и предупреждениях.

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

Как тестировать ИИ-приложения: личный опыт

ИИ-инструменты разработки бросают тестированию уникальные вызовы, особенно когда речь идёт о качестве кода, безопасности и масштабируемости. Большинство людей, использующих ИИ для написания кода, обнаруживают, что хоть инструменты и могут генерировать впечатляющие прототипы, сложность реальных систем всё равно требует значительного участия человека. На мой взгляд, это вывело QA и тестировщиков на передний план — они стали важнее, чем когда-либо.

Когда ИИ-инструменты только появились, казалось, что это идеальное решение для эффективной разработки, способное производить качественный код с невероятной скоростью. Такие инструменты, как Lovable.dev, Replit, Manus, A0.dev и Firebase Studio, отлично подходят для быстрого прототипирования. Но код, который они создают, часто не выдерживает требований контекста, масштабируемости и интеграции с системой.

Читать статью полностью...

В феврале этого года я писал на Хабре про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.

С тех пор фреймворк вырос. Сильно. Из узкоспециализированного решения для промышленного ПО превратился в универсальный инструмент. Теперь работает с чем угодно - офисные пакеты, банковские клиенты, CAD-системы.

Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.

Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.

Читать статью полностью...

Зачем вообще нужно нагрузочное тестирование

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

Читать статью полностью...

Что общего у кулинарии и автоматизации тестирования?

Что общего у кулинарии и автоматизации тестирования, спросите вы? Можно провести красивые параллели между программированием и готовкой: автоматизаторы тестирования как шеф-повара, скрипты автоматизации как рецепты, фреймворки автоматизации как кастрюли и сковородки, а кулинарная книга — как эта статья! Эта статья посвящена всем тестировщикам, которые ищут новые рецепты аутентификации с использованием Playwright.

Статья предназначена для автоматизаторов тестирования, которые уже знакомы с Playwright или используют его в своей работе. Для демонстрации я буду использовать учебный магазин Book Cart, на который я наткнулась в статье Сары Дири на сайте Ministry of Testing.

Для этой «поваренной книги» я отобрала четыре рецепта аутентификации, варьирующиеся от базового до среднего уровня сложности. Эти рецепты используют сочетание методов аутентификации через UI и API, с объяснением реальных сценариев применения для каждого из них.

Читать статью полностью...

Пролог

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

О статье и общая проблематика

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

• это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сосмнения), что их воспоминания о фактическом поведении “серой логики” верны 

• на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”

• сам проект уже в production

• при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)

Согласитесь, не так, чтобы эти условия были какой-то редкостью).

Читать статью полностью...