Войти через соцсеть:
Войти через email:
В докладе мы поделимся новым опытом нашей команды в повышении стабильности автотестов. Мы рассмотрим подходы в работе с локаторами, обеспечивающие их долгосрочное использование, в том числе введение кастомных атрибутов и унификацию написания кода. Также расскажем, как нам удалось вовлечь в этот процесс разработчиков. Во второй части доклада будут представлены инструменты и правила, которые мы разработали для контроля состояния автотестов.
В докладе обсудим, как подняться из задач, нахождения багов и подсчета метрик качества дальше - в понимание бизнеса.
Зачем вообще обычного тестировщику понимать, как работает бизнес и кто у нас клиент.
Разберемся в двух крайностях - "Гендальф", который блокирует каждый релиз или "провайдер информации" который дает выбор бизнесу в принятии решения, катить или нет.
Погрузимся во все стадии бизнеса, что в них делать и почему.
В докладе я расскажу о том, как внедрение в процесс тестирования метрики тестового покрытия может может улучшить качество продукта и оптимизировать подход к осуществлению тестов. Фокус на тестовом покрытии в процедурах подготовки и проведения тестов позволит не только определить какие части продукта были протестированы, а какие ещё нет, но и выявить, каким модулям не хватает внимания и какие проблемы испытывает проект в плане ведения требований.
Также я рассмотрю, как подсчитывать тестовое покрытие и производить тест-аналитику на проектах, испытывающих проблемы с ведением требований: на проектах с непрослеживаемыми требованиями, с неатомарными требованиями или даже на тех, где требования и вовсе не ведутся. В завершении мы поговорим о тех метриках, которые могут быть выведены, исходя из подсчитанного тестового покрытия и приведу пример нескольких способов оформления подсчётов этих метрик.
Инструменты и модели выходят каждый день, но есть нечто общее - умение пользоваться ими посредством методов промпт-инжиниринга. О них и поговорим
В докладе я поделюсь собственным опытом по реализации тестов с токенами под платформы Windows/Linux.
Какие инструменты для этого необходимы и как ими пользоваться.
С какими проблемами можно столкнуться и как их решить.
Также расскажу, как можно организовать проброс токенов по сети без специального оборудования (USB over IP концентратор DistKontrolUSB).
1. Ретроспектива опыта
2. Основные факапы и как их можно избежать или решить
3. Какие факапы не являются факапами
Нагрузочное тестирование - сложный и дорогой процесс. Но мы в озон запускаем более 35к тестов в месяц, большая часть из которых по проду. В докладе расскажу как мы в Озон проводим регулярные нагрузочные тесты и при этом пиково выдаем более 3.5 миллионов RPS на наши сервисы. Так же - какие мы проблемы при этом решали и почему они возникали.
Сервисный подход к нагрузочному тестированию часто представляют как универсальное решение для повышения эффективности проектов. Однако на практике он может принести не меньше сложностей, чем пользы. В этом докладе:
Разберем, какие проблемы может создать сервисный подход, и почему они часто остаются незамеченными на старте.
Обсудим реальные кейсы, когда сервисный подход стал не спасением, а источником дополнительных рисков и ошибок.
Поделимся методами, которые помогут не превратить "сервис" в хаос, а извлечь из него максимум пользы.
Этот доклад — о том, почему сервисный подход не всегда работает, как его избежать ошибок и подготовиться к реальным трудностям. Также вы узнаете, какие потенциальные проблемы могут ждать на пути внедрения нагрузочного тестирования в подобных условиях.