Е.А. Калиберда, (Доцент, Омский государственный институт сервиса) А.А. Рыбкин, (Аспирант, Омский государственный институт сервиса) |
|
|||||||||||||||||||||||||||||||||||||||||
Неоспоримый факт, что конкуренция в сфере IT индустрии растет с каждым днем и уже сегодня, когда компании готовы инвестировать деньги в новые технологии позволяющие увеличить прибыль, за счет повышения качества готовой продукции. В этой статье авторы попытаются описать этапы становления и взросления процессов, связанных с тестированием программного обеспечения учитывая специфику российского рынка IT индустрии. [1, с. 14] 10 лет назад ситуация с тестированием ПО в России выглядела следующим образом: небольшие и средние компании выполняли эту работу просто «для галочки», потому что на западе этот процесс пользовался популярностью, а гиганты индустрии выполняли эту работу, потому, что культура обеспечения качества и тестирования в частности были скорее навязаны им снаружи и воспринимались, как данное, нежели стали плодом самого развития индустрии в РФ. Тогда же в процессе тестирования и контроля качества появились зачатки системности. Работа, как правило, строилась следующим образом: программисты писали бета-версию ПО и передавали ее тестировщикам, которые искали ошибки, сообщали о них разработчикам, а те в свою очередь исправляли их и выпускали готовый продукт. Спустя пару лет, в компаниях стали появляться первые тест-кейсы и чек-листы, а также первые попытки по созданию отчетности о результатах тестирования. Постепенно в работе компаний стали происходить изменения. Процессы тестирования становились сложнее, менялись взгляды на необходимость процесса контроля качества. В этот момент, 5-6 лет назад, стали массово появляться чек-листы и тест-кейсы, потому, что стало понятно, что с их помощью можно значительно ускорить процесс тестирования, сделать его прогнозируемым и системным. Тогда же были первые попытки вывести процессы тестирования на новый уровень, когда этот процесс стал неотъемлемым этапом в процессе создания ПО. Вследствие ошибок программистов в готовом продукте могут быть уязвимости, которые наносят как косвенные имиджевые так и прямые финансовые потери компании. Поэтому не так давно, 3-4 года назад, даже небольшие компании стали бороться за опытных тестировщиков. Это происходило не только потому, что компании хотели избавиться от рисков разработки без тестирования, а в большей степени потому, что появилось понимание того, что тестировщик способен экономить компаниям огромные деньги. [2] Если раньше ошибки исправлялись де факто уже в готовом продукте, то сегодня системность процесса контроля качества достигла такого уровня, что позволяет системным аналитикам предопределить всю работу программистов, еще до написания ими первых строчек кода, предостеречь от возможных ошибок с помощью правильной постановки задачи. А сами разработчики применяют в работе метод модульного тестирования (unit testing). Идея этого метода состоит в том, чтобы писать тесты для каждой нетривиальной функции. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, т.е. к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.[3] Следующим этапом повышения качества продуктов, может стать метод позволяющий оценить структурную надежность всей информационной системы и частных ее компонентов. Подобный метод уже успешно применяется при создании электротехники, строительстве зданий, моделировании и т.д. Главная проблема на сегодняшний день в адаптации этого метода для работы с информационными системами. Этот процесс адаптации требует серьезных финансовых и временных затрат, в связи с этим, авторы статьи провели опрос среди представителей IT индустрии России. Анализ результатов опроса (Табл. 1) свидетельствуют, о том, что процедура тестирования является обязательной в процессе разработки программных продуктов небольшими компаниями, однако тестирование надёжности, в силу различных причин, не проводится вообще. Однако необходимость данного вида тестирования компаниями признаётся, что делает направление исследования вопросов надёжности программных продуктов актуальным и перспективным. Таблица 1. - Результаты опроса
|
|||||||||||||||||||||||||||||||||||||||||
СПИСОК ЛИТЕРАТУРЫ: 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. |
< Предыдущая | Следующая > |
---|