Размещено на http://www.allbest.ru/

Оглавление

• Список терминов и сокращений
• Введение
• Обзор сферы тестирования программного обеспечения
• Статистические данные о рынке ПО
• Стоимость ошибки
• Рынок инструментов тестирования
• Процесс жизненного цикла программной ошибки
• Стадия стабилизации в Microsoft Solution Framework
• Виды нефункционального тестирования
• Разработка навигатора процесса стабилизации
• Описание игры в стабилизацию
• Разработка пространства программного продукта
• Логика работы приложения
• Навигатор процесса стабилизации как бизнес-инструмент
• Заключение
• Библиографический список
• Приложения

Список терминов и сокращений

АО - аппаратное обеспечение.

БД - база данных.

ЖЦ - жизненный цикл.

ИС - информационная система.

ИТ - информационные технологии.

ПО - программное обеспечение.

ПП - программный продукт.

ТЗ - техническое задание.

ЭВМ - электронно-вычислительная машина.

MSF - Microsoft Solution Framework.

PPS - Program Product Space, пространство программного продукта.

SP - Service Pack, пакет обновления.

TDD - Test Driven Design, тест-ориентированная разработка.

Введение

Microsoft Solutions Framework (MSF) - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки программного продукта. В методологии MSF в целом и на стадии стабилизации, в особенности, большое внимание уделяется таким параметрам ИС, как кроссплатформенность, кроссбраузерность, совместимость с различными форматами данных, версиями ПО, удобство использования, производительность при работе на ЭВМ различной мощности, с БД больших объемов, с доступом через глобальную сеть по имеющимся каналам связи и т.д.

Однако, в процессе обучения ИТ-специалистов технологии MSF эти аспекты, как правило, разбираются только на лекциях. При этом практических занятий не проводится ввиду отсутствия необходимого ПО.

Основная проблема состоит в том, что на текущий момент не существует ИС, моделирующей поведение программы во время тестирования.

Объектом исследования является процесс обучения студентов стадии стабилизации методологии MSF.

Предметом исследования является автоматизация организации практических занятий по изучению стадии стабилизации методологии MSF.

Целью работы является разработка ИС, моделирующей поведение "тестируемой программы" на стадии стабилизации для проведения практических занятий.

Для достижения цели были поставлены следующий задачи:

1. Изучить технологию нефункционального тестирования.

2. Изучить подходы к преподаванию нефункционального тестирования.

нефункциональное тестирование программное обеспечение

3. Изучить ИС, способствующие проведению нефункционального тестирования.

4. Спроектировать ИС обучения нефункциональному тестированию.

5. Реализовать ИС обучения нефункциональному тестированию.

6. Провести практическую апробацию разработанной ИС.

Обзор сферы тестирования программного обеспечения

Ключевые понятия

Рассмотрим основные понятия, позволяющие в наибольшей мере раскрыть содержание работы. Первое из ключевых понятий: тестирование. В международном стандарте IEEE дается обобщенное определение этому понятию, которое можно применить не только к сфере ИТ, но и к любой другой системе: "Тестирование - это процесс выполнения или оценки системы или компонента системы вручную или с помощью автоматизированных средств для подтверждения ее соответствия заранее заданным требованиям или для обнаружения различий между ожидаемыми и действительными результатами работы системы (the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results)" [17].

Г. Майерс (Glenford J. Myers) рассматривает термин тестирование, как процесс выполнения программы с целью обнаружения ошибок: "Testing is the process of executing a program with the intent of finding errors" [23]. Похожее определение дает А. Коробейник: "тестирование - это процесс направленный на выявление расхождений между поведением программы и ожиданиями заинтересованных лиц" [7]. Запуск программы непосредственно с целью нахождения ошибки предполагает, в первую очередь, тестирование потенциально ошибкоопасных мест ("отлавливание багов"), до которых пользователь может в принципе не добраться в процессе эксплуатации системы. А в процессе тестирования наиболее важно проверить те места программной системы, которые будут чаще остальных использоваться, особенно в условиях ограниченности времени и ресурсов, когда полная проверка программы невозможна.

Немного отстраненное определение дает Б. Бейзер. Тестирование - проектирование, отладка и выполнение тестов [3]. Данное определение может быть понято лишь непосредственно в контексте работы, соответственно принять ее в рамках нашего исследования мы не можем

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

Другим ключевым понятием является понятие "Информационная система". В электронном словаре BusinessDictionary.com информационная система определяется как "комбинация программного обеспечения, аппаратного обеспечения, инфраструктуры и специально обученного персонала, созданная с целью улучшения функций планирования, контроля, координации и принятия решений в организации. (a combination of hardware, software, infrastructure and trained personnel organized to facilitate planning, control, coordination, and decision making in an organization)" [18].

Похожее определение дают Дж. Валасич (J. Valacich) и К. Шнейдер (C. Schneider). Information systems are combinations of hardware, software, and telecommunications networks that people build and use to collect, create, and distribute useful data, typically in organizational settings [26]. Информационная система - это такая система, состоящая из АО, ПО и системы коммуникаций, созданная людьми для сбора, создания и распространения необходимых данных, в особенности в корпоративном секторе.

В Российских стандартах ГОСТ приводятся различные определения в зависимости от типа и спецификации стандарта. Информационная система - это:

· система, которая организует хранение и манипулирование информацией о предметной области [6].

· совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств [4].

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

Третьим из понятий, определяющих работу, является понятие "бизнес-процесс". В немецкой литературе часто дается следующее определение этому понятию. Бизнес-процесс - это набор специфичных для предприятия и направленных на достижение определенной цели активностей, расположенных в хронологическом порядке. Ein Geschдftsprozess ist eine Menge von unternehmensspezifischen und zielgerichteten Aktivitдten besteht, welche in einem logischen und zeitlichen Zusammenhang stehen [27].

Можно встретить и другие определения:

- бизнес-процесс - это модель, построенная из набора связанных, структурированных действий или задач, которые производят определенный продукт или определенную услугу (преследуют конкретную цель) для конкретного покупателя или потребителя (a business process, or business method, is a model composed by a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers) [19];

- бизнес-процесс - это набор шагов, нацеленных на производство продукта или услуги. Он включает в себя любые виды активностей, дающие определенный результат для конкретного потребителя (внешнего или внутреннего) (a business process is a series of steps designed to produce a product or a service. It includes all the activities that deliver particular results for a given customer (external or internal)) [22].

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

Статистические данные о рынке ПО

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

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

Однако, результаты исследования, проведенного The Standish Group, [16] показывают, что всего чуть больше трети (39%) проектов были завершены успешно, 43% проектов были завершены с превышение бюджета или сроков, либо была сокращена функциональность приложения (см. рис. 1.1). И почти пятая часть (18%) проектов были "провалены".

Успешность реализации ИТ-проектов в 2013 г.

С исторической точки зрения процент успешно завершенных ИТ-проектов растет (см. табл. 1.1), но растет медленно, а их доля остается очень малой. К тому же, количество "проваленных" ИТ-проектов не опускалось ниже уровня 2004 года.

Успешность ИТ-проектов с 2004 по 2012

	2004	2006	2008	2010	2012
Успешно	29%	35%	32%	37%	39%
Провалено	18%	19%	24%	21%	18%
С превышением	53%	46%	44%	42%	43%

Очевидно, компании стремятся улучшить качество создаваемых программных продуктов. Согласно отчету компании WorkSoft: "2013 Trends in Automated Testing" [15] почти половина (45,1%) ошибок остаются незамеченными специалистами по тестированию (см. рис. 1.2).

Соотношение ошибок, найденных в процессе тестирования и в процессе эксплуатации.

Из 594 респондентов, участвовавших в исследовании Worksoft, 204 компании (34,3%) указали, что в 2013 году планируется увеличение инвестиций в автоматизацию тестирования и обеспечение качества. Только четверть респондентов ответили, что не планируют дополнительных инвестиций.

Остальные ответившие не знают о планах в отношении инвестиций в автоматизацию тестирования. Результаты опроса представлены на рис.1.3.



Результаты ответов на вопрос: "Планирует ли ваша компания увеличить инвестирование в автоматизацию тестирования в ближайшие 12 месяцев?".

Учитывая большое число не определившихся с выбором (41, 1%), можно предположить, что некоторые из этих компаний всё же планируют дополнительные инвестиции. Это значит, что настоящее число фирм, планирующих увеличение инвестиций в автоматизацию тестирования в 2013 году, скорее всего больше 34% [10].

В любом случае, исследование показывает увеличение интереса к автоматизации тестирования, которое наблюдается с 2012 года. На текущий момент 74% организаций не используют решения для автоматизированного тестирования, а 53% до сих пор работают при помощи программ общего назначения, таких как Word или Excel [5].

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

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

Стоимость ошибки

Зачем нужно тестировать ПО? Для компании, создающей программные продукты, ошибка в программе - это экономические потери:

1) расходы компании на тестирование и отладку программы. Расходы такого типа поддаются приблизительной оценке;

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

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

1) оплата времени работы специалиста по тестированию;

2) оплата времени работы программиста, который реализовал модуль, содержащий ошибку, а затем исправил ее;

3) стоимость реализации "неправильного" модуля;

4) стоимость тестирования "неправильного" модуля;

5) стоимость исправления ошибки и проблем, появившихся из-за ее наличия.

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

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

1) время службы поддержки;

2) компенсации пользователю понесенных затрат;

3) иски против компании;

4) утраченная потенциальная оплата услуг компании ушедшими пользователями и пользователями, которые могли бы стать клиентами компании, но не стали ими из-за ухудшения репутации.

Такие убытки, как правило, не поддаются объективной оценке.

Но от "неправильных" программ страдают не только производители, но и пользователи, а иногда даже люди, которые не имеют совершенно никакого отношения к программе.

Часто в качестве примера ПО с наиболее губительными последствиями эксплуатации приводятся катастрофа Ariane 5 и инциденты с Therac-25. Ariane 5 - ракета-носитель, запуск которой был произведен 4 июня 1996 года. Полет продлился неполные 40 сек., после чего произошел взрыв [2].

Из-за ошибок в программной части медицинского комплекса Therac_25 минимум шесть человек получили передозировки радиации, некоторые пациенты получили дозы в десятки тысяч рад. Как минимум двое умерли непосредственно от передозировок [20].

В истории РФ также были примеры катастрофических последствий ошибок в программном обеспечении. Например, 5 декабря 2010 года три спутника, критически важные для завершения составления группировки российской навигационной системы ГЛОНАСС - упали в Тихий океан недалеко от Гавайских островов вскоре после их запуска ракетой "Протон-М". Финансовые потери оцениваются в 4 миллиарда рублей. В результате расследования виной аварии была признана ошибка в программировании, которая привела к тому, что в ракету залили неправильное количество топлива. [11]

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

Рынок инструментов тестирования

Рынок инструментов тестирования, в основном, состоит из систем автоматического тестирования.

На рынке присутствуют программные продукты трех видов:

1) коммерческий продукт (WinRunner, Rational Robot, SilkTest, TestComplete и др.);

2) бесплатные и условно-бесплатные инструменты (freeware, shareware);

3) собственные утилиты компаний (написанные в ходе работы над проектами).

Рассмотрим недостатки и преимущества продуктов этих видов. Для сравнения существующих систем были выделены следующие критерии:

1) функциональность;

2) стоимость;

3) гибкость настройки продукта под нужды компании;

4) возможность самостоятельно дорабатывать продукт;

Коммерческие продукты

Преимущества:

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

2) как правило, такие инструменты поставляются со своей собственной средой разработки, которая предоставляет хорошие возможности для написания и отладки автотестов.

Недостатки:

1) высокая стоимость таких продуктов;

2) нет доступа к исходному коду:

a. Если в инструменте обнаруживается ошибка, то его исправление силами поставщика может занять существенное время.

b. Нет возможности оперативно настраивать продукт под нужды компании.

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

Собственные инструменты:

Преимущества:

1) иногда такие инструменты являются побочным результатом создания приложения, особенно в случае TDD (достались бесплатно);

2) о них известно "от и до", их достаточно легко использовать;

3) доступен исходный код.

Недостатки:

1) функциональность таких утилит может быть недостаточной для организации автоматизированных тестов;

2) доработка до полноценной системы тестирования и её поддержка может быть дорогостоящей.

Бесплатные и условно-бесплатные инструменты:

Преимущества:

1) разумная стоимость владения. Продукт доступен либо бесплатно, либо за небольшую, как правило, плату;

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

3) зачастую у подобных утилит доступен исходный код.

Недостатки:

1) функциональность таких продуктов может оказаться недостаточной для решения поставленных задач;

2) существует риск остаться без поддержки со стороны разработчика продукта.

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

Сравнение наиболее распространенных на рынке продуктов представлено в табл. 1.2.

Сравнение продуктов автоматизированного тестирования

Разработчик	Продукт	Функциональное тестирование	Нагрузочное тестирование	Качество кода	Управление тестами
IBM	Rational Robot	+	+	+	+
Borland	SilkTest	+	+	-	+
AutomatedQA	TestComplete	+	+	-	+
HP	WinRunner	+	+	+	+
Open-source	Abbot, Selenium, Watir	Grinder, Jmeter, OpenSTA	GCT, NCover, Cobertura	FitNesse, TestLink

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

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

Процесс жизненного цикла программной ошибки

Жизненным циклом программной ошибки называется промежуток времени между обнаружением ошибки в программном продукте и ее закрытием.

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

Если после проведения повторного (очередного) тестирования ошибка не была обнаружена, то тестировщик "закрывает ошибку", тем самым утверждает завершение работ по исправлению и принятие результата.

Стоит отметить, что после обнаружения несоответствия между спецификацией программы и ее поведением, ошибка может быть отклонена в том случае, если тестировщик ошибся при проведении тестирования, либо если ошибка присутствует, но не в программном коде, а в описании приложения (ТЗ).

Существует 6 различных сценариев прохождения жизненного цикла (см. рис. 1.4).

Сценарий № 1:

1. Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

2. Руководитель проверяет, является ли ситуация, описанная тестировщиком, ошибочной.

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

Сценарий № 2:

1. Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

2. Руководитель оценивает, является ли ситуация, описанная тестировщиком, ошибочной.

ЖЦ программной ошибки.

3. Руководитель подтверждает наличие ошибки в программе и передает заявку на исправление ошибки команде разработчиков с статусом "новая".

4. Руководитель команды разработки (или определенный член команды разработки) проверяет, действительно ли ошибка присутствует в программном коде. Наличие ошибки не подтверждается, заявка передается обратно в отдел тестирования и ожидает отклонения.

5. После того, как получен удовлетворительный ответ от разработчиков, руководитель отдела тестирования отклоняет ошибку.

Сценарий № 3:

1. Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

2. Руководитель отдела тестирования оценивает, является ли описанная ситуация ошибочной.

3. Руководитель отдела тестирования подтверждает наличие ошибки в программе и передает заявку на исправление ошибки команде разработчиков с статусом "новая".

4. Руководитель команды разработки (или определенный член команды разработки) проверяет, действительно ли ошибка присутствует в программном коде. Если наличие ошибки подтверждается, руководитель назначает разработчика для исправления. Статус ошибки изменяется на "Назначена".

5. Разработчик исправляет проблему, переводит ошибку в состояние "Исправлена" и передает ее обратно руководителю отдела разработки.

6. Руководитель команды разработки изменяет статус ошибки на "Ожидает повторного тестирования" и передает ее в отдел тестирования для повторной проверки.

7. Руководитель отдела тестирования изменяет статус ошибки на "Повторное тестирование" и передает ее тестировщику для проведения повторного тестирования.

8. Тестировщик проверяет функционирование программы. Если программа работает корректно, он закрывает ошибку, т.е. устанавливает статус "Закрыта".

Сценарий № 4:

1. Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

2. Руководитель отдела тестирования оценивает, является ли описанная ситуация ошибочной.

3. Руководитель отдела тестирования подтверждает наличие ошибки в программе и передает заявку на исправление ошибки команде разработчиков с статусом "новая".

4. Руководитель команды разработки (или определенный член команды разработки) проверяет, действительно ли ошибка присутствует в программном коде. Если наличие ошибки подтверждается, руководитель назначает разработчика для исправления. Статус ошибки изменяется на "Назначена".

5. Разработчик исправляет проблему, переводит ошибку в состояние "Исправлена" и передает ее обратно руководителю отдела разработки.

6. Руководитель команды разработки изменяет статус ошибки на "Ожидает повторного тестирования" и передает ее в отдел тестирования для повторной проверки.

7. Руководитель отдела тестирования изменяет статус ошибки на "Повторное тестирование" и передает ее тестировщику для проведения повторного тестирования.

8. Тестировщик проверяет функционирование программы. Если ошибка не была исправлена, тестировщик отправляет ее на доработку в отдел разработки.

Сценарий № 5:

1. Специалист по тестированию находит ошибку и сообщает о ней руководителю отдела тестирования.

2. Руководитель отдела тестирования проверяет, является ли описанная ситуация ошибочной.

3. Руководитель отдела тестирования подтверждает наличие ошибки в программе и передает заявку на исправление ошибки команде разработчиков с статусом "новая".

4. Разработчик пытается воспроизвести ошибочную ситуацию, но безрезультатно. После чего обращается к тестировщику за помощью.

5. Тестировщику также не удается повторить описанную ситуацию, и ошибка отклоняется.

Сценарий № 6:

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

Таким образом, ошибка проходит по одному из описанных сценариев, в итоге, завершает прохождение ЖЦ с одним из статусов: "Закрыта", "Отложена" или "Отклонена".

Описание Microsoft Solution Framework

Microsoft Solutions Framework (MSF) представляет собой гибкий подход, который позволяет быстрее создавать технологические решения, задействуя меньшее количество людей, снижая риски и повышая уровень качества. MSF помогает командам направлять силы непосредственно на наиболее распространенные причины неудач технологических проектов, а значит, улучшать показатели успеха проектов, качество решения и бизнес-результаты [8].

Одной из особенностей модели MSF является подход, основанный на вехах (см. рис. 1.5). Вехи - это моменты жизненного цикла проекта, когда полученные на той или иной фазе результаты синхронизируются членами проектной группы друг с другом и с ожиданиями заказчика [21]. В этот момент заказчиком, заинтересованными сторонами и проектной группой производится формальный анализ достигнутого прогресса.

Процесс разработки ПО состоит из 5 стадий (см. рис. 1.5):

1) стадия выработки концепции;

2) стадия планирования;

3) стадия разработки;

4) стадия стабилизации;

5) стадия внедрения.

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

Фазы и вехи модели процессов MSF.

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

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

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

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

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

Проектная группа MSF состоит из 6 ролевых кластеров - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции и связанные с ними цели и задачи. Подробное описание ролевых кластеров приведено в табл. 1.3.

Описание ролевых кластеров MSF

Ролевой кластер	Цель	Область компетенции	Функции
Управление продуктом	Удовлетворенные заказчики	Маркетинг Бизнес-отдача (бизнес-приоритеты) Представление интересов заказчика Планирование продукта	Выступает в роли представителя заказчика Формирует общее видение/рамки проекта Организует работу с требованиями заказчика Развивает сферы применения в бизнесе Формирует ожидания заказчика Определяет компромиссы между параметрами "возможности продукта / время / ресурсы" Организует маркетинг, PR и евангелизацию Разрабатывает, поддерживает и исполняет план коммуникаций
Управление программой	Достижение результата в рамках проектных ограничений	Управление проектом Выработка архитектуры решения Контроль производственного процесса Административные службы	Управляет процессом разработки с целью получения готового продукта в отведенные сроки Формулирует спецификацию продукта и разрабатывает его архитектуру Регулирует взаимоотношения и коммуникацию внутри проектной группы Следит за временным графиком проекта и готовит отчетность о его состоянии Проводит в жизнь важные компромиссные решения Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта Организует управление рисками
Разработка	Создание продукта в соответствии со спецификацией	Технологическое консультирование Проектирование и осуществление реализации Разработка приложений Разработка инфраструктуры	Определяет детали физического дизайна Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна Разрабатывает или контролирует разработку элементов Подготавливает продукт к внедрению Консультирует команду по технологическим вопросам
Тестирование	Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены	Планирование тестов Разработка тестов Отчетность по тестам	Обеспечивает обнаружение всех дефектов Разрабатывает стратегию и планы тестирования Осуществляет тестирование
Удовлетворение потребителя	Повышение эффективности пользователя, увеличение потребительской ценности продукта	Обеспечение технической поддержки Обучение Эргономика Графический дизайн Интернационализация Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)	Представляет интересы потребителя в команде Организует работу с требованиями пользователя Проектирует и разрабатывает системы поддержки производительности Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта Определяет требования к системе помощи и её содержание Разрабатывает учебные материалы и осуществляет обучение пользователей
Управление выпуском	Беспроблемное внедрение и сопровождение продукта	Инфраструктура Сопровождение Бизнес-процессы Управление выпуском готового продукта	Представляет интересы отделов поставки и обслуживания продукта Организует снабжение проектной группы Организует внедрение продукта Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта Организует сопровождение и инфраструктуру поставки Организует логистическое обеспечение проектной группы

Стадия стабилизации в Microsoft Solution Framework

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

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

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

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

Суть точки конвергенции.

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

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

Точка достижения нуля.

После завершения тестирования наступает момент, когда решение "столкнется" с производственной средой, и проектная группа должна как можно тщательнее оттестировать решение до этого момента, - до начала испытания пилотного выпуска.

К вехе "Контрольное тестирование завершено" проектная группа должна:

1. Оценить результаты тестирования в соответствии с имеющимися критериями успешности.

2. Подготовить среду внедрения.

3. Создать необходимые для внедрения процедуры, скрипты и массивы данных.

4. Иметь готовые учебные материалы.

5. Обеспечить условия для сопровождения решения.

6. Создать и протестировать план "отката".

Данная веха может считаться пройденной лишь после обретения проектной группой полной уверенности в готовности и отлаженности всего, что необходимо для внедрения решения.

Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения [21].

Для пилотной группы подготавливается и выпускается серия версий-кандидатов. Выпуск каждой из них является промежуточной вехой. Эти версии имеют следующие особенности:

1. Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство.

2. Создание версии-кандидата служит тестом готовности решения к выпуску, то есть проверяет готовность всех его составляющих.

3. Период тестирования, следующий за созданием каждой версии-кандидата, определяет, пригодна ли созданная версия к внедрению, или же проектная группа должна подготовить новую версию-кандидат, исправляющую недостатки предыдущей.

4. Тестирование версий-кандидатов, проходящее внутри проектной группы, требует высокой степени концентрации и интенсивности работы и фокусируется на выявлении критических "накладок".

5. Тестирование сопряжено с процессом приоритезации всех нововыявленных ошибок, необходимым для организации их устранения.

6. Маловероятно, что первая версия-кандидат окажется заключительной. Как правило, при интенсивном тестировании версий-кандидатов будут выявлены "накладки".

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

1. На предприятии это может быть релиз для группы пользователей или подмножества серверов данных.

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

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

Общим для всех этих форм предварительно выпуска является максимальное приближение тестирования к реальным условиям.

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

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

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

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

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

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

6. Шаг вперед: пилотное внедрение нового релиза.

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

8. Приостановка: пилотная версия "замораживается".

9. Исправление и продолжение: пилотная группа получает "заплату" к существующему коду.

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

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

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

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

Фаза стабилизации завершается вехой "Готовность решения утверждена". К моменту наступления этой вехи проектная группа завершает разрешение всех существенных проблем и производится выпуск или внедрение решения. Ответственность за непрерывное управление и поддержку решения формально переходит от проектной группы к командам сопровождения.

Виды нефункционального тестирования

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

Перечень нефункционального тестирования, составленный на основе ISO/IEC 9126, представлен на рис. 1.8.

Компоненты нефункционального тестирования.

Тестирование интерфейса пользователя (UI testing).

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

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

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

Тестирование локализации (localization testing).

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

Тестирование скорости и надежности. (load/stress/performance testing)

Это проверка поведения программы (или ее отдельных частей) при одновременном использовании множеством пользователей.

У каждого, кто пользуется Интернетом, есть опыт ожидания, когда, например, кликаешь на ссылку, и следующая страница загружается крайне медленно.

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

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

Тестирование безопасности (security testing)

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

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

Тестирование удобства использования (usability testing).

Тестирование опыта пользователя призвано объективно оценить опыт пользователя (user experience), который будет работать с разрабатываемым интерфейсом. Юзабилити-тестирование часто проводится путем привлечения группы потенциальных пользователей с целью собрать впечатления от работы с системой.

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

Также при юзабилити-тестировании проверяется интуитивность интерфейса.

Тестирование совместимости (compatibility testing).

Тестирование совместимости - это проверка того, как программа взаимодействует с:

1) аппаратным обеспечением;

2) ПО (браузерами/операционными системами) пользователей.

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

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

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

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

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

Кроме того, в этой главе была рассмотрена методология MSF и стадия стабилизации и приведено обоснование перехода от оперирования термином "тестирование" к использованию термина "стабилизация".

Разработка навигатора процесса стабилизации

Для проверки основных идей и определения требований к разрабатываемой ИС на втором курсе программной инженерии была проведена деловая игра в стабилизацию.

Описание игры в стабилизацию

В игре вводится некий холдинг Обалдеит, имеющий 4 подразделения. Фирма не имеет централизованной информационной системы. Информационное обеспечение деятельности каждое территориальное отделение организует самостоятельно с учетом имеющихся ресурсов и потребностей. Обмен информацией с центральным офисом фирмы происходит нерегулярно. Единый регламент отсутствует. Каждое территориальное отделение действует по-своему, с учетом имеющихся возможностей. Что серьезно затрудняет деятельность фирмы как единого целого и снижает ее конкурентоспособность как на внутреннем, так и на международном рынке.

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

В игре считается, что ИС "ОбладеИТ" уже была разработана. На текущий момент инициирована стадия стабилизации. Студент играет роль специалиста по тестированию (ролевой кластер "Тестирование"), т.е. в его задачи входит тестирование программного продукта и сообщение об ошибках разработчикам.

Для проведения деловой игры были подготовлены гиперкуб с заранее расставленными ошибками и техническое задание (не лучшего качества), описывающее программный комплекс для холдинга "Обалдеит". Цель работы студентов - добиться приемлемого с точки зрения пользователя поведения программы.

Специалист по тестированию (студент) тестирует программу (см. рис. 2.1): подготавливает конфигурацию, прогоняет набор тестов, получает некоторый ответ.



Процесс тестирования с точки зрения деловой игры в стабилизацию.

После чего тестировщик должен задокументировать полученные результаты, проанализировать и, если была обнаружена ошибка, передать "программисту" (реально программиста в игре не существует). На построение и прогон тестов тратится модельное время. Это позволит вести работу "во времени", считать количество ошибок, обнаруженных каждый день, отслеживать их увеличение или уменьшение и т.п.

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

На процесс тестирования отведено фиксированное количество модельного времени. Игра завершается либо по причине полной готовности ИС, либо по истечению отведенного на нее модельного времени.

Проведение игры в стабилизацию.

Деловая игра в стабилизацию проводилась с использованием "бумажного" прототипа будущей ИС. "Бумажный" прототип использовался для определения того, что должно быть включено в обучающий инструмент в первую очередь, реализацию чего можно немного отложить, от каких идей лучше отказаться (или пока отказаться) и т.д.

"Бумажный" прототип являлся моделью пространства программного продукта (в виде многомерного куба) в программе Excel. Все операции проводились "вручную".

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

По итогам проведения деловой игры были получены следующие результаты:

1) Были выявлены недостатки "бумажной" модели:

a) составление пространства программного продукта требует значительных трудозатрат;

b) проверка (запуск набора тестов и получение результатов) проходит довольно медленно, что приводит к формированию очередей и потере большого количества времени;

c) отслеживание версионности (поставки версий программ) отдельно для каждой команды практически невозможно;

2) количество измерений гиперкуба увеличилось примерно в 2 раза;

3) определен механизм взаимодействия программы со студентами;

4) определен способ представления результатов тестирования (в частности, внедрен и апробирован механизм сообщений).

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

1) студенты на практике поняли, что такое тестирование и как надо действовать при тестировании программ;

2) студенты на практике ощутили, к чему приводят допущенные в ТЗ неточности спецификации программного продукта;

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

Однако, были и отрицательные моменты:

1) количество организаторов меньше, чем количество студентов, из-за чего участники игры иногда оставались незадействованными, а непосредственно игра затягивалась;

2) игра дорабатывалась по ходу ее проведения, вводимые изменения иногда приводили студентов в замешательство.

Рефлексии студентов приведены в приложении С.

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

Разработка пространства программного продукта