Интервью с QA-архитектором Владимиром Савельевым продолжает серию публикаций на актуальные IT-темы.
Владимир рассказывает об основных головных болях тестировщиков и делится эффективным способом их решения 
Кто есть кто": Автоматизированная система контроля качества — платформа проектирования для тестирования, имеющая единую структуру, единую модель и позволяющая автоматизировать тестирование с использованием этой единой модели.
Эта платформа подходит для простого запуска автотестов в водопадных проектах и для комплексного контроля качества в гибких проектах, а также для проектов, использующих непрерывную интеграционную разработку и другие методы.
Звездный крестовый поход — коллекционная карточная игра с большим количеством карточек (более 320 штук).
Игра имеет сложную серверную часть и клиентское приложение с большим количеством графических эффектов, анимированной графикой и различным функционалом (чаты, система друзей и дуэлей).
Продукт имеет ряд веб-интерфейсов: — веб-интерфейсы серверов, которые используются командой разработки и поддержки продукта.
— веб-сайт игры, который виден конечным пользователям и на котором можно скачать сборку игры.
В настоящее время доступна альфа-сборка.
Какие проблемы возникают при тестировании? Можете ли вы их перечислить? ПРОТИВ: Основываясь на своем опыте, я могу выделить несколько основных проблем при тестировании.
Проблема 1: ошибки из-за неструктурированного тестирования.
Если тестировщик выполняет серию тестов, логически противоречивых и неструктурированных, то такое тестирование может не охватить весь продукт, поэтому каждый раз он находит все новые и новые ошибки, для исправления которых разработчикам и тестировщикам приходится много общаться друг с другом.
.
Избыток таких коммуникаций приводит к потере времени и ухудшению качества продукта.
Проблема 2: отсутствие инструментов для эффективного анализа ошибок или неумение использовать эти инструменты 100%.
Дело в том, что анализ бага не ограничивается только его словесным описанием (например, что не работает какая-то кнопка или действие в игре выполнено неправильно).
Чтобы разработчик мог понять, в чем заключается ошибка, и исправить ее, тестировщик должен собрать определенный объем информации о найденной ошибке.
Классический пример — логи (отчеты) тестируемого приложения, включающие скриншоты, некоторые расширенные таблицы (выборки из баз данных).
В сложных проектах сложно собрать всю информацию воедино, да и времени на это уходит слишком много.
Поэтому необходимо иметь инструменты, позволяющие быстро и эффективно собирать информацию о найденных дефектах.
Отсутствие таких инструментов — еще одна головная боль тестировщика и, как следствие, головная боль разработчика.
Проблема 3: постоянная рутинная работа.
Как всем известно, при реализации ИТ-проектов разработчики практически ежедневно добавляют и оптимизируют функционал, исправляют найденные ошибки.
Поэтому приложение необходимо каждый раз тестировать заново, чтобы проверить работоспособность нового функционала и поискать регрессионные ошибки.
В противном случае невозможно будет гарантировать, что код, который работал ранее, продолжит работать после внесения изменений.
Тестировщику приходится каждый день выполнять полный набор тестов, который с каждым разом только увеличивается.
И отдельно хотелось бы подкласс регрессионные ошибки.
Когда разрабатываемый продукт не тестируется регулярно или тестируется неструктурированно, появляется огромное количество регрессионных ошибок.
Со временем такие ошибки накапливаются как снежный ком и делают дальнейшее развитие продукта просто невозможным.
Как мы можем решить все эти проблемы, чтобы упростить процесс разработки и тестирования? ПРОТИВ.
: Прежде всего, необходимо решить проблемы общения.
Все члены команды (как тестировщики, так и разработчики) должны не только полностью понимать компонент, за который они отвечают, но и видеть разрабатываемый продукт в целом, а также иметь минимальные знания обо всех остальных компонентах продукта.
Наши разработки по контролю качества, которые включают в себя такие инструменты, как:
графическая модель контроля качества карта тестового покрытия четко структурированные тесты Эти инструменты были созданы в ходе работы над различными проектами и позволяют построить качественную графическую древовидную модель для тестирования проекта так же, как и в Agile-разработке.Проект разделен на эпики, которые, в свою очередь, делятся на пользовательские истории и конкретные задачи разработки и тестирования.
Модель органично вписывается в структуру разработки Agile-проектов и помогает структурировать и систематизировать тестирование в проектах Waterfall. На первый взгляд инструменты не представляют собой ничего особенного.
Это просто диаграмма, отражающая модель продукта и древовидная модель отображения тестов.
Я неоднократно слышал отзывы, что это «очевидные вещи».
Впрочем, это легко сказать, глядя на готовый результат. Реальность работы над проектами показывает, что эти вещи не столь очевидны.
Графическая модель контроля качества отображает продукт таким, каким его хотят видеть тестировщики.
Например, на высоком уровне меня может не волновать, работает ли код продукта на Tomcat и какие конкретно библиотеки используются для взаимодействия с MySQL и LDAP. Мне важно проверить, что продукт способен выполнять пользовательскую операцию: авторизацию (включающую обращения к базе данных и обмен данными с клиентами), обмен сообщениями (взаимодействие между 2-мя XMPP-клиентами) и так далее.
Однако ничто не мешает мне спуститься на уровень ниже и уточнить модель или разбить ее на несколько слайдов/экранов, дополнительно показав внутреннюю структуру компонентов.
Эту модель контроля качества можно сделать интерактивным инструментом, собрав в ней не просто информацию о конструкции продукта, но и конструкторскую документацию, информацию о юнит-тестах, различные статьи базы знаний и т. д. Ведь при решении конкретного тестирования/ проблема разработки, специалисту не нужна вся документация по проекту; ему нужна информация о той части продукта, над которой он сейчас работает. Таким образом, мы гарантируем, что команда имеет одинаковое понимание продукта, и любой член команды может быстро получить необходимую информацию.
Команда не должна тратить время на объяснение всего с нуля каждому новому сотруднику, а сотрудник не должен тратить время на чтение кучи документации, которой ему нужно не более 30% для решения текущей задачи.
Графическая модель контроля качества
Аналогичная ситуация и с картой тестового покрытия.
Это логически продолжает модель контроля качества и позволяет покрывать продукт тестами в том формате, в котором разрабатывается функционал.
Если было решено доработать или даже переработать какой-то функционал, то тестовое покрытие можно быстро обновить, поскольку оно представлено в виде четкой древовидной модели.
Было много дискуссий о том, сколько дополнительного времени это займет. Например, создание карты тестового покрытия, показанной здесь, заняло у меня около 15 минут. 
Тестовое покрытие, представленное списком тестов.
Тестовое покрытие с использованием древовидной модели (карты тестового покрытия) Расскажите подробнее о результатах внедрения разработанных инструментов ПРОТИВ.
: Пример из реальной жизни: я взял тестовое покрытие одного из компонентов, сделанное опытным коллегой-тестировщиком, где было около 70 тестов, и разбил его, как показано на карте тестового покрытия.
Было обнаружено около 15 недостающих тестов, а вся работа заняла около 30 минут. Со временем вы начинаете рассматривать каждый продукт как одну и ту же модель, и любая деятельность, связанная с тестированием продукта, становится структурированной и последовательной.
Особенно это актуально для новичков.
Помню, как я начал писать тесты и не мог понять, с какой стороны подойти к тестированию, как покрыть продукт тестами, чтобы ничего не упустить.
Если бы у меня тогда были такие инструменты, я бы гораздо быстрее начал работать штатным сотрудником.
Мы также провели эксперимент. Мы предоставили новичку неструктурированное и частично устаревшее тестовое покрытие и пример с этой картой.
Имея под рукой пример, диаграмму тестового покрытия и задав несколько вопросов кампании, человек, не имевший опыта в тестировании, смог за 2 дня создать хорошее тестовое покрытие.
До уровня полноценного инженера по тестированию он дошёл за месяц, т.е.
через месяц он уже работал с командой на постоянной основе, и речь шла о тестировании сложных телеком-систем.
Еще один пример использования комбинации модель+карта — наш опыт общения с техническим писателем.
Приступая к написанию пользовательской документации к почти готовому продукту, он сначала решил разобраться, как этот продукт работает, чтобы структурировано его документировать.
Я также предоставил ему модель + карту и дал несколько комментариев.
Он мгновенно понял структуру нужной ему части продукта.
Модель ему настолько понравилась, что он включил ее в официальную документацию продукта.
То есть использование наших разработок позволяет нам быстро вникать в проекты заказчика и быстро адаптировать к системе специалистов заказчика, которые работают с нами.
Что делать с отсутствием инструментов для тестирования и анализа ошибок? ПРОТИВ.
: Как известно всем тестировщикам, существует большое количество инструментов для анализа ошибок.
Какие-то из них лучше, какие-то хуже, но в целом хорошего результата можно добиться только при умении комплексно использовать сразу несколько инструментов.
Если существующие инструменты не позволяют нам решить стоящие перед нами проблемы, мы создаём их сами.
В качестве примера могу привести методику анализа логов любого тестируемого приложения во время выполнения теста.
Журналы — основной источник информации о том, что происходило в приложении, когда тестировщик обнаружил ошибку.
Созданные нами инструменты позволяют эффективно собирать логи всех необходимых компонентов и предоставлять разработчику наглядную информацию, которая позволит ему выяснить, в чем заключается дефект. Инженер может увидеть всю картину сразу, а не собирать ее по частям.
Самый низший уровень наших разработок — это автоматизация тестирования, т. е.
мы встраиваем в наши автотесты комплексную модель QA, карту тестового покрытия и создаваемые нами инструменты.
Таким образом одновременно решаются проблемы рутинной работы и ошибок регресса.
Мы выделили три основных этапа выполнения автотеста: подготовка среды для тестирования тестирование отменить внесенные изменения На первом этапе мы запускаем приложение, делаем в нем определенные настройки и готовим выполнение функциональной части.
Например, если мы тестируем меню игры, нам нужно запустить приложение, открыть это меню и затем провести в нем операции тестирования.
Второй этап — это сами операции тестирования — те действия, которые помогут нам понять, правильно или неправильно работает тестируемый нами функционал.
Третий этап особенно важен для автотестов.
Это отмена внесенных изменений.
Каждое испытание, в т.ч.
и автоматические, должны выполнять некоторые операции тестирования в тестовой среде, оставляя ее неизменной после завершения работы.
Потому что ключевым требованием качественного тестирования является выполнение тестовых операций в неизмененной среде и в тех же шагах, как это делал бы пользователь.
Таким образом, наши разработки в области тестирования решают все перечисленные проблемы тестировщиков.
Давайте поговорим подробнее о системе.
Какие еще преимущества Автоматизированной системы контроля качества можно выделить? ПРОТИВ.
: ИТ-специалисты получают выгоду от наших комплексная модель контроля качества , что позволяет систематизировать и структурировать коммуникации по проекту, что позволит оптимизировать процесс тестирования и разработки.
Также интересными, с моей точки зрения, будут наши конструктор платформ .
Люди, знакомые с Linux, меня прекрасно поймут. Как мы все знаем, Linux представляет собой большую коллекцию небольших инструментов, каждый из которых выполняет отдельную функцию, но если инструменты использовать вместе, они могут решать гораздо более крупные проблемы.
По этому принципу я построил нашу платформу-конструктор, которую мы называем Автоматизированная система контроля качества .
Наши автотесты используются для масштабные задачи тестирования .
В качестве примера приведу наши функциональные автотесты из проекта.
Звездный крестовый поход , которые, начав с простых скриптов для тестирования карт, были дополнены новыми инструментами и теперь представляют собой инструмент для тестирования всего продукта: как клиентского, так и серверного.
В Star Crusade есть множество карт, которые постоянно меняются по мере их сбалансированности, что требует постоянного тестирования продукта.
При разработке тестов для проекта мы выбирали между двумя вариантами: 1) стабильные автотесты, способные самостоятельно обрабатывать те или иные изменения карты 2) тесты, которые нужно менять вручную, но которые также легко создавать и обновлять.
В итоге мы остановились на втором варианте, потому что.
Работая с автотестами и наблюдая игровые сценарии через клиент, тестировщик остается постоянно погруженным в эту среду.
Он начинает пробовать, экспериментировать, находить новые области, нестандартные баги и может быстро исправить все эти сценарии автоматическим тестом.
Это еще раз подчеркивает тот факт, что тестировщики используют автотесты как инструмент диагностики для контроля качества всего продукта, а не только для решения локальной проблемы.
Для специалистов это будет огромным преимуществом механизм управления задачами , который реализован в Автоматизированной системе контроля качества.
Для тестирования больших проектов каждый раз необходимо сначала скачать свежую сборку продукта, развернуть ее в тестовой среде, выполнить ряд специфических настроек и только потом можно запускать автотесты напрямую.
Механизм управления задачами позволяет эффективно создавать такие задачи, автоматизировать их и запускать в необходимой тестировщику последовательности.
Мы также используем автоматизация с помощью макромодулей — тестирование модулей, выполняющих более глобальную задачу, чем обычный модуль.
Для сравнения приведу распространенный в программировании объект, выполняющий определенное количество задач.
Макромодулем в этом случае будет часть теста, выполняющая сложную задачу.
Например, выполнение определенных настроек продукта с помощью веб-интерфейса или использование функционала серверной части.
Преимущество автоматизированной системы контроля качества заключается в возможность гибридной автоматизации .
С помощью макромодулей мы можем создавать гибридные тесты, выполняющие операции в совершенно разных средах (управление графической частью продукта, выполнение операций на рабочих станциях Windows, Unix-серверах, мобильных устройствах или в веб-интерфейсе).
Все эти операции можно использовать в рамках одного теста, организовать обмен информацией между макромодулями и предоставить централизованный результат о выполнении такого теста.
Какие преимущества система предоставляет клиентам? ПРОТИВ.
: Во-первых, мы предоставляем пакетные услуги для контроля качества программного обеспечения.
Это значит, что мы обеспечиваем комплексный контроль качества проекта нашего клиента.
Модель включает в себя более чем 10-летний опыт команды тестировщиков.
Это достаточно длительный период, за который мы выработали практики и подходы, выявили большое количество узких мест, систематизировали и закрепили полученный опыт и пришли к той модели контроля качества, которую я описал.
Только благодаря всестороннему контролю качества можно достичь наилучшего качества проекта.
Во-вторых, наша автоматизированная система тестирования и наша модель ручного тестирования (которая включает в себя карту тестового покрытия и графическую модель контроля качества) вместе со структурированными тестами позволяют оперативно предоставлять результат заказчику .
Это значит, что тесты, которые мы пишем и проводим, изначально представляют собой структурированную древовидную модель, на основе которой легко вручную или автоматически создать отчет и предоставить его заказчику.
Наши автоматизированные выходные тесты выдают результаты в относительно понятном для человека формате, т.е.
менеджер может самостоятельно оценить результаты большинства тестов.
Они не содержат большого количества технических данных, понятных только специалистам.
В-третьих, в случае автоматических тестов возможно отслеживать запуск пакетов автоматического тестирования продуктов в режиме онлайн .
Для этого мы реализовали веб-интерфейс, к которому можем предоставить доступ заказчику.
Также у заказчика есть возможность отслеживать различные метрики: графики с динамикой т.н.
passrate - процент успешного прохождения тестов, динамика добавления автоматических тестов и ряд других тенденций, в т.ч.
мы можем добавить необходимые графики и организовать сбор информации по этим графикам.
Динамика успешности тестирования (тенденции сдачи тестов)
Это означает, что наша система расширяема и модернизируема.
Таким образом, заказчик получает комплексное тестирование всего проекта и возможность получать подробные отчеты о проведенных испытаниях как оффлайн, так и онлайн.
Мы также предоставляем возможность сотрудничать с командой нашего клиента, что позволяет нам обмениваться опытом.
Приведите, пожалуйста, несколько практических примеров использования Автоматизированной системы контроля качества? ПРОТИВ.
: Наш опыт автоматизации начался с тестирования сложных телекоммуникационных систем, где ключевые функции выполнялись на Linux-сервере, а взаимодействие с пользователем осуществлялось через веб-интерфейсы.
Большую часть нашего опыта мы накопили именно на таких проектах.
В настоящее время мы активно используем описанную выше модель в нашем флагманском проекте Star Crusade. Мы используем автоматизированные функциональные тесты для тестирования серверной части продукта.
Серверную часть мы тестируем с помощью управляемых ботов, которые выполняют определенные операции на сервере с помощью команды автотеста.
Тестируем действия на игровом поле в клиентской части, наблюдая за прохождением автотеста в специальном режиме наблюдателя — функционал, который также будет игровым.
Когда интерфейс продукта достигнет «финишной черты», мы исправим это с помощью автотестов с использованием технологий графического зрения, когда тест выполняет операции в клиенте так же, как это сделал бы конечный пользователь.
С точки зрения тестирования это идеальный вариант, поскольку, получая команды от драйверов мыши или клавиатуры, приложение управляется теми же интерфейсами, которыми будет управлять пользователь.
Мы тестируем веб-сервисы (сайт, веб-интерфейсы серверов) с помощью Selenium, а также у нас есть разработки, которые делают автоматизацию Selenium проще и эффективнее.
Таким образом, все функциональные тесты объединяются в наш пакет тестирования.
Второй уровень тестирования — системные тесты.
Системные тесты определенно представляют собой гибридное тестирование, то есть управление несколькими инструментами в рамках одного теста.
Здесь мы используем тот же конструктор модуля макроса.
Например, в одном тесте мы выполняем определенные настройки на сервере с помощью консоли Linux и веб-интерфейса, проверяем необходимую механику с помощью управляемых ботов и завершаем тестирование с помощью графического зрения.
Ключевым моментом здесь является возможность быстрой смены автотестов.
Например, мы тестируем возможность пользователя зарегистрироваться на сайте, подтвердить свою учетную запись электронной почты, а затем войти в игру под своей учетной записью и сыграть в какую-нибудь игровую игру.
Это можно сделать разными способами.
Мы можем зарегистрироваться на сайте с помощью веб-интерфейса явно, а можем отправлять запросы к серверу на низком уровне.
Результат выполнения будет тот же.
Но в первом случае мы также тестируем сайт и его веб-интерфейс, а во втором просто быстро выполняем необходимую операцию, не концентрируясь на веб-интерфейсе сайта.
Используя управляемых ботов, мы играем в игру.
В этом случае мы быстро и надежно тестируем преимущественно серверную часть продукта.
Также возможно тестирование продукта через клиент с помощью графического зрения, затем мы также проверяем клиентскую часть.
В созданном автотесте мы можем переключать различные функциональные элементы.
Например, мы впервые тестируем с помощью настройки продукта через веб-интерфейс и запускаем тесты с помощью управляемых ботов, получая централизованную выдачу результата.
А в другой раз концентрируемся на графической части продукта и настраиваем продукт с прямым запросом к серверу и играем в игру через клиентское приложение.
Переключение между модулями происходит путем изменения одной или двух опций в автоматических тестах.
Автотесты прекрасно дополняют другие инструменты, используемые нашими тестировщиками.
За шесть месяцев после внедрения Автоматизированной системы контроля качества были решены следующие проблемы: 1. Часть сервера, отвечающая за карточную механику, покрыта автотестами.
2. На сервере обнаружен ряд проблем 3. Выявлено большое количество ошибок клиента 4. Автотесты используются для проверки работы внутриигровых эффектов и анимации.
5. Автотесты используются для демонстрации различных интересных игровых ситуаций.
Функционал Автоматизированной системы контроля качества постоянно расширяется и обновляется.
Каковы перспективы развития системы? ПРОТИВ.
: Мы видим три основных направления развития Автоматизированной системы контроля качества: разработка инструментов для создания гибридных тестов с использованием графического зрения разработка технологий параллельного тестирования улучшение тестирования на виртуальных машинах и в облачных средах Прежде всего, мы хотим работать над развитием графического видения для создания гибридных тестов для match-3. Наши игры похожи Лил Квест , Маффин Квест и другие головоломки очень удобно тестировать с помощью ботов — скриптов, которые автоматически оценивают ситуацию на игровом поле и выполняют игровые действия.
Но такие боты пропускают тестирование графического интерфейса.
Мы хотим создать аналог таких ботов, которые смогут тестировать продукт как через графический интерфейс, так и в его обход. Второй момент — мы развиваем технологии параллельного тестирования.
В настоящее время у нас есть модель параллельного запуска тестов, которая лучше всего подходит для тестирования различных веб-проектов.
Параллельное тестирование позволяет сэкономить время, запуская один и тот же тест одновременно в нескольких браузерах или даже на нескольких мобильных устройствах.
Модель предполагает разделение тестов на общие и специальные.
Общие тесты одинаковы для всех браузеров и устройств, тогда как частные тесты специфичны для конкретного браузера или устройства.
Например, при тестировании системы онлайн-платежей, скорее всего, потребуется несколько отдельных тестов, поскольку интерфейсы настольных компьютеров и мобильных устройств часто различаются и протестировать их с помощью одного теста невозможно.
Поэтому мы хотим развивать эту модель и иметь возможность полностью распараллеливать выполнение всех гибридных тестов.
Это означает, что мы сможем запускать параллельно не только тесты веб-интерфейса, но и любые тесты, созданные в нашей системе, в том числе гибридные.
Стоит отметить, что автотесты для StarCrusade уже пригодны для параллельного запуска.
Конечно, для разработки этой модели важно огромное количество моментов вне системы тестирования: структура тестовой среды, выделение аппаратуры для таких тестов и т.д. В настоящее время мы анализируем эти проблемы и пытаемся их систематизировать.
, структурировать их и разработать какое-то оптимальное решение.
Мы также улучшаем тестирование на виртуальных машинах.
Имеем опыт автоматизации тестирования на виртуальных машинах, в т.ч.
в облачных средах.
Сейчас мы также дорабатываем нашу модель для более быстрого, удобного и качественного тестирования, запуская наши гибридные тесты на виртуальных машинах и в облачных средах.
В заключение, мы работаем над самыми разными проектами, и это позволяет нам постоянно совершенствовать и обновлять нашу систему и нашу практику.
Благодаря нашему опыту тестирования продуктов мы предоставляем комплексные услуги по контролю качества клиентских проектов, а четкая структура и логика системы позволяют легко работать в одной команде со специалистами нашего заказчика.
В нашей презентации есть несколько наглядных примеров того, как работает система.
Мы будем рады ответить на все ваши вопросы! Теги: #qa #тестирование #контроль качества #автоматизация тестирования #Разработка игр #Тестирование веб-сервисов #Тестирование мобильных приложений #Тестирование игр
-
Бесплатные Сценарии Фильмов
19 Oct, 24 -
Станция Слежения Дата-Центры Opendns
19 Oct, 24 -
Эффективное Построение Команды
19 Oct, 24 -
Google Переходит На Html 5
19 Oct, 24 -
Microsoft Отзывает Ms13-061
19 Oct, 24 -
Launchy - Маленький, Но Очень Полезный!
19 Oct, 24
