Повышение качества компьютерных программ

- kbrbank

Повышение качества компьютерных программ

На данный момент компьютерные программы широко применяются в коммерческих и национальных структурах, а также в повседневной судьбе. Серьёзное место программы занимают в деятельности коммерческих банков, довольно часто определяя успех развития бизнеса.

Значение качества для компьютерных программ

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

Все эти показатели характеризуют уровень качества программы. Для проверки безопасности программ смогут употребляться как обеспечения качества и общие технологии тестирования, так и используемые специально для этих направлений (к примеру, автоматизация попыток взлома, подбора ключа либо пароля и т. п.).

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

В настоящей статье мы разглядим обеспечения качества организации и современные направления тестирования при создании компьютерных программ.

Понятие качества

Понятие качества по большому счету, а для приложений – тем более возможно трактовать достаточно обширно. В определение качества смогут включаться разные составляющие. Хорошим определением качества есть соответствие продукта ожиданиям/потребностям клиента/клиента/потребителя.

С данной точки зрения обеспечение качества программы начинается с согласования и определения с клиентами/потребителями главных функциональных и нефункциональных требований. Из поля зрения нужно не потерять в первую очередь нефункциональные, системные требования, поскольку функциональные в большинстве случаев закреплены в проектной документации, тогда как нефункциональные начинают уточняться уже в ходе эксплуатации программы.

Подходы к обеспечению качества

Чтобы разрабатывать приложения высокого качества, нужно применять комплексные среды разработки, снабженные инструментами, разрешающими разработчикам создавать качественный код и проводить особые испытания для подтверждения определенного уровня качества.

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

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

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

обеспечения качества и Проблемы тестирования

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

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

Само собой разумеется, в таковой ситуации на управление тестированием и средами уходит большое количество времени, в следствии отсутствует интеграция тестирования с прочими процессами и разработками, кроме этого довольно часто нет интеграции кодов и тестов.

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

В принципе, тестер может вручную сравнить ветхие и новую версию программы (тестирование способом «белый/прозрачный ящик») и распознать ветки и изменения кода, каковые нужно протестировать. Так, связывание трансформаций кода с тестированием все-таки происходит, не смотря на то, что и ручным, медленным и не совсем надежным методом.

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

Бывает сложно отследить покрытие тестами конкретного требования к продукту, как полно и глубоко тестируется требование, отследить связи. Наиболее значимый вопрос – какое количество нужно «перетестировать», в случае если поменялся некий количество кода.

Наконец, еще более занимательный вопрос содержится в том, сколько осталось недостатков в протестированной программе. Протестировать все на 100% нереально. Определить количество оставшихся неточностей и узнать их критичность кроме этого нереально. Возможно лишь оценить их опосредованными способами; минимизировать либо снизить влияние на конечный продукт либо бизнес-процессы, каковые этот продукт снабжает.

подобные метрики и Эта проблема требуют для собственного рассмотрения отдельной статьи.

Перечисленные неприятности делают процесс тестирования непрозрачным для проектного менеджмента. Непрозрачность ведет к неуверенности в качестве поставляемого кода и продукта.

Итак, как решить подобные неприятности и минимизировать их влияние на внедрение и производство программных продуктов?

Среды разработки и инструменты управления тестированием

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

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

В случае если какая-то часть функционала по окончании внесения трансформаций не протестирована, не может быть гарантии надежной и надёжной работы данной части приложения. Критически ответственные для бизнеса приложения должны внедряться лишь по окончании многоуровневой проверки технических и пользовательских качеств функционирования, и проверки нефункциональных взаимодействия и параметров с интегрированными приложениями технического парка организации.

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

Управление средами нужно организовать на несложном понятийном уровне, с разрешением распрей борьбы за ресурсы. Обязана находиться возможность назначать автоматические и ручные скрипты на выполнение на определенных средах (и на конкретных исполнителей). В обязательном порядке обязан вестись протокол прохождения тестов.

При происхождении неточностей описание недостатков с большой сопроводительной информацией (которая заполняется машинально) должно скоро и комфортно заводиться в совокупность. При воспроизведении неприятности разработчик получает возможность поднять правильный снимок состояния совокупности (snapshot), на котором появилась неприятность. Очень полезно, в то время, когда при проведении автоматического тестирования сведения о недостатках заносятся машинально. Нужно, дабы было реализовано управление и хранение (с контролем предположений) библиотек test cases, сред, недостатков, дорог решения проблем, знаний и т. п.

Эффективность тестирования быстро возрастает, в то время, когда оно интегрировано с кодом. Очень полезно, в то время, когда связи прослеживаются до требований и возможно контролировать степень и покрытие протестированности каждого требования. Сценарий сборки в большинстве случаев включает в себя построение исполняемых программ, получение отчета о том, какие конкретно тесты нужно повторить из-за трансформаций в собранной совокупности (impacted tests).

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

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

распределение обеспечения ответственности и Процесс качества

Как выяснить границы и рамки ответственности при обеспечении качества, кто отвечает за качественный итог работы либо продукта?

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

Нереально протестировать программу на 100% из-за сложности современных программ. К примеру, дабы всецело протестировать программу всего с 300 переменными, потребуется больше времени, чем время судьбы Вселенной. Успешное тестирование не говорит о том, что в программе не осталось недостатков, а лишь демонстрирует ее работоспособность для охваченных тестовыми техниками и тестами случаев.

Исходя из этого досконально тестируются самые критичные и значительно чаще применяемые области программы.

Из этого следует, что «нельзя полагаться на совокупности обеспечения качества на 100%», «тестеры не занимаются обеспечением качества» .

Иначе говоря обеспечение качества – более широкое понятие, чем это принято вычислять. Обеспечение качества хорошо переплетено со всеми процессами разработки и оптимизируется не только по инженерным, но и по экономическим и политическим параметрам.

Нужно выделить важность становления процесса обеспечения качества на самом высоком уровне. Для этого необходимо руководствоваться положениями обширно распространенных руководств и стандартов: ISO, CMMI, ГОСТ, LEAN Six Sigma, SWEBOK, PMBOK, BABOK и др. При сопровождении сервисов и программ возможно порекомендовать применение стандартов ITSM, ITIL, COBIT…

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

Основное – обученные и мотивированные люди, а инструментарий – лишь помощь поставленного процесса.

Уровень качества

Довольно часто дискутируется вопрос определения уровня качества. Уровень качества — понятие субъективное: любой – пользователь, разработчик, маркетинговый менеджер, продвигающий продукт на рынок, аналитик либо тестер – оценивает его по-своему. Верно выстроенный процесс разработки программ с обратной связью обязан сводить к минимуму различия в этих оценках.

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

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

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

Завершение тестирования

Еще один вопрос жизни и смерти – определение готовности ПО к выпуску (поставка клиенту либо выход на рынок). Кто принимает это решение? Какая информация нужна для вывода о готовности программы?

В какой момент времени это решение должно быть принято?

В самой сфере разработчиков программ представлен разносторонний взор на принятие ответа по этому вопросу. Ответ выглядит по-различному с позиции продуктового либо проектного менеджера, менеджера по качеству и разработчиков либо тестеров ПО.

Не все отысканные недостатки будут исправлены, в особенности в конце проекта. Сейчас критично ответ: продолжать ли искать недостатки? Так, большая часть важных недостатков должны быть уже распознаны при применения подхода тестирования, основанного на рисках (risk based testing), в то время, когда критичный и самый применяемый функционал, и тот функционал, в котором неточности самый возможны, тестируется прежде всего.

Предстоящий поиск недостатков не повысит уровня качества, тем более что не все отысканные неточности успеют исправить.

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

Рис. 1. График зависимости прибыли от уровня качества

Довольно часто ответ о готовности продукта к применению принимается стороной разработки. Но верным направлением для принятия для того чтобы решения будет проведение приемочного тестирования пользователями, администраторами либо работой помощи, т. е. теми, кто конкретно будет применять программу.

Процесс принятия ПО к внедрению в эксплуатацию включает два ответственных ответы: ответ о внутренней готовности (readiness) и ответ о приемке и выпуске в свет (acceptance). Ответ о внутренней готовности принимается инженерной командой перед тем, как демонстрировать элементы совокупности клиенту. Ответ о приемке принимается клиентом на основании информации, взятой на протяжении оценки готовности, и дополнительного тестирования интегрированных элементов на протяжении приемки.

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

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

Применим кроме этого подход Minimal Marketable Functionality , в то время, когда определяется уровень готовности релиза. Имеется минимальное множество приемлемо трудящегося функционала, при котором целесообразно выводить продукт на рынок (сдавать клиенту). Продукт выпускается, в то время, когда минимально целесообразный комплект функциональности реализован, достиг определенного уровня качества и принят клиентом.

Рис. 2. Схема модели минимальной функциональности

Нужно как возможно раньше затевать процесс сотрудничества (обратной связи) с принимающей стороной. Тогда возможно динамически замечать прогресс уровня качества. Каскадная методика (waterflow) этого не разрешает, а инкрементальные agile-процессы, а также XP (eXtreme programming), снабжают стремительную обратную сообщение.

Критерии готовности

В итоге для принятия ответа о готовности продукта употребляется целый комплект параметров готовности как отдельной функциональности, так и всей версии.

Критерии готовности функциональности:

• специфицированы и утверждены критерии приемки;
• готовы скрипты тестирования (а также автоматизированные), демонстрирующие достижение параметров;
• готов код, предназначенный для приемочного тестирования;
• код и тесты зарегистрированы в совокупности контроля предположений;
• программа из поставленного кода удачно компилируется и собирается на сервере сборки;
• приемочные тесты (unit, component, system) для выстроенной программы удачно выполнены;
• ни один из всех остальных приемочных и блочных тестов не закончился неуспешно;
• пользовательская документация готова и обновлена;
• обладатель продукта принял итог трансформаций.
Критерии готовности версии:
• целый рыночно значимый функционал включен в версию-кандидат;
• инспекция безопасности совершена удачно;
• тестовая команда уверена, что ни одна из добавленных функций не имеет значимого риска появления неприятностей на рабочей (продуктовой) среде, выполнены следующие параметры:
— все найденные неточности высокой и высокой критичности исправлены,
— совершено конфигурационное тестирование,
— совершено минимальное тестирование локальной версии (в разрезе государств, языков),
— совершено минимальное тестирование глобального продукта,
— проверена доступность,
— проверена достаточность уровня опыта пользователей,
— проверена производительность;
• достигнуто соответствие бизнес-целям;
•созданы понятные, лаконичные руководства по откату и установке для команды помощи;
• созданы база решения знаний и листы проблем для применения представителями работы помощи пользователей;
• любая включенная функция была показана и принята обладателем продукта.

Основываясь на проверке исполнения перечисленных параметров, вероятно совершенно верно и вовремя принимать ответ о выпуске продукта клиенту.

Что дальше?

Во второй части отечественной статьи предполагается рассмотрение следующих тем:
• дизайн программ для тестирования (под тестирование);
• количественные метрики для требований;
• методики тестирования ниже уровня интерфейса с пользователем;
• автоматизация тестирования;
• инструментарий помощи автоматизации обеспечения тестирования и процессов качества;
• конкурентный анализ и тестирование производительности параллельных совокупностей;
• сетевая эмуляция;
• «поведенческо-ориентированный» подход к разработке программ;
• «верные» unit tests;
• Domain-Driven Design (DDD);
• другие виды тестирования.

И еще большое количество увлекательного!

Александр Горшков, Консультант Департамента консалтинга NVision Group

В практике реализации процесса тестирования отмечается два варианта, в то время, когда тестирование реализовывают сотрудники:
• подразделения тестирования;
• разных подразделений.

В первом случае требуется решить вопрос тестирования глубоко своеобразного функционала, к примеру информационной безопасности. Во втором случае остро стоит вопрос сотрудничества между разными подразделениями, обеспечения всех сотрудников лицензиями и их обучения. Организация сотрудничества между подразделениями есть самый важным моментом в обоих вариантах организации тестирования.

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

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

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

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

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

При автоматизации процесса тестирования нужно учитывать, что часть функционала автоматизировать будет запрещено. Для некоторых ответов нереально создать универсального механизма автоматической подготовки тестовых стендов. Создание тестовых сред не заканчивается процессом копирования продуктивной среды. Соблюдение требований отечественного законодательства (а также Закона № 152-ФЗ) требует удаления из баз данных настоящей информации.

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

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

FPS до небес — Как повысить производительность ПК в играх, при записи видео и работе — эпичный гайд!

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: