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

Среди разработчиков бытует поговорка «никаких деплоев в пятницу», оправдавшая себя в 2024 году. 19 июля мир замер от крупнейшего краха, когда-либо ранее зафиксированного. Глобальный сбой был вызван обновлением ПО «CrowdStrike Falcon» от гиганта в сфере кибербезопасности CrowdStrike, которое нарушило работу критической инфраструктуры во многих сферах. Поскольку инфраструктура становится всё сложнее, это однозначно не последний катастрофический сбой. Однако он не был и первым. История полна примеров, подтверждающих «цифровую хрупкость».

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

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

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

Привет! Меня зовут Иван, я разработчик из Яндекс 360. Делаю Телемост — сервис для видеозвонков.

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

Недавно у меня была возможность обсудить трудности, уроки и успехи в разработке Spectrum Web Components вместе с коллегами-разработчиками пользовательских элементов из команд IBM, ING, SAP и Vaadin. Один из участников панельной дискуссии справедливо отметил, что разработчикам не хватает материалов, которые можно было бы использовать для внедрения надёжных практик доступности в области веб-компонентов.

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

Печальная картина, когда кандидат на серьёзные позиции скидывает резюме, где навыки идут следующим образом:

• Функциональное тестирование

• Написание чек‑листов

• Анализ документации

• Заведение багов

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

Навыки в резюме — это умения, знания и владение программами, которые позиционируют соискателя как профессионала.

Вам надоело ждать выполнения набора тестов при помощи Playwright? Хотите запускать тесты на разных операционных системах и браузерах без необходимости управлять сложной инфраструктурой? Ускорить выполнение тестов и улучшить покрытие, запускать тесты на различных комбинациях ОС и браузеров поможет Microsoft Playwright Testing.

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

Привет! Меня зовут Катя, я тестировщик.

Когда я только пришла работать в 2ГИС, я занималась тестированием фронтенда карты. Всё было чётко и понятно, ведь был один проект. Но когда я переключилась на тестирование бэкенда, ситуация радикально изменилась. В работу команды, связанной с пользовательским контентом, входило 30+ проектов разного размера и приоритета, с разным уровнем покрытия тестами. Из общего только, что все проекты разработаны на Go, а автотесты — на Python.

Ситуация была настоящий «омагад🫣». Даже опытным сотрудникам было сложно ориентироваться в каждом проекте, не говоря о новом члене команды. Это приводило к неприятным последствиям. Например, перед внедрением фич мы часто не могли прогнозировать время тестирования и оценивать необходимые усилия. Бизнесу давались одни сроки, но на практике они сдвигались из-за неожиданно обнаруженных проблем. В результате доставка фич на бой затягивалась или срывались сроки, нарастал техдолг, и вся эта вакханалия повторялась по кругу.

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

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

Меня зовут Кирилл Поляков, я ведущий инженер по тестированию Lamoda Tech. В этом тексте я поделюсь своими ответами, основанными на 12-летней практике в тестировании. Разберем, как связаны чистая архитектура и пирамида тестирования, расскажу нюансы выстраивания стратегии на разных уровнях тестирования, дам рекомендации для QA-инженеров, которые помогут улучшить процесс проверки кода.

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

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

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

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

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

Все началось пару дней назад, когда ко мне в предложку ВК попал мой первый руководитель, с которым мы не виделись уже несколько лет. Перейдя в профиль, я увидел, что он учился в Сомалийском Университете Пиратства и Абордажного Судозахвата. Мы всегда пользовались и пользуемся лицензионным ПО, поэтому я сразу смекнул, что ни на какого пирата он не учился. Дальше я попробовал через веб-интерфейс в своем профиле поставить такое же высшее образование, но такого университета в списке доступных не нашлось... Но откуда тогда взялся университет пиратства?

Статья кратко описывает основные концепции и преимущества использования лямбда-выражений в Java, а также их применение в сочетании с функциональными интерфейсами и новыми возможностями, такими как stream() и ссылки на методы. Она будет особенно полезна начинающим тестировщикам-автоматизаторам, знакомящимся с современными подходами к работе с кодом.

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

Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works:Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!

JavaScript и Node.js имеют множество библиотек тестирования и утверждений, таких как Jest, Jasmine, Qunit и Mocha.

В этой статье мы рассмотрим, как использовать Mocha для тестирования, Chai для утверждений и Sinon для моков, шпионов и стабов.

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

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

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд.

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

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

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

Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки «на глаз» оказывались неточными. Ведь если заложить слишком много рисков — в продакшен попадут не все задачи, а если их не заложить — есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

Интеграционные тесты, написанные программистом — это отличный способ обеспечить уверенность в своём веб-сервисе.

В мире .NET для разработки веб-сервисов обычно используют ASP.NET Core, но интеграционное тестирование часто упускают из виду либо делают не очень качественно.

Статья покажет полноценный подход к организации интеграционных тестов на языке Gherkin для API-сервиса, написанного на C# 12 с ASP.NET Core 8 и использующего PostgreSQL.

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