Файл: Отладка и тестирование программ: основные подходы и ограничения (Этапы тестирования программного обеспечения).pdf

Спецификация тестовой процедуры:

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

Использование стандарта IEEE STD 829 в реальных проектах.

За последние три года данный стандарт эффективно использовался Центром тестирования департамента консалтинга компании АйТи в следующих проектах: нагрузочное тестирование биллинговых систем, функциональное тестирование CRM-системы, внедрение стандарта предприятия для учреждения Банк. Большой эффект экономии ресурсов и средств дает использование отработанных, адаптированных шаблонов документов, перечисленных в стандарте. Для каждого проекта можно определить степень стандартизации – создание СТП, методики или простое использование шаблона.

По практике данных работ видно, что стандарт можно дополнить, например, если используется объектно-ориентированное проектирование (ООП), то можно добавить следующие документы: описание тестовых классов, тестовых пакетов. Экономия при использовании шаблонов не только в том, что есть образец, но и в том, что логика и состав документа тщательно продуманы и проработаны, как оп смыслу, так и по оформлению, т.е. не нужно «изобретать велосипед». А для случаев, когда выполняется заказная работа, эти шаблоны готовы для рассмотрения и согласования с Заказчиком с первых дней и часов с начала работ. Для больших и/или достаточно формализованных проектов (RUP) требуется полный или расширенный список документов, а для малых проектов, которые очень распространены в последнее время в связи с популярностью аутсортинга, методологий RAD, XP – список документов может быть сокращен или упрощен.

Плюсы внедрения стандарта – унификация (ускорение работ, единая корпоративная структура), смысловая полнота.

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

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

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

Рассматриваемый стандарт рекомендуется использовать не только для планирования и выполнения работ по тестированию, но и для разработки стандарта предприятия, программы и методики испытаний, а также для создания методик по отдельным видам тестирования (функциональному, нагрузочному, стрессовому, приемочному и т.п.). В этом случае можно также использовать ГОСТ 19.301-79 Программы и методики испытаний. Стандарты предприятий рекомендовано создавать для разработчиков ПО, для служб сопровождения (тиражные системы). Программы и методики испытаний – для служб эксплуатации систем (биллинг, ERP, CRM).

Ресурсные затраты на разработку одинакового типа шаблона могут отличаться для разных организаций: создание в первый раз – от 8 часов, при наличие подходящего образца и опыта, до нескольких дней; адаптация отработанного шаблона для нового проекта – от 1 часа до 1дня. Некоторые методологии и пакеты инструментальных средств предлагают наборы типовых шаблонов по разным процессам, в том числе и для тестирования.

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

1. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем [текст] / Б. Бейзер; - Питер, 2017, 320 с. ISBN ↑

2. Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; - Питер, 2004, 656 с. ISBN 5-94723-663-X. .Винниченко И.В. Автоматизация ↑

3. Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; - Питер, 2004, 656 с. ISBN 5-94723-663-X. .Винниченко И.В. Автоматизация ↑

4. 4. Винничeнкo И. Aвтoмaтизaция прoцeссoв тeстирoвaния. - СПб.: Питeр, 2018. с. 203. ↑

5. Липaeв В.В. Нaдёжнoсть прoгрaммных срeдств. - М.: СИНТEГ, 2017. с. 240. ↑

6. Липaeв В.В. Oтлaдкa слoжных прoгрaмм. - М.: Энeргoaтoмиздaт, 2017. с. 235. ↑

7. Мaкгрeгoр Д, Сaйкс Д. Тeстирoвaниe oбъeктнo-oриeнтирoвaннoгo прoгрaммнoгo oбeспeчeния. Прaктичeскoe пoсoбиe. - К.: ТИД "ДС", 2018. с. 432. ↑

8. Мaкгрeгoр Д, Сaйкс Д. Тeстирoвaниe oбъeктнo-oриeнтирoвaннoгo прoгрaммнoгo oбeспeчeния. Прaктичeскoe пoсoбиe. - К.: ТИД "ДС", 2018. с. 432. ↑

9. Сoммeрвилл И. Инжeнeрия прoгрaммнoгo oбeспeчeния. - СПб.: Вильямс, 2017. с. 624. ↑

10. Сoммeрвилл И. Инжeнeрия прoгрaммнoгo oбeспeчeния. - СПб.: Вильямс, 2017. с. 624. ↑