2 дня офлайна

Спикер расскажет, какие паттерны проектирования стоит использовать в автотестах, исходя из продуктовых задач. Вы узнаете, как сразу писать код автотестов удобно, функционально и красиво. Эмилия рассмотрит разные случаи и то, как под них подстраивать автотесты, чтобы поддержка была более легкой. Примеры будут для web, mobile web, Android и iOS.

В докладе будет рассказано про нагрузочное тестирование в Ozon Tech и проведение 19000 тестов в месяц. О том, как устроен соответствующий сервис в Ozon и какие проблемы он решает. Какие вызовы и проблемы возникли при его построении и развитии.

Часто от команды приходит требование: «А давайте left-shift testing проводить, раньше вникать в аналитику, готовиться к тестированию». А как именно тестировать эту самую аналитику, остается за кадром. Предлагаем на мастер-классе наглядно обучиться тому, как это делать, понять, на что обращать внимание, разобрать понятную для всех постановку аналитики и попробовать применить полученные знания на практике.

Стенды и пайплайны тестирования Flipper Zero. Как проводить различные тесты (юнит-тесты, интеграционные, smoke, e2e) в случае с hardware, как автоматизировать процесс при отсутствующем API с помощью OpenCV, тестировать open source и масштабировать данные процессы?

Любой написанный Android UI-автотест должен на чем-то запуститься, будь то устройство или эмулятор. Но даже оптимально написанный автотест будет работать плохо, если мощности железа под ним не соответствуют потребностям.

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

Библиотека Allure-Go, появившаяся в начале 2022 года, предназначена для E2E-тестов на Go, интегрированных с Allure. Проект начался как форк Testify, но теперь отличается от Testify тем, что имеет полную поддержку Allure, параметризованные тесты и внятно работающую параллельность. Его главные преимущества и особенности: простота интерфейса; широкие возможности детализации отчетов; гибкость; параметризация; параллельная работа тестов.

В чем секрет хороших UI-тестов? Быстро пишутся, легко читаются, редко падают, пишут логи, тестовую документацию, замеряют тестовое покрытие, соблюдают паттерны программирования, распределяются между командами (TestOps), легко меняют фреймворк. Всего 40 минут — и вы узнаете основной рецепт их приготовления. Вместе со спикером вы зайдете во вселенную Microsoft и возьмете у нее самое лучшее.

Проблема автоматизации Flutter-приложений ставит перед тестировщиком ряд нетривиальных задач. Стандартные средства автоматизации не подходят. В докладе будет рассказано, как решать задачу, и сделан краткий обзор трех основных инструментов: утилиты integration_test (ex-Flutter Driver), которую предлагает сам Flutter, библиотеки flutter_gherkin() и Appium Flutter Driver. Рассмотрим на примере, почему стандартный Appium не подходит, разберем плюсы и минусы трех инструментов, проведем практическую часть с примером автоматизации тестового сценария с использованием Appium Flutter Driver.

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

Как простейшим путем, оставаясь в привычном для функциональных тестировщиков стеке, внедрить регулярный прогон тестирования производительности? Зачем здесь Java и стоило ли прикручивать Cucumber? Как понять, что производительность бэкенда не деградировала, но при этом до поры до времени обойтись без профилирования?

Смотрим на нагрузочные тесты под другим углом, и оборачиваем наш любимый JMeter в функциональноподобный тест.

В докладе будет агрегировано рассказано о ручном мобильном тестировании и о том, что для него надо знать. За основу доклада Александр взял свой курс по мобильному тестированию в МГТУ им. Н.Э. Баумана и МИФИ, дополнив его интересными кейсами из реальной практики. Особое внимание будет уделено каверзным вопросам на собеседованиях, которые он встречал за все время работы или задавал сам.

Если взглянуть на API с нестандартной точки зрения, то окажется, что с помощью API-запросов можно значительно ускорить, упростить, стабилизировать UI-тесты, а часть тестирования бизнес-логики и вовсе переместить в область API тестирования. Такие «гибридные» тесты, совмещающие UI и API-шаги, встречаются крайне редко. И хотелось бы наглядно, с примерами, продемонстрировать, что это не сложно, крайне эффективно и никаким канонам классического UI тестирования не противоречит.

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

К результатам нагрузочного тестирования всегда нужно относиться критически. Рассмотрим примеры, где цифры врут, с помощью Apache JMeter и Gatling (в докладе иногда будет встречаться специфика Java/JVM). Сколько RPS выдержит наш сервис? Что мы только что протестировали? Почему на проде цифры меньше/больше? А не хлопнуть ли нам по проду? Если уже знаете ответы, вероятно, это не тот доклад, который вы ищете. Но если только знакомитесь с темой перформанс-тестирования — это тот самый случай, когда о некоторых граблях можно узнать заранее.

В 2021 году при начале разработки Ozon Банка стали выстраивать процесс тестирования, основанный на полной автоматизации. При этом было принято решение тестировать фронтенд в изоляции с замоканными «ручками». А в качестве инструмента браузерного тестирования фронтенда был выбран Playwright. В докладе расскажут, почему был сделан такой выбор, оправдал ли он ожидания, с какими проблемами столкнулись в процессе и какие решения получилось построить. 

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

Вы же не думаете, что все миллионы лет эволюции человека наша природа стремилась к тому, что мы будем сидеть в комфортном кресле и тестировать релизы (или писать автотесты)? Большую часть времени наш мозг создавал сложную систему правил и оптимизаций, чтобы мы не посходили с ума. Думаете, это пошло нам на пользу? Конечно, мы таки не посходили с ума! Но как и любые оптимизации, заточка под happy path не всегда ведет к правильным результатам.

Руслан расскажет, какие именно когнитивные искажения заставляют вас делать ошибки, неверные выводы и предположения. Но он не будет пытаться объяснить, как с ними бороться — тут уж вы сами!

Chrome DevTools — основной инструмент дебага во время веб-разработки. А Console — один из главных модулей DevTools. Его основная задача заключается в отображении ошибок в коде, но также он отвечает и за выполнение команд на JS. Разберемся, как с помощью консоли и других модулей DevTools сократить время на тестирование. Рассмотрим подготовку тестовых данных, автоматизацию рутины, и поймем, нужно ли сделать свое расширение для помощи тестировщикам.

Марс — интересная и загадочная планета. Еще не разгадана тайна марсианских каналов, а на Красной планете уже найдены русла высохших рек и гигантские «колодцы», ведущие в подземный мир Марса. Когда-нибудь на этой планете обязательно побывают люди, но пока ее исследуют роботы. Ближайшая задача — создание роботов-спелеологов, способных автономно исследовать марсианские пещеры. И тестировать их программное обеспечение придется на Земле, моделируя условия Марса.

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

Automatization Nonstop Testing Over Network — автоматизация непрерывного тестирования по сети. Она включает в себя методологию и стандарты, применение которых позволит сделать разработку и тестирование продуктов прозрачным, предсказуемым и более гибким для всех участников команды. Но прежде всего, это платформа для удаленного тестирования и разработки программного обеспечения на реальном «железе», которая воспроизводит все пользовательские и технические сценарии взаимодействия с продуктом на этапе его производства и использования готового продукта.

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

Доклад о том, как работают обычные™ индексы в базах данных. Будет крайне полезен как тем, кто начинает работать с базами данных, так и тем, кто работал, но подзабыл. Используете IndexedDB? А порядок колонок в индексе правильный указываете? Или, быть может, у вас backend на PostgreSQL. И там без индексов никуда. Рассмотрим: как индекс ускоряет поиск, нужно ли индексировать условия where, нужно ли индексировать условия в order by, нужно ли индексировать foreign keys, что делать, если критериев поиска несколько, в каком порядке указывать колонки в индексе, случаи, когда индекс замедляет работу, и как снизить влияние индекса на приложение.

Как появилась и развивалась ферма устройств в VK. Поговорим про выявление проблем и пути их решения с подробностями: как боролись с лагами и с черным экраном при вводе пароля; как учитывали требования разных команд; как делали сервис девайсов для автотестов внутри фермы; как решали вопрос с горизонтальным размещением некоторых моделей.

Большие компании, где больше одного отдела тестирования, часто решают одни и те же задачи сами по себе. Это менее эффективно, чем единый подход. Поэтому в компании спикера решили реализовать один общий инструмент. Был сделан фреймворк на Python, шаблоны для CI/CD и много статей в корпоративной wiki. В итоге получилось снизить порог вхождения в АТ и сэкономить много времени, используя универсальные решения.

Плавность скролла, время появления контента — это тоже можно измерять и тестировать.

Многие из тех, кто знаком с паттерном Dependency Injection (Service Locator), скажут, что это «что-то из программирования» и «нужно для написания сервисов», но точно не относится к автотестам. Но это не так. С помощью данного паттерна (или даже подхода) можно писать автотесты проще и быстрее, а читаемость вашего проекта станет заметно выше.

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

Бывало ли у вас такое, что вы что-то забыли, и пытаетесь вспомнить? А что читать перед собеседованием? Или может, забыли, в какой таблице лежит нужная вам информация в БД на вашем проекте?

Доклад расскажет, как удобнее и эффективнее вести заметки. Он будет полезен как тем, кто только начинает свой путь в QA, так и тем, кто уже давно находится в сфере.

Как пишутся UI-автотесты в команде, отвечающей за авторизацию, регистрацию и восстановление. Необходимо учитывать, что очень часто проводятся эксперименты с фичами: применяются разные страницы авторизации, разные страницы подтверждения телефона и так далее. Используемые технологии: Selenium и Selenide, паттерн проектирования Factory, API для подготовки тестовых данных.

Что происходит после того, как провели нагрузочное тестирование сервиса и получили результаты? Уже есть достаточно много материалов о правильном запуске тестов, различных инструментах, инфраструктуре нагрузочного тестирования внутри разных команд или компаний. Но очень мало рассказов о том, что происходит после нагрузочного тестирования, как работать с результатами и в зависимости от них выстраивать и масштабировать инфраструктуру. Попробуем это исправить.