Мы не любим ждать в очереди, хотим сделать заказ онлайн, мы не готовы покупать билет в кассе, пусть все будет в приложении, в электронном виде. И вот тут есть важное «Но»! Мы всё хотим здесь и сейчас, но чтобы это работало без сбоев, как часы. Доставку пиццы осуществили вовремя, место в кинотеатре совпало с полученным в подтверждении. Что во всем этом многообразии приложений и сервисов играет одну из ключевых ролей?

Конечно — это тестовое окружение, без чего невозможен быстрый выпуск качественного продукта! Современные инструменты тестирования ворвались в нашу жизнь как ураган и буквально за несколько лет изменили наши возможности. Мы семимильными шагами освоили виртуализацию и контейнеризацию, попробовали линейку Selenium-а, спорили о преимуществах и недостатках Docker-а.

Зачем все это было нужно и к чему мы пришли?
Какое будущее нас ждет?

Поговорим «за тестирование» с гуру профессии. Пройдёмся от А до Я по инструментарию. Помогут нам в этом Игорь Хрол и Антон Семенченко.

Запасаемся кофе, чаем, другими напитками и начинаем. Беседа будет долгой.

Итак, Игорь Хрол — специалист по автоматизации тестирования в Toptal. Игорь имеет большой опыт работы с большинством популярных инструментов (Selenium, HP QTP, TestComplete, JMeter).

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

Добрый. Я позволю себе не согласиться с самой постановкой вопроса. Классические отделы тестирования, которые принимают определённую сборку продукта на тестирование и выдают список дефектов, уже не отвечают современной скорости ведения бизнеса и разработки ПО. Мы становимся более Agile (слово это уже весьма заезжено), когда внутри проектной команды есть специалист по тестированию, готовый быстро помочь разработке. Конечно, инженеры по тестированию общаются между собой, но как такового отдела со своей управленческой структурой нет. В таком формате работает много передовых компаний (в качестве примера тут очень хорошо написано о Spotify). Тестирование все плотнее интегрируется в процесс разработки.

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

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

— Первые инструменты для тестирования стали появляться в середине 90-х годов. Вы согласны с утверждением, что активное развитие началось именно в этот период, или он стал всего лишь фундаментом к «постройке» высокотехнологичных продуктов сегодняшнего дня?

Первые xUnit-системы появились достаточно давно (Wikipedia говорит про 1989-й год) и пока не было такого большого количества пользовательских интерфейсов, наверное, этого хватало. Потом, в конце девяностых, начале двухтысячных, когда появилось больше пользовательских интерфейсов, начали появляться первые инструменты для UI. Одними из первых в моей практике был WinRunner (появился в 1995) и Watir (есть версии от 2005-го года).

Тогда и сейчас

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

Если говорить применительно к теме тестового окружения, то я бы не сказал, что есть специальные инструменты именно для подготовки тестового окружения. То, что мы делаем — это применяем подходы для развёртывания production окружений: Docker, Puppet, Ansible и другие смежные решения. Они создавались для того, чтобы был воспроизводимый результат. Как эффект мы можем клонировать нашу production среду и тестировать безопасно, в максимально приближенном к реальности варианте.

Раньше это были инструкции на сто листов, а новые окружения для тестирования разворачивались месяцами, сейчас же подходы значительно лучше. Всё стало автоматизированным, всё в коде: запустил скрипт — окружение настроено. Поэтому я бы не стал называть эти штуки инструментами для тестирования, это скорее тема DevOps, администрирования.

— Игорь, расскажите, пожалуйста, о вашем первом «знакомстве» с решениями в этой области. Когда вы, например, познакомились с платформой VMware? Сейчас вы пользуете данные программные продукты?

Если говорить о VMware, то действительно это было достаточно хорошее подспорье, тогда, когда нам нужно тестировать продукты в разных операционных системах. К сегодняшнему дню оно эволюционировало в облака, например, в Amazon или Google Cloud. Если мне нужно тестовое окружение, то я запустил скрипт или написал Slack-боту – и у меня есть работающий сервер.

Попользовался пару часов/дней/недель и приглушил это дело. Для continuous integration у нас в Toptal это всё тоже по максимуму автоматизировано. Пушнул код в github, а оно там где-то само подняло в Google Cloud нужное количество серверов, прогнало тесты и мне отписало в pull request, нет ли регрессионных проблем. Локально иногда приходится поднимать виртуальные машины для тестирования какие-то специфических вещей: например, понять, как xlsx-отчёт будет выглядеть в Microsoft Office в Windows.

— Многие разработчики любят разделять тестовое окружение на чистое (с предустановленной ОС и минимальным ПО) и грязное (максимально приближенное к prod варианту). Как вы считаете, такое разграничение уместно? Вам не кажется, что таких вариантов может быть огромное количество, и их лучше не рассматривать только в этом ключе?

Смотря для каких задач. Если запускаете юнит-тесты, то необходим минимальный набор ПО: что-то, чтобы запустить ваш код (JVM, интерпретатор...) и всё. Если тестируете отдельный микросервис или компоненту системы, то, возможно, вам много чего не надо запускать, а иметь работающим только то, что интересует. Практика показывает, что иметь некий staging или preproduction (кто как называет), максимально приближенный к боевому окружению, очень полезно для финальных проверок, приёмочных тестов. Максимальная приближенность будет заключаться во всём: таком же железе, в минорных версиях и патчах на ПО, полноценном наборе данных и т д.

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

Когда я начинал работать, тестовое окружение создавалось по каким-нибудь инструкциям. Или вообще неведомым образом некими админами. По мере взросления тестировщики уже начали проверять эти инструкции, тестировать процесс развертывания. Постепенно всё шло к большей автоматизации и, как следствие, воспроизводимости результата, уменьшению человеческого фактора. Сейчас настройка окружения редко производится руками — скорее всего, это будет ansible, puppet ну или что-то аналогичное. В итоге тестовое окружение максимально приближено к production, и мы не тестируем то, чего не будет на prod’e.

— Вы использовали / используете контейнерные технологии в повседневной работе? Вы смотрели решение rancherOS или Atomic от Red Hat?

Тема docker/контейнеров и надстроек над ними сейчас бурно развивается. Влияет ли это на тестовое окружение? Конечно, влияет. Получить работающую систему для тестов уже можно в пару кликов, что радует. У нас в Toptal контейнеры используются в основном для тестирования:

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

— После всех действий с созданием идентичных конфигов и приложений встает вопрос о переносе данных. В каком случае целесообразна поддержка тестовой среды в виде зеркальной версии prod-а? Немаловажный момент — это обезличивание базы с данными. Как вы относитесь к этой практике при передаче в тестирование?

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

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

Selenium

— Сейчас происходит активное внедрение и использование Selenium-а (линейки продуктов) в тест среде. Вы видели, как видоизменяется данный проект, обрастая новым функционалом? Что вы скажете о Selenium WebDriver в его нынешнем состоянии?

За развитием Selenium’a я активно слежу и использую его начиная с версий 0.8. Пересказывать всю историю тут не вижу смысла, так как на сайте selenium2.ru очень хорошо написано про это.

Говоря про текущее состояние проекта, самым знаковым можно назвать то, что проект стал w3c-стандартом для браузеров, и основные производители браузеров сами реализуют драйверы.

Экосистема вокруг WebDriver’a тоже не стоит на месте. Возможно, она развивается даже быстрее, чем WebDriver API. Если раньше любой проект по автоматизации тестирования начинался с написания собсвенного фреймворка, то сейчас использование самописных решений считается дурным тоном. Практически в любом языке уже есть готовые библиотеки, позволяющие не писать очередной раз то, как правильно проверять наличие элементов на странице или работать с AJAX. На Java: HtmlElements, Selenide. В Ruby-мире: Capybara и page-object. Webium в Python.

Из хороших ресурсов, посвящённых Selenium’у, могу посоветовать записи конференции SeleniumCamp. Я там регулярно участвую и мне нравится то, как тематика развивается каждый год.

— Как вы считаете, какие именно инструменты для создания тестовых сред удалось сделать отлично, на пятерку, за последние несколько лет? Какие сервисы однозначно стоит попробовать уже сейчас? Может, существуют развивающиеся проекты, на которые стоит обратить внимание уже сейчас?

Тема создания тестовых сред тесно перекликается с DevOps, и как таковых отдельных инструментов для тестировщиков как-то не приходит в голову. Я считаю замечательным достижением то, что сейчас реже встречается фраза «А у меня работает», так как окружения становятся всё более и более одинаковыми. Ключевые слова в этом отношении — это ansible, puppet, docker, vagrant. Скрипты для развертывания стали неотъемлемой частью проектов и поставки.

Нельзя не упомянуть cloud-решения (AWS, Google Cloud, DigitalOcean). Раньше все покупали себе сервера и поднималась куча возмущения при попытке что-то отдать третьим лицам. Сейчас немногие компании могут себе позволить собственные датацентры, да и незачем.

Из перспективных направлений могу отметить cloud-решения, где у вас вообще нету серверов как таковых, которые нужно перегружать, устанавливать обновления и всячески тратить время, вместо полезной деятельности. Push’нули код – и этот код в тестовой среде или на prod’e. Это Heroku, Google App Engine.

— Спасибо за ответы. Будем ждать ваших следующих выступлений.

Антон Семенченко — активист сообщества автоматизаторов www.COMAQA.BY и «суровой» разработки C++ и www.CoreHard.by. Основная специализация: автоматизированное тестирование, низкоуровневая разработка на C++ и ниже.

— Антон, добрый вечер. Тема нашей беседы – «Эволюция тестового окружения». Предлагаю немного затронуть историю вашего становления в качестве специалиста, а в развитии поговорим о тестировании.

Добрый! ОК.

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

Все получилось случайно, но это, безусловно, мой выбор. Я, как и любой другой IT-специалист широкого профиля, был косвенно связан с тестированием. Обеспечение качества конечного продукта – сложный комплексный процесс, поэтому и стандарты кодирования, и код-review, и unit-тесты, и парное программирование, и формальные обсуждения ключевых участков кода, и работа с ERD, PRD – это все равно элементы Quality Assurance (далее QA), в которых участвуют разработчики. Поэтому мне был ясен общий цикл QA, я, безусловно, принимал участие в обеспечении качества.

Были проекты, целиком и полностью связанные с QA, например, Unit-тестированием, так, от Symantec был запрос на покрытие Unit-тестами ядра своих флагманских продуктов, разработанных на чистом C в начале 80-х годов. С одной стороны – это сложная техническая задача по разработке, с другой стороны – стопроцентный QA. Мы занимались исключительно Unit-тестами того, что в принципе не было предназначено для тестирования. Порой попадались функции с цикломатической сложностью в 250 и более. Все, приехали, месяц можно разбираться лишь с одной функцией, чтобы понять, как именно покрыть ее тестами. Так что я, конечно, был связан с QA, но специфически, косвенно.

Автоматизированное тестирование

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

Мне поступило предложение организовать подобный отдел с нуля. Эта роль требовала разных навыков и в разработке ПО, и в умении работать с людьми, ведь требовалось собрать замечательную команду, иначе «горы не сдвинуть». Выбор пал на меня не только и не столько в силу исключительно технической составляющей, а по совокупности факторов. «Назначение» показалось мне интересным, как я тогда полагал и, видимо, не ошибся – автоматизация тестирования это безусловный тренд.

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

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

Представители других компаний очень глубоко знали одно или два направления, но вот двадцать, столь широкого охвата не было. Плюс мы увидели проблему информационного вакуума, по крайней мере, четыре года назад единицы специалистов знали, что такое автоматизация сегодня, и были готовы делиться своими «сакраментальными» знаниями. Мы начали сами выступать с докладами, «шарить» информацию, так пришла идея организовать сообщество www.COMAQA.BY, цель которого — строительство эффективной площадки для общения специалистов, прямо или косвенно связанных с автоматизацией тестирования.

Было понятно, что область настолько динамично развивается, настолько широкая и многогранная, что силами одной компании ее гарантированно невозможно охватить, для этого требуется работа очень разных специалистов, из разных компаний, лучше из разных стран. Сейчас мы активно двигаемся по СНГ, стараемся сотрудничать, только осенью я буду участвовать в 25 событиях по всем уголкам России и Беларуси. Примерно так я пришел в эту интересную сферу. Не могу сказать, что это был исключительной мой выбор. Если бы мне не поступило подобное предложение, если бы не удалось собрать замечательную команду, этого бы не случилось. Во многом это заслуга ребят, что я сейчас в автоматизации.

— Можно ли говорить о том, что подготовка корректного тестового окружения и сам процесс тестирования постепенно становятся стандартом во время подготовки и выпуска продукта?

Мне кажется, это очень сложный, неоднозначный вопрос, его стоит разбить на несколько, на целую группу вопросов. Я сейчас озвучу свое субъективное мнение, возможно, многие специалисты с ним не согласятся, тем интересней увидеть горячую полемику. На мой взгляд, ничего концептуально нового в подходах к организации некоего процесса привнести практически невозможно, неважно, говорим мы об управлении феодальным замком или о процессе разработки ПО. В широком смысле слова, Сократ в формулировке Платона был первым объектно-ориентированным программистом. У него были архетипы, категории (иерархии), неидеальные реализации архетипов в нашем мире и т.п. Если эту идею развить и применить к IT, то вот вам ООП с классами, мета-классами, объектами и прочей технической атрибутикой.

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

В это трудно поверить, но разработка hardware и software, описанная Фредериком Бруксом в его «канонической» книге «Мифический человеко-месяц», является вторым по стоимости научным проектом в истории человечества, первый – американская космическая программа. Это сегодня мы можем неверно организовать env и пропустить дефект, в прошлом специалисты, помимо стандартных «минусов», в придачу получали ситуацию, когда здесь и сейчас были впустую потрачены десятки или сотни тысяч долларов, ведь «машинное время» стоило «космически» дорого.

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

Сам же «скачок» на новый виток Гегелевской кривой продиктован необходимостью в силу закона «Иерархических компенсаций» Седова. Развивая «прикладную» мысль, множество разных операционных систем и их версий, браузеров и прочей «обвязки», ориентированной на пользователя, а также тех. составляющая, вроде версии JVM или .Net Framework-а, «средств» в широком смысле слова, физическое и виртуальное окружение, очень разное железо – вот реалии сегодняшнего дня.

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

С одной стороны, я не могу говорить о «принципиальных» изменениях, с другой – не могу отрицать «качественного» роста, поскольку количество разных environment-ов растет по экспоненте и всегда существовала проблема скрещивания, интеграции. Одно дело, когда у нас n вариантов окружения, и совсем другое — e в степени n, и мы начинаем их «соединять». Данная проблема комбинаторики и динамичного окружения в целом стоит сейчас оооочеень остро.

Я не могу дать однозначного ответа на столь сложный изначально сформулированный вопрос, разве что следующий, теоретически-многозначительный, похожий на отговорку: «Тестовое окружение сегодня – следующий виток диалектической Гегелевской спирали, причем диаметр спирали постепенно сокращается, а «шаг» — растет, осознав тренд, можно увидеть «перелом» следующего витка, используя наработки прошлого в новом контексте своевременно подготовиться к нему, главное – не выйти на «диалектическую вертикаль», или, пользуясь синергетической терминологией, не выйти на «вертикаль Паннова-Снукса» в области окружений – мы или построим «Скайнет», или взойдем на вершину, раз и навсегда справимся с комбинаторной сложностью путем введения огромного количества слоев абстракций, забудем, как работает «голое» железо, что такое системное администрирование «руками», но «все дороги с вершины ведут вниз», оба сценария утопично — пессимистичные».

Виртуализация

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

Нельзя сказать, что виртуализация – это нечто новое (новизна, «устаревшая» на пятьдесят лет), с другой стороны, в сегодняшнем виде, когда существует множество разных virtualization engine и всех их нужно «соединить» с друг дружкой, «вызов» принципиально иной. Появился даже отдельный класс приложений, единственная задача которых – единообразно эффективным образом «сдружить» разные virtualization engine, построить единый API по управлению, неважно, это low level CLI или общий UI, далее может идти некая надстройка.

Приведу несколько косвенных личных примеров. Я много лет трудился над разработкой data protection решений – бесконечные вариации резервного копирования и восстановления данных. Одна из очень востребованных задач в недавнем прошлом, сегодня и, уверен, завтра — «хитрый» bare metal restore[2].

Абстрактная ситуация «из головы»: физическая машина на 32 bit-ном Intel-овcком железе с ОС Windows 2000; путем back-up и bare metal restore переносится в десятки минут, в идеале, по одному клику, на 64 bit-ное AMD-шное железо с Windows Server 2008… а если в эту «наваристую кашу» добавить щепотку разных virtualization engine … а если попытаться решить задачу «по-горячему», без выключения машины с точки зрения потребителя «сервиса»? Подобные нетривиальные трансформации очень востребованы.

3 года назад существовал настоящий IT-клондайк, многие крупные компании пытались «втиснуться» в этот золотоносный рынок, подмножества bare metal restore решений, в том числе («юношеский максимализм» виден невооруженным глазом) мой стартап DPI.Solutions. Как только официально Windows XP перестали поддерживать, банки судорожно начали искать безопасный, быстрый и осуществимый способ массового перехода на новую ОС, так как по своим внутренним policy не имели права оставаться на «операционке» без актуальных security pack-ов.

В силу инерционности любой крупной организации и огромных трат на обновления ОС, банки до последнего дня надеялись на продолжение поддержки Windows XP со стороны Microsoft и переход не инициировали. В итоге сложилась «фатальная» для банка ситуация: в течение двух месяцев или полугода перевести сотни тысяч машин, каждого сотрудника, в каждом крохотном отделении на следующую версию ОС. Всё, можно стреляться.

Специализированный bare metal restore решал подобную задачу в указанные «жуткие» ограничения. Сделал backup машины с Windows XP и развернул полностью готовую к работе, со всей «исторической» информацией и настройками, уже на новом или прежнем железе со свежей виндой, где выходят security pack обновления. Многие компании специализировались именно в этой области. Это пусть косвенная, но яркая ситуация, иллюстрирующая сегодняшние сложности «окружений».

Юношеские проблемы

Мне кажется, формальная подготовка тестового окружения пришла к нам лишь сегодня, во многом потому, что IT в СНГ — «юная» профессиональная область, на памяти наших преподавателей / учителей произошел разрыв поколений.

Сперва, Советское IT, очень мощное, яркое, со своими плюсами и минусами, мне, мягко говоря, трудно судить об этом времени, это истории «с чужого плеча». Затем IT у нас не было вовсе, ну или почти не было. Бурное развитие пошло в двухтысячных: повсеместно создавались первые компании, но они не были большими, IT не был мейнстримом, зарплаты, а значит и поток талантливых кадров, были относительно невысокими, сопоставимыми с другими инженерными областями.

Только с 2005 года пошел активный рост, отрасль развивается лет десять, ну пусть пятнадцать; будем откровенны, мы ещё подростки, с классическими «подростковыми» проблемами незнания и переоценивания, открытия заново того, что было давно известно нашим отцам. Чего далеко ходить, давайте посмотрим на наших коллег, возьмем страны с физически меньшим объемом IT. Например, понятие «бизнес-аналитик» в Молдавии появилось считанные годы назад. Понятно, что эта функция была всегда, но само понятие о роли появилось лишь несколько лет назад — яркая иллюстрация «молодости профессии», ведь мы в СНГ в «одном соку варимся».

Взять другой пример, поделились «наболевшим» коллеги из Узбекистана. У них весь рынок IT специалистов — от тысячи до двух тысяч человек, нет критической массы, необходимой для качественного скачка. Тренинговых центров считанные единицы, можно пересчитать по пальцам одной руки на всю столицу; почти все IT-шники – специалисты широкого профиля, знают и умеют все, но по верхам.

Мы страдаем болезнями, незрелостями, мировое IT развивается очень быстро, наш IT-рынок очень активно растет, а значит, сложности, в том числе сложности «неуспевания», возводятся в степень.

Если говорить о DevOps-специалистах, как давно появился этот термин в России? В Беларуси активно используется лишь последние три года, не более. Мы своими глазами видим «взросление» и одновременно развитие IT-отрасли на примере Минска. Так, четыре года назад проходила одна крупная специализированная IT-конференция в квартал, не более, часть направлений не были охвачены в принципе.

Сейчас каждый день есть, как минимум, небольшая встреча, meet-up, посвященный одной из IT-специализаций, можно ежедневно заниматься очным IT-образованием самого широкого профиля, было бы желание.

Количество и качество событий растет принципиально. Взять, к примеру, QA. Три года назад в Беларуси не было ни одного активного сообщества, посвящённого автоматизации тестирования, и лишь одно, посвященное Quality Assurance в целом, организующее 1-2 небольших технических события в год, с 3-4 отличными докладами на базе SQA Days и 20-40 слушателями. Ребята регулярно встречались в неформальной обстановке, создавали условия для личного общения, играли в Мафию и другие игры. Они делали очень важное и полезное дело, но это начинание, при всем моем глубоком уважении к участникам, нельзя назвать профессиональным сообществом, а «уютные посиделки» — конференциями или даже meet-up-ами.

Ребята были первопроходцами, за что огромное им спасибо. Сегодня только сообщество COMAQA.by проводит 4 полномасштабные бесплатные или условно платные конференции в год, посвященные QA Automation, а есть еще регулярные чтения в Университетах и школах, сотрудничество с множеством провайдеров IT-курсов, meet-up-ы и вебинары. Ближайшее событие пройдет 5-6 ноября: 2 дня, 2 потока, 8 мастер-классов, 16 докладов, более 500 очных слушателей, онлайн-трансляция по СНГ. Один из мастер-классов будет посвящен Docker-у. Всю необходимую информацию для участия в роли слушателя или докладчика можно найти на сайте сообщества. Будем очень рады поделиться своими знаниями и наработками.

Другой яркий пример. Около года назад мной совместно с коллегами было создано сообщество CoreHard, собравшее специалистов по «суровой» разработке, прежде всего на С++ и ниже. Сегодня мы проводим по 4 конференции в год. Ближайшее событие 22 октября: 11 докладчиков из СНГ и США, более 350 очных слушателей, онлайн-трансляция по СНГ. Событие CoreHard соберет замечательных speak-еров: это и Антон Полухин – активный разработчик Boost, автор книги «Boost C++ Application Development Cookbook», представитель в международном комитете по стандартизации С++ от России; и Егор Кишилов — более 8 лет работает в Microsoft, все это время занимаясь разработкой поисковой системы Bing; и Святослав Размыслов — руководитель отдела, занимающегося разработкой ядра анализатора PVS-Studio для анализа C и C++ кода; и Евгений Охотников – независимый разработчик с более чем 20-летним стажем, занимающийся OpenSource-инструментарием для упрощения разработки многопоточных приложений на языке C++; и многие-многие другие замечательные специалисты. Большущее спасибо коллегам, готовым поделиться своими знаниями.

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

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

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

Буду краток. Мне кажется, тест-план безусловно нужен, а тестовое окружение – обязательная часть, вне зависимости от размера ПО и выбранной методологии, неформальной документации или строгого следования стандартам.

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

Можно соглашаться с указанной терминологией или же горячо дискутировать (я, скорее, «не соглашатель»), но единая непротиворечивая база очень важна. Главное, в ISTQB уделяется пристальное внимание и тест-плану, и его составным частям, в том числе тестовому окружению, поэтому учебник для прохождения сертификации стоит использовать для приобретения актуальных знаний.

Про Минск могу сказать следующее, сегодня нет открытых курсов, тренингов по менеджменту в тестировании. От сообщества COMAQA.by мы хотим запустить восьмичасовой мастер-класс по метрикам тестирования как составной части менеджмента, посвященный, прежде всего, практике и в меньшей степени теории их использования. На правах рекламы сообщу, что заканчиваю работу над «авторским» курсом по «Менеджменту в тестировании», который в совершенно разных вариациях будет запущен удаленно в Software-Testing.ru и очно в Минске, совместно с тренинг-центром «Искра».

Некоторые части курса были прочитаны в рамках корпоративных тренингов на английском языке, впервые на русском я озвучу часть курса в виде 6-часового мастер-класса на конференции SECR в Москве. Надеюсь, информирование позволит окончательно убедить наших замечательных QA-специалистов в необходимости «сознательной» плановой работы над тестовым окружением.

— На какие этапы вы можете разделить создание тестового окружения? Что вы однозначно закладываете при выборе способов и инструментов для тестирования? Сколько времени занимает процесс настройки сейчас и сколько занимал в недавнем прошлом?

Замечательные вопросы. Так и хочется ответить по КВН-овски: «Все как всегда зависит от всего!» :) Чтобы раскрыть эти темы, требуется, как минимум, несколько докладов, а лучше — мастер класс. Не хочу давать простой некорректный ответ на сложный и важный вопрос. Давайте подробно проговорим их в рамках отдельного поста, часть ответов можно найти в рамках моих выступлений.

Сегодня скажу лишь следующее: ROI, всегда и во всем нужно руководствоваться ROI, разрабатывать свой микро Calculator под специфику конкретного проекта / задачи и использовать его совместно с stakeholder-ом. Если даже в области права и моральных компенсаций, человечество не смогло выработать лучшего универсального мерила, чем деньги, нам точно не стоит пытаться выдумать нечто свое. Любое решение должно быть взвешенным, материально просчитанным, в том числе выбор подхода к организации тестового окружения, выбор способов и инструментов тестирования.

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

— Подготовка конфигов и тестовых данных — основа, или каждый отдельный случай — это «чистый лист», который приходится переписывать с нуля?

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

Безусловно, должен быть набор готовых, специфичных для компании или бизнес-домена в рамках компании эталонных виртуальных машин, «шаблонов» тестовых данных, неких специализированных решений, архитектур для автоматизации тестирования из серии, если у нас Java stack, Web, Angular, приложение среднего размера и с большой вариабельностью данных, то начинать стоит, исходя из решения 25.

В этом смысле очень показательна конференция ExTENT 2015. Именно такой подход я вместе с коллегами пытался реализовать на прошлом месте работы, организовал сегодня в DPI.Solutions и принимаю посильное участие в систематизации в рамках EPAM. Крупные компании, на мой субъективный взгляд, переросли ситуацию недостатка наработок и готовых решений, скорее, мы видим инверсию, проблема не недостатка, а избытка «экспертизы с полки», когда требуется улучшить мета-описание и систему ранжирования, иначе в море готовых возможностей можно утонуть.

— За эти несколько лет активно развивался пласт готовых из коробки решений для построения изолированных сред тестирования. Насколько они хороши? Можно ли среди них выделить самые интересные, удобные решения? Как раньше справлялись без этого?

К сожалению, я не смогу детально ответить на этот вопрос, лично не занимался сравнительным анализом подобных инструментов. Как справлялись раньше?.. Это классический эволюционный вопрос. А как наши родители справлялись без стиральных машин, микроволновых печей? Я не говорю о мобильных телефонах, компьютерах, интернете. Справлялись! Но к хорошему привыкаешь оооочень быстро.

— Вы используете технологию Docker? В сравнении, например, с OpenVZ — был сделан шаг в сторону упрощения использования? Расскажите о вашем опыте. До «Докера» были удобные решения подобного уровня или они есть и сейчас? С какими ограничениями Докера вы сталкиваетесь и как их решаете?

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

Удобный UI, очень простой лаконичный набор команд для решения большинства задач, мета-описание «машины» в одном файле, иерархичность, оптимизация по трафику при скачивании и дискового пространства при хранении. Море плюсов. Минусы, конечно, тоже есть, не бывает лекарств без побочных эффектов. Не все так радужно при попытках серьезного масштабирования, проблемы обратной совместимости API, в силу быстрого роста, а также множество низкоуровневых специфических проблемок, для решения каждой из которых есть некоторые рекомендации, но я недостаточно компетентен, чтобы формулировать обширный список best practices.

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

На мой взгляд, аппаратная архитектура и проблемы отличия тестового и реального окружения постепенно уходят на второй план. Сегодня как production, так и test-овый env все чаще находится в облаках, а значит, благодаря дополнительным прослойкам виртуализации и сервисов проблема нивелируется.

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

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

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

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

Идеи 60-х в совершенно новом качестве реализуются здесь и сейчас. Даже не знаю, как охарактеризовать подобный процесс, скажем «Эволюционная революция». Виртуализация, контейнеризация, выход в «облака», появление одновременно минималистичных и универсальных средств автоматизации, вроде Selenium-а и, благодаря изначальной гибкости архитектурных решений, распространение на «смежные» области, такие как мобильная автоматизация и автоматизация Desktop-ных приложений.

– Спасибо за ваши ответы.

Приобрести билеты на конференцию можно уже сейчас, регистрация открыта.

Кроме докладов Игоря («Автотесты: Такие же, но лучше») и Антона («Хорошие» и «плохие» варианты параллельного запуска Selenium WebDriver тестов) советуем вам обратить внимание и на эти:

No Such Thing as Manual Testing and Other Confusions
Appium: Automation for Apps
Как научить роботов играть в игры?
Hero’s Journey to Perfect System Tests — Eight Assessment Criteria for Tests’ Architecture Design
Page Objects — лучше меньше, да лучше
Тестирование распределенных систем
Тестирование Android–приложения Juno с ️: CI, Unit, Integration и Functional (UI) тесты. 100% Kotlin, 90%+ RxJava, Spek, JUnit, DSL для UI тестов
Combining manual and automated testing: process and tools
Список покупок: что нужно не забыть при запуске JMeter-тестов
Статический вынос мозга: что скрывают анализаторы кода?

Эволюция тестового окружения: Интервью с Игорем Хролом (Toptal) и Антоном Семенченко (COMAQA.BY и CoreHard)