Home

Интересное событие в области обеспечения качества программного обеспечения состоялось 23 марта 2010 года – конференция "Microsoft Quality Assurance Day". Докладчиками конференции выступали ведущие специалисты и эксперты в области обеспечения качества, разработки и тестирования компьютерных приложений. В работе конференции приняли участие представители из многих ведущих компаний: HP, Acceleration, Amphora Group, Arcadia Inc, AVIcode, Bercut, Ltd., Brightconsult, CareerLab, CRIF Russia, Deutsche Bank Ltd., EMC, EPAM Systems, GE Money, Infowatch, Inline Telecom Solutions, Intetics, IT-Online, LG ERP, Mary Kay, Microsoft, Quest Software,RapidSoft, ScrumTrek, Shelmabay, Softline, SQALab, Tri-Media Integrated Marketing Technologies Inc. (Canada), YOTA, Агенство информационных технологий, ВТБ Факторинг, ДубльГИС, ЗАО "АСТ", ЗАО Лаборатория Касперского, ЗАО РАМЭК-ВС, Интетикс, Консалтинговая группа Бизнес-инженер, НИФТИ ННГУ, ОАО "ВымпелКом", ОАО “ИнфоТеКС”, ООО "Автоматизированное обеспечение качества", ООО "Велл Пэй", ООО "ДКС", ООО "Доктор Веб", ООО "ИндаСофт", ООО "НТКФ "Си-Норд", ООО "Прикладные системы", ООО "Ричмедиа", ООО "Стэл КС", ООО "Такском", ООО "Ти Ай Системс", ООО "УСП КомпьюЛинк", ООО «Открытый код», ООО ММТР, Росгосстрах, Софтек Девелопмент, ФГУП «РФЯЦ-ВНИИЭФ», Цезарь Сателлит, Экоклимат, Эльдорадо

Четыре доклада и круглый стол в завершение работы конференции составили ее программу. Освещались актуальные вопросы тестирования программ. Как обеспечить качество программного обеспечения? Какие методы тестирования наиболее популярны и почему? Можно ли автоматически тестировать графический интерфейс и как это делать? Что такое разработка через тестирование или test-driven development (TDD) и behavior driven development (BDD)?

Первым выступал д-р Григорий Мельник, представивший доклад «Стратегические соображения о тестировании и готовности программного обеспечения к эксплуатации» (Strategic thoughts on testing and software readiness).

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

Высказаны соображения и модели для концептуализации тестирования и различных тестовых практик. Подчеркнута важность дизайна ПО под тестирование (design for testability). Освещена роль средств, инструментариев и автоматизации тестирования.

Интересными показались следующие утверждения Григория: «нельзя полагаться на системы обеспечения качества на 100%», «тестеры не занимаются обеспечением качества». Иными словами, обеспечение качества –более широкое понятие, чем это принято считать, оно плотно переплетено со всеми процессами разработки и оптимизируется вокруг не только инженерных, но и экономических и политических критериев.

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

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

Программы пишутся людьми, отсутствие ошибок в программах невозможно, даже в самой простой, печатающей “Hello World!”. Боле того, код из ста строк может генерировать столько комбинаций перебора возможных вариантов по управлению и по данным, что на полное тестирование всех комбинаций не хватит времени жизни вселенной. И это не учитывая различные среды внедрения и интероперабельности с другими системами или устройствами.

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

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

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

Решение о готовности продукта к использованию часто принимается стороной разработки. Однако верным подходом для принятия такого решения будет проведение приемочного тестирования, проводимого пользователями, администраторами или службой поддержки, другими словами, теми, кто непосредственно будет использовать программу. Процесс принятия информационных систем к внедрению в эксплуатацию включает два важных решения: решение о внутренней готовности (readiness) и решение о приёмке и «выпуске в свет» (acceptance). Решение о внутренней готовности производится инженерной командой, перед тем как показать систему или ее часть заказчику. Заказчик производит решение о приемке на основании информации, полученной во время оценки готовности и дополнительного тестирования интегрированных элементов во время приёмки. Существует и третье решение – это решение пользователя о покупке и/или использованию программного продукта. Отзывы в результате подобной оценки уже не могут повлиять на текущий релиз, а могут только учитываться в процессе разработки следующей версии продукта.

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

Существует подход Minimal Marketable Functionality, по которому определяется уровень готовности релиза. Есть минимальное множество приемлемо работающего функционала, при котором целесообразно выводить продукт на рынок (сдавать заказчику).

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

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

• специфицированы и утверждены критерии приемки;
• готовые test scripts (в том числе автоматизированные), демонстрирующие достижения критериев;
• готов код и unit тесты и зарегистрированы в системе контроля версий;
• сервер беспрерывочной сборки успешно производит build;
• документация готова
• тесты (unit, component, system) успешно выполнены;
• проведена демонстрация заказчику;

….

Обычно, большая часть тестирования производится на уровне системного тестирования через пользовательский интерфейс (GUI) в конце производственного цикла. Этот подход не эффективен, так как он приводит к хрупким и медленным тестам, и не обеспечивает раннюю обратную связь. Большой объем бизнес логики может быть протестирован ранее по методику, которую Григорий называет «подкожным тестированием». Для этого, код должен быть разработан с соответствующим API для тестирования. Для повышения качества продукта, количество блочных (unit) тестов должно превышать количество системных или приемочных. Блочные тесты пишутся программистами (желательно до написания кода, в стиле Test-Driven Development) и являются частью их «профессиональной гигиены» (выражаясь словами Григория). Блочные тесты должны охватывать все аспекты реализации и являться фундаментом для более высокоуровневых тестов. В этом случае любые изменения кода будут покрыты тестами самого начального уровня. Тестирование пользовательского интерфейса должно рассматриваться как отдельная задача с использованием специальных методов и инструментария.

Важным аспектом в успешном достижении высокого уровня качества является «качественная автоматизация тестирования». Авто тесты должны быть не просто записанные для воспроизведения, но и параметризованные и разложенные на составные функции (Григорий называет этот метод «Record & Refactor»). Иногда к тестированию полезно привлечь человека со стороны, не давая ему тест скриптов и документации.

А самое главное – это целостность команды и культура разработки. Люди, а не процессы или инструменты делают основной вклад в достигаемый уровень качества.

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

Дмитрий Андреев представлял доклад «Оптимизация производительности и нагрузочное тестирование в среде Visual Studio Team System 2010».

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

Профайлер позволяет получить всевозможные отчеты, интегрирован с кодом, умеет вырабатывать рекомендации по оптимизации кода, поддерживает технологию виртуализации. Можно осуществлять профайлинг слоев приложений, только своего кода, Javascript, конкурентных систем и HPC приложений. Контролируется множество параметров аппаратной и операционной системы: процессор, память, ввод/вывод, SQL запросы и прочее. Отчеты построены в форме руководства к действию по оптимальной производительности и возможности расширения, графики производительности показывают «узкие места», и детали работы, визуализируют стеки вызовов.

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

Есть возможность проводить целевые тесты (Goal Based), создавать комбинации подтестов (Test Mix), анализировать весь спектр индикаторов производительности ОС, подключить данные для контекстного взаимодействия тестов, сроить графики и сохранить результаты для дальнейшего анализа и сравнения, а также расширить функциональность с помощью addons. Нагрузочные тесты проводятся с помощью, так называемых тестовых агентов, управляемых тестовым контроллером, результаты тестов собираются на сервере.

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

Есть возможность записывать действия в Internet Explorer или другом браузере, переводя затем запись в автоматические скрипты для web тестирования.

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

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

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

Следующий доклад «Завтра в тестировании уже наступило или рассказ о том, как догнать разработчиков, используя Microsoft Test and Lab Management» представил Владимир Гусаров. Автор продемонстрировал новую технологию тестирования, которую уже используют в компании Quest Software в настоящее время.

Многие команды тестирования сталкиваются с похожими проблемами. Изменения, о которых не информируют. Необходимость больших изменений в тест скриптах при минимальных изменениях кода. Что, когда и кем тестировалось? Различные среды для воспроизведения у разных участников команды. На какой функционал оказывает влияние изменение кода – что тестировать?

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

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

Test and Lab Management позволяет организовать планирование тестирования, связать требования, код, покрытие тестами. Все это вместе дает точную информацию, что нужно перетестировать при тех или иных изменениях, что уже было протестировано. Изящно организовано управление средами. Можно назначать автоматические и ручные скрипты на исполнение на определенных средах, ведется протокол прохождения тестов. При возникновении ошибок, дефекты с максимальной информацией быстро и удобно заводятся в систему. При воспроизведении проблемы, разработчик может поднять точный snapshot среды, на котором возникла проблема. При автоматическом тестировании дефекты могут заноситься автоматически. Ведутся библиотеки test cases, сред, дефектов.

Тестирование интегрировано с кодом. Связь прослеживается до требований и можно проверять покрытие и протестированность каждого требования. Сценарий сборки включает построение билда, получение отчета о том, какие тесты необходимо повторить из-за изменений в собранном билде (impacted tests). Если эти тесты автоматические они самостоятельно запустятся после сборки.

Все тесты и протоколы их выполнения документированы. В результате, получаем экономию времени при управлении средами, описании дефектов; упрощение ручного тестирования. Результаты тестирования прозрачны, продукт качественнее.

Андреем Бибичевым прочитал доклад: "Behavior-Driven Development (BDD) или элегантные тесты на доменную модель". «Поведенческо-ориентированный» подход к разработке ПО.

При написании unit-тестов на бизнес-логику часто возникают следующие затруднения:

• тестовые методы называются в стиле TestSomeMethod и являют собой длинную простыню хитросплетений разных сценариев для проверки работы одного метода;
• рекомендация держать ровно один Assert на тест не выполняется или приводит к огромному дублированию кода и перегруженности логики в одном тесте;
• при изменении требований не так-то легко найти, какие тесты нужно поправить, и даже найдя их, еще нужно сообразить, что и как поправить в длинном коде;
• по мере развития продукта тестовых методов становится все больше и больше;
• что делать, если у нескольких тестов есть общая часть, - как ее следует оформить?
• как "правильно" называть тесты, как их группировать в тестовые классы?
• значительную часть тестовых методов занимает подготовка и настройка окружения, так что тяжело понять, что же именно проверяется;
• попытки поместить создание всего окружения в SetUp-методы делают тестовые классы путанными, а отдельные тестовые методы зависимыми друг от друга;
• как соотносятся между собой acceptance-критерии выполнения требований и набор unit-тестов?

Не важно, используете ли вы TDD (test-driven) или же пишете тесты после реализации - это перечень общих проблем.

Behavior-Driven Development (BDD) является современной Agile-практикой, позволяющей вывести unit-тестирование на качественно более высокий уровень, решить описанные выше проблемы и вовлечь в процесс создания unit-тестов остальных участников проекта (плюс к разработчикам).

Предлагается основной шаблон тестового метода: “Given, when, then” («дано, когда, тогда»). Имя теста должно быть предложением. Шаблон такого предложения «класс должен делать это». «Поведение» более правильное слово, чем «тест».

Использование шаблона Fluent builder позволяет задавать тестовые данные и окружение в виде красивых, лаконичных и читаемых конструкций языка. Использование собственных (custom) методов проверки (asserts) так же способствует ясности и четкости тестового кода. Цель, которую нужно добиться: код теста должен быть лаконичным, читаемым и не содержать ветвлений и циклов. Тест должен описывать поведение класса!

В докладе приводились примеры кода из реальной практики и решение описанных проблем при помощи BDD. Рассматривается соотношение BDD с Test-Driven Development, Domain-Driven Design, User Stories и Acceptance-критериями.

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

BDD преподносится как agile следующего (второго) поколения. «BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.» by Dan North [Конференция «Agile Specifications, BDD and Testing eXchange», Ноябрь 2009].

Domain-Driven Design (DDD) разработка на основе модели предметной области и бизнес логики. Бизнес логика определяет тестовые методы (unit tests). У подхода DDD три основные аспекта: модель, архитектура, дизайн и проектирование. Для модели используется унифицированный язык. Модель проектируется в классах, у классов есть поведение, которое тестируется по приведенным шаблонам (дано, когда, тогда).

Одновременное использование TDD, BDD, DDD дает синергетический эффект. В заключение доклада был приведен краткий обзор фреймворков для .Net, призванных помочь в следовании BDD.

В довершении конференции, прошел круглый стол, на котором участники могли задать любой вопрос докладчикам, как по прослушанному материалу, так и любой проблеме тестирования или обеспечения качества. Кроме докладчиков к работе круглого стола подключились Евгений Злобин (Microsoft) и Андрей Воронович (MVP, приглашенный эксперт), ведущим был Владимир Гусаров.

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

Прозвучал вопрос об организации тестирования баз данных, не на уровне интерфейса пользователя, а на уровне SQL запросов и их производительности. Обсуждение постановило, что не только команда тестирования борется за качество, а также и другие участники проекта. В данном случае – DBA (Database Administrators) должны прийти на помощь в организации тестов SQL запросов и их производительности. Должно быть осуществлено распределение обязанностей и проведено полное укомплектование команды, чтобы целевой уровень качества достигался эффективно и с минимальными потерями.

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

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

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

Приложение 1.

Состав докладчиков конференции Microsoft Quality Assurance Day 2010.

Григорий Мельник, PhD – Senior Program Manager в команде patterns & practices в Microsoft. В настоящее время руководит проектами Microsoft Enterprise Library и Software Testing Guidance. Его профессиональный опыт – более 15 лет. Как инженер-разработчик ПО, научный сотрудник и профессор университета с более 40 публикациями внёс существенный вклад в развитие современных методов разработки, тестирования и внедрения комплексных программных систем (включая Acceptance Test-Driven Development). Постоянный докладчик на индустриальных конференциях по прикладной математике и методам моделирования и разработки ПО во всем мире. Признанный эксперт в гибких методам (agile), системному тестированию и ПО эволюции. Член Cовета IEEE Software Advisory Board. Автор книги "Acceptance Test Engineering Guide".

Дмитрий Андреев

Эксперт по Архитектуре информационных систем Департамента Стратегических Технологий компании Microsoft. В индустрии с 1996 года, с опытом работы в компаниях специализирующихся на системной интеграции и разработке программного обеспечения. С 2004 года работает в компании Microsoft и имеет опыт внедрения информационных систем во многих крупных российских компаниях.

Владимир Гусаров

Занимается разработкой программного обеспечения в течение 19-ти лет. Он принимал участие в таких проектах как "PDP-11 emulator for Windows NT/DEC Alpha™ Platform", "AMSD Ariadna – First Russian Internet Browser", "C++ Compiler for DEC Alpha™" и других. В настоящее время Владимир руководит разработкой продуктов Recovery Manager for Active Directory и Recovery Manager for Exchange компании Quest Software.

Андрей Бибичев

Работает руководителем отдела технологического развития в компании CustIS. Опыт в разработке коммерческого ПО более дюжины лет. Участвовал в качестве разработчика, тех. лида и PM-а в проектах по созданию корпоративных операционных и операционно-аналитических систем для крупных банков и торговых сетей, расчетно-платежного ПТК для ЖКХ Нижегородской области. Сейчас сконцентрирован на вопросах тех. процесса внутри компании: как на организационной стороне и практиках, так и на создании внутренних библиотек и инструментария.

Выпускник Московского Физико-Технического Института (Факультет Управления и Прикладной Математики).

Приложение 2.

Примеры критериев готовности функциональности (feature) и релиза от Григория Мельника.

Доклад «Стратегические соображения о тестировании и готовности программного обеспечения к эксплуатации» (Strategic thoughts on testing and software readiness).

Критерии готовности функциональности

• The acceptance criteria are specified and agreed upon
• The team has a test/set of tests (preferably automated) that prove the acceptance criteria are met
• The code to make the acceptance tests pass is written
• The unit tests and code are checked in
• The CI server can successfully build the code base
• The acceptance tests pass on the bits the CI server creates
• No other acceptance tests or unit tests are broken
• User documentation is updated
• The product owner signs off on the story

Критерии готовности релиза

• All MMF features are included in the release candidate (RC) build.
• A security review has been conducted.
• Test team is confident that none of the included features has a significant risk of causing problems in the production environment, i.e. MQR is met, incl:
• no Sev 1 or 2 known bugs unsolved
• config testing, side-by-side
• min localizability
• min globalization testing
• accessibility
• user experience
• performance
• Business compliance achieved
• There are clear, concise deployment and rollback instructions for the operations team.
• There are clear trouble-shooting scripts and knowledge base articles for use by the help desk representatives.
• All included features have been demoed to and accepted by the product owner.

Обсудить в форуме