Сегодня процесс разработки программного обеспечения стал неоднозначным. По этой причине необходим процесс, которым руководствуются его разработчики. В настоящее время существующая методология в Computer Applications Company предоставляет руководство для действий и рабочих процессов, которые организуют процесс разработки программного обеспечения в этом учреждении. Чтобы справиться с огромными усилиями, необходимыми для выполнения проекта с помощью этой методологии, необходимо разделить его на итерации. Каждая итерация процесса (выполненный результат) принимает в качестве входных данных продукт, полученный в результате предыдущей итерации, и генерирует увеличенный продукт в качестве выходных данных, который необходимо проверять и подтверждать на каждой итерации с областью качества и клиентом. Этот процесс не распространяется на все подразделения, он централизован по регионам (Запад,Центр и Восток), что делает невозможным измерение прогресса качества на каждом этапе проекта. В связи с вышеизложенным возникла необходимость в создании процедуры для выполнения частичных тестов в различных итерациях разработки программного обеспечения, чтобы сгладить те острые углы, которые могут возникнуть у конечного пользователя после того, как запрошенный продукт будет готов.
ВВЕДЕНИЕ
В настоящее время в индустрии программного обеспечения создание систем нацелено на создание все более крупных и сложных продуктов. Очень часто бывает, что их необходимо в короткие сроки изготовить по спецификации заказчика.
Мир коммерциализации и бизнеса с каждым днем становится все более конкурентным и требует более высокого качества в процессе разработки и контроля выполнения проектов программного обеспечения, поэтому важно использовать самые современные компьютерные технологии, чтобы гарантировать повышение эффективности процессов разработки программного обеспечения.
Эти ситуации вкупе с методологией разработки, реализованной в территориальных подразделениях Computer Applications Company, приводят к внедрению механизма контроля качества выполнения проектов на каждой итерации. Это позволяет продукту дойти до конечного пользователя с минимумом ошибок.
Цель этой работы - представить процедуру, подробно описанную ниже, которая устанавливает процедуру управления частичным качеством продуктов, разработанных в территориальном отделении Гуантанамо.
РАЗРАБОТКА
Характеристика территориального подразделения Гуантанамо
Компания Computer Applications (Desoft) имеет цель, ориентированную на компьютеризацию кубинского общества, для этого она в основном занимается разработкой, маркетингом, развертыванием и поддержкой программного обеспечения, хотя она также работает в таких направлениях, как: услуги мобильности, обучение, компьютерная безопасность, среди прочего. Он состоит из территориальных подразделений и центрального офиса в столице, поэтому специалисты и техники, работающие там, распределены по всей стране. В территориальном отделении Гуантанамо группа разработчиков состоит из 15 человек. Средняя продолжительность каждого проекта составляет девять месяцев, и каждая команда разработчиков состоит не более чем из трех специалистов.Приемочные испытания проводятся в конце каждого проекта в соответствии с методологией разработки Desoft в ее текущей версии 3.0. Группа качества на национальном уровне находится в территориальном подразделении Santi Spíritus и рассматривает только те проекты, характеристики которых соответствуют продуктовому портфелю компании на национальном уровне. Между тем, другие продукты зависят от критериев клиентов, которые во многих случаях не знают, как выразить то, что они хотят, и подписать акты приема-передачи, чтобы избежать проблем.другие продукты оставлены на усмотрение клиентов, которые во многих случаях не знают, как выразить то, что они хотят, и подписать акты приема-передачи, чтобы избежать проблем.другие продукты оставлены на усмотрение клиентов, которые во многих случаях не знают, как выразить то, что они хотят, и подписать акты приема-передачи, чтобы избежать проблем.
Процедура тестирования программного обеспечения
Нефункциональное тестирование играет важную роль в проверке качества программного продукта, исходя из того, что чем больше тестируется продукт и тем больше диапазон типов тестов, тем больше достигается подход к желаемому качеству. Этот документ служит руководством для проверки качества продукта, он составлен в соответствии со стандартами, установленными в методологии разработки программного продукта в компании Desoft. В нем подробно описаны этапы, роли с их обязанностями, инструменты и артефакты, задействованные на каждом этапе, типы тестов, которые необходимо провести, и поток обнаруженных несоответствий.
Объем
Он применим ко всем направлениям развития Управлений компьютеризации и Территориальных центров компьютерных услуг территориальных подразделений. Компьютерные приложения, которые представляют собой разработку по индивидуальному заказу, а также те, которые могут быть или не быть частью портфеля продуктов, будут подпадать под эту процедуру. Его также можно настроить для организаций со схожими характеристиками инфраструктуры и небольших групп разработчиков.
задача
- Определите шаги и требования, которые необходимо выполнить для частичной проверки компьютерных систем, разработанных территориальным подразделением Гуантанамо. Убедитесь, что продукты поставляются с постоянным уровнем качества, отвечающим ожиданиям клиентов. Подтвердите функциональность модулей, системы и интерфейсы, определенные в рамках проекта.
Понятия и определения
ПО - Программное обеспечение
HW - Оборудование
ГБ - гигабайт
RAM - оперативная память
NC - Несоответствия
EPGD - Ведущий специалист группы развития
EFC - специалист по качеству
CP - Тестовый пример
Этапы процедуры
Процедура тестирования программного обеспечения объединяет набор действий, которые описывают шаги, которые должны быть выполнены в процессе тестирования, такие как: планирование, разработка тестовых примеров, выполнение и результаты, с учетом того, сколько усилий и ресурсы потребуются для получения в результате правильной конструкции программного обеспечения. На следующем рисунке графически описаны этапы процедуры тестирования.
планирование
На этом этапе проводится проектный комитет, где происходит обмен между всеми ролями, которые участвуют в процессе тестирования. При этом на каждом собрании составляется протокол, подтверждающий его ежемесячное проведение. Соответствующие этапы также анализируются в соответствии с графиками проекта, чтобы решить, какие из них будут рассмотрены в рассматриваемом месяце. На данном этапе предстоит решить следующие задачи:
- Провести проектный комитет Согласовать с разработчиками график тестирования Определить количество ежемесячных проверок Подготовить тестовую среду
Реализация
Основная задача этого этапа - обзоры. Для этого разработчики доставят тестовые примеры главному специалисту по разработке, которые затем будут доставлены специалисту по качеству функций для их обработки и перехода к рассмотрению приложения на основе контрольных списков. После завершения этого процесса обнаруженные несоответствия будут вставлены в инструмент mantis для последующего анализа и мониторинга. Кроме того, заместитель директора по компьютеризации будет проинформирован о статусе процесса в виде частичного отчета после завершения каждой проверки. На данном этапе предстоит решить следующие задачи:
- Доставка артефактов Выполнение обзоров Запуск типов тестов Создание частичного отчета о тестировании Отслеживание несоответствий
Релиз
На этом этапе устраненные несоответствия закрываются после подтверждения с помощью регрессионных тестов специалистом по качеству. Заместитель директора по компьютеризации вместе с главным специалистом по разработке и специалистом по качеству также оценивает основные и наиболее неотложные трудности, возникающие во время всего процесса тестирования, и, наконец, продукт выпускается. Итак, задачи, которые необходимо выполнить на этом этапе, будут следующими:
- Выполнить регрессионные тесты Устранить несоответствия Выпустить модуль Подготовить окончательный отчет о тестировании
Необходимые требования для получения товара
Будет создана тестовая среда, в которой будет доступно проверяемое приложение.
Персонализированные ключи должны быть доставлены в соответствии с пользователями системы и файлом проекта в соответствии с методологией разработки на соответствующем этапе.
Необходимая документация должна публиковаться по следующему адресу: ftp://ftpdesarrollo.gtm.desoft.cu в конце пятницы каждой недели.
Типы тестов для выполнения
Чтобы гарантировать успех еженедельных проверок, специалист по качеству будет полагаться на некоторые типы тестов, указанные ниже.
- Исследовательские тесты
Они представляют собой не что иное, как процесс исследования продукта, который проверяет качество доставки, где будут оцениваться необходимые требования для получения продукта, если они не соответствуют им, тесты будут автоматически отменены.
Интеграционное тестирование
Интеграционные тесты выполняются во время построения системы, включают в себя все большее количество модулей и завершают тестирование системы в целом. Все связанные модули протестированы. Они выполняются для поиска неисправностей в интерфейсах между программным обеспечением и другими устройствами, с которыми оно взаимодействует.
Функциональное тестирование
Они оценивают набор функций и возможности компонентов системы. Они обеспечивают соответствующую работу функциональных требований, включая навигацию, ввод данных, обработку и получение результатов.
Функция: они состоят из проверки функциональных возможностей, представленных в приложении (в соответствии с Каталогом требований), с уделением внимания проверкам, исключениям и службам.
Безопасность: убедитесь, что и к данным, и к системе будут иметь доступ только желаемые субъекты и каждый со своими конкретными разрешениями.
Подтверждено следующее:
- Что каждое бизнес-правило применяется правильно. Ожидаемые результаты возникают при использовании достоверных данных. При использовании недопустимых данных отображаются соответствующие сообщения об ошибках и предупреждения.
Юзабилити-тестирование
Тест ориентирован на человеческий фактор, эстетику, контекстную помощь и онлайн. Ошибки в пользовательском интерфейсе, такие как: соответствие друг другу, сходство в прототипе, одинаковый шрифт, одинаковые типы кнопок, значки, формат, видимость, навигация, меню, цвета, удобочитаемость и т. Д.
Тесты на надежность
Восстановление и отказоустойчивость: убедитесь, что процессы ручного или автоматического восстановления правильно восстанавливают базу данных, приложения и системы и приводят их в известное или желаемое состояние.
Тест производительности
Сосредоточен на мониторинге времени в потоке выполнения, доступе к данным, вызове функций и системе для выявления и устранения узких мест и неэффективных процессов.
Сдерживание: сфокусирован на проверке навыков элемента, который будет протестирован, чтобы приемлемо удовлетворить спрос нескольких участников на одном и том же ресурсе.
Тесты на возможность поддержки
Конфигурация: ориентирована на обеспечение работы с различными конфигурациями оборудования и программного обеспечения. Этот тест также реализован как тест производительности системы.
Установка: ориентирована на обеспечение установки в различных конфигурациях оборудования и программного обеспечения при различных условиях, недостаточном дисковом пространстве и т. Д.
Регрессионные тесты
Тест был сосредоточен на проверке того, что инциденты, обнаруженные в предыдущей итерации, были правильно разрешены командой проекта, чтобы перейти к следующей итерации, в которой будет проверено, что при исправлении ранее обнаруженных ошибок не было внесено никаких ошибок. Цель этих тестов - убедиться, что дефекты, выявленные в предыдущем прогоне теста, были исправлены и что внесенные изменения не привели к появлению новых дефектов или повторному появлению предыдущих дефектов.
Системное тестирование
Обеспечивает правильную навигацию в системе, ввод, обработку и поиск данных. Проверяет правильность выполнения бизнес-правил.
Тесты предельных значений
Тесты, предназначенные для оценки обработки ошибок с помощью предельных или экстремальных значений. Если входное условие находится в диапазоне значений от A до B, тесты должны быть разработаны для пределов A и B, а также для значений внутри и выше пределов.
Инструменты тестирования программного обеспечения
Прецедент
Они представляют собой набор входных данных, условий выполнения и ожидаемых результатов, разработанных для конкретной цели. Они созданы с использованием таких техник, как белый ящик и черный ящик. Они выполняются в программном обеспечении после тестового примера, или полученные результаты сравниваются с ожидаемыми результатами, чтобы определить, есть ли какие-либо ошибки. Каждый тестовый пример должен иметь идентификацию и цель, подробное описание входов, способ их выполнения и подробное описание ожидаемых выходов.
Они определяют, как тестировать систему, включая входные данные, предварительные условия, спецификацию участников, которые будут выполнять тесты, и условия, при которых она должна быть протестирована. Это набор входных данных и ожидаемых результатов, которые проверяют компонент с целью вызвать отказы и обнаружить дефекты.
перечни
Он определяется как список вопросов в форме анкеты, служащей для проверки степени соответствия определенным правилам, установленным априори для конкретной цели. Их легко применять, резюмировать и сравнивать. Его анализ выполняется быстро, поскольку он заключается в проверке наличия или отсутствия контроля, применимого к анализируемому объекту.
Отчет об испытаниях
Он содержит информацию о выполнении тестов. Для каждого тестового примера необходимо указать полученные выходные данные, и, если они отличаются от ожидаемых, задокументировать обнаруженную ошибку с максимально возможным уровнем детализации. Его необходимо доставлять заместителю директора по компьютеризации каждую пятницу после согласования с главным специалистом группы разработки.
Отслеживание ошибок Mantis
Mantis - это система регистрации и контроля Несоответствий. Доступ к приложению веб-типа осуществляется через браузер. Mantis не имеет ограничений на тип браузера, который должен использоваться для работы в качестве клиента. Цель Mantis - создать и поддерживать систему контроля несоответствий, и она разработана таким образом, чтобы ее можно было легко модифицировать, настраивать и обновлять.
GitLab
Это веб-сервис для совместной разработки программного обеспечения и контроля версий на основе Git. В дополнение к менеджеру репозитория, сервис также предлагает вики-хостинг и систему отслеживания ошибок, все из которых публикуются под лицензией с открытым исходным кодом.
Nas Development
Инструмент FTP для репозитория исходного кода и файлов проекта.
Роли и обязанности
Ведущий специалист по развитию:
- Передайте документацию по проектам, которые будут проверяться на каждом этапе, специалисту по информатике после рассмотрения с назначенными разработчиками. Просмотрите и отправьте разработчикам несоответствия, обнаруженные на разных этапах для каждого из проектов, и примите Соответствующие меры Принятие решений при наличии разногласий между сторонами, участвующими в проверке. Отправьте заместителю директора по компьютеризации список проектов, которые будут проверяться на каждом этапе.
Специалист по качеству:
- Ознакомиться с документацией и заявками, полученными от Главного специалиста, подать отчет о Несоответствиях, обнаруженных на соответствующем этапе, Главному специалисту и заместителю директора по компьютеризации.
Заместитель директора по компьютеризации
- Принимайте стратегические решения относительно прогресса проекта.
Рабочий процесс
- О документации, которая должна быть доставлена ведущим специалистом группы разработки (EPGD) специалисту по качеству (EFC).
- EPGD должен проверять артефакты и документы, предоставленные его специалистами, в соответствии с их прогрессом. Главный необходимый артефакт - это контрольный пример (CP) каждого проверяемого проекта. Вам также потребуется доступ к каждому компонентному модулю этих проектов. В противном случае можно использовать неполное руководство пользователя, если оно существует. EPGD доставляет артефакты в EFC для проверки со следующего понедельника и уведомляет об этом заместителя директора по компьютеризации.
- EFC должен уведомить заместителя директора по компьютеризации о том, что он получил или не получил артефакты, которые он собирается рассмотреть, до конца рабочего дня, соответствующего понедельнику. EFC должен проверить документы по методологии, действующей для проектов развития, и подготовить отчет. Частичное (IP), если оно незамедлительно отразит обнаруженные несоответствия (NC). Они будут введены в инструмент mantis для последующего анализа и мониторинга. EFC должен проверить модули, которые он получил, и использовать в качестве основы CP, полученный от EPGD, или, в противном случае, частичное руководство пользователя, соответствующее указанным модулям. должен подготовить частичный отчет (IP), в котором, помимо оперативного отражения функциональных возможностей с проблемами,Вам нужно будет включить экраны, которые будут отражены в инструменте mantis для последующего анализа и мониторинга.
- Частичный отчет (IP) должен быть отправлен EFC в EPGD в пятницу днем, после согласования с EPGD. Вы должны отправить копию указанного отчета заместителю директора по компьютеризации. Если во время получения отчета EPGD обнаружит NC, который можно сохранить не более чем за 1 рабочий день, вы должны сообщить об этом заместителю директора по компьютеризации, чтобы он мог принять решение по этому поводу и В случае утверждения немедленно уведомите EFC. EPGD должен доставить исправленные артефакты в EFC не позднее, чем на следующий день после решения заместителя директора по компьютеризации. После подготовки окончательной версии проверки качества EFC должна отправить по почте сказал Заключительный отчет EPGD и заместителю директора по компьютеризации.
- EPGD должен разработать план действий по лечению ХН. И определите, какие из этих NC будут снова рассмотрены для проверки качества следующего периода.Эти NC должны быть включены в артефакты, которые будут доставлены в EFC в следующем периоде.
ПОЛУЧЕННЫЕ РЕЗУЛЬТАТЫ
Для поддержки предложенного решения был выбран настольный проект, разработанный с помощью IDE NetBeans и языка программирования Java, что демонстрирует применимость процедуры. Следует отметить, что проект родился вместе с идеей решения. Обзоры этого проекта проводились в течение трех лет. Ниже представлены статистические данные с их результатами.
ВЫВОДЫ
На сегодняшнем конкурентном рынке выживают только качественные продукты. Качество, хотя и является субъективным восприятием потребителя, основано на философии компании, которая стремится предлагать продукты и услуги, превосходящие ожидания клиентов. Для этого тестирование продукта является фундаментальным фактором. Кроме того, чтобы повысить вероятность обнаружения даже незначительных ошибок, важно, чтобы тесты выполнял кто-то другой. Ни для кого не секрет, что разработчику ПО сложно выявить собственные ошибки. Вот почему так важно использовать передовые и настраиваемые инструменты для автоматизации и тестирования программного обеспечения, а также иметь команду высококвалифицированных тестировщиков.
БИБЛИОГРАФИЯ
Что такое гибкие методологии? Доступно по адресу:
Что такое схватка? Доступно по адресу:
Преимущества применения гибких методологий при разработке программного обеспечения. Доступно по адресу:
Методологии гибкой разработки программного обеспечения. Доступно по адресу: http: //danielgrifol.es/metodologias-agiles-de-desarrollo-de-software/
Методология разработки программного обеспечения v3.0.doc
Якобсон, И. и др., Унифицированный процесс разработки программного обеспечения, Аддисон Уэсли, Мадрид, Испания, 2000.
Стандарт ISO / IEC 90003: 2006.
Флорес, Мариано, Применение комплексной методологии управления проектами к интегрированной системе управления бизнесом в Unión Eléctrica. (SIGEMETODO V1.0), Мастер EOI América-CENSAI, май 2001 г. Молинер, Е., Softmethod V 1.0, Softcal, 2003.
РАФАЭЛЬ, М. Программная инженерия. Методики разработки, 02.05.2008.
PATRICIO, LT, EMILIO, ASL Гибкие методологии разработки программного обеспечения.
________________
ОБ АВТОРАХ
Инженер Арлети Бетанкур Матос работает в Desoft Computer Applications Company, в частности, в территориальном подразделении Гуантанамо, у него 6 лет опыта работы в отделе компьютеризации, а 3 года назад он специально работал в роли специалиста по качеству программного обеспечения. Категория обучения: Desoft Внутренний Инструктор. Член Национальной ассоциации экономистов Кубы ANEC. Союз информатики Кубы МСЖД.
Инженер Лиан Лизетт Уртадо Линарес работает в компании Desoft Computer Applications, в частности, в территориальном подразделении Sancti Spíritus, у нее 9 лет опыта работы в отделе разработки программного обеспечения, а 5 лет назад она специально работала в роли специалиста качество программного обеспечения, проводимое национальной группой технических обзоров программных продуктов. Категория обучения: Desoft Внутренний Инструктор. Член Национальной ассоциации экономистов Кубы ANEC. Союз информатики Кубы МСЖД.
Скачать оригинальный файл
