Стачка.QA

От качества продукта зависит буквально все в мире информационных технологий: работающее ПО, счастье пользователей, клиентов и самих разработчиков!

На секции прозвучат доклады про:

  • Методологиям тестирования
  • Разработке в тестировании
  • Нагрузочному и мобильному тестированию.

Купить билеты


Антон Семенченко
CSO, Co-founder, IT Consultant @ COMAQA, CoreHard, EPAM, DPI.Solutions
Minsk

Мы так привыкли к сложным решениям разработки из кровавого enterprise, что порой, на «автопилоте», не задумываясь, переносим неоправданно тяжеловесные подходы, Architectural и Design Pattern-ы, Approaches, взращивая кодо-монстра в считанне месяцы \ годы. Наиболее популярным техникам кодо-монстро-производства и будет посвящен наш доклад. На выходе мы получим checklist из 10 стандартных задач и способов их решения от упрощенного, до оптимального и далее технически-кошмарного. Приходите – будет интересно и holywar-но :)


Александр Александров
Эксперт @ RSTQB
Москва
Бесконечность тестирования

Доклад принят в программу конференции


из Доклады

    — Исчерпывающее тестирование невозможно

    — Значит, надо правильно планировать усилия и рубить концы.

    — И на это можно смотреть как с технологической (приоритеты и риски), так и с экономической (деньги) точек зрения.

    — Детализация этих двух точек зрения, особенно второй


    Павел Сташевский
    Senior QA Engineer @ Lamoda
    Москва
    Тестирование больших кросс-командных проектов в дедлайн

    Доклад принят в программу конференции


    из Доклады

      Большие проекты, в которые включено сразу много команд и сервисов, интересны тем, что рано или поздно нужно протестировать ВСЁ. И не только протестировать, а пофиксить баги (лучше не на продакшне) и задеплоить сервисы в нужном порядке.

      И очень часто этот этап становится неуправляемым. То нельзя поднять нужную инфраструктуру на тестовых стендах, то кто-то постоянно включается/выключается из процесса, то появляются критичные ошибки, то кто-то не успел свою часть разработки. В итоге интеграционное тестирование идет долго и мучительно.

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

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

      1) какие есть роли в кросс-командном проекте, и зачем нужен интеграционный QA Lead;

      2) как подготовиться к интеграционному тестированию, чтоб не было мучительно больно;

      3) тестируем. Где, кем и как долго;

      4) протестировали. Что дальше?


      Александр Сеничкин
      @ PVS-Studio
      Тула
      В помощь разработчику: мини анализатор кода на базе .NET Compiler Platform ("Roslyn")

      Доклад принят в программу конференции


      из Доклады

        В процессе разработки проекта, часто сталкиваешься с одинаковыми паттернами ошибок. Своими или коллег по команде. Возможно ли автоматизировать проверку этих паттернов? Мы занимаемся именно этим и можем показать вам, как написать свой анализатор. Я покажу возможности Roslyn на примере автоматизации проверки некоторых ошибок.


        Парвиз Хавари
        Старший специалист по автоматизированному тестированию @ Открытая мобильная платформа
        Иннополис
        Упрощаем автотесты API на Python

        Доклад принят в программу конференции


        из Доклады

          Тестирование Web-API довольно интересный и, порой, сложный процесс. В чем же заключается его сложность? Обсудим некоторые проблемы, с которыми приходится сталкиваться:

          - Необходимость проверки структуры ответа от сервера;

          - Генерация тестовых данных для избежания дублей;

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

          Рассмотрим варианты того, как можно решить эти проблемы используя библиотеки attrs, cattrs и faker. Также не обойдем стороной и строгую типизацию, так как без нее никак.


          Максим Голубев
          QA Lead @ ФИКС
          Казань
          Как не потерять контроль над качеством ?

          Доклад принят в программу конференции


          из Доклады

            При разработке B2B решений часто возникает вопрос: Что важнее качество или скорость доставки?

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

            - Компетенции тестировщиков

            - Подготовка перед тестами

            - Зачем нужны автотесты ?

            - Мутационное тестирование


            Елена Кирдяйкина
            QA lead @ iiko
            Казань
            Автоматизация тестирования десктопного проекта в Agile команде

            Доклад принят в программу конференции


            из Доклады

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


              Анастасия Чеснокова
              ведущий инженер @ АО СТС
              Иннополис
              Организация процесса тестирования с нуля

              Программный комитет не принял решения по этому докладу


              из Голосование

              - Организация отдела QA

              - Не тестирование, а контроль качества

              - Минусы атомарного подхода в тестировании

              - Основы тест дизайна

              - Грамотный подход к подготовке тестовой модели

              - Элементарная автоматизация BE


              Анна Чернышева
              Lead Software Test Automation Engineer @ EPAM
              Москва
              How to heal your test automation

              Программный комитет не принял решения по этому докладу


              из Голосование

              Every test automation engineer probably faced with the problem of unstability of automated tests because of "bad" locators or dynamically changing UI. Tests should be frequently updated but this routine work could be automated. There are some well-known solutions for self-healing test automation, like Mabl, testim.io, Applitools but they are not suitable for most kind of projects and has obvious disadvantages. I'm going to tell you about the MVP of a new Self-healing tool that we are developing in Epam and how it can fix your test automation.


              Александр Вазюков
              Scrum Master @ Ак Барс Цифровые Технологии
              Казань
              Никому не нужны тестировщики

              Программный комитет не принял решения по этому докладу


              из Голосование

              Немного Александра и реальных кейсов. Как разные подходы к разработке влияют на качество? Какая роль отведена ценностям? Что с этим делать?


              Андрей Татаренко
              Marketing QA @ Skyeng
              Ставрополь
              Чем QA отличается от тестировщика: не только не пускаем баги, но и влияем на продукт

              Программный комитет не принял решения по этому докладу


              из Голосование

              Я работаю в команде тестирования маркетинга Skyeng - мы отвечаем за все этапы прохождения пользователя до прямой оплаты: лендинги, промо-акции, онбординги и самое главное - личный кабинет нашего студента. Все это - лицо любого продукта. И оно должно выглядеть изящно, а функционировать - безотказно. Поэтому мы научились “примерять новинки на себя”, задаваться вопросами “А купил бы я это?”, “Чего здесь может не хватать?”, активно общаться с бизнесом и договариваться с другими командами. Я расскажу:

              Как научиться смотреть на продукт глазами его потребителя

              Как работать с заказчиком в этой парадигме, решать спорные моменты и создавать дополнительные точки соприкосновения

              Как сплит-тестирование помогает исследовать изменения “лица” вашего продукта

              Как грамотно закрывать межпроектные зоны и обмениваться с другими командами знаниями и опытом во всех направлениях


              Виктор Бодров
              Старший специалист по исследованию производительности @ ООО НКО «Яндекс.Деньги»
              Санкт-Петербург
              Практика стрельбы по проду: от идеи до реализации

              Программный комитет не принял решения по этому докладу


              из Голосование

              Чтобы получать максимально точные результаты мы проводим разнообразные исследования производительности на проде. Для наших экспериментов мы создали специальную инфраструктуру, содержащую в себе выделенные маршруты, тестовые данные и сущности.

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

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


              Юлия Колесник
              Старший консультант по нагрузочному тестированию @ X5 Retail Group
              Москва
              Как нагрузить интеграционную шину и найти предел прочности

              Программный комитет не принял решения по этому докладу


              из Голосование

              Интеграционная шина – важная компонента для крупной компании, так как она обеспечивает бесперебойный обмен данными между всеми звеньями цепи. В докладе мы поделимся опытом проведения нагрузочного тестирования интеграционной шины, которое позволило бесстрашно и безболезненно вывести в промышленную эксплуатацию новое решение. Сложным кейсом для тестировщика была и остается задача по созданию профиля нагрузочного тестирования, который бы соответствовал продуктивной нагрузке. Мы решили эту задачу в рамках замены интеграционной шины WFD, обеспечивающей транспортировку данных между 12 000 магазинов и ERP-системой, на новое решение SAP PI.

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


              Никита Прибылов
              Руководитель отдела тестирования @ Clover Group
              Казань
              Успеть на уходящий поезд или как создать тестирование на работающем проекте.

              Программный комитет не принял решения по этому докладу


              из Голосование

              Я расскажу вам об опыте создания тестирования в компании которая недавно была стартапом.

              1. Как возникает потребность в тестировании у компании.

              2. Как запустить процесс тестирования.

              3. Как донести важность тестирования команде разработки

              4. Регламент и тестовая документация, как сделать чтобы документы работали на вас.


              Максим Крошкин
              QA Team Lead @ X5 Retail Group
              Москва
              Тестирование Comarch или самая большая система лояльности

              Программный комитет не принял решения по этому докладу


              из Голосование

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

              В докладе поделимся опытом тестирования перевода системы лояльности на новую версию платформы.

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

              Объясним, почему основной упор делали на тестировании API, а не GUI.

              Поделимся опытом, полученным в условиях, когда требований к системе изначально «не было», а основная разработка дислоцируется в другой стране.