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

Если вы знаете ответы на все эти вопросы, то приходите и помогите рассказать остальным.
Мы пишем все автотесты до релиза фичи (без автотестеров)
Виталий Рощупкин,
Контур
Мы давно покрыли весь регресс автотестами. Для поддержания покрытия мы "всего лишь" пишем новые тесты до релиза каждой задачи.

В команде разработки нет выделенных автотестеров, и мы не хотим их нанимать. Поэтому разработчики пишут тесты всех уровней (включая UI) до передачи задачи в тестирование. А тестеры делают код-ревью и дописывают недостающие автотесты.
При этом, у тестеров нет власти. Мы не можем приказать разработчикам: "Все пишите тесты!". Приходится договариваться.

В докладе я расскажу, что нужно делать тестировщику, чтобы развить такую культуру разработки. И что можно сделать, чтобы её развалить. Техномяса не будет, доклад про психологию и общение с людьми.
E2E тесты — это мерзость
Дмитрий Красильников,
DINS
Управленческие поединки
Дмитрий Якин,
Контур
Многие из нас прокручивают в голове прошедшие или будущие диалоги. Какими они могли быть, что надо было сказать. «В другой раз я обязательно выйду победителем».

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

Мы проиграем несколько эпизодов и рассмотрим, что было надо сказать, а что было лишним. Приходите поучаствовать или просто посмотреть.

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

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