Издательство «НАУЧНЫЕ ТЕХНОЛОГИИ»

МОСКВА, тел. +7(495)-755-19-13

Изд-во «НАУЧНЫЕ ТЕХНОЛОГИИ» : / Конференции / ПОЛИТИКА КОНФИДЕНЦИАЛЬНОСТИ
A+ R A-

Тестирование надёжности – необходимый этап в создании качественного программного продукта

E-mail Печать

Е.А. Калиберда,  (Доцент, Омский государственный институт сервиса)

А.А. Рыбкин,  (Аспирант, Омский государственный институт  сервиса)

alt

Конференция 01
Секция - ПРИКЛАДНЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

 

«ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В НАУКЕ, БИЗНЕСЕ И ОБРАЗОВАНИИ»:

Сборник статей V Международной научно-практической конференции студентов, аспирантов и молодых ученых.

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

10 лет назад ситуация с тестированием ПО в России выглядела следующим образом: небольшие и средние компании выполняли эту работу просто «для галочки», потому что на западе этот процесс пользовался популярностью, а гиганты индустрии выполняли эту работу, потому, что культура обеспечения качества и тестирования в частности были скорее навязаны им снаружи и воспринимались, как данное, нежели стали плодом самого развития индустрии в РФ.

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

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

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

Вследствие ошибок программистов в готовом продукте могут быть уязвимости, которые наносят как косвенные имиджевые так и прямые финансовые потери компании.  Поэтому не так давно, 3-4 года назад, даже небольшие компании стали бороться за опытных тестировщиков. Это происходило не только потому, что компании хотели избавиться от рисков разработки без тестирования, а в большей степени потому, что появилось понимание того, что тестировщик способен экономить компаниям огромные деньги. [2]

Если раньше ошибки исправлялись де факто уже в готовом продукте, то сегодня системность процесса контроля качества достигла такого уровня, что позволяет системным аналитикам предопределить всю работу программистов, еще до написания ими первых строчек кода, предостеречь от возможных ошибок с помощью правильной постановки задачи. А сами разработчики применяют в работе метод модульного тестирования (unit testing). Идея этого метода состоит в том, чтобы писать тесты для каждой нетривиальной функции. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, т.е. к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.[3]

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

Таблица 1. - Результаты опроса

 

Да

Нет

Не знаю

Проводите ли вы тестирование своих проектов?

87

17

0

Тестирование проводиться до релиза проекта?

79

25

0

В вашей компании есть специалисты тестировщики

(не занимаются разработкой)?

61

43

0

Применяются ли в вашей компании "Чек-листы"?

41

55

8

Применяются ли в вашей компании "Тест-кейсы"?

38

55

11

Применяются ли в вашей компании "Юнит-тесты"?

27

67

10

Проводите ли вы инспекцию-кода (codereview)?

23

71

10

Ваш проект проходит оценку надежности как система?

0

62

42

Проводили бы вы оценку надежности проекта при

наличии автоматизированных и простых средств?

31

29

44


СПИСОК ЛИТЕРАТУРЫ:

1. Леонтьев Е. А.  Надежность экономических информационных систем: учеб. пособие / Е. А. Леонтьев. – Тамбов: Изд-во Тамб. гос. техн. ун-та, – 2002 – C. 14. 

2.  Тестирование: из грязи в князи / Информационный портал [электронный ресурс] – Режим доступа: [http://habrahabr.ru/post/151279/]

3.  Мартыненко С. Модульное тестирование. Зачем, как и кто / Информационный портал [электронный ресурс] – Режим доступа: [http://software-testing.ru/library/testing/general-testing/77-2008-09-29-07-30-13].


© Е.А. Калиберда, А.А. Рыбкин,  Изд-во "Научные технологии", 2012.
 

Книжные Изданияbadge

badge
  • Реструктуризация информационного пространства органов государственной власти Санкт-Петербурга
  • Профессия «Бухгалтер»: прошлое, настоящее, будущее
  • Финансово-кредитная политика России
  • О недостаточности категории «графическое слово» для описания языкового материала арабского литературного языка (в связи с акцидентальными письменными словами в АЛЯ)