Тестирование

Привет Хабр!

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

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

API (Application Programming Interface, программный интерфейс приложения), является жизненно важным компонентом в современном ландшафте разработки программного обеспечения, обеспечивая строительные блоки для взаимодействия приложений друг с другом. В этой статье рассмотрим пять основных типов API: REST, SOAP, WebSocket, gRPC и GraphQL, чтобы получить более четкое представление об их функциях, особенностях и идеальных сценариях использования.

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

Привет, меня зовут Андрей Николаев и я занимаюсь автоматизацией тестирования в hh. Более 2/3 наших десктопных пользователей прямо сейчас используют последнюю версию Google Chrome, поэтому мы хотим, чтобы и в наших E2E-автотестах (Java + Selenium) версия браузера была максимально приближена к пользовательской. Но не всегда апгрейд версии в тестах проходит гладко (то работа с куками поменяется, то remote DevTools по умолчанию оказываются недоступны, то просто наши хитровыдуманные клики начинают кликать не туда, и т.д. и т.п.). Поэтому нельзя просто так взять и поднять версию Chrome в автотестах — нужна предварительная проверка, которая при ручном выполнении требовала множества телодвижений, поэтому в какой-то момент мы решили, что раз работа серверов стоит дешевле работы человека, то пусть они и проверяют.

Привет, Хабр! На связи Марк Ерофеев и Никита Потапов из команды Platform V UI Workflow СберТеха. Мы затронем одну из наименее раскрытых тем — тестировании плагинов IDE. Если вы хотя бы раз пытались протестировать плагин, то знаете, что примеров с хорошим покрытием тестами днём с огнём не найти. Плагины либо не тестируются вовсе, либо логика их настолько проста, что хватает элементарной проверки функциональности.

Мы расскажем, как автоматизировали тестирование плагина для IntelliJ IDEA. Статья будет полезна всем, кто ищет информацию на эту специфическую тему или вообще интересуется нетривиальными задачами в области тестирования.

Всем привет!

В этой статье хотел бы поделиться опытом автоматизации REST API с помощью таких инструментов как Postman, Newman и Jenkins.

Postman — популярный клиент API, который позволяет тестировать, делиться, создавать, сотрудничать и документировать процесс разработки API внутри команды. Немаловажной функцией Postman является возможность писать и выполнять тесты на основе JavaScript для API. Postman предлагает встроенные инструменты для интеграции API для некоторых инструментов непрерывной интеграции (CI), например Jenkins.

В данной статье разберём, как писать API автотесты на TypeScript и Playwright, применяя лучшие практики автоматизации.

Разбираем процесс создания UI автотестов на python с самого нуля.

В этой статье установим Python и PyCharm. Начнем пользоваться GitHub, автоматизируем работу в браузере, найдем локаторы. В результате получим работающий автотест.

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

Пишем UI автотесты на TypeScript используя Page Object, Page Component, Page Factory, Playwright, Allure.

Что может быть более полезно для будущего, чем образование?

Что может быть более полезно для образования, чем интерактивный QA-учебник состоящий из 42 модулей, 42 онлайн-тестов, 500+ страниц от менторов с суммарным опытом 100+ лет?

Что может быть более полезно для кошелька QA-студента, чем когда это всё бесплатно?

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

Как правильно писать API авто тесты на Python используя Pytest, Pydantic, Httpx, Allure.

Эта статья как продолжение статьи Как правильно писать UI авто тесты на Python. Если мы говорим про UI автотесты, то тут хотя бы есть паттерны Page Object, Pagefactory; для API автотестов таких паттернов нет. Да, существуют общие паттерны, по типу Decorator, SIngletone, Facade, Abstract Factory, но это не то, что поможет протестировать бизнес логику на уровне API тестируемой системы

Как правильно писать UI авто тесты на python используя Playwright, Page Object, Page Component, Page Factory.

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

Вот почему нагрузочное тестирование так важно. Кроме коммерческих инструментов, также доступны варианты с открытым исходным кодом.

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

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

Российские ритейлеры уже не первый год трансформируются в ответ на внешние обстоятельства и внутренние потребности рынка. Своевременная и адекватная реакция на быстро меняющуюся ситуацию на рынке розничной торговли позволяет ритейлеру отстроиться и опередить конкурентов. Часть компаний активно разрабатывает собственные ИТ-решения для оптимизации производственных процессов и выстраивания крепких и доверительных отношений с клиентами. В то же время возрастают и критерии, предъявляемые к качеству программного обеспечения.

Для обеспечения и поддержания высокого качества ИТ-продукта необходимо включить этап тестирования в жизненный цикл разработки ПО. Отсутствие этого важного этапа отрицательно сказывается на безопасности, производительности и функциональности конечного продукта. Тестирование любого ИТ-проекта на ранних стадиях его работы позволяет снизить затраты и издержки на ликвидацию возникающих ошибок. Главная задача QA-инженера ­— помочь команде разработки предоставить заказчику удобное и стабильно работающее решение. 

В этой статье рассказываем, как мы в команде «Автомакон» проводим тестирование 1С-продуктов и сервисов для одного из ведущих ритейлеров страны — ВкусВилл. Наши специалисты отвечают за автоматизацию более 1300 магазинов, складов сети и 120 дарксторов, а также оказывают поддержку и консалтинговые услуги. 

Привет, Хабр! Меня зовут Сергей Петровский, я руководитель IT-направления в СберТехе — компании, которая строит цифровой фундамент Сбера.

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

SyntWork, о котором пойдёт речь, входит в семейство инструментов Platfrom V Works для agile-разработки. Эта статья — первая в цикле материалов о Works. В следующих статьях расскажем про другие инструменты: в Works много сервисов для agile-разработки, и каждый достоин отдельного материала.

Поехали!

На большей части проектов сейчас востребованы знания по тест-дизайну и тестированию API.

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

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

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

Несколько месяцев назад на моем пути возник GraphQL.

Это произошло, когда я присоединилась к одному из наших проектов, где был не только привычный REST, но и GraphQL API. Это было моё первое знакомство с ним. Я понятия не имела, что он собой представляет, в чем его особенности, а самое главное для меня, как QA инженера – не знала, как его тестировать. 

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