Интервью с QA-архитектором Владимиром Савельевым продолжает серию наших публикаций на актуальные ИТ-темы. Владимир рассказывает об основных головных болях тестировщиков и делится эффективным способом их решения
Кто есть «who»:
Automated QA System – платформа-конструктор для тестирования, которая имеет единую структуру, единую модель и позволяет по этой единой модели автоматизировать тесты. Эта платформа подходит и для простого прогона автотестов на waterfall проектах, и для комплексного контроля качества на agile проектах, а также для проектов, где используется непрерывная интеграционная разработка и другие методики.
Star Crusade — коллекционная карточная игра с большим количеством карт (более 320 шт.) Игра имеет сложную серверную часть и клиентское приложение с большим количеством графических эффектов, анимированной графики и различным функционалом (чаты, система друзей и дуэлей).
Продукт имеет ряд веб-интерфейсов:
— серверные веб-интерфейсы, которые используются командой разработки и поддержки продукта
— сайт игры, который виден конечным пользователям и где можно скачать сборку игры. В настоящее время доступна альфа-сборка.
Какие существуют проблемы в тестировании? Можешь их перечислить?
В.С: Исходя из своего опыта, я могу выделить несколько главных проблем в тестировании.
Проблема 1: баги из-за неструктурированного тестирования.
Если тестировщик выполняет ряд тестов, которые логически непоследовательны и неструктурированы, то такое тестирование может покрывать не весь продукт, поэтому каждый раз он находит все новые и новые баги, для исправления которых разработчикам и тестировщикам приходится много общаться между собой. Избыток таких коммуникаций приводит к потере времени и ухудшению качества продукта.
Проблема 2: недостаток инструментов для эффективного анализа багов или неумение пользоваться этими инструментами на 100%. Дело в том, что анализ бага не сводится только к его словесному описанию (о том, например, что не работает какая-то кнопочка или действие в игре производится неверно). Для того, чтобы разработчик мог понять, в чем состоит баг, и исправить его, тестировщик должен собрать определенное количество информации о найденном баге.
Классический пример – это логи (отчеты) тестируемого приложения, в том числе скриншоты экрана, какие-то расширенные таблицы (выборки из баз данных). На комплексных проектах трудно собрать всю информацию воедино, к тому же это занимает слишком много времени. Поэтому необходимо иметь инструменты, которые позволяют быстро и эффективно собирать информацию о найденных дефектах. Вот недостаток таких инструментов и является еще одной головной болью тестировщика и, как результат, головной болью разработчика.
Проблема 3: постоянная рутинная работа. Как всем известно, при реализации ИТ-проектов разработчики практически ежедневно добавляют и оптимизируют функционал, исправляют найденные баги. Поэтому приложение необходимо каждый раз тестировать заново для проверки работоспособности нового функционала и для поиска регрессионных багов. Иначе нельзя будет гарантировать, что тот код, который работал ранее, будет продолжать работать и после внесенных изменений. Тестировщику приходится ежедневно прогонять полный набор тестов, который с каждым разом только увеличивается.
И отдельно я бы хотел вынести в подкласс регрессионные баги. Когда разрабатываемый продукт не тестируется регулярно или тестируется неструктурированно появляется огромное количество регрессионных багов. Со временем подобные баги накапливаются как снежный ком и делают дальнейшую разработку продукта просто невозможной.
Как можно решить все перечисленные проблемы, чтобы упростить процесс разработки и тестирования?
В.С.: В первую очередь необходимо решить проблемы коммуникаций. Все члены команды (как тестирования, так и разработки) должны не только полностью разбираться в том компоненте, за который ответственны, но и видеть разрабатываемый продукт в комплексе, и обладать минимальными знаниями обо всех остальных компонентах продукта. В этом нам помогают наши наработки для контроля качества, в которые входят такие инструменты как:
Эти инструменты были созданы в процессе работы на различных проектах, и они позволяют выстроить качественную графическую древовидную модель тестирования проекта таким же образом, как в Agile разработке. Проект разделяется на Epic’и, которые в свою очередь делятся на User Story и конкретные задачи разработки и тестирования. Модель органично вписывается в структуру разработки на Agile проектах и помогает структурировать и систематизировать тестирование на Waterfall проектах.
С первого взгляда инструменты не представляют из себя ничего особенного. Это просто диаграмма, отражающая модель продукта, и древовидная модель отображения тестов. Я неоднократно слышал отзывы, что это “очевидные вещи”. Однако легко говорить, смотря на готовый результат. Реальность работы на проектах показывает, что эти вещи не так уж очевидны.
На графической модели контроля качества отображается продукт в том виде, в котором его необходимо видеть тестировщикам. Например, на верхнем уровне мне может быть неважно, что код продукта работает на Tomcat и какие именно библиотеки используются для связи с MySQL и LDAP. Мне важно проверить, что продукт способен выполнить пользовательскую операцию: авторизацию (которая включает в себя обращения к базе и обмен данными с клиентами), обмен сообщением (взаимодействие между 2 XMPP клиентами) и прочее. Однако, мне ничто не мешает спуститься уровнем ниже и уточнить модель или разбить ее на несколько слайдов/экранов, показывая дополнительно внутреннюю структуру компонентов.
Эту модель контроля качества можно сделать интерактивным инструментом, собирая в ней не просто информацию об устройстве продукта, но и проектную документацию, информацию по unit-тестам, различные статьи базы знаний и прочее. Ведь решая конкретную задачу тестирования/разработки, специалисту не нужна вся документация по проекту, ему нужна информация по той части продукта, над которой он в данный момент работает.
Таким образом, мы гарантируем, что команда имеет одинаковое представление о продукте и любой член команды может быстро получить нужную ему информацию. Команда не должна тратить время, объясняя каждому новому сотруднику все с нуля, а сотрудник не должен тратить время читая кучу документации, из которой для решения его текущей задачи ему необходимо не более 30%.
Графическая модель контроля качества
Подобным образом дело обстоит и с картой тестового покрытия. Она логически продолжает модель контроля качества и позволяет покрывать продукт тестами в таком формате, в каком ведется разработка функционала. Если какой-то функционал было решено доработать или даже переработать, то обновить тестовое покрытие можно быстро, поскольку оно представлено в виде понятной древовидной модели.
Было много дискуссий о том, сколько это занимает дополнительного времени. Например, на создание карты тестового покрытия, которая приведена здесь, я потратил около 15 минут.
Тестовое покрытие, представленное списком тестов
Тестовое покрытие с использованием древовидной модели (карты тестового покрытия)
Расскажи подробнее о результатах внедрения разработанных инструментов
В.С.: Пример из жизни: я взял тестовое покрытие одного из компонентов, сделанное опытным коллегой-тестировщиком, где было около 70 тестов, и разбил его так, как показано на карте тестового покрытия. Было найдено около 15 пропущенных тестов, при этом на всю работу ушло около 30 минут.
Со временем каждый продукт начинаешь видеть подобной моделью, и любые активности, связанные с тестированием продукта, становятся структурированными и последовательными. Особенно актуально это для новичков. Я помню, как я начинал писать тесты и не мог понять, с какой стороны мне подойти к тестированию, как покрыть продукт тестами, чтобы ничего не упустить. Если бы у меня были тогда такие инструменты, я бы приступил к работе в качестве полноценного сотрудника намного быстрее.
Мы также проводили эксперимент. Предоставляли новичку неструктурированное и частично устаревшее тестовое покрытие и пример с этой картой. Имея под рукой пример, диаграмму тестового покрытия, и задавая какие-то вопросы походу, человек, который не имел никакого опыта в тестировании, смог создать неплохое тестовое покрытие в течение 2 дней. На уровень полноценного инженера по тестированию он вышел в течение месяца, т.е. через месяц он уже полноценно работал с командой, при этом речь шла о тестировании сложных телеком-систем.
Еще одним примером использования связки модели + карты можно считать наш опыт коммуникации с техническим писателем. Принимаясь за написание пользовательской документации по практически готовому продукту он сначала решил разобраться как этот продукт устроен, чтобы документировать его структурированно. Я также предоставил ему модель + карту и дал несколько комментариев. Он моментально разобрался в устройстве нужной ему части продукта. Модель ему настолько понравилась, что он включил ее в официальную документацию по продукту.
То есть использование наших наработок позволяет нам быстро вникать в проекты заказчиков и оперативно адаптировать к системе специалистов заказчика, которые работают вместе с нами.
А что делать с недостатком инструментов для тестирования и анализа багов?
В.С.: Как всем тестировщикам известно, инструментов для анализа багов существует большое количество. Какие-то из них лучше, какие-то хуже, но в целом, хороший результат может дать только умение комплексно использовать несколько инструментов сразу.
Если имеющиеся инструменты не позволяют решить стоящие перед нами задачи, мы самостоятельно их создаем.
В качестве примера могу привести методику для анализа логов любого тестируемого приложения в процессе выполнения теста. Логи являются основным источником информации о том, что происходило в приложении, когда тестировщик нашел баг.
Созданные нами инструменты позволяют эффективно собирать логи для всех необходимых компонентов и предоставлять четкую вырезку разработчику, которая позволит выяснить, в чем же состоит дефект. Инженер может увидеть полную картину сразу, а не собирать ее по частям.
Самый нижний уровень наших наработок – это автоматизация тестирования, т.е. мы вкладываем комплексную модель контроля качества, карту тестового покрытия и созданные нами инструменты в наши автотесты. Таким образом, одновременно решаются проблемы рутинной работы и регрессионных багов.
Мы выделили три базовых стадии выполнения автотеста:
На первой стадии мы запускаем приложение, делаем в нем определенные настройки и подготавливаем выполнение функциональной части. Например, если мы тестируем меню игры, нам необходимо запустить приложение, открыть это меню и дальше уже выполнять в нем операции тестирования.
Вторая стадия – это непосредственно сами операции тестирования – те действия, которые помогут нам понять, правильно ли работает функционал, который мы тестируем, или неправильно.
Третья стадия особенно важна для автотестов. Это отмена сделанных изменений. Каждый тест, в т.ч. и автоматический, должен выполнять какие-то операции по тестированию в тестовой среде, оставляя ее в неизменном виде после завершения работы. Потому что ключевое требование качественного тестирования – это производить тестовые операции в неизмененной среде и такими шагами, как это будет делать пользователь.
Таким образом, наши наработки в области тестирования решают все перечисленные проблемы тестировщиков.
Давай подробнее поговорим о системе. Какие еще преимущества Automated QA System можно выделить?
В.С.: Для ИТ-специалистов преимуществами является наша комплексная модель контроля качества, которая позволяет систематизировать и структурировать коммуникации на проекте, что позволит оптимизировать процесс тестирования и разработки.
Также интерес будет представлять с моей точки зрения и наша платформа-конструктор. Меня отлично поймут люди, которые знакомы с Linux. Как нам всем известно, Linux представляет собой большой комплекс маленьких инструментов, каждый из которых выполняет какую-то отдельную функцию, но если инструменты использовать вместе, ими можно решать гораздо более масштабные задачи. По такому принципу я строил нашу платформу конструктор, которую мы называем Automated QA System.
Наши автотесты используются для масштабных задач тестирования. В качестве примера приведу наши функциональные автотесты с проекта Star Crusade, которые, начинаясь с простых сценариев для проверки карт, были дополнены новыми инструментами и теперь представляют собой инструмент для тестирования всего продукта: и клиента, и сервера. Star Crusade имеет множество карт, параметры которых постоянно меняются по мере балансировки, что приводит к необходимости постоянного тестирования продукта.
При разработке тестов для проекта мы выбирали между двумя вариантами:
1) стабильными автотестами, которые могут самостоятельно обрабатывать определенные изменения карт
2) тестами, которые нужно менять вручную, но которые также просты в создании и обновлении.
В итоге остановились на втором варианте, т.к. работая с автотестами и наблюдая за игровыми сценариями через клиент, тестировщик остается постоянно погруженным в эту среду. Он начинает пробовать, экспериментировать, находить новые области, нестандартные баги и может все эти сценарии быстро зафиксировать автотестом.
Это дополнительно подчеркивает тот факт, что тестировщики используют автотесты как диагностический инструмент для контроля качества всего продукта, а не только для решения локальной задачи.
Для специалистов огромным преимуществом будет и механизм управления задачами, который реализован в Automated QA System. Для тестирования крупных проектов каждый раз необходимо сначала загружать свежую сборку продукта, разворачивать ее в тестовой среде, выполнять ряд определенных настроек и только потом можно прогонять непосредственно автотесты. Механизм управления задачами позволяет эффективно создавать такие задачи, автоматизировать их и запускать в нужной для тестировщика последовательности.
Мы также используем и автоматизацию макромодулями — модулями тестирования, которые выполняют более глобальную задачу, чем обычный модуль.
Для сравнения я приведу обычный объект в программировании, который выполняет определенное количество задач. Макромодулем в данном случае будет часть теста, которая выполняет комплексную задачу. Например, произведение определенных настроек продукта с использованием веб-интерфейса или с использованием функционала серверной части.
Достоинством Automated QA System является и возможность гибридной автоматизации. С использованием макромодулей мы можем создавать гибридные тесты, которые выполняют операции в совершенно различных средах (управление графической частью продукта, выполнение операций на рабочих станциях Windows, Unix серверах, мобильных устройствах или в веб-интерфейсе). Все эти операции можно использовать в рамках одного теста, организовывать обмен информацией между макромодулями и выдавать централизованный результат о выполнении такого теста.
Какие преимущества предоставляет система для заказчиков?
В.С.: Первое, мы оказываем пакетные услуги по контролю качества программного обеспечения. Это значит, что мы предоставляем комплексный контроль качества проекта нашего клиента. В модель вложен опыт команды тестирования более чем за 10 лет. Это достаточно долгий период, в течение которого мы наработали практики, подходы, выявили большое количество «узких мест», систематизировали и консолидировали полученный опыт, и пришли к той модели контроля качества, которую я описал. Только благодаря комплексному контролю качества можно достичь наилучшего качества проекта.
Второе, наша система автоматизированного тестирования и наша модель ручного тестирования (которая включает в себя карту тестового покрытия и графическую модель контроля качества) вместе со структурированными тестами позволяют оперативно предоставлять результаты заказчику. Это значит, что тесты, которые мы пишем и проводим, изначально представляют собой структурированную древовидную модель, из которой легко в ручном или в автоматическом режиме создать отчет и предоставить его заказчику. Наши автоматизированные тесты на выходе дают результат в относительно понятном для людей формате, т.е. результаты выполнения большинства тестов менеджер может оценить самостоятельно. В них не содержится большого количества технических данных, которые понятны только специалистам.
Третье, в случае с автоматическими тестами имеется возможность наблюдать за прогонами пакетов автоматических тестов продукта в онлайн режиме. Для этого у нас реализован веб-интерфейс, к которому мы можем предоставить заказчику доступ. Заказчик имеет возможность отслеживать также различные метрики: графики с динамикой т.н. pass rate — процента успешного выполнения теста, динамикой добавления автоматических тестов и ряд других трендов, в т.ч. мы можем добавлять необходимые графики и организовывать сбор информации по этим графикам.
Динамика успешности прохождения тестов (pass-rate trends)
Это значит, что наша система является расширяемой и обновляемой.
Таким образом, заказчик получает комплексное тестирование всего проекта и возможность получить подробные отчеты по проведенным тестам как в оффлайн, так и в онлайн режимах.
Мы также предоставляем возможность совместной работы с командой нашего заказчика, что позволяет обмениваться опытом.
Приведи, пожалуйста, несколько практических примеров использования Automated QA System?
В.С.: Наш опыт автоматизации начался с тестирования сложных телеком-систем, где ключевой функционал работал на linux сервере, а взаимодействие с пользователем производилось через веб интерфейсы. Большую часть нашего опыта мы собрали именно на подобных проектах.
В настоящий момент мы активно применяем описанную выше модель на нашем флагманском проекте Star Crusade. Мы используем автоматизированные функциональные тесты для тестирования серверной части продукта. Серверную часть мы тестируем с помощью управляемых ботов, которые выполняют на сервере определенные операции по команде автотеста.
Действия на игровом поле в клиентской части мы тестируем, наблюдая за прогоном автотеста через специальный режим наблюдателя, функционал, который также будет являться игровым. Когда интерфейс продукта выйдет на «финишную прямую» мы зафиксируем его автотестами с использованием технологий графического зрения, когда тест выполняет операции в клиенте также, как это бы делал конечный пользователь. С точки зрения тестирования это идеальный вариант, ведь, получая команды от драйверов мыши или клавиатуры, приложение управляется теми же самыми интерфейсами, какими будет управлять пользователь.
И веб-сервисы (сайт, серверные веб-интерфейсы) мы тестируем с помощью Selenium, при этом у нас также есть разработки, которые позволяют упростить Selenium автоматизацию и сделать ее более эффективной. Таким образом, все функциональные тесты объединяются в наш пакет тестирования.
Второй уровень тестирования – системные тесты. Системные тесты – это однозначно гибридное тестирование, т.е. управление несколькими инструментами в пределах одного теста. Здесь мы используем тот же самый конструктор из макромодулей. Например, в рамках одного теста мы проводим определенные настройки на сервере, используя консоль Linux и веб-интерфейс, проверяем необходимые механики с использованием управляемых ботов и завершаем тестирование с применением графического зрения. Ключевым моментом здесь является возможность оперативного изменения автотестов.
К примеру, мы тестируем возможность пользователя зарегистрироваться на сайте, подтвердить свой e-mail аккаунт и затем войти в игру под своим аккаунтом и сыграть какую-то игровую партию. Это можно делать разными путями. Мы можем регистрироваться на сайте с использованием веб-интерфейса в явном виде, либо мы можем на низком уровне посылать запросы на сервер. Результат выполнения будет одинаковым. Но в первом случае мы тестируем еще и сайт, его веб-интерфейс, а во втором – просто быстро выполняем необходимую операцию, не концентрируясь на веб-интерфейсе сайта.
С использованием управляемых ботов мы разыгрываем партию в игре. В данном случае мы быстро и надежно тестируем в большей степени серверную часть продукта. Также есть возможность тестировать продукт через клиент с помощью графического зрения, тогда мы проверяем еще и клиентскую часть. В созданном автотесте мы можем переключать различные функциональные элементы. Например, первый раз мы тестируем с использованием настройки продукта через веб-интерфейс и прогоняем тесты с помощью управляемых ботов, получая централизованный вывод результата. А в другой раз мы концентрируемся уже на графической части продукта и настраиваем продукт прямым запросом на сервер и играем партию уже через клиентское приложение.
Переключение между модулями происходит путем изменения одной-двух опций в автоматических тестах. Автотесты прекрасно дополняют используемые нашими тестировщиками прочие инструменты.
За полгода после внедрения Automated QA System были решены следующие проблемы:
1. Покрыта автотестами часть сервера, отвечающая за механики карт
2. Был обнаружен ряд проблем на сервере
3. Было выявлено большое количество багов клиента
4. Автотесты используются для проверки работы внутриигровых эффектов и анимаций
5. Автотесты используются для показов различных интересных игровых ситуаций
Функционал Automated QA System постоянно расширяется и обновляется. Какие перспективы развития у системы?
В.С.: Мы видим три основных направления развития Automated QA System:
Прежде всего мы хотим поработать в направлении развития графического зрения для создания гибридных тестов для match-3. Такие наши игры как Lil Quest, Muffin Quest и прочие игры-головоломки очень удобно тестировать с использованием ботов – скриптов, которые автоматически оценивают ситуацию на игровом поле и выполняют игровые действия. Но такие боты пропускают тестирование графического интерфейса. Мы хотим создать аналог таких ботов, которые смогут тестировать продукт как через графический интерфейс, так и минуя его.
Второй момент – мы развиваем технологии параллельного тестирования. В настоящий момент у нас есть модель параллельного запуска тестов, которая больше всего подходит для тестирования различных веб-проектов. Параллельное тестирование позволяет экономить время, запуская один и тот же тест одновременно на нескольких браузерах или даже на нескольких мобильных устройствах.
Модель подразумевает разделение тестов на общие и частные. Общие тесты одинаковы для всех браузеров и устройств, а частные специфичны для конкретного браузера или устройства.
Например, при тестировании системы-онлайн платежей скорее всего потребуется несколько частных тестов, потому как интерфейсы для настольных компьютеров и мобильных устройств зачастую различны и тестировать их с помощью одного теста не представляется возможным. Поэтому мы хотим развить эту модель и иметь возможность полноценно запараллеливать выполнение всех гибридных тестов. Это значит, что мы сможем параллельно выполнять не только тесты веб-интерфейса, а любые тесты, созданные в нашей системе, в том числе, гибридные. Стоит отметить, что автотесты для StarCrusade уже пригодны для параллельного запуска.
Разумеется, для развития данной модели имеет значение огромное количество моментов за пределами системы тестирования: структура тестовой среды, выделение аппаратного обеспечения для таких тестов и пр. В настоящий момент мы занимаемся анализом этих проблем и стараемся их систематизировать, структурировать и выработать какое-то оптимальное решение.
Мы также совершенствуем тестирование на виртуальных машинах. У нас есть опыт автоматизации тестирования на виртуальных машинах, в т.ч. в облачных средах. Сейчас мы также дорабатываем нашу модель для более быстрого, удобного и качественного тестирования, запуска наших гибридных тестов на виртуальных машинах и облачных средах.
В заключение хочу сказать, что мы работаем на самых разных проектах, и это позволяет нам постоянно улучшать и обновлять нашу систему и наши практики. Благодаря нашим наработкам для тестирования продуктов мы оказываем комплексные услуги по контролю качества проектов клиента, а понятная структура и логика системы позволяет легко работать вместе одной командой со специалистами наших заказчиков.
Несколько наглядных примеров работы системы в нашей презентации.
Мы с радостью ответим на все Ваши вопросы!
Кто есть «who»:
Automated QA System – платформа-конструктор для тестирования, которая имеет единую структуру, единую модель и позволяет по этой единой модели автоматизировать тесты. Эта платформа подходит и для простого прогона автотестов на waterfall проектах, и для комплексного контроля качества на agile проектах, а также для проектов, где используется непрерывная интеграционная разработка и другие методики.
Star Crusade — коллекционная карточная игра с большим количеством карт (более 320 шт.) Игра имеет сложную серверную часть и клиентское приложение с большим количеством графических эффектов, анимированной графики и различным функционалом (чаты, система друзей и дуэлей).
Продукт имеет ряд веб-интерфейсов:
— серверные веб-интерфейсы, которые используются командой разработки и поддержки продукта
— сайт игры, который виден конечным пользователям и где можно скачать сборку игры. В настоящее время доступна альфа-сборка.
Какие существуют проблемы в тестировании? Можешь их перечислить?
В.С: Исходя из своего опыта, я могу выделить несколько главных проблем в тестировании.
Проблема 1: баги из-за неструктурированного тестирования.
Если тестировщик выполняет ряд тестов, которые логически непоследовательны и неструктурированы, то такое тестирование может покрывать не весь продукт, поэтому каждый раз он находит все новые и новые баги, для исправления которых разработчикам и тестировщикам приходится много общаться между собой. Избыток таких коммуникаций приводит к потере времени и ухудшению качества продукта.
Проблема 2: недостаток инструментов для эффективного анализа багов или неумение пользоваться этими инструментами на 100%. Дело в том, что анализ бага не сводится только к его словесному описанию (о том, например, что не работает какая-то кнопочка или действие в игре производится неверно). Для того, чтобы разработчик мог понять, в чем состоит баг, и исправить его, тестировщик должен собрать определенное количество информации о найденном баге.
Классический пример – это логи (отчеты) тестируемого приложения, в том числе скриншоты экрана, какие-то расширенные таблицы (выборки из баз данных). На комплексных проектах трудно собрать всю информацию воедино, к тому же это занимает слишком много времени. Поэтому необходимо иметь инструменты, которые позволяют быстро и эффективно собирать информацию о найденных дефектах. Вот недостаток таких инструментов и является еще одной головной болью тестировщика и, как результат, головной болью разработчика.
Проблема 3: постоянная рутинная работа. Как всем известно, при реализации ИТ-проектов разработчики практически ежедневно добавляют и оптимизируют функционал, исправляют найденные баги. Поэтому приложение необходимо каждый раз тестировать заново для проверки работоспособности нового функционала и для поиска регрессионных багов. Иначе нельзя будет гарантировать, что тот код, который работал ранее, будет продолжать работать и после внесенных изменений. Тестировщику приходится ежедневно прогонять полный набор тестов, который с каждым разом только увеличивается.
И отдельно я бы хотел вынести в подкласс регрессионные баги. Когда разрабатываемый продукт не тестируется регулярно или тестируется неструктурированно появляется огромное количество регрессионных багов. Со временем подобные баги накапливаются как снежный ком и делают дальнейшую разработку продукта просто невозможной.
Как можно решить все перечисленные проблемы, чтобы упростить процесс разработки и тестирования?
В.С.: В первую очередь необходимо решить проблемы коммуникаций. Все члены команды (как тестирования, так и разработки) должны не только полностью разбираться в том компоненте, за который ответственны, но и видеть разрабатываемый продукт в комплексе, и обладать минимальными знаниями обо всех остальных компонентах продукта. В этом нам помогают наши наработки для контроля качества, в которые входят такие инструменты как:
- графическая модель контроля качества
- карта тестового покрытия
- четко структурированные тесты
Эти инструменты были созданы в процессе работы на различных проектах, и они позволяют выстроить качественную графическую древовидную модель тестирования проекта таким же образом, как в Agile разработке. Проект разделяется на Epic’и, которые в свою очередь делятся на User Story и конкретные задачи разработки и тестирования. Модель органично вписывается в структуру разработки на Agile проектах и помогает структурировать и систематизировать тестирование на Waterfall проектах.
С первого взгляда инструменты не представляют из себя ничего особенного. Это просто диаграмма, отражающая модель продукта, и древовидная модель отображения тестов. Я неоднократно слышал отзывы, что это “очевидные вещи”. Однако легко говорить, смотря на готовый результат. Реальность работы на проектах показывает, что эти вещи не так уж очевидны.
На графической модели контроля качества отображается продукт в том виде, в котором его необходимо видеть тестировщикам. Например, на верхнем уровне мне может быть неважно, что код продукта работает на Tomcat и какие именно библиотеки используются для связи с MySQL и LDAP. Мне важно проверить, что продукт способен выполнить пользовательскую операцию: авторизацию (которая включает в себя обращения к базе и обмен данными с клиентами), обмен сообщением (взаимодействие между 2 XMPP клиентами) и прочее. Однако, мне ничто не мешает спуститься уровнем ниже и уточнить модель или разбить ее на несколько слайдов/экранов, показывая дополнительно внутреннюю структуру компонентов.
Эту модель контроля качества можно сделать интерактивным инструментом, собирая в ней не просто информацию об устройстве продукта, но и проектную документацию, информацию по unit-тестам, различные статьи базы знаний и прочее. Ведь решая конкретную задачу тестирования/разработки, специалисту не нужна вся документация по проекту, ему нужна информация по той части продукта, над которой он в данный момент работает.
Таким образом, мы гарантируем, что команда имеет одинаковое представление о продукте и любой член команды может быстро получить нужную ему информацию. Команда не должна тратить время, объясняя каждому новому сотруднику все с нуля, а сотрудник не должен тратить время читая кучу документации, из которой для решения его текущей задачи ему необходимо не более 30%.
Графическая модель контроля качества
Подобным образом дело обстоит и с картой тестового покрытия. Она логически продолжает модель контроля качества и позволяет покрывать продукт тестами в таком формате, в каком ведется разработка функционала. Если какой-то функционал было решено доработать или даже переработать, то обновить тестовое покрытие можно быстро, поскольку оно представлено в виде понятной древовидной модели.
Было много дискуссий о том, сколько это занимает дополнительного времени. Например, на создание карты тестового покрытия, которая приведена здесь, я потратил около 15 минут.
Тестовое покрытие, представленное списком тестов
Тестовое покрытие с использованием древовидной модели (карты тестового покрытия)
Расскажи подробнее о результатах внедрения разработанных инструментов
В.С.: Пример из жизни: я взял тестовое покрытие одного из компонентов, сделанное опытным коллегой-тестировщиком, где было около 70 тестов, и разбил его так, как показано на карте тестового покрытия. Было найдено около 15 пропущенных тестов, при этом на всю работу ушло около 30 минут.
Со временем каждый продукт начинаешь видеть подобной моделью, и любые активности, связанные с тестированием продукта, становятся структурированными и последовательными. Особенно актуально это для новичков. Я помню, как я начинал писать тесты и не мог понять, с какой стороны мне подойти к тестированию, как покрыть продукт тестами, чтобы ничего не упустить. Если бы у меня были тогда такие инструменты, я бы приступил к работе в качестве полноценного сотрудника намного быстрее.
Мы также проводили эксперимент. Предоставляли новичку неструктурированное и частично устаревшее тестовое покрытие и пример с этой картой. Имея под рукой пример, диаграмму тестового покрытия, и задавая какие-то вопросы походу, человек, который не имел никакого опыта в тестировании, смог создать неплохое тестовое покрытие в течение 2 дней. На уровень полноценного инженера по тестированию он вышел в течение месяца, т.е. через месяц он уже полноценно работал с командой, при этом речь шла о тестировании сложных телеком-систем.
Еще одним примером использования связки модели + карты можно считать наш опыт коммуникации с техническим писателем. Принимаясь за написание пользовательской документации по практически готовому продукту он сначала решил разобраться как этот продукт устроен, чтобы документировать его структурированно. Я также предоставил ему модель + карту и дал несколько комментариев. Он моментально разобрался в устройстве нужной ему части продукта. Модель ему настолько понравилась, что он включил ее в официальную документацию по продукту.
То есть использование наших наработок позволяет нам быстро вникать в проекты заказчиков и оперативно адаптировать к системе специалистов заказчика, которые работают вместе с нами.
А что делать с недостатком инструментов для тестирования и анализа багов?
В.С.: Как всем тестировщикам известно, инструментов для анализа багов существует большое количество. Какие-то из них лучше, какие-то хуже, но в целом, хороший результат может дать только умение комплексно использовать несколько инструментов сразу.
Если имеющиеся инструменты не позволяют решить стоящие перед нами задачи, мы самостоятельно их создаем.
В качестве примера могу привести методику для анализа логов любого тестируемого приложения в процессе выполнения теста. Логи являются основным источником информации о том, что происходило в приложении, когда тестировщик нашел баг.
Созданные нами инструменты позволяют эффективно собирать логи для всех необходимых компонентов и предоставлять четкую вырезку разработчику, которая позволит выяснить, в чем же состоит дефект. Инженер может увидеть полную картину сразу, а не собирать ее по частям.
Самый нижний уровень наших наработок – это автоматизация тестирования, т.е. мы вкладываем комплексную модель контроля качества, карту тестового покрытия и созданные нами инструменты в наши автотесты. Таким образом, одновременно решаются проблемы рутинной работы и регрессионных багов.
Мы выделили три базовых стадии выполнения автотеста:
- подготовка среды к тестированию
- тестирование
- отмена сделанных изменений
На первой стадии мы запускаем приложение, делаем в нем определенные настройки и подготавливаем выполнение функциональной части. Например, если мы тестируем меню игры, нам необходимо запустить приложение, открыть это меню и дальше уже выполнять в нем операции тестирования.
Вторая стадия – это непосредственно сами операции тестирования – те действия, которые помогут нам понять, правильно ли работает функционал, который мы тестируем, или неправильно.
Третья стадия особенно важна для автотестов. Это отмена сделанных изменений. Каждый тест, в т.ч. и автоматический, должен выполнять какие-то операции по тестированию в тестовой среде, оставляя ее в неизменном виде после завершения работы. Потому что ключевое требование качественного тестирования – это производить тестовые операции в неизмененной среде и такими шагами, как это будет делать пользователь.
Таким образом, наши наработки в области тестирования решают все перечисленные проблемы тестировщиков.
Давай подробнее поговорим о системе. Какие еще преимущества Automated QA System можно выделить?
В.С.: Для ИТ-специалистов преимуществами является наша комплексная модель контроля качества, которая позволяет систематизировать и структурировать коммуникации на проекте, что позволит оптимизировать процесс тестирования и разработки.
Также интерес будет представлять с моей точки зрения и наша платформа-конструктор. Меня отлично поймут люди, которые знакомы с Linux. Как нам всем известно, Linux представляет собой большой комплекс маленьких инструментов, каждый из которых выполняет какую-то отдельную функцию, но если инструменты использовать вместе, ими можно решать гораздо более масштабные задачи. По такому принципу я строил нашу платформу конструктор, которую мы называем Automated QA System.
Наши автотесты используются для масштабных задач тестирования. В качестве примера приведу наши функциональные автотесты с проекта Star Crusade, которые, начинаясь с простых сценариев для проверки карт, были дополнены новыми инструментами и теперь представляют собой инструмент для тестирования всего продукта: и клиента, и сервера. Star Crusade имеет множество карт, параметры которых постоянно меняются по мере балансировки, что приводит к необходимости постоянного тестирования продукта.
При разработке тестов для проекта мы выбирали между двумя вариантами:
1) стабильными автотестами, которые могут самостоятельно обрабатывать определенные изменения карт
2) тестами, которые нужно менять вручную, но которые также просты в создании и обновлении.
В итоге остановились на втором варианте, т.к. работая с автотестами и наблюдая за игровыми сценариями через клиент, тестировщик остается постоянно погруженным в эту среду. Он начинает пробовать, экспериментировать, находить новые области, нестандартные баги и может все эти сценарии быстро зафиксировать автотестом.
Это дополнительно подчеркивает тот факт, что тестировщики используют автотесты как диагностический инструмент для контроля качества всего продукта, а не только для решения локальной задачи.
Для специалистов огромным преимуществом будет и механизм управления задачами, который реализован в Automated QA System. Для тестирования крупных проектов каждый раз необходимо сначала загружать свежую сборку продукта, разворачивать ее в тестовой среде, выполнять ряд определенных настроек и только потом можно прогонять непосредственно автотесты. Механизм управления задачами позволяет эффективно создавать такие задачи, автоматизировать их и запускать в нужной для тестировщика последовательности.
Мы также используем и автоматизацию макромодулями — модулями тестирования, которые выполняют более глобальную задачу, чем обычный модуль.
Для сравнения я приведу обычный объект в программировании, который выполняет определенное количество задач. Макромодулем в данном случае будет часть теста, которая выполняет комплексную задачу. Например, произведение определенных настроек продукта с использованием веб-интерфейса или с использованием функционала серверной части.
Достоинством Automated QA System является и возможность гибридной автоматизации. С использованием макромодулей мы можем создавать гибридные тесты, которые выполняют операции в совершенно различных средах (управление графической частью продукта, выполнение операций на рабочих станциях Windows, Unix серверах, мобильных устройствах или в веб-интерфейсе). Все эти операции можно использовать в рамках одного теста, организовывать обмен информацией между макромодулями и выдавать централизованный результат о выполнении такого теста.
Какие преимущества предоставляет система для заказчиков?
В.С.: Первое, мы оказываем пакетные услуги по контролю качества программного обеспечения. Это значит, что мы предоставляем комплексный контроль качества проекта нашего клиента. В модель вложен опыт команды тестирования более чем за 10 лет. Это достаточно долгий период, в течение которого мы наработали практики, подходы, выявили большое количество «узких мест», систематизировали и консолидировали полученный опыт, и пришли к той модели контроля качества, которую я описал. Только благодаря комплексному контролю качества можно достичь наилучшего качества проекта.
Второе, наша система автоматизированного тестирования и наша модель ручного тестирования (которая включает в себя карту тестового покрытия и графическую модель контроля качества) вместе со структурированными тестами позволяют оперативно предоставлять результаты заказчику. Это значит, что тесты, которые мы пишем и проводим, изначально представляют собой структурированную древовидную модель, из которой легко в ручном или в автоматическом режиме создать отчет и предоставить его заказчику. Наши автоматизированные тесты на выходе дают результат в относительно понятном для людей формате, т.е. результаты выполнения большинства тестов менеджер может оценить самостоятельно. В них не содержится большого количества технических данных, которые понятны только специалистам.
Третье, в случае с автоматическими тестами имеется возможность наблюдать за прогонами пакетов автоматических тестов продукта в онлайн режиме. Для этого у нас реализован веб-интерфейс, к которому мы можем предоставить заказчику доступ. Заказчик имеет возможность отслеживать также различные метрики: графики с динамикой т.н. pass rate — процента успешного выполнения теста, динамикой добавления автоматических тестов и ряд других трендов, в т.ч. мы можем добавлять необходимые графики и организовывать сбор информации по этим графикам.
Динамика успешности прохождения тестов (pass-rate trends)
Это значит, что наша система является расширяемой и обновляемой.
Таким образом, заказчик получает комплексное тестирование всего проекта и возможность получить подробные отчеты по проведенным тестам как в оффлайн, так и в онлайн режимах.
Мы также предоставляем возможность совместной работы с командой нашего заказчика, что позволяет обмениваться опытом.
Приведи, пожалуйста, несколько практических примеров использования Automated QA System?
В.С.: Наш опыт автоматизации начался с тестирования сложных телеком-систем, где ключевой функционал работал на linux сервере, а взаимодействие с пользователем производилось через веб интерфейсы. Большую часть нашего опыта мы собрали именно на подобных проектах.
В настоящий момент мы активно применяем описанную выше модель на нашем флагманском проекте Star Crusade. Мы используем автоматизированные функциональные тесты для тестирования серверной части продукта. Серверную часть мы тестируем с помощью управляемых ботов, которые выполняют на сервере определенные операции по команде автотеста.
Действия на игровом поле в клиентской части мы тестируем, наблюдая за прогоном автотеста через специальный режим наблюдателя, функционал, который также будет являться игровым. Когда интерфейс продукта выйдет на «финишную прямую» мы зафиксируем его автотестами с использованием технологий графического зрения, когда тест выполняет операции в клиенте также, как это бы делал конечный пользователь. С точки зрения тестирования это идеальный вариант, ведь, получая команды от драйверов мыши или клавиатуры, приложение управляется теми же самыми интерфейсами, какими будет управлять пользователь.
И веб-сервисы (сайт, серверные веб-интерфейсы) мы тестируем с помощью Selenium, при этом у нас также есть разработки, которые позволяют упростить Selenium автоматизацию и сделать ее более эффективной. Таким образом, все функциональные тесты объединяются в наш пакет тестирования.
Второй уровень тестирования – системные тесты. Системные тесты – это однозначно гибридное тестирование, т.е. управление несколькими инструментами в пределах одного теста. Здесь мы используем тот же самый конструктор из макромодулей. Например, в рамках одного теста мы проводим определенные настройки на сервере, используя консоль Linux и веб-интерфейс, проверяем необходимые механики с использованием управляемых ботов и завершаем тестирование с применением графического зрения. Ключевым моментом здесь является возможность оперативного изменения автотестов.
К примеру, мы тестируем возможность пользователя зарегистрироваться на сайте, подтвердить свой e-mail аккаунт и затем войти в игру под своим аккаунтом и сыграть какую-то игровую партию. Это можно делать разными путями. Мы можем регистрироваться на сайте с использованием веб-интерфейса в явном виде, либо мы можем на низком уровне посылать запросы на сервер. Результат выполнения будет одинаковым. Но в первом случае мы тестируем еще и сайт, его веб-интерфейс, а во втором – просто быстро выполняем необходимую операцию, не концентрируясь на веб-интерфейсе сайта.
С использованием управляемых ботов мы разыгрываем партию в игре. В данном случае мы быстро и надежно тестируем в большей степени серверную часть продукта. Также есть возможность тестировать продукт через клиент с помощью графического зрения, тогда мы проверяем еще и клиентскую часть. В созданном автотесте мы можем переключать различные функциональные элементы. Например, первый раз мы тестируем с использованием настройки продукта через веб-интерфейс и прогоняем тесты с помощью управляемых ботов, получая централизованный вывод результата. А в другой раз мы концентрируемся уже на графической части продукта и настраиваем продукт прямым запросом на сервер и играем партию уже через клиентское приложение.
Переключение между модулями происходит путем изменения одной-двух опций в автоматических тестах. Автотесты прекрасно дополняют используемые нашими тестировщиками прочие инструменты.
За полгода после внедрения Automated QA System были решены следующие проблемы:
1. Покрыта автотестами часть сервера, отвечающая за механики карт
2. Был обнаружен ряд проблем на сервере
3. Было выявлено большое количество багов клиента
4. Автотесты используются для проверки работы внутриигровых эффектов и анимаций
5. Автотесты используются для показов различных интересных игровых ситуаций
Функционал Automated QA System постоянно расширяется и обновляется. Какие перспективы развития у системы?
В.С.: Мы видим три основных направления развития Automated QA System:
- развитие инструментов для создания гибридных тестов с использованием графического зрения
- развитие технологий параллельного тестирования
- совершенствования тестирования на виртуальных машинах и в облачных средах
Прежде всего мы хотим поработать в направлении развития графического зрения для создания гибридных тестов для match-3. Такие наши игры как Lil Quest, Muffin Quest и прочие игры-головоломки очень удобно тестировать с использованием ботов – скриптов, которые автоматически оценивают ситуацию на игровом поле и выполняют игровые действия. Но такие боты пропускают тестирование графического интерфейса. Мы хотим создать аналог таких ботов, которые смогут тестировать продукт как через графический интерфейс, так и минуя его.
Второй момент – мы развиваем технологии параллельного тестирования. В настоящий момент у нас есть модель параллельного запуска тестов, которая больше всего подходит для тестирования различных веб-проектов. Параллельное тестирование позволяет экономить время, запуская один и тот же тест одновременно на нескольких браузерах или даже на нескольких мобильных устройствах.
Модель подразумевает разделение тестов на общие и частные. Общие тесты одинаковы для всех браузеров и устройств, а частные специфичны для конкретного браузера или устройства.
Например, при тестировании системы-онлайн платежей скорее всего потребуется несколько частных тестов, потому как интерфейсы для настольных компьютеров и мобильных устройств зачастую различны и тестировать их с помощью одного теста не представляется возможным. Поэтому мы хотим развить эту модель и иметь возможность полноценно запараллеливать выполнение всех гибридных тестов. Это значит, что мы сможем параллельно выполнять не только тесты веб-интерфейса, а любые тесты, созданные в нашей системе, в том числе, гибридные. Стоит отметить, что автотесты для StarCrusade уже пригодны для параллельного запуска.
Разумеется, для развития данной модели имеет значение огромное количество моментов за пределами системы тестирования: структура тестовой среды, выделение аппаратного обеспечения для таких тестов и пр. В настоящий момент мы занимаемся анализом этих проблем и стараемся их систематизировать, структурировать и выработать какое-то оптимальное решение.
Мы также совершенствуем тестирование на виртуальных машинах. У нас есть опыт автоматизации тестирования на виртуальных машинах, в т.ч. в облачных средах. Сейчас мы также дорабатываем нашу модель для более быстрого, удобного и качественного тестирования, запуска наших гибридных тестов на виртуальных машинах и облачных средах.
В заключение хочу сказать, что мы работаем на самых разных проектах, и это позволяет нам постоянно улучшать и обновлять нашу систему и наши практики. Благодаря нашим наработкам для тестирования продуктов мы оказываем комплексные услуги по контролю качества проектов клиента, а понятная структура и логика системы позволяет легко работать вместе одной командой со специалистами наших заказчиков.
Несколько наглядных примеров работы системы в нашей презентации.
Мы с радостью ответим на все Ваши вопросы!
