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

Внедрение BDD регулярно вызывает или неоправданный энтузиазм либо глухое упорное сопротивление технических специалистов. Возникают даже терминологические диспуты: подразумеваем BDT, говорим BDD; формулируем требования для разработчиков на Gherkin-е, не внедряя «поддерживающие» практики и называем этот, как минимум, спорный – однобокий подход «true BDD»; утверждаем что BDD и Waterfall не совместимы ...
Так что же такое BDDT на самом деле?

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

Давайте все вместе попробуем дать ответы на все эти вопросы. Приходите – будет интересно и holywar-но.

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

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

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

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

Доклад содержит, в том числе, и преодоление технических трудностей, опыт нагрузки с использованием WebSocket соединения. Сам подход может использоваться для различных инструментов нагрузочного тестирования и вариантов реализации сервисов .

Переход от Водопадной модели к 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?
Как можно сравнивать объекты со сложной структурой?

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