Химион Дмитрий Викторович

• Пожалуй редкий проект, в наши дни обходится без тестирования. Однако, если задаться вопросом – «Как MS Project, задачи в Jira или Velocity команды освещают или измеряют качество разработанного?». Ответ будет – «Никак»
•  Далее вопрос - "А кто отвечает за качество? И какое оно, это качество?". Ответ - "Команда и тестеры, да и кто его знает... это "качество", оно же всегда - good enough". 

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

• В современной разработке микро-сервисная архитектура - main stream и тестировщикам необходимо обеспечить её быстрым и достаточно полным тестированием. Не вопрос - CDC нам в помощь, но вот какие шишки можно набить в процессе реализации не менее интересный вопрос. Всем этим я постараюсь поделиться в своём докладе
  

Множество framework-ов и Agile методологии реализуют возможность достаточно быстрой разработки, за которой полноценное тестирование не поспевает. В методологиях автоматизации тестирования есть такая штука – Model Based Testing, которая намекает на реализацию полноценного тестирования в условиях Agile. Я проведу её анализ, в котором покажу интересные и коварные стороны MBT и покажу наши разработки в этой области.

Зачем люди играют в компьютерные игры? В основном - это развлечение и социализация. Качество реализации двух этих составляющих в значительной (на мой взгляд) степени определяют успешность игры. Наилучшей иллюстрацией совмещения этих факторов является групповое PvE и PvP.

Мы рассмотрим групповое PvE, как более простую сущность для тестирования в сравнении с PvP. Рассмотрим составляющие PvE и основные термины. Что такое level-design, какую роль он играет в формировании игрового процесса (gameplay). Поделюсь личным опытом тестирования группового PvE, подробностями проверок на примере MMORPG и single player RPG.

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

1 .Рассмотрим термин quality gates (QG - шлюзы качества), откуда у него "растут ноги".

2. Применение к реалиям современной разработки

3. В какой парадигме мы будем использовать шлюзы качества

4. Возможности применения QG в зависимости от уровня зрелости процессов

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

Из проекта в проект, от системы к системе, сменяя инструменты, на которых эффективно производить автоматизацию, из месяца в месяц, сталкиваясь с разными интерпретациями по сути одних и тех же проблем, я часто грешил на свою экспертизу, но начал замечать закономерность между функционалом инструментов и решаемыми проблемами. В итоге пришёл к выводу – инструменты автоматизации глубоко ущербны. На каждом проекте приходится так или иначе дорабатывать и расширять функционал инструментов. Если убрать создаваемые доработки, то автоматизация становится вообще не работоспособна. Я расскажу, из чего состоят инструменты, что нам от инструментов надо и в чём заключается убогость. Подведём итоги и обсудим понимание развития инструментария автоматизации тестирования.