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

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

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

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

Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке. И сегодня я расскажу как подготовиться к интервью, если у вас мало или совсем нет опыта в найме и отборе кандидатов. Какие вопросы задавать, как анализировать ответы кандидатов и принимать взвешенные решения, чтобы собеседование проходило комфортно и эффективно для всех участников.

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

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

Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.

Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.

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

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

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

Мне неожиданно помогла локально запущенная лама, которая мощно сходу дала мне хорошую подсказку, как сделать в скрипте постмана запрос с телом urlencoded и сохранить из него ответ в переменные. Чем я собственно и хотел поделиться.

Итак исходное положение. Имеем некую коллекцию запросов в постмане и все креды для авторизации сохранённые в переменных.

У нас есть запрос Auth, который получает токен авторизации.

Статья нацелена в первую очередь на PHP backend-разработчиков уровня junior/middle, чтобы познакомить с теорией, которую спрашивают на собеседованиях, и с практическими примерами/советами, полезными для разработки.

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

Автоматизация тестирования, которая не ломается при первом редизайне

Как мы проектировали, внедряли и поддерживаем живую систему автотестов

Как использовать в тестировании ИИ? Как тестировать сам ИИ? И главное: как не завязнуть в излишнем хайпе вокруг ИИ, а совершенствоваться и в «нехайповых» темах вроде безопасности или нагрузки?

Мы уже много лет проводим конференцию по тестированию Heisenbug. Если посмотреть, как менялась программа с годами, получится срез актуальных для индустрии вопросов, который постепенно изменялся со временем. Например, можно проследить, как с определённого момента среди тем появилось название Playwright, и никуда уже не делось (вот и в этот раз встретится).

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

В программу ещё вносят последние детали, и отдельные доклады здесь не описаны — пусть тогда они будут секретом-сюрпризом.

Привет, Хабр!

Cегодня рассмотрим то, как мокировать зависимости в Go. Мокирование — это замена реальных зависимостей на предсказуемые заглушки для изолированного и быстрого тестирования. Вместо реальной БД или внешнего API подставляем stub, mock или fake, которые возвращают заранее определённые результаты или фиксируют вызовы. В Go это реализуется через интерфейсы и dependency injection: определяется контракт (интерфейс) и используем его в коде, а в тестах подставляем нужную заглушку.

Дратути!

Работая в одной финтех компании TL QA, я столкнулся с тем, что уровень моих сотрудников по автоматизации не дотягивает до нужного, а рутину хотелось бы автоматизировать. В компании использовался Python (вроде все легко и просто) и все попытки обучить персонал через четкий индивидуальный план развития заканчивались тем, что у сотрудника «не хватало» времени на обучение и поднятие своего грейда как специалиста.

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

Итак, приступим к интересному.

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

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

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

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

Традиционные подходы к тестированию на многих уровнях уже не успевают за реалиями разработки: ручное тестирование становится слишком трудоёмким, а написание unit- или end-to-end-тестов не всегда позволяет отследить именно визуальные изменения. И здесь на помощь приходит методология скриншотного тестирования — мощный инструмент для выявления визуальных багов, появляющихся в интерфейсе. Он позволяет убедиться в том, что ваш продукт отображается так, как задумано, и избавляет команду от многих сюрпризов.

Работа с Playwright всегда доставляет мне удовольствие. «Наиграв» уже десятки, если не сотни часов в библиотеке, решая проблемы, копаясь в исходниках или на просторах сети, я практически всегда находил удачное решение. И это я списываю не столько на свой опыт, сколько на удобство самой библиотеки. Чаще всего удачные решения находились уже в коробке. А то, что приходилось допиливать руками, всегда сопровождалось ощущением игры и веселья – настолько приятно и легко работать с этим инструментом. Вот уже год, как наши тесты работают стабильно без каких-либо значимых изменений. Сегодня я расскажу вам о скриншотных тестах, реализованных на основе Playwright и Storybook.

Привет, Хабр!

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

Всем привет! Меня зовут Макс. Я Lead Backend в компании ИдаПроджект и автор YouTube-канала PyLounge.

Любой крупный проект так или иначе используют брокеры сообщений — и чаще всего это Apache Kafka. Так что уметь взаимодействовать с Kafka (хотя бы на базовом уровне) будет полезно как разработчику, так и тестировщику или аналитику. 

Я в своей работе практически ежедневно взаимодействую с кафкой, поэтому решил поделиться опытом. В команде мы используем графический интерфейс Offset Explorer (далее OE), о котором сегодня и пойдет речь.

Погнали!

Привет! Меня зовут Артём Дронов, я аналитик команды A/B-тестирования в Авито. Недавно мы выпустили на внешний рынок продукт, разработанный AvitoTech, который помогает нам проводить эксперименты в компании — это платформа для А/Б-тестирования Trisigma. В этой статье я сделаю краткий обзор основных возможностей платформы и расскажу о её преимуществах.

Со старта нашего проекта Polymatica EPM (бизнес‑платформа для автоматизации процессов стратегического планирования и бюджетирования) мы решили: код должен покрываться тестами. Проект построен на стеке FastAPI + Poetry + Pytest. Из‑за особенностей проекта тесты, в основном, функциональные. Все шло хорошо, команда росла, тесты писались, но запускались только на локальной машине перед коммитами. Наступил момент, когда нужно было внедрить автоматический прогон тестов на этапе Merge Request (MR).
На тот момент у нас был собственный GitLab и настроенный CI/CD, но ресурсы DevOps были ограничены. Поэтому задачу пришлось решать силами разработчиков. Меня зовут Дмитрий Богданов, я старший бэкенд‑разработчик, и в этой статье расскажу, как мы оптимизировали запуск тестов, с какими проблемами столкнулись и почему выбрали именно базовый образ для CI/CD.

Пирамида тестирования — это модель, помогающая сбалансировать юнит-, интеграционные и UI/E2E-тесты по скорости, затратам и эффективности. В статье разбираются классическая пирамида (Майк Коун), песочные часы (Маурисио Аниче), перевернутая пирамида и гибридные подходы, востребованные в Agile и DevOps.

Особое внимание уделено перевернутой пирамиде: несмотря на ее неэффективность в классическом тестировании, она применяется в геймдеве, мобильной разработке и AR/VR, где критически важны UI и пользовательские сценарии.

Также рассматривается связь тестирования с DevOps и CI/CD: как распределение тестов влияет на скорость релизов, стабильность пайплайнов и качество продукта. В статье есть практические рекомендации по автоматизации, параллельному запуску, контрактному тестированию и CI/CD-интеграции.

Ссылки на авторитетные источники — включая Continuous Delivery (Хамбл, Фарли) и Agile Testing (Грегори, Криспин) — помогут глубже разобраться в теме.