Запрос счета
Заполните поля ниже, чтобы получить счет на оплату билетов DUMP от юридического лица
Юр.лицо
ИНН
Количество билетов
+
Напишите нам
Задайте вопрос, напишите пожелания или оставьте отзыв
Ваш e-mail
Ваше имя
Напишите здесь то, что хотели:
Заявка на спонсорство
Заявка на выступление
Имя и фамилия
Компания
Должность
Город
Ваш e-mail
Ваш телефон
Тема
Краткое описание
Какую ценность слушатели получат в итоге:
В какой секции хотите выступить

Секция Тестирование и QA

Принимаем заявки! Осталась пара слотов на выступления
Программный комитет
Евгения Азанова
Naumen
инженер-программист
Евгений Сабиров
Хост
тестировщик
Дмитрий Якин
Контур
тестировщик
Поданные доклады
Накладывает ли BDD подход Архитектурные ограничения на решения Автоматизации тестирования Front-End и Back-End?
Антон Семенченко,
COMAQA.by
Внедрение BDD регулярно вызывает или неоправданный энтузиазм либо глухое упорное сопротивление технических специалистов. Возникают даже терминологические диспуты: подразумеваем BDT, говорим BDD; формулируем требования для разработчиков на Gherkin-е, не внедряя «поддерживающие» практики и называем этот, как минимум, спорный – однобокий подход «true BDD»; утверждаем что BDD и Waterfall не совместимы ...
Так что же такое BDDT на самом деле?

-Границы применимости и не применимости.
-Что может дать подход и что он дать гарантированно не может?
-Можно ли \ нужно ли использовать BDDT при работе с backend?
-Правы ли технические специалисты, рассуждая о технических ограничениях и «несвободном полете dev фантазии».
-Какие технические ограничения на Архитектуру решений Автоматизации накладывают современные BDD Engine-ы …?

Давайте все вместе попробуем дать ответы на все эти вопросы. Приходите – будет интересно и holywar-но.
Приоритизация тест-кейсов
Лидия Сошкина,
2GIS
Вы крутая команда и колбасите фичи безостановочно. Каждый релиз приносит что-то новенькое не только пользователям, но и в список ваших тест-кейсов. Как сдержать стремительный рост регрессии?

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

Покажу, как работает наша система, на примере мобильного приложения 2ГИС. Не претендую на абсолютную истину и всеобщую универсальность, но верю, что мой доклад будет полезен всем, кто ещё не автоматизировал всё на свете и пока вынужден справляться с большим объёмом ручного регрессионного тестирования.
Слушатель получит практический гайд по приоритизации тест-кейсов
Достоверный нагрузочный тест c учетом непредвиденных нюансов
Антон Нечеухин,
Realtimeboard
Расскажу о том, как можно подойти к созданию нагрузочного теста, когда в короткие сроки необходимо выяснить лимит нашего сервиса, в момент быстрого роста количества он-лайн пользователей.

Доклад содержит, в том числе, и преодоление технических трудностей, опыт нагрузки с использованием WebSocket соединения. Сам подход может использоваться для различных инструментов нагрузочного тестирования и вариантов реализации сервисов .
Инженерия качества во времена DevOps
Алексей Лапаев,
Tinkoff.ru
Переход от Водопадной модели к Agile методологии имеет в продолжение пропаганду DevOps движения. В каждой парадигме команда должна балансировать между скоростью поставки и обеспечением качества. В каждой философии находилось место человеку, своей ролью топившему за перевес в сторону качества, но рынок заставляет переосмысливать применяемые подходы.

Во времена DevOps роли тестировщиков и QA-специалистов становятся не совсем ясны. Давайте посмотрим в будущее профессии и подумаем о том, как стоит подходить к вопросу качества, чтобы не выпадать из ритма развития сферы разработки.

Докопаемся до сути идей "shift left" и "shift right" на простых примерах. Посмотрим на агрегированную информацию по практикам и инструментарию уменьшения времени и стоимости проверок. Спроецируем пирамиду тестирования на DevOps движение и переосмыслим стратегии. Цель - понять, куда эволюционировать из условного тестировщика.
Как отдать технический долг, не работая по выходным
Анна Боголюбова, Точка
Бэклог всегда является какой-то мусорной свалкой на "авось когда-нибудь руки дойдут". Баги и мелкие доработки копятся, на техдолг время не выделяется - всегда есть приоритетные задачи на сейчас, техдолг потом, "когда спокойней будет". А ещё бывает так, что вот есть проект, есть MVP, уже выкатили первый релиз и радуемся, а про всякие остальные доработки, которые могут обрадовать клиента, забываем, бежим дальше к следующему проекту. И все вот такие мелкие задачки копятся и остаются где-то на дне бэклога, на потом, на авось. Клиенты страдают, разрабы страдают поддерживать говнокод и мечтают о выделенном дне рефакторинга, тестеры страдают больше всех. Но что делать: постоянно появляются новые проекты, новые идеи, которые несут большие деньги, статус компании, престиж и т.д., и конечно же, приоритет уходит на выполнение этих действий.

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

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

Но запуская тесты, мы столкнулись с тем, что на тестовых машинах нагрузка ЦП не достигает даже 20%. А это значит, что неэффективно расходуется машинное время и обратная связь до разработчика доходит дольше, чем могла бы.

Решения два: увеличить мощность, заказав новые тачки, либо разобраться в причинах недоиспользования процессора и увеличить параллелелизм тестов.
В докладе расскажу о том, как можно загрузить ЦП на номинальную нагрузку с помощью NUnit 3.10.1. вместо покупки дорогостоящего железа

А так же отвечу на вопросы правда ли, что:
Assert.IsTrue в NUnit -- это сладкий if-esle?
Assert.Throws -- это сладкий try-catch-finally?
При использовании атрибута Parallelizable(ParallelScope. All) создаётся несколько экземпляров [TestFixture] класса?
Какие типы данных можно использовать в аттрибуте [TestCase]
Как можно добиться параллелизма, не используя атрибут Parallelizable?
Как можно сравнивать объекты со сложной структурой?

Если вы знаете ответы на все эти вопросы, то приходите и помогите рассказать остальным.

Оставайтесь на связи

Мы отправим программу, когда она будет готова, и будем заранее предупреждать о повышении цен. Никакого спама

Концепция и темы 2019

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

Что в планах?

  • Инструменты функционального и нефункционального тестирования;
  • Навыки поиска уязвимостей в веб-приложениях;
  • Мастер-классы – для любителей выйти с конференции с практическими знаниями и умениями;
  • Управление командой тестирования и способы решения карьерных перипетий – для задумывающихся о вертикальном росте в профессии;
  • Что такое тестирование сейчас и через 5 лет – для амбициозных тестировщиков (или просто любителей помечтать);
  • Словесные дуэли, круглые столы, прочие эксперименты с форматом – для тех, кто устал от слова "конференция".
Присылайте заявки на блиц-доклады (до 20 минут), технические и хардкор-доклады (до 45 минут) и мастер-классы (до 4 часов).
Купить билет