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

Привет, меня зовут Иван, и я зануда.

Сразу скажу, что в моем понимании зануда в тестировании — не тот человек, который всех достал и которого все хотят удушить, а тот, который умеет показать людям, что нужно делать хорошо и не делать плохо, и добиться от них этого. Я считаю, что QA должно расшифровываться как Quality Assistant. Это даже не про Assurance, когда вы обеспечиваете качество, это именно про то, что вы как тестировщик и участник команды помогаете на каждом этапе от требований до выкатки в прод и работы с сопровождением и вашими коллегами добиться того, чтобы каждый этап проходил все лучше и лучше.

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

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

Привет, Хабр. Меня зовут Николай Борисенко. Я специалист по автоматизации тестирования в ОК, и я продолжаю наш рассказ о генерации тестов на основе спецификации API.

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

Привет, Хабр! Я Михаил Бибик, работаю в СберТехе QA-automation-инженером, пишу автотесты для СУБД Pangolin — это целевая СУБД в Сбере и не только. В прошлом году наша команда искала и нанимала QA-инженеров с различным опытом, в том числе совсем начинающих. Когда я провёл штук 15-20 собеседований, то понял, что могу обобщить некоторые наблюдения и составить простые советы по поводу составления тест-кейсов для начинающих (скорее, очень начинающих) тестировщиков. В этой статье я покажу, как применить теорию тестирования на техническом собеседовании. Для этого разберу реальную задачу с нашего собеседования. Проходите под кат.

Привет! Я Даниил, занимаюсь разработкой на Angular в T-Банке и хочу поделиться с вами опытом использования фикстур в Playwright. Я решил поговорить об этом, потому что вместе с ростом функциональности проектов растут и сложности при тестировании, а фикстуры предоставляют удобный способ избавиться от дублирующегося кода и сложных моков.

Эта статья посвящена основам: зачем нужны фикстуры, чем они отличаются друг от друга и какую пользу приносят при тестировании веб-приложений. Мы подробно разберем устройство фикстур, посмотрим, как их создавать и грамотно внедрять в тесты. А еще рассмотрим практические примеры, которые помогут с легкостью применить полученные знания на реальном проекте. Поехали!

Привет, Хабр. Я Мария, тестировщик в «АйТи-Балансе». Как многие начинающие тестировщики, после курсов я вышла на рынок труда с багажом заблуждений по поводу профессии. Из собственного опыта и историй коллег я составила список из 10 распространённых мифов о работе в ручном тестировании и постаралась их развенчать. Рекомендую ознакомиться со статьей всем, кто только учится или ищет работу в manual QA — поможет лучше понять, как на самом деле устроено ручное тестирование и подходит ли этот вариант для построения карьеры в IT лично Вам.

Чтобы понимать, какие запросы можно отправлять в GraphQL API и что можно получить в ответе, нужно уметь читать его схему. Это как WSDL в SOAP API — описание всех доступных методов.

Да, программы типа Postman или Apollo сами считывают схему и показывают вам всё в красивом виде — просто ходи да «натыкивай» запросы. Но если само API ещё в разработке, чтение схемы поможет понять, что вас ожидает.

Поэтому в этой статье я расскажу, что такое Schema GraphQL API и как её читать.

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

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

Локаторы — важная часть автоматизации тестирования. Они позволяют находить элементы на странице для взаимодействия с ними в тестах. Но что делать, если стандартные методы, такие как CSS-селекторы и XPath, становятся громоздкими, ломаются при изменении структуры страницы или не поддерживают уникальные особенности элементов? Решение — кастомные локаторы.

Меня зовут Лёша, и я занимаюсь тестированием в 2ГИС. Моя команда работает над сервисом по бронированию отелей Отелло. В этой статье я расскажу, как использовать кастомные локаторы, чтобы тесты оставались стабильными и поддерживаемыми даже при изменениях в приложении. В примерах я использую Python, но не стоит пугаться, если вы не знакомы с этим языком, каких-то сложных операций мы сегодня выполнять не будем.

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

Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

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

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

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

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

Всем привет, меня зовут Максим Ажгирей, я руковожу в СберТехе командой разработки, которая занимается развитием инструмента нагрузочного тестирования (НТ) SyTester в линейке интеграционных решений Platform V Synapse.

У SyTester есть две редакции: Enterprise Edition (EE) и Community Edition (CE). Вторая — бесплатная, мы сделали её совсем недавно и разместили на GitVerse, то есть протестировать её может любой желающий. Сегодня расскажу о том, какие проблемы мы смогли решить благодаря этому инструменту, а также об особенностях каждой его версии. Статья будет полезна разработчикам, которым нужно быстро, не тратя время на сложные настройки, провести нагрузочное тестирование, а также специалистам, которым требуется тестировать приложения с очень большими нагрузками (от 100 000 ТПС) и для различных протоколов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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