Методологические основы

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

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

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

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

— выявленные дефекты и ошибки в программах и данных;

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

• 
  Ошибки и предложения по корректировке программ первоначально селектируются специалистами по компонентам ПС и анализируются сове­том конфигурационного управления по их влиянию на качество функцио­нирования комплекса программ и по затратам на осуществление измене­ний. Приоритетность каждого предлагаемого изменения программ це­лесообразно оценивать по следующим критериям:
  

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

• 
  Для повышения качества новых версий руководитель и совет кон­фигурационного управления анализируют все предлагаемые изменения и выделяют из них целесообразные для анализа возможного использования в очередной версии (см. рис. 16.2). При выделении изменений приходится решать оптимизационную задачу по оценке и сопоставлению ущерба от того, что изменение не проведено и не повышается соответственно каче­ство функционирования ПС, с затратами ресурсов на проведение измене­ний и возможным ущербом, если они содержат дефекты. Селекция прово­димых изменений в версиях сложных ПС требует формализации анализа этого процесса и документирования предполагаемых и утвержденных из­менений.
  
• 
  В совете конфигурационного управления сосредоточивается инфор­мация для планирования основных операций по доработке и выпуску оче­редных версий ПС. Специалисты должны оценивать степень срочности исправления ошибок и проведения модернизаций, а также выявлять усло­вия, позволяющие достаточно полноценно эксплуатировать программы до выполнения всех запланированных изменений при выпуске очередной вер­сии. Кроме того, специалистам группы управления конфигурацией необ­ходима «дипломатическая» квалификация для того, чтобы убеждать пользо­вателей до выпуска очередной версии некоторое время использовать ПС без проведения изменений, возможно, с некоторыми ограничениями или видоизменениями функций.
  
• 
  В процессе разработки (л + 1)-й базовой версии ПС используются вновь разработанные компоненты и версии i-x компонентов и модулей, переписываемых из предыдущей n-й версии. После внесения изменений из этих компонентов образуются j-с версии для комплексирования функ­циональных групп программ, которые после автономного тестирования объединяются в (п + 1)-ю версию ПС для квалификационного тестирова­ния, испытания и документального оформления. При корректировках ком­понентов, групп программ и версий ПС все процедуры выполняются с учетом ограничений права доступа каждого специалиста к реализации соответствующих изменений (см. табл. 16.1). Все версии разработчиков должны сопровождаться дубликатами, которые эпизодически тестируют­ся на соответствие основной версии разработчика модификаций на дан­ном уровне. При выявлении отклонения дубликата от основной версии разработчика тестирование продолжается до установления места и причи­ны различия. После этого осуществляется корректировка дубликата или основной версии до абсолютного совпадения.
  
• 
  Корректировку компонентов и сборку очередной базовой версии про­изводят специалисты, ответственные за интеграцию, по возможности, с привлечением разработчиков предыдущих версий. Пользователи в этих работах не участвуют, но могут привлекаться для предварительного испы­тания и уточнения целей корректировок (Альфа-тестирование). Процесс проведения изменений должен поддерживаться средствами автоматиза­ции конфигурационного управления и обеспечения защиты от несанкцио­нированного доступа к корректируемым компонентам на последователь­ных этапах выполнения изменений. Каждое разработанное изменение долж­но документироваться в описании и базе данных предполагаемых коррек­тировок с указанием содержания, автора, времени и степени срочности.
  
• 
  Для принятых к внедрению изменений разрабатывается план до­работок программ и определяется конкретный специалист, ответствен­ный за каждую корректировку программы. Изменения программ могут потребовать либо полной замены модуля или группы программ, либо не­большого изменения текста программного модуля, описания данных или констант. При полной замене компонентов ПС они подлежат тестиро­ванию, как все вновь созданные компоненты. Изменения, выделенные и утвержденные уполномоченным лицом для реализации, селектируются по приоритетам на группы:
  

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

• 
  Эти группы изменений регистрируются в описании и базе данных подготовленных корректировок для последующего использования с ука­занием специалистов, их подготовивших, и лиц, принявших решение о реализации. Подготовленные и утвержденные предложения на изменения ПС поступают к специалистам, осуществляющим планирование их внесения в реальные программы, а также разработку и корректировку конкретных компонентов и документов. После выполнения доработок разработчиками компонентов и корректировки документации следует окончательная про­верка корректности изменений, которая осуществляется специалистами по квалификационному тестированию и испытаниям очередной вер­сии ПС (см. рис. 16.2).
  
• 
  Тестирование необходимо сосредоточивать на компонентах, впервые вводимых или значительно модифицируемых в данной версии. Если измене­ния в программе или в данных невелики, то тестирование обычно можно ограничить компонентами, непосредственно связанными с выполненной корректировкой. При этом следует учитывать, что корректировки про­грамм в 10—30% случаев сами содержат ошибки и требуют тщательного тестирования не только тех частей, где внесены изменения.
  
• 
  Наличие в сложных программах глубоких межмодульных связей по управлению и по информации вызывают необходимость частичного тес­тирования тех компонентов и их интерфейсов, где по первому впечатле­нию корректировки не оказывают влияния. Такие связи зачастую приводят к проявлению дефектов вследствие проведенных изменений и нарушения концептуальной и/или функциональной целостности группы взаимодей­ствующих программных компонентов и данных. Поэтому регрессионному тестированию необходимо подвергать также некоторые части и интер­фейсы комплекса программ, которые не подвергались изменениям. Для этого могут использоваться тесты, ранее применявшиеся при испытаниях предыдущей п-й версии. Проверенные, таким образом, изменения регист­рируются в описании и базе данных утвержденных и проведенных кор­ректировок для (п + 1)-й базовой версии программного продукта или для срочных извещений пользователям.
  
• 
  Объединение и сборка функциональных компонентов — групп от­корректированных программ позволяет создать эталон базовой (п + 1)-й версии ПС, подлежащий квалификационному тестированию по полной программе испытаний. При большом количестве выполненных изменений сложность испытаний может приближаться к испытаниям первой базовой версии. Объем тестирования при испытаниях (п + 1)-й базовой версии должен согласовываться между разработчиком, заказчиком или с пользо­вателями. Результаты испытаний регистрируются в типовых протоколах и в проекте акта о завершении испытаний (п + 1)-й версии. Все проверенные и подтвержденные при испытаниях корректировки программ регистриру­ются и утверждаются уполномоченным руководителем конфигурационно­го управления в акте, определяющем завершение подготовки новой базо­вой версии программного продукта.
  
•