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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.jpg

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

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

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

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

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

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

2.jpg

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

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

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

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

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

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

Что дальше?

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

И еще много интересного!

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

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

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

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

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

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

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