Экономическая эффективность внедрения технологии автоматизированного тестирования

- операционная прибыль, рассчитанная не по GAAP, составила $158,7 миллиона, что на 28,9% больше, чем в конце 2014 года;

- разводненная прибыль на одну акцию (EPS) по GAAP составила $1,62 (для сравнения в конце 2014 года - $1,40);

- разводненная прибыль на одну акцию (EPS), рассчитанная не по GAAP, равна $2,73 (в 2014 году - $2,22).

Приток денежных средств от основной деятельности за 3 квартал 2012 года составил $76,4 миллиона. По состоянию на 31 декабря 2015 года в распоряжении EPAM Systems находится $199,4 миллиона денежных средств и их эквивалентов. [6]

Финансовый прогноз на 2016 год:

- выручка в 1 квартале 2016 прогнозируется на уровне минимум $258 миллионов;

- разводненная прибыль на акцию (EPS), рассчитанная не по GAAP, в 1 квартале 2016 года ожидается в диапазоне $0.7-$0.8. Эти оценки получены из расчета, что средневзвешенное количество разводненных акций в 2016 финансовом году составит 53 миллиона;

- рост чистой прибыли, рассчитанной не по GAAP, ожидается на уровне 20%. [7]

2.2 Информационное обеспечение ИООО "ЭПАМ Системз"

У каждого сотрудника предприятия есть в пользовании компьютер. В подразделениях технические характеристики компьютеров различаются. В ходе практики нам была предоставлена возможность работать с компьютерами со следующими техническими характеристиками: скорость процессора 3.5 ГГц, оперативная память - 16 ГБ ОЗУ.

Предприятие пользуется операционной системой - Microsoft Windows 7 Professional. На некоторых компьютерах предприятия установлена ОС Linux.

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

Программы, которые используются на предприятии это Microsoft Office Word, Microsoft Office Excel, Microsoft Office Access, Microsoft Outlook.

Также активно используются следующие web-браузеры: Google Chrome, Mozilla Firefox, Internet Explorer, Opera, Safari.

Для связи используется Skype, ZoIPer softphone, X-Lite softphone, Webex.

Zoiper Classic - Клиент IP-телефонии с поддержкой протоколов IAX и SIP. Бесплатная Версия. Поддерживает различные языки.

X-Lite - Клиент IP-телефонии. Совмещает в себе голосовые звонки, видеосвязь и мгновенные сообщения, поддерживает интернет-звонки, в том числе и на обычные телефоны, через различных операторов IP-телефонии.

MySQL - свободная система управления базами данных (СУБД). MySQL является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. [5]

Также для контроля и хранения кодов разрабатываемого ПО используется SVN (Subversion) -- свободная централизованная система управления версиями. Хранилище может располагаться на локальном диске или на сетевом сервере. Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. При сохранении новых версий система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.

Для разработки также используются: Microsoft Visual Studio, Eclipse.

Microsoft Visual Studio -- линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight.[6]

Eclipse -- свободная интегрированная среда разработки модульных кроссплатформенных приложений. Развивается и поддерживается Eclipse Foundation. Является мультиязычной. Также он представляет собой расширяемый на основе плагинов фреймворк. [7]

Также имеются следующие корпоративные системы:

1) PMC (Project Management Center) - Центр Управления Проектами - программное решение, которое упрощает планирование проекта, управление рисками, создание программного обеспечения, контроль качества продукции, количественное управление проектами и анализ эффективности процессов.

EPAM PMC отвечает требованиям международных стандартов качества и объединяет в себе передовые ИТ-практики в области управления проектами.

Рисунок 2.7 - Система PMC

Примечание - Источник: [9].

2) UPSA (EPAM Utilization and Project Staffing Analyzer) представляет собой автоматизированную среду для выполнения различных задач, связанных с управлением персоналом компании, создания необходимых условий для привлечения новых людей; планирования загрузки персонала на проектах. Система UPSA тесно интегрирована с PMC.У каждого проекта в ЕПАМ тоже есть свой профайл в UPSA.

UPSA обладает следующими возможностями:

- управление информацией, касающейся производственной деятельности и эффективности сотрудников компании;

- осуществление проектного планирования в части управления человеческими ресурсами;

- анализ и управление рабочей нагрузкой сотрудников Организации.

- эффективное управление сотрудниками «on the bench»;

- оценка сотрудников проектных команд;

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

- отчетность (в том числе различные типы отчетов, связанных с деятельностью сотрудников).

Рисунок 2.8 - Система UPSA: главная страница

Примечание - Источник: [9].



Рисунок 2.9 - Система UPSA: закладка навыков сотрудника

Примечание - Источник: [9].

3) CTC (Cost Tracking Center) представляет собой веб-приложение для сбора и контроля информации о расходах Компании.

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

Рисунок 2.10 - Система CTC

Примечание - Источник: [9].



4) EPAM Process Asset Library (PAL) -- внутренний информационный ресурс, который создан для доступа к утвержденным и действующим в EPAMSystems документам Системы Менеджмента Качества (QMS), т.е. документам, которые регламентируют деятельность компании.

Рисунок 2.11 - Система PAL

Примечание - Источник: [9].

2.3 Анализ процесса автоматизации тестирования программного обеспечения в компании

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

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

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

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

«EPAM» Systems, обеспечивает необходимые ресурсы для проведения тестирования, а в частности ресурсный менеджер, руководствуясь описанием процесса менеджмента проекта, занимается поиском и выделением сотрудников.

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

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

Существует также определенное распределение ролей и обязанностей.

Проектный менеджер либо координатор проекта ответственен за следующее:

- контроль выполнения основных принципов тестирования принятых в компании;

- установление ожиданий от процесса тестирования, которые должны выполнятся;

- прослеживание затраченных средств, в процессе проведения тестирования;

- тестовая документация, экспертные оценки, утверждение документов;

- текущий анализ результатов тестирования рабочего продукта;

- доведения сведений о процессе тестирования до высшего руководства.

- руководитель группы тестирования ответственен за следующее:

- контроль выполнения основных принципов тестирования принятых в компании;

- оценка, планирование, назначение ответственных и контроль за выполнением членами команды тестирования поставленных задач;

- составление плана тестирования;

- экспертная оценка составленных тест кейсов;

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

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

- создание и публикация результатов проведения тестирования;

- сбор информации о готовности продукта к передаче заказчику.

В обязанности тестировщика (специалиста по тестированию) входит следующее:

- соблюдение основных принципов тестирования, принятых в компании;

- спецификация тесткейсов;

- экспертная оценка составленных тест кейсов;

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

- анализ причины, вызвавшей дефекты;

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

Входящая информация:

- спецификация требований для рабочих продуктов (клиентские и технические требования) и вся связанная с проектом документация;

- список осуществленных изменений (новые требования, исправленные дефекты) для тестирования программного обеспечения;

- проектная документация (в особенности генеральный план и план гарантии качества);

- версии рабочих продуктов.

Основными показатели для начала процесса тестирования являются:

- запуск проекта;

- предоставление доступа команде к начальным требованиям;

- окончание набора членов команды имеющих достаточную компетентность для выполнения тестирования.

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

Выходные данные процесса тестирования следующие:

- тестплан;

- тесткейсы;

- результаты тестирования (необработанные);

- отчеты о результатах тестирования;

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

- дефекты (ошибки) приложения, занесённые в систему, отслеживающую дефекты;

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

Существуют следующие этапы тестирования программного продукта:

- планирование тестирования;

- этап дизайна тестов;

- выполнение тестирования;

- оценка и анализ результатов тестирования.

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

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

- критерии оценки качества продукта;

- критерии приёмки продукта;

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

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

- описание тестового окружения (включая описание входных данных для тестирования);

- описание выделенных ресурсов;

- график тестирования и основные вехи;

- измерения.

Руководитель группы тестирования предоставляет план тестирования проектному менеджеру для утверждения. Проектный менеджер проводит обзор тест плана с соответствующими заинтересованными лицами (Проектной группой и/или клиентами и/или пользователями), и на основании результатов обзора одобряет или отклоняет тестплан. После утверждения тест плана руководитель группы тестирования размещает его в системе управления конфигурацией проекта. [9]

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

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

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

После получения новой версии продукта, команда тестирования приступает к этапу выполнения тестирования:

- проверяет соответствие версии продукта проектной документации;

- проводит установку продукта на тестовое окружение;

- выполнение приёмочного теста.

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

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

Отметим возможные результаты тестирования:

- успешно пройден;

- не пройден;

- продукт не пригодный для тестирования.

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

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

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

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

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

Уровень квалификации специалистов для участия в процессе должен обеспечивать предоставление в результате качественного продукта отвечающего всем требованиям заказчика. В рассматриваемом случае команды из 7 человек является наличие 3-х специалистов высокой квалификации (senior level), 3-ёх средней квалификации (middle level) и 1-го специалиста начального уровня (junior).

2.4 Регрессионная модель анализа зависимости выручки компании от численности занятых

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

Источниками формирования денежных доходов выступают:

- выручка от реализации продукции, товаров (работ, услуг);

- операционные доходы;

- внереализационные доходы.

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

Рисунок 2.12 - Выручка ИООО «ЭПАМ Системз» поквартальная 2011-2015

Примечание - Источник: [10].

Своевременное поступление выручки - непременное условие непрерывного процесса производства.

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

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

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

Выручка - это еще не доход, но источник возмещения затраченных на производство продукции средств и формирования денежных фондов и финансовых резервов предприятия. В результате использования выручки из нее выделяются качественно разные составные части созданной стоимости.Затраты -- размер ресурсов (для упрощения измеренных в денежной форме), использованных в процессе хозяйственной деятельности за определённый временной промежуток. Иначе говоря, затраты -- это стоимостная оценка ресурсов. Одной из статей формирования затрат предприятия являются затраты по оплате труда, размер которых в свою очередь определяется численностью сотрудников. Отсюда следует, что размер выручки зависит от числа сотрудников предприятия.

Имеем поквартальные данные по выручке от оказания ИТ-услуг, расходов и численности ИТ-специалистов за 2009-2015гг. Требуется исследовать зависимость выручки от числа занятых и расходов, а также сделать прогноз по выручке на 1 квартал 2016 г, если в 1 квартале 2016 г планируется нанять ещё 300 ИТ-специалистов. Исходные данные представлены в таблице 2.1.

Таблица 2.1 - Исходные данные

Период	y - доходы от ИТ-услуг, тыс. $	-расходы компании, тыс. $	-численность ИТ-персонала, тыс. чел
1 квартал 2009	35 300,00	19 500,00	2,62
2 квартал 2009	36 100,00	20 000,00	3,10
3 квартал 2009	38 700,00	20 200,00	3,50
4 квартал 2009	39 800,00	27 600,00	3,78
1 квартал 2010	40 300,00	25 100,00	4,35
2 квартал 2010	52 000,00	21 400,00	4,77
3 квартал 2010	57 400,00	21 300,00	5,02
4 квартал 2010	72 100,00	34 200,00	5,35
1 квартал 2011	70 800,00	26 700,00	5,75
2 квартал 2011	80 600,00	35 400,00	6,09
3 квартал 2011	87 900,00	38 200,00	6,35
4 квартал 2011	95 200,00	51 200,00	6,97
1 квартал 2012	93 100,00	72 000,00	7,48
2 квартал 2012	103 900,00	88 100,00	7,79
3 квартал 2012	110 100,00	97 200,00	8,12
4 квартал 2012	126 700,00	102 700,00	8,50
1 квартал 2013	124 200,00	106 100,00	8,72
2 квартал 2013	133 200,00	112 100,00	8,89
3 квартал 2013	140 200,00	117 000,00	9,07
4 квартал 2013	157 600,00	131 000,00	9,34
1 квартал 2014	160 400,00	135 300,00	9,76
2 квартал 2014	174 700,00	148 300,00	10,99
3 квартал 2014	192 800,00	163 500,00	11,44
4 квартал 2014	202 200,00	166 000,00	11,79
1 квартал 2015	200 000,00	167 900,00	12,67
2 квартал 2015	217 800,00	181 900,00	13,25
3 квартал 2015	236 000,00	196 300,00	14,00
4 квартал 2015	260 300,00	215 100,00	16,08

Примечание - Источник: собственная разработка.

Вначале необходимо осуществить выбор факторных признаков для построения регрессионной модели. Используем инструмент КОРРЕЛЯЦИЯ. В результате получим матрицу коэффициентов парной корреляции:

Рисунок 2.13 - Матрица корреляции

Примечание - Источник: собственная разработка.

Проведём анализ коэффициентов. Зависимая переменная y имеет тесную связь с обоими факторами. Однако коэффициент свидетельствует о наличии мультиколлинеарности, а значит, один из факторов необходимо исключить. Исключим фактор , т.к. он меньше влияет на y. В результате будем рассматривать однофакторную модель зависимости доходов компании y от численности занятых x.

Решим данную задачу с помощью приложения Excel пакета MS Office.

Занесём статистические данные в электронную таблицу по столбцам.

Построим уравнение регрессии, описывающее зависимость между независимым фактором x и результативным фактором y. Оценим качество уравнения регрессии, статистическую значимость его параметров и уравнения в целом. Для этого вызовем функцию РЕГРЕССИЯ. Зададим входной интервал Y - столбец с выручкой - и входной интервал X - столбец с числом занятых. Выведем протокол регрессионного анализа.

Рисунок 2.14 - Протокол регрессионного анализа

Примечание - Источник: собственная разработка.

Согласно результатам расчётов, получено следующее уравнение регрессии:

Для оценки статистической значимости параметров и уравнения в целом рассчитаем статистики Стьюдента и Фишера F. При заданных степенях распределения , F = 4,225.

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

Перед прогнозированием проверим остатки уравнения регрессии на гетердоскедастичность.

Проверим выполнение одной из предпосылок МНК - постоянство дисперсий остатков уравнения регрессии. График остатков показывает, что остатки гомоскедастичны.

Чтобы проверить данное предположение, проведём тест Голдфелда-Квандта, для чего вначале отсортируем исходные табличные данные по переменной x. Исключим из рассмотрения 10 средних наблюдений, т.е. примерно третью часть от общего числа. Останутся 1 и 3 группы.

Рисунок 2.15 - Остатки уравнения регрессии

Примечание - Источник: собственная разработка.

Рисунок 2.16 - График остатков уравнения регрессии

Примечание - Источник: собственная разработка.

Рисунок 2.17 - 1 и 3 группы данных

Примечание - Источник: собственная разработка.

Построим регрессию по данным группам наблюдений. Вычислим отношение большей суммы квадратов остатков регрессии к большей.

где - сумма квадратов остатков регрессии по 1 группе

- сумма квадратов остатков регрессии по 3 группе

Найдём для уровня значимости 0,05 и степеней свободы 28-1-1=26.



А значит, остатки регрессии гомоскедастичны.

Выполним точечный прогноз результативного показателя по полученному уравнению регрессии. Согласно плану ИООО собирается в 1 квартале 2016 года увеличить численность ИТ-сотрудников на 300 человек. Т.е. x=16,38 тыс. чел. Тогда выручка в 1 квартале 2016 года должна составить:

Таким образом, в 1 квартале 2016 выручка от реализации ИТ-услуг при условии найма 300 ИТ-специалистов дополнительно составит около 274532,08 тыс. $.

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

Рисунок 2.18 - Полиномиальная модель

Примечание - Источник: собственная разработка.



Полиномиальное уравнение:

Точечный прогноз объёма выручки на 1 квартал 2016 года (29 значение) составит:

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



3. Экономическая эффективность внедрения программного продукта типа Framework

3.1 Функциональное и автоматизированное тестирование в управлении ИТ-процессами на проекте

На любом ИТ-проекте необходимым элементом является система контроля версий (System Version Control), в которой хранятся как тест-кейсы для ручного тестирования, так и для автоматизации. На данном проекте используется система Team Foundation Server (TFS). TFS представляет собой элемент интегрированной среды разработки VisualStudio, обеспечивающий репозиторий контроля кода, контроль над рабочими элементами и службы отчетности. Стоит отметить, что после внесения изменений локально во фреймворк, изменения через специальное средство контроля версий TFS вносятся и во фреймворк, доступный всем пользователям. [15][16]

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

TestComplete - коммерческий инструмент для автоматизации тестирования как браузерных, так и десктопных приложений. Для разработки автоматизированных тестов TestComplete использует язык JScript, Delphi, C#Script, и поддерживает следующие технологии: Webservices, MacromediaFlex, Ajax, Delphi, .NET, J2EEWeb, VisualBasic, ActiveX, Java, Oracle, Silverlight, Adobe.[13]

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

Соответственно при выборе данного средства менеджеры проекта руководствовались тем, что:

- TestComplete поддерживает работу с web-объектами, windows- объектами, web-сервисами.

- TestComplete легко интегрируется с существующей системой хранения тестов QC.

- Изменение тестов происходит путём их открытия в TestComplete.

- Есть возможность проводить изменения тестового фреймворка через TestComplete, путём их присоединения к существующему тесту.

- TestComplete - достаточно недорогой инструмент.

В результате проведённого анализа решением в рамках рассматриваемого процесса является предложение использования автоматизированного тестирования.

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

- принятие решения об автоматизации;

- выбор инструментальных средств тестирования;

- внедрение автоматизированного тестирования;

- планирование проектирование и разработка тестирования;

- выполнение и управление автоматизированным тестированием;

- оценка и усовершенствование процесса.

Этап принятия решения означает осознание объективной необходимости применения подхода к существующему процессу.



Рисунок 3.1 - Структура тестового фреймворка

Примечание - Источник: собственная разработка.

3.2 Сравнительная оценка эффективности внедрения технологии автоматизированного тестирования с использованием методов многокритериальной оптимизации

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

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

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

- Минимизация денежных затрат на проведение тестирования

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

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

(3.1)

Обозначим - целевая функция на минимум времени, - целевая функция на максимум доходов.

Введём коэффициенты целевых функций:

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

- время, затраченное инженером по автоматизации на выполнение полученных заданий (тасков);

- доход от использования тестировщика на проекте;

- доход от использования автоматизатора на проекте.

Отметим, что показатели дохода являются средней величиной, т.е. не ранжируется по стажу сотрудника.

Тогда целевые функции для нашей задачи примут вид:

(3.2)

(3.3)

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

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

С учётом этого, необходимо дополнить нашу задачу следующими ограничениями:



(3.3)

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

(3.4)

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

Объединим выведенные нами ограничения и запишем общий вид оптимизационной модели:

(3.5)

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

Таблица 3.1 - Исходные данные задачи

7	2	800	1200	113	32	500	250	15

Примечание - Источник: собственная разработка.

Перезапишем систему (1) с учётом имеющихся данных:

(3.6)

Решим данную задачу, используя математический инструмент Matlab.

Для решения задач целочисленного линейного программирования в Matlab используется функция intlinprog, которая имеет следующий вид:

[x,fval,exitflag,output] = intlinprog(f,intcon,A,b,Aeq,beq,lb,ub,options) (3.7)

Здесь intcon - вектор целочиселенности переменных, A - матрица коэффициентов при переменных системы, b - правая часть системы, lb - нижняя граница значений переменных системы, exitflag - показатель, равенство которого значению 1 означает успешное нахождение оптимального решения и окончание задачи. Функция intlinprog решает задачу на минимум.

Запишем код программы:

Используем функцию intlinprog для поиска решения по первому критерию:

Получим следующий результат:

Optimal solution found.

И затем по второму критерию:

[x,fval2,exitflag,output] = intlinprog(f2,intcon,A,b,[],[],lb)

Получим следующий результат:

Optimal solution found.



Рисунок 3.2 - Исходный код программы

Примечание - Источник: собственная разработка.

Как видно, решения по первому и второму критерию совпали не полностью, т.е. следует искать компромиссное решение.

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

Дополним код нашей программы:

Aeq =

[f1'/fval1-f2'/fval2];

%новое ограничение

beq =

2;

%его правая часть

И оптимальное решение будем искать так:

[x3,fval3,exitflag,output] = linprog(-f2,A,b,Aeq,beq,lb)

Пересчитаем целевые функции:

f31 =

f1*x3

%новое значение первой целевой функции

f32 =

f2*x3

%новое значение второй целевой функции

Получим следующий результат:

x3 =

4

10

f31 =

50

f32 =

16400

Рисунок 3.3 - Обновлённый код программы

Примечание - Источник: собственная разработка.



Итак, согласно полученному решению, оптимальным является состав команды из 4 мануальных тестировщиков и 10 автоматизаторов. При этом затраченное время на выполнение работы составит 50 единиц времени, а доходы компании 16400. Условия задачи соблюдены полностью, решение удовлетворяет заданным ограничениям. Также данное решение позволяет перевыполнить план в случае необходимости на 70 автоматизированных тестов. Т.е. наблюдается создание некоторого резерва на случай изменений в плане тестирования в сторону увеличения количества тестов. Видно также, что в связи с этим нецелесообразно увеличивать количество сотрудников до допустимого значения, т.к. намеченные задачи выполняются полностью. Также видно, что выполняется на 50 ручных тестов меньше, чем требуется по условию задачи. Однако специфика тестирования такова, что в случае, если мануальные тестировщики не укладываются в сроки с выполнением всех своих тестов, менеджер принимает решение о привлечении автоматизаторов к ручному тестированию. Это экономически выгодней для компании, чем нанимать дополнительную штатную единицу, т.к. в этом случае возрастают расходы на оплату труда. Обычно количество таких тестов достаточно небольшое, чтобы распределить их между всеми автоматизаторами без потерь времени и финансов.

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

Максимальный доход компании:

А ограничение на количество тестов:

Т.е. существенно возрастают затраты времени и снижаются доходы компании.

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

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

Заключение

Проведенное исследование позволяет сделать некоторые выводы.

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

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

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

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

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

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

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

Для участия в процессе разработки продуктов организовываются команды для различных модулей разрабатываемого продукта, такие команды состоят в основном из 3-ёх программистов, 2-ух специалистов тестирования, и 2-ух специалистов для автоматизированного тестирования.

Уровень квалификации специалистов для участия в процессе должен обеспечивать предоставление в результате качественного продукта, отвечающего всем требованиям заказчика. В рассматриваемом случае команды из 7 человек является наличие 3-ёх специалистов высокой квалификации (senior level), 3-ёх средней квалификации (middle level) и 1-го специалиста начального уровня (junior).

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

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

- выбранный инструмент автоматизации должен поддерживать работу с web-объектами;

- также поддержка работы с windows объектами т.к. существуют определённые windows приложения, через которые идёт настройка интерфейса

- возможность работы с web-сервисами, которые также входят в состав рассматриваемого приложения;

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

- должна быть использована система для отслеживания изменений в тестах;

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

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

программный автоматизация экономический архитектура



Список использованных источников

1 Тестирование программного обеспечения - основные понятия и определения//Про Тестинг [Электронный ресурс].- Дата доступа: 24.04.2016.

2 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению: СТБ ИСО/МЭК 12119-2003. - Введён 01.11.2003. -Минск: Государственный комитет по стандартизации Республики Беларусь, 2003. - 16с.

3 Информационные технологии. Пакеты программ. Требования к качеству и тестирование: СТБ ИСО/МЭК 9126-2003. - Введён 01.11.2003. -Минск: Государственный комитет по стандартизации Республики Беларусь, 2003. - 28с.

4 Автоматизация тестирования//Компания Qulix QA [Электронный ресурс]. - Режим доступа: http://www.qa.qulix.ru/knowledge/avtomatizatsiya-testirovaniya.php. - Дата доступа: 24.04.2016.

5 О стандартизации в области информационных технологий в Республике Беларусь [Электронный ресурс]: материалы IX Международного форума по банковским информационным технологиям, Минск, 21-22 ноября 2012 г. / Расчетный центр Национального банка РБ: А.В. Глушков. - Минск, 2007.- Дата доступа: 27.04.2016.

6 EPAM объявила результаты деятельности за 4 квартал 2015 года// Официальный сайт компании EPAM Systems в Республике Беларусь [Электронный ресурс] Дата доступа: 21.04.2016.

7 EPAM объявила результаты деятельности за 1 квартал 2016 года// Официальный сайт компании EPAM Systems в Республике Беларусь [Электронный ресурс] Дата доступа: 11.05.2016.

8 Официальный сайт компании EPAM Systems в Республике Беларусь [Электронный ресурс] -Дата доступа: 22.03.2016.

9 Внутренний источник: Technologies. Projects. Persons //EPAM Systems. - 2015

10 Внутренний источник: Functional Testing Process Description// EPAM Systems. - 2015

11 Средства автоматизированного тестирования [Электронный ресурс] // "Открытые системы". Дата доступа: 18.04.2016.

12 Методические указания по технико-экономическому обоснованию программных средств (ПС) [Электронный ресурс] / А.А. Носенко: БГУИР, кафедра экономики. -Дата доступа: 28.04.2016.

13 TestComplete overview [Электронный ресурс] - Режим доступа: Дата доступа: 17.04.2016

14 Censor, Y., "Pareto Optimality in Multiobjective Problems, " Appl. Math. Optimiz., Vol. 4, pp 41-59, 1977.

15 Team Foundation Server (TFS) [Электронный ресурс] Дата доступа: 17.04.2016

16 Microsoft Visual Studio [Электронный ресурс] Дата доступа: 17.04.2016

17 Fletcher, R., "Practical Methods of Optimization," Vol. 1, Unconstrained Optimization, and Vol. 2, Constrained Optimization, John Wiley and Sons, 1980.

18 Biggs, M.C., "Constrained Minimization Using Recursive Quadratic Programming," Towards Global Optimization (L.C.W. Dixon and G.P. Szergo, eds.), North-Holland, pp 341-349, 1975.

19 Da Cunha, N.O. and E. Polak, "Constrained Minimization Under Vector-valued Criteria in Finite Dimensional Spaces," J. Math. Anal. Appl., Vol. 19, pp 103-124, 1967.

20 Dantzig, G., Linear Programming and Extensions, Princeton University Press, Princeton, 1963.

21 Dennis, J.E., Jr. and R.B. Schnabel, Numerical Methods for Unconstrained Optimization and Nonlinear Equations, Prentice-Hall Series in Computational Mathematics, Prentice-Hall, 1983.

22 Fleming, P.J., "Computer-Aided Control System Design of Regulators using a Multiobjective Optimization Approach," Proc. IFAC Control Applications of Nonlinear Prog. and Optim., Capri, Italy, pp 47-52, 1985.

23 Fletcher, R., "Practical Methods of Optimization," Vol. 1, Unconstrained Optimization, and Vol. 2, Constrained Optimization, John Wiley and Sons, 1980.

24 Forsythe, G.F., M.A. Malcolm, and C.B. Moler, Computer Methods for Mathematical Computations, Prentice Hall, 1976.

25 Gill, P.E., W. Murray, M.A. Saunders, and M.H. Wright, "Procedures for Optimization Problems with a Mixture of Bounds and General Linear Constraints," ACM Trans. Math. Software, Vol. 10, pp 282-298, 1984.

26 Gill, P.E., W. Murray, and M.H. Wright, Numerical Linear Algebra and Optimization, Vol. 1, Addison Wesley, 1991.

27 Gill, P.E., W. Murray, and M.H.Wright, Practical Optimization, London, Academic Press, 1981.

28 Hollingdale, S.H., Methods of Operational Analysis in Newer Uses of Mathematics (James Lighthill, ed.), Penguin Books, 1978.

29 Levenberg, K., "A Method for the Solution of Certain Problems in Least Squares," Quart. Appl. Math. Vol. 2, pp 164-168, 1944.

30 Nocedal, J. and S.J. Wright, Numerical Optimization, Springer Series in Operations Research, Springer Verlag, 1999.



Приложение А

Программный продукт типа Framework

Рисунок A.1 - Ручной тест, TFS

Примечание - Источник: собственная разработка.

Рисунок A.2 - Автоматизированный тест, TestComplete

Примечание - Источник: собственная разработка.



Рисунок A.3 - Отчёт о результатах тестирования (по количеству найденных дефектов)

Примечание - Источник: собственная разработка.

Размещено на Allbest.ru

...