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

ВВЕДЕНИЕ

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

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

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

На основе вышеперечисленных фактов можно определить цель данной работы: «Оптимизация затрат службы технической поддержки путем автоматизации процесса тестирования (Continuous integration)».

В качестве объекта исследования мною была выбрана компания «Infinnity Solutions», разработчик инновационного программного обеспечения в области здравоохранения. Основными направлениями разработки программных продуктов являются интегрированная электронная медицинская карта (ИЭМК), медицинские информационные системы (МИС), а так же мобильные медицинские приложения.

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

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

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

ГЛАВА 1. СОВРЕМЕННЫЙ ОТЕЧЕСТВЕННЫЙ И ЗАРУБЕЖНЫЙ ОПЫТ В ТЕСТИРОВАНИИ ПРОГРАММНЫХ ПРОДУКТОВ

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

· продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

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

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

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

С точки зрения ISO 9126, качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

· Надёжность

· Сопровождаемость

· Практичность

· Эффективность

· Мобильность

· Функциональность

Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.

1.1 История развития тестирования программного обеспечения

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

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

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

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

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

В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.

1.2 Тестирование программного обеспечения

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

По объекту тестирования:

*Функциональное тестирование (functional testing)

*Тестирование производительности (performance testing)

o Нагрузочное тестирование (load testing)

o Стресс-тестирование (stress testing)

o Тестирование стабильности (stability / endurance / soak testing)

*Юзабилити-тестирование (usability testing)

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

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

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

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

По знанию системы:

*Тестирование чёрного ящика (black box)

*Тестирование белого ящика (white box)

*Тестирование серого ящика (grey box)

По степени автоматизации:

*Ручное тестирование (manual testing)

*Автоматизированное тестирование (automated testing)

*Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

*Компонентное (модульное) тестирование (component/unit testing)

*Интеграционное тестирование (integration testing)

*Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

*Альфа-тестирование (alpha testing)

*Дымовое тестирование (smoke testing)

*Тестирование новой функциональности (new feature testing)

*Подтверждающее тестирование (confirmation testing)

*Регрессионное тестирование (regression testing)

*Приёмочное тестирование (acceptance testing)

*Бета-тестирование (beta testing)

По признаку позитивности сценариев:

*Позитивное тестирование (positive testing)

*Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

*Тестирование по документации (formal testing)

*Тестирование ad hoc или интуитивное тестирование (ad hoc testing)

Рассмотрим три вида тестирования производительности подробнее.

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

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

Существует несколько принципов нагрузочного тестирования:

1. Уникальность запросов

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

2. Время отклика системы

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

3. Зависимость времени отклика системы от степени распределённости этой системы.

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

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

4. Разброс времени отклика системы

Из утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определённые в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.

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

5. Точность воспроизведения профилей нагрузки

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

Стресс - тестирование (англ. Stress Testing) -- один из видов тестирования программного обеспечения, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для «критически важного» ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.

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

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

Необходимость стресс-тестирования диктуется следующими факторами:

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

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

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

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

У стресс - тестирования существует несколько направлений применения:

· Общее исследование поведения системы при пиковых нагрузках.

· Исследование обработки ошибок и исключительных ситуаций системой при пиковых нагрузках.

· Исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках.

· Тестирование ёмкости системы.

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

Тестирование стабильности (Stability / Reliability Testing) -- один из видов автоматизированного тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.

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

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

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

Регрессионное тестирование (по некоторым источникам) включает new bug-fix - проверка исправления вновь найденного дефекта, old bug-fix - проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect - проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

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

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

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

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

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

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

· Серверный

· Клиентский

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

– Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.)

– Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.)

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

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

· Тип, версия и битность операционной системы (подобный вид тестирования называется кросс-платформенное тестирование)

· Тип и версия Web барузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование)

· Тип и модель видео адаптера (при тестировании игр это очень важно)

· Работа приложения при различных разрешениях экрана

Порядок проведения тестирования:

Перед началом проведения конфигурационного тестирования рекомендуется:

· создавать матрицу покрытия (матрица покрытия - это таблица, в которую заносят все возможные конфигурации),

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

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

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

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

Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

1. Требования

2. Бизнес-процессы

Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

Преимущества функционального тестирования:

· имитирует фактическое использование системы;

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

· возможность упущения логических ошибок в программном обеспечении;

· вероятность избыточного тестирования.

1.3 Автоматизированное тестирование ПО

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

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

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

Требования к проекту:

· Исходный код и всё, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями;

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

Организация:

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

• получение исходного кода из репозитория;

• сборка проекта;

• выполнение тестов;

• развёртывание готового проекта;

• отправка отчетов.

1.4 Применение автоматизированного тестирования

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

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

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

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

Установочное тестирование, выполняется для проверки условий инсталляции (и настройки) продукта с учётом тех или иных требований к системе от заказчика.

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

• Исключен «человеческий фактор». Сильное достоинство. Все мы люди и никто из нас не застрахован от ошибок. Выполняемый же тест-скрипт не пропустит тест по неосторожности и ничего не напутает в результатах.

• Быстрое выполнение - автоматизированному скрипту не нужно сверяться с инструкциями и документациями.

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

• Отчеты - автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.

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

Недостатки:

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

• Затраты на поддержку - чем чаще изменяется приложение, тем они выше.

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

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

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

Средства непрерывной интеграции

• Bamboo (англ.)

• Hudson и Jenkins

• CruiseControl

• TeamCity

• BuildBot

• Travis CI

1.5 Зарубежный опыт автоматизации процесса тестирования программного обеспечения

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

Я расскажу вам о том, как тестируют в Google, и поможет мне в этом одноименная книга, которую написал Джеймс Уиттакер, бывший технический директор этой компании, сейчас работает в Microsoft. Уиттакер был ответственен за тестирование таких крупных проектов как Chrome, Maps и других, не менее полезных веб-приложений Google.

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

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

Философия тестирования в Google гласит, что тестирование нужно не для качества. Тестирование, это часть инженерной культуры. Тестирование, это часть разработки, тестирование, это то, что сотрудники делают перед релизами. Но они не тестируем для того, чтобы поднять качество. Высокое качество закладывается разработчиками, менеджерами проектов и тестировщиками, а не тестами. Мне кажется, что особенность компании Google заключается в том, что они сделали тестирование, абсолютно неотъемлемой частью их работы. Ни один разработчик не может внести в ветку проекта код, который был бы не покрыт тестами. Это все происходит автоматически, как часть рабочего процесса. Этот метод называется TDD (Test Driven Development), техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Google немного видоизменили стандартное понимание термина TDD, добавив в это понятие свою философию:

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

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

Выводы по главе 1

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

ь Тестирование - неотъемлемая и очень важная часть процесса разработки ПО

ь Тестирование - очень затратный, как по времени, так и по ресурсам, процесс

ь В наши дни тестирование активно развивается, внедряются новейшие технологии

ь Наиболее распространенным методом тестирования является автоматизированное тестирование

ГЛАВА 2. АНАЛИЗ СОСТОЯНИЯ ОРГАНИЗАЦИИ

2.1 Общая информация, миссия, видение, стратегия и цели

Infinnity Solutions -- компания разработчик инновационного программного обеспечения в области здравоохранения. Основными направлениями разработки программных продуктов являются интегрированная электронная медицинская карта (ИЭМК), медицинские информационные системы (МИС) и мобильные медицинские приложения.

В 2006 году для решения актуальных задач и сокращения бумажного документооборота в поликлиниках Челябинской области был разработан программный продукт медицинская информационная система «МЕДИК+». Результатом внедрения МИС «МЕДИК+» стала ликвидация очередей в регистратуру и кабинеты врачей, сокращение времени записи пациентов на прием, автоматизированный контроль над оказанием медицинской помощи, что привело к повышению качества и доступности медицинской помощи в г.Миасс, Челябинск, Кыштым и других городах Челябинской области.

В 2010 году по заданию Челябинского областного МИАЦ МИС «МЕДИК+» была доработана до последних требований Минздравсоцразвития РФ, включая требования законодательства по защите персональных данных при ведении медицинских карт в электронном виде. Для централизованного распространения и доступа к МИС посредством тонкого клиента через веб-интерфейс для поликлиник Челябинской области была выпущена подсистема «Электронная регистратура»

Сегодня МИС «МЕДИК+» распространяется среди ЛПУ Челябинской области для ведения персонифицированного учета оказанной медицинской помощи на основе первичных данных и записей ЭМК, управления взаиморасчетами за оказанную медицинскую помощь, анализа деятельности и формирование отчетности.

Два года подряд на Южно-Уральском Инновационном Форуме, проводимом Минэкономразвития Челябинской области, деятельность компании ООО "Infinnity Solutions" была отмечена за вклад в развитие в инновационного потенциала Челябинской области, а сама компания за наиболее динамичное развитие, научно-технический потенциал и активное внедрение инновационных технологий была признана лидером инновационного бизнеса Челябинской области. Начиная с 2009 года, компания Infinnity Solutions входит в число ведущих российских разработчиков медицинских информационных систем и успешно подтверждает статус партнера по работе с организациями здравоохранения.

В 2011 году была выпущена и зарегистрирована в Федеральной службе по интеллектуальной собственности, патентам и товарным знакам интеграционная платформа openHealth, которая уже прошла апробацию в ходе реализации пилотного проекта создания интегрированной ЭМК Челябинской области.

В 2012 году совместно с компаниями IBS и Ocean Informatics выигран конкурс на разработку и пилотное внедрение ИЭМК для Департамента Информационных Технологий г. Москва. По заданию городского управления здравоохранением г. Челябинска развернута общегородская система записи на прием ко врачу через Интернет. Произведена комплексная автоматизация федеральных учреждений ФМБА МСЧ№72 г. Трехгорный, клиника ЧелГМА г. Челябинск, Федеральное государственное бюджетное учреждение науки Уральский научно-практический центр радиационной медицины ФМБА России (ФГБУН УНПЦ РМ ФМБА России г. Челябинск).

Сегодня для создания инновационных информационных систем в здравоохранении компания Infinnity Solutions предлагает:

· интеграционную платформу InfinniPlatform для создания централизованного регионального хранилища данных медицинских информационных систем, ЭМК и сервисов взаимодействия с общесистемными компонентами федерального уровня;

· электронную регистратуру и портал для записи на прием через Интернет.

· Медицинскую информационную систему «Медик+» для доступа к ИЭМК, моделирования клинических данных, а также автоматизации всех основных бизнес процессов в медицинском учреждении.

Динамичное развитие продуктов компании происходит при поддержке зарубежных партнеров Ocean Informatics (Австралия), Microsoft (США), а так же за счет использования открытого международного стандарта openEHR и самых передовых и инновационных технологий разработки программного обеспечения.

Главное преимущество компании Infinnity Solutions -- это минимизация технических и финансовых рисков при реализации сложных комплексных проектов внедрения современных информационных систем в рамках региональных проектов модернизации здравоохранения, за счет использования многолетнего опыта и программного обеспечения, специально разработанного под новую концепцию информатизации Минздравсоцразвития РФ (ЕГИСЗ РФ) и современные требования рынка медицинских информационных систем.

Миссия

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

Цели

Цели предприятия приведены в рисунке 2.1. Детализация целей с ключевыми показателями представлена на рисунке 2.1.



Рисунок 2.1 - Стратегическая карта целей ООО «Infinnity Solutions»

Таблица 2.1 - Показатели целей

Цель	Показатель	Способ измерения	Целевое значение
Увеличение прибыли компании	Совокупная прибыль компании	разница между совокупным доходом (выручкой) и совокупными издержками	На 25% за год
Увеличение объема продаж	Валовая прибыль компании	Разница между выручкой от проведенных работ и услуг. (за вычетом НДС, акцизов и аналогичных платежей) и себестоимостью предоставленных работ и услуг	На 25% за год
Снижение затрат	Процент издержек на разработку	Временные ресурсы на разработку	На 20% за год
Удержание стратегических клиентов	Количество стратегических клиентов	Процент клиентов, приносящих основной доход по отношению ко всем	Процент не должен уменьшиться
Увеличение занимаемой доли рынка	Доля рынка по типу предоставляемых услуг	Количество клиентов компании к общему числу потенциальных клиентов	На 20% за год
Повышение удовлетворенности клиента	Количество жалоб клиентов	Процент недовольных клиентов	На 10% за год
Освоение новых направлений бизнеса	Количество новых направлений в год	Количество внедренных и освоенных компанией новых направлений бизнеса за год	2 направления за год
Соблюдение сроков выполнения проектов	Процент проектов, выполненных в срок	Процент выполненных проектов в рамках установленного срока	95% за год
Повышение качества работы с проектами	Соответствие стандартам и требованиям	Процент проектов, соответствующих документации и стандартам	100% в год

Ценности, ключевые принципы деятельности:

· Промышленный подход к разработке программного обеспечения

· Высокая ответственность за результат

· Фокус на минимизации рисков всех типов

· Новаторство

Виды деятельности:

· Системный анализ лечебно-диагностической и административной деятельности медицинских организаций

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

· Исследования зарубежного опыта, промышленных платформ и открытых стандартов на предмет их применимости для российского здравоохранения

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

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

· Внедрение и сопровождение собственных разработок в рамках создания региональных сегментов Единой государственной информационной системы здравоохранения РФ.

2.2 Анализ внешней среды

2.2.1 STEP-анализ дальнего окружения

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

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

Социальные факторы

· Демографическая ситуация. По данным челябинской статистики, в области происходит старение нации. Данный факт говорит о том, что все большая часть населения нуждается в своевременной и качественной медицинской помощи, которую должны обеспечивать ЛПУ. Увеличение числа пациентов повысит спрос на МИС;

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

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

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

Технологические факторы

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

· Дороговизна оснащения для ЛПУ. Для того, чтобы внедрить в какое-либо медицинское учреждение, например, электронные медицинские карты, необходимо, чтобы кабинеты всех врачей были оснащены необходимым оборудованием для ведения этих карт. Даже если необходимое оборудование есть, то чаще всего имеет место быть в высокой степени изношенность основных производственных фондов учреждений здравоохранения. Данный факт говорит о том, что государственные ЛПУ часто не в состоянии приобрести достаточное количество оборудования для успешного внедрения той или иной подсистемы МИС;

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

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

Экономические факторы

· Низкий уровень финансовых возможностей ЛПУ. Какие бы потенциально интересные и привлекательные идеи и возможности не производила бы отрасль МИС, финансовые возможности ЛПУ и всей системы здравоохранения влияли и по-прежнему прямо влияют на будущее МИС. В этом плане нужно оценить объем средств, которые каждое ЛПУ и регион могут выделять на направление IT и соотносить их со стоимостью предлагаемых решений и затратами на их внедрение;

· Рост числа частных ЛПУ. Когда частными клиникам разрешили обслуживать население по полисам обязательного медицинского страхования, их по сути дела уравняли в правах с государственными больницами. В результате количество коммерческих клиник стало расти. Данный факт положительно влияет на деятельность компании, так как появляется все больше потенциальных клиентов с потребностью в современном конкурентоспособном программном обеспечении;

· Финансовый кризис. Институт прикладной математики РАН, специалисты которого спрогнозировали мировой финансовый кризис за два года до его наступления, сейчас дает новый прогноз - в 2014 году мировую экономику накроет вторая, еще более страшная волна кризиса. Как правило, во время кризиса банки ужесточают условия выдачи кредитов малому бизнесу либо вовсе сворачивают данные программы. В связи с этим у малого бизнеса могут появиться проблемы с доступом к заемным ресурсам;

· Рост среднедушевых денежных доходов населения. По данным государственной статистики по Челябинской области среднедушевые доходы имеют положительную динамику и к февралю 2014го года составляют чуть больше 20 тысяч. Рост доходов населения увеличит спрос на медицинские услуги, в частности платные. Медицинские учреждения для удовлетворения платежеспособных клиентов захотят повысить качество обслуживания, которое можно обеспечить с помощью МИС.

Экологические факторы

· Экологическая проблема. Экологическая обстановка в Челябинской области выражается в наличии добывающих и перерабатывающих производств, загрязняющих окружающую среду, и наличии фактических и возможных источников радиации. Данный факт негативным образом сказывается на здоровье людей, вынуждая их обращаться за медицинской помощью. Для эффективной организации процесса оказания услуг населению потребуется помощь компаний, внедряющих МИС;

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

Политико-правовые факторы

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