Профессия: тестировщик

Как у них и что делать нам…

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

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

• план тестирования —документ, содержащий краткие сведения о самой системе, силы и средства, которыми предполагается ее тестировать, что именно предполагается тестировать (вплоть до списков или даже описаний тестов), примерные планы по срокам, критерии окончания тестирования и признания релиза успешным, риски и прочие сведения, могущие оказать влияние на процесс тестирования. В литературе и в Интернете есть масса заготовок тест-планов, из которых можно составить для себя нужный шаблон. Есть два подхода к написанию тест-плана — статический и динамический. Статический — когда тест план пишется один раз при разработке стратегии тестирования и содержит только неизменяемые сведения. И динамический — когда в тест-плане содержатся еще и описания тестов, которые по ходу разработки ПО корректируются и дополняются. Честно говоря, я не понимаю, зачем так делать, если все изменения можно вносить в связанные с тест-планом документы, что позволяет лучшую структуризацию и отслеживание версионности, но — дело вкуса. Я пользуюсь первым подходом.
• контрольный пример — документ с описанием конкретного теста. Его детализация не должна быть чрезмерной – в конце концов, в предполагаемых в статье условиях работы у вас не будет на это ни сил, ни времени. Основное требование к контрольному примеру — описание проверки и ожидаемых результатов четко определенной самостоятельной части функциональности (или свойств) программного обеспечения, которое должно быть однозначно понятно и вам и вашим подчиненным, если таковые имеются. Вся прелесть таких контрольных примеров в том, что их можно потом структурировать, как душе угодно, превращая в наборы таблиц контроля (при автоматизации тестирования это будут наборы);
• таблица контроля (Check-list, он же Suite — набор) — собственно, в предыдущем пункте я про них написал. Это табличный документ, объединяющий в себе (через гиперссылки) набор контрольных примеров с отметками о результате их исполнения и примечаниями.
• отчет о тестировании — результирующий документ, содержащий в себе ссылки на таблицы контроля и выводы о работоспособности релиза с подписями тестера и руководителя проекта.

Из всего моря типов документов, предлагаемых, например, в RUP, можно для начала оставить только четыре

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

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

• файл с тест-планом;
• файл с шаблоном отчета о тестировании;
• каталог TestCase с набором контрольных примеров по данному проекту;
• каталог Builds, в котором в отдельных папках хранятся отработанные контрольные примеры по данной сборке (практически, копия папки TestCase, документы из которой используются в качестве шаблонов) и отчет о тестировании.

Для начала (да и на потом) подобной структуры вполне хватит для контроля процесса тестирования. Желательно в папку каждой сборки вкладывать файл со списком требований на данную итерацию.

Почему есть проекты второго типа?

ScrumTrekДарт Автотестиусне только не помогает, но вредит проектуследующих основных правил

• Быть достоверными
• Не зависеть от окружения, на котором они выполняются
• Легко поддерживаться
• Легко читаться и быть простыми для понимания (даже новый разработчик должен понять что именно тестируется)
• Соблюдать единую конвенцию именования
• Запускаться регулярно в автоматическом режиме

Что тестировать, а что – нет?

1. Простой код без зависимостей. Скорее всего здесь и так все ясно. Его можно не тестировать.
2. Сложный код с большим количеством зависимостей. Хм, если у вас есть такой код, тут пахнет God Object’ом и сильной связностью. Скорее всего, неплохо будет провести рефакторинг. Мы не станем покрывать этот код юнит-тестами, потому что перепишем его, а значит, у нас изменятся сигнатуры методов и появятся новые классы. Так зачем писать тесты, которые придется выбросить? Хочу оговориться, что для проведения такого рода рефакторинга нам все же нужно тестирование, но лучше воспользоваться более высокоуровневыми приемочными тестами. Мы рассмотрим этот случай отдельно.

1. Cложный код без зависимостей. Это некие алгоритмы или бизнес-логика. Отлично, это важные части системы, тестируем их.
2. Не очень сложный код с зависимостями. Этот код связывает между собой разные компоненты. Тесты важны, чтобы уточнить, как именно должно происходить взаимодействие. Причина потери Mars Climate Orbiter 23 сентября 1999 года заключалась в программно-человеческой ошибке: одно подразделение проекта считало «в дюймах», а другое – «в метрах», и прояснили это уже после потери аппарата. Результат мог быть другим, если бы команды протестировали «швы» приложения.

Что почитать?

Тестирование, да и ИТ в целом, — бурно развивающаяся отрасль, поэтому часто можно встретить скептическое отношение к книгам. Слишком уж у них велик “цикл производства”. Писать, издавать, распространять — долго. Он растягивается более чем вдвое, если мы говорим о переводной литературе.
Однако одну книгу наш отдел тестирования рекомендовал почти единогласно — “Тестирование Дот Ком” Романа Савина. Это самая известная книга по теме, которая просто и доступно вводит в курс основных понятий и процессов в ручном тестировании. И хотя она издана довольно давно, базовые знания, изложенные в ней, до сих пор актуальны. Пожалуй, ее читали процентов 80 всех тестировщиков в странах СНГ.
Другие рекомендации легко найти в распространенных в интернете “списках N книг для начинающего тестировщика”. Но в целом наша команда тестирования считает, что базы из книги Романа Савина будет достаточно для запуска дальнейшего процесса самообразования.

Основные задачи тестирования

Еще несколько терминов, которые связаны с упомянутыми двумя задачами, которыми занимается тестировщик, это стимулы, реакции и оракул.

• Стимулы – это данные, которые подаются на вход программе.
• Реакции — это то, что получается на выходе.
• Оракул — это способ проверки наблюдаемого результата, совпадает он с некоторыми ожиданиями или не совпадает.

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

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• графический,
• текстовый,
• консольный,
• и речевой.

Через пользовательский интерфейс компьютер взаимодействует с человеком, с пользователем.

Через программный интерфейс программы взаимодействуют друг с другом (человек тут не нужен).

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

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

Это состояние окружения, которое могут программы модифицировать и, соответственно, тоже читать.

Это события, в частности, таймер. То есть некоторые механизмы отслеживания времени.

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

Стресс тестирование

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

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

Карьера тестировщика: варианты развития

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

Вертикальное развитие

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

В каждом сегменте тестирования существуют свои грейды, которые определяют уровень специалиста: junior, middle и senior. Руководителем всех специалистов является test-lead или team-lead в зависимости от специфики компании. На некоторых проектах может быть также отдельный инженер по качеству, head of QA.

Из начинающего специалиста тестировщик может дорасти до любого из уровней, главное — постоянно держать себя в тонусе. Азы профессии освоить не трудно, а вот развиваться дальше и на каждом этапе приобретать новые знания уже гораздо сложнее. Конечно, всё зависит от человека, но, например, от junior до middle возможно дорасти в среднем за год.

Горизонтальное развитие

Второй вариант — развиваться как специалист и прокачивать hard skills, а в дальнейшим благодаря ним можно будет выбрать наиболее интересное направление. Тестировщик может стать автотестером или специалистом по тестированию юзабилити, безопасности, производительности. При этом есть профессионалы, которые могут совмещать оба варианта.

Чтобы выбрать более узкое направление, нужны приличные знания программирования и другой технический бэкграунд. В небольших компаниях бывает так, что за все описанные выше направления ответственен один специалист. Ему поручают и нагрузочное тестирование провести, и автотесты написать, своеобразный человек-оркестр — этот подход распространён, хотя и не совсем верен.

Спрос на автоматизированное тестирование

Автотестирование, если говорить о навыках специалиста, требует большей квалификации, а следовательно и оплачивается выше, чем ручное тестирование. Многие компании пришли к выводу, что автотесты для рутинных процессов, например прохождения регрессий, во многом выгоднее, чем ручное тестирование. Они стараются нанимать сотрудников, которые пишут автотесты на те процессы, которые ранее проверялись ручными тестировщиками (а то и вообще не проверялись).

Ручное и автоматизированное тестирование: рассматриваем преимущества и недостатки подходов

tproger.ru

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

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

Переход в смежные сферы

Третий путь развития тестировщика — переквалификация в смежную специальность. Принято считать, что тестирование — это своего рода простая точка входа в IT и из него гораздо легче переходить в другие технические направления. Поэтому иногда специалисты по тестированию решают попробовать себя в других IT-профессиях. Так, например, тестировщик может стать продакт-менеджером, бизнес-аналитиком, разработчиком и даже дизайнером. На самом деле это не так просто, как кажется, — понадобятся дополнительные знания, желание развиваться, время на обучение и поиск работы.

Как тестировщику стать разработчиком — отвечают эксперты

tproger.ru

Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать

Перевод

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?

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

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

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

Если вы создаете автотесты вслепую или по своей прихоти, это увеличивает вероятность того, что вы не получите от них столько пользы, сколько следовало бы.

Жизненный цикл продукта и тестирование

Все чаще в наше время используются итеративные процессы разработки ПО, в частности, технология RUP — Rational Unified Process (Рис. 1). При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов. В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл.

Рис. 1. Жизненный цикл продукта по RUP

Тестирование обычно проводится циклами, каждый из которых имеет конкретный список задач и целей. Цикл тестирования может совпадать с итерацией или соответствовать ее определенной части. Как правило, цикл тестирования проводится для конкретной сборки системы.

Жизненный цикл программного продукта состоит из серии относительно коротких итераций (Рис. 2). Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.

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

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

В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Рис. 2. Итерации жизненного цикла программного продукта

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

Базовые требования к профессионалу

• Опыт технической поддержки — это плотное изучение технологий в сжатые сроки, умение понимать проблемы и быстро сопоставлять их с причинами и путями решения + навыки документирования заявок. Отличная почва для старта карьеры тестировщика.
• Основы программирования — желательно Java, SQL, Python, но сойдёт буквально всё.
• Знание методологии Agile, умение встроиться в микро-команды. 
• Основы Linux.
• Основы архитектуры ПК.
• Модель OSI и сети (базовое понимание, знание структуры заголовков пакетов и проч.). Практически сразу потребуется свободная работа с утилитой Wireshark.
• Инструменты управления тестированием — Bugzilla, Jira или любой другой багтрекер.
• Selenium — инструмент для автоматизации действий веб-браузера. Очень популярный инструмент тестирования. 
• Желательно — понимание стратегий тестирований чёрного, белого, серого ящиков и осознание того, где вы наиболее хорошо применимы как специалист.

1. Станьте QA-фрилансером, чтобы выполнять небольшие проекты по ручному тестированию. Платят мало, но вы научитесь мыслить как тестировщик, писать контрольные примеры и сообщать о результатах. 
2. Если цель — тестирование веба (а это чаще всего), создайте свой кривой-косой, но полноценный сайт без шаблонов и готовых CMS. Так вы поймёте, как среда работает изнутри и будете знать места обитания всех типичных багов.
3. Найдите программу любого курса по тестированию, ищите по ней материалы и накапливайте теоретическую базу, чтобы успешно пройти первое собеседование.

Приоритеты в тестировании

Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?

Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то …».

Но — всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя. И они уходят…

Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».

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

Технология составления теста

На первый взгляд может показаться, что разработать тест достаточно просто — придумал вопрос, набросал варианты ответов и готово. На практике же многие испытывают сложности с разработкой. Чтобы быстро составить эффективный тест, мы рекомендуем следующие этапы разработки теста: выбрать правильный ответ, поставить к нему вопрос, подобрать неправильные ответы (или дистракторы). Разберем это подробней.

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

Смысловая единица — это то самое важное, что студент должен вынести из пройденного урока. Главное ключевое данное урока

Тесты мы всегда делаем на смысловые единицы. По-хорошему на каждую смысловую единицу нужно делать минимум по 3 теста.

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

ДистракторыИли раздражители. Так называют неправильные варианты ответов в тесте. Как составить дистракторы? Чтобы придумать неверные варианты ответов, попробуйте сначала сделать простое противопоставление правильному ответу. Затем можно поменять одну деталь формулировки из нескольких и сделать погранично верный ответ. И так далее. На разработку дистракторов можно привлечь самих студентов, оставив ответ незаполненным и попросив их закончить фразу.

Время на тестирование

Время, потраченное на тестирование, почти не изменилось с 2018 года — в среднем это 61% рабочего времени.

Комментарий Алёны Батицкой: «Количество типов тестирования, интерес к этой теме и запрос на качество ПО сильно выросли, но при этом количество времени не изменилось. Это свидетельствует о хайпе, но не о деле или об оптимизации процессов тестирования».

Самым трудоёмким занятием 23% респондентов считают выполнение тестов. Создание автоматизированных тестов на втором месте (18%), следом идёт написание сценариев ручного тестирования (17%). Отчетность / анализ результатов теста остались на прежнем уровне — четвёртое место с 12% опрошенных, но это значительно выше, чем 3%, которые сказали, что именно это было самой трудоёмкой задачей в 2017 году.

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

Выявилась такая корреляция: респонденты, которые проводили за тестированием менее 20% времени, были менее удовлетворены процессом тестирования в отличие от тех, кто провёл за тестированием от 20 до 80%. Это может отражать либо большую осведомлённость о процессах и об их удобстве, либо более низкий уровень интереса и удовлетворённости у тех, кто тестирует реже.

TransMaintain — инструмент для поддержания файлов переводов интерфейса Symfony проектов в консистентном состоянии

Из песочницы

Сколько проектов не проходило через мои руки — всегда одно и то же — файлы переводов в ужасном состоянии. Лучше всего эту проблему выражают слова Агаты Кристи в начале статьи. Здесь не будут разбираться лингвистические нюансы и качество переводов. Предположим у нас имеются отменные переводы. Под катом разбираются те проблемы, которые можно проконтролировать техническими средствами и инструменты предназначенные для этого. Материал рассчитан на людей имеющих опыт работы с Symfony и в целом с консолью Linux. Также предполагается, что вы умеете подключать сторонние бандыл в проект. Поэтому часть вопросов не разбирается с позиции “и так всё понятно”.

Как стать тестировщиком

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

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

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

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

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

Ещё один важный и не совсем очевидный плюс курсов в том, что они дополнительно дисциплинируют и забросить учебу становится сложно: всегда есть четкое расписание занятий, домашние задания, пример других студентов. Это своеобразный волшебный пинок, которого обычно так не хватает при самостоятельном обучении.

Если говорить об обучении уже практикующего специалиста, например, ручного тестировщика, то здесь тоже немало вариантов: от специализированных курсов до самостоятельного изучения языков и инструментов, которые понадобятся в новом направлении. Как пример, если интересно тестирование веб-приложений, можно начать с изучения Selenium или Katalon Studio и Java.

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

Ещё один интересный вариант для тех, кто не знает, что именно ему понадобится, — попробуйте автоматизировать собственные рутинные процессы и разобраться, чего не хватает в знаниях.

Обеспечение качества сейчас — бурно развивающаяся перспективная сфера, особенно в России и СНГ, и это очень радует и вдохновляет постоянно развиваться в этом направлении.