Опубликован выпуск рассылки за 2 квартал 2025 года.

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

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Автор: Астапов Святослав, системный инженер
Оригинальная публикация

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

Автор: Дэн Бурлаку (Dan Burlacu)
Оригинал статьи
Перевод: Ольга Алифанова

Зачем тестировать в Kubernetes?

Мне, как инженеру-тестировщику, поставили задачу разработать автоматизированные UI-тесты (пользовательского интерфейса) для сложного веб-приложения с динамически генерируемым содержимым. Это означает, что у веб-элементов, с которыми мне нужно взаимодействовать, зачастую отсутствуют статические атрибуты, на которые можно легко сослаться. В результате нужно использовать более сложные стратегии поиска и взаимодействия с этими элементами. Попрыгав через ряд колец локализации веб-элементов и убедившись, что я кликаю по нужным кнопкам и имею доступ к правильным встроенным фреймам, я закончил работу над тестами.

Веб-приложение запускается, как отдельная K8S (Kubernetes) копия для каждой клиентской компании, на отдельном кластере K8S, где ресурсы этой конкретной копии сгруппированы в пространства. UI-тесты автоматически запускаются перед крупными обновлениями версий веб-приложения, а также сразу после, чтобы проверить, что обновление не повредило работе приложения. Это было достигнуто через контейнеризацию кода UI-тестов в образ Docker, его отправку в репозиторий организации и использование задачи K8S для деплоя тестов в конкретном пространстве копии перед обновлением и сразу после него.

Образ Docker, разворачивающийся на сотнях ресурсов, должен быть легким, поэтому тесты запускались в окружении Linux. Запуск в Linux без поддержки дисплея означал, что тесты не могли открыть обычны браузер и вынуждены были использовать режим без графического интерфейса. Вся разработка и тестирование в компании проводятся в Chrome, и поэтому я, естественно, использовал ChromeDriver для запуска настройки Chromium в деплое контейнера. Сервер, отслеживающий расписание обновлений, использовался для запуска тестов в конкретной копии веб-приложения, а тесты возвращали на сервер JSON-отчет о результатах.

Евгений Гусинец, Middle+ QA Engineer, автор телеграмм канала о тестировании QA❤️Life https://t.me/QA4Life

На связи Евгений Гусинец — Middle+ QA Engineer из Минска, ментор и автор ТГ‑канала QA❤️4Life. Добро пожаловать в мою небольшую подборку «тестировочной рутины» и советов, как с ней справляться! Наверняка, многие из вас узнают себя в этих ситуациях. А может быть, вы даже сможете поделиться своими «любимыми» повторяющимися задачами в комментариях? В любом случае, надеюсь, этот пост поднимет вам настроение и, возможно, даст пару полезных идей.

Ох, рутина… Это такое знакомое слово каждому, кто хоть раз окунался в мир IT, и тестировщики тут, поверьте, не исключение. Казалось бы, каждый день что‑то новенькое, баги выискиваем, приложения ломаем по‑хорошему... Но если копнуть глубже, у каждого тестировщика найдется свой «день сурка» из повторяющихся задач. Давайте вместе посмеемся (или погрустим?) над этими моментами, разбавив это дело мудростью из книжек, которые не раз помогали мне и моей команде.

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

Автор: Абишек Дюбей (Abhishek Dubey)
Оригинал статьи
Перевод: Ольга Алифанова

Я собираюсь объяснить, как можно измерить производительность Redis. Об этом уже написано множество статей, но я хочу поделиться своим опытом, опытом DevOps-инженера. Я также хочу рассказать о методах, которые внедряются в нашей компании.

Итак, нагрузочное тестирование чего, зачем?

Первое, что приходит в голову – это вопрос, зачем нам нагрузочное тестирование? Наше окружение и так хорошо работает? Или оно хорошо работало с первого же запуска.

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

«Искры туши до пожара, беду отводи до удара»

Проще говоря, легче предотвратить что-то плохое, чем чинить все после того, как ущерб уже нанесен.

Оригинальная публикация

Всем привет! Мы – Саша Королёв и Юля Трусова, инженеры в Design System Авито. Наша команда работает над качеством интерфейсов: актуальностью, предсказуемостью, доступностью. В этой статье рассказываем про наш опыт внедрения edge-to-edge в мобильном приложении Avito для Android.

Материал будет особенно вам интересен, если ваше приложение не использовало режим edge-to-edge, но ввиду последних требований от Google по переходу на target SDK 35, появилась в этом необходимость. Ведь данное обновление применяет режим по умолчанию без возможности его отключить. Из статьи вы узнаете, с какими сложностями столкнулись мы как участники большого проекта при интеграции данного режима в масштабный проект с не одной сотней экранов.

Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Есть ли тут проблема? Почему определенные тесты падают, кажется, всегда

Как тестировщики, мы хотим, чтобы тесты говорили нам, если код продукта ведет себя не так, как мы ожидаем. Во многих окружениях непрерывной интеграции и деплоя (CI/CD) мы привыкли ожидать, что упавшие тесты будут «красными» на дашборде результатов. Красный цвет сообщает, что где-то есть проблема.

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

Автор: Анна Север (Литвинова), Ведущий инженер по качеству, Рексофт

Любите ли вы чек-листы так, как люблю их я?

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

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

Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег — например, они использовали его как шпаргалку, где ожидаемый результат должен быть 400, а где — 404, какие проверки валидны, какие — уже и нет, а какие — следует добавить. Поехали!