Введение
Проектирование и разработка программного обеспечения считаются достаточно молодыми сферами деятельности, однако они широко распространены и растут быстрее, чем когда-либо прежде. Индустрия программного обеспечения в настоящее время считается одной из главных опор экономического роста во многих странах. Софтверные компании, стремящиеся к достижению удовлетворенности клиентов, часто сталкиваются со сложными проблемами поставки высококачественных продуктов.
Качество программного обеспечения как необходимость
С тех пор как программное обеспечение стало неотъемлемой частью нашей повседневной жизни, спрос на него значительно увеличился. Сегодня высокое качество воспринимается как обязательный компонент программного обеспечения. Поэтому очень важно вовлечь группы контроля качества в процесс планирования и реализации проектов с самого начала. Тем не менее до сих пор существуют компании, которые считают, что задача обеспечения качества ПО решается путем тестирования в конце жизненного цикла разработки.
Нужно иметь в виду, что рынок предлагает множество альтернатив, в том числе бесплатное ПО с открытым исходным кодом. Кроме того, постоянно растет осведомленность клиентов и конечных пользователей о качестве программного обеспечения, которое они покупают. Приложения или корпоративные системы, которые демонстрируют низкую производительность или некачественное взаимодействие с пользователями, будут вытеснены другими продуктами. Сегодня софтверным компаниям необходимо заботиться о качестве своей продукции как никогда ранее.
Сквозное обеспечение качества программного обеспечения
Обеспечение качества ПО на этапе тестирования (после выполнения всех задач разработки) обходится дорого и подвергает большому риску весь проект. На этапе тестирования разработчики делают все возможное, чтобы в их коде было минимальное количество дефектов. Пока менеджеры и клиенты предвкушают выход на рынок готового программного обеспечения, тестировщики лихорадочно ищут в нем новые дефекты.
Вопрос в том, зачем многие софтверные компании заставляют группу разработки строго выдерживать сроки, не обращая внимания на несовершенство кода, большое количество дефектов, архитектурные ошибки и отсутствие документации?
Спешка при разработке, возможно, экономит время в краткосрочной перспективе, но в конечном итоге приводит к большим затратам времени на переделки, если основные вопросы разработки не были продуманы с самого начала. Это заставляет направлять ресурсы на исправление ошибок и реинжиниринг кода вместо того, чтобы вкладывать их во что-то более полезное. Группы разработки знают все это наизусть, но придирчивые клиенты, требовательные группы продаж и уверенность некоторых разработчиков в том, что они пишут бездефектный код, часто вынуждают заниматься обеспечением качества после окончания написания кода.
Стандарты разработки программного обеспечения и их использование
Следует отметить, что компании не обязаны следовать каким-либо конкретным стандартам разработки ПО или определенным процессам. Существуют различные стандарты типичного цикла разработки ПО (software development life cycle - SLDC), такие как IEEE, ISO - 12207 и CMMI. Цель этих стандартов - гарантировать, что конечный продукт будет соответствовать требованиям рынка и удовлетворять конечных пользователей.
Сегодня продается много программ, мобильных приложений и даже корпоративных систем, которые были разработаны без использования каких-либо стандартов. Тем не менее люди все равно покупают их. Игнорирование стандартов не равноценно снижению качества программного обеспечения и уменьшению спроса на конечный продукт (если это не жизненно важные программы, такие как медицинское ПО, которое требует одобрения FDA внутри США и должно соответствовать одному из стандартов). Проблема не в следовании стандартам. Проблема в игнорировании или принижении значения качества ПО.
Эта статья не об SDLC-стандартах и не превосходном процессе разработки и тестирования. Прежде всего важно понимать, что качество является важнейшим компонентом любого программного обеспечения. Компании не обязаны иметь высокопрофессиональные методики и группу обеспечения качества, но по крайней мере они должны принять саму культуру и соответствующие методики.
Методики обеспечения качества ПО в рамках всего жизненного цикла разработки
В этом разделе представлены методики, позитивно влияющие на качество ПО и не создающие слишком высокую нагрузку или проблемы для группы разработки. Они заслуживают рассмотрения при разработке и тестировании.
Анализ требований
Согласитесь, что расходовать средства на создание неправильной функциональности бессмысленно. Анализ требований к ПО перед началом нового этапа разработки позволяет минимизировать дефекты и учесть пожелания клиентов. Анализ требований до реализации помогает продумать возможные изменения и преодолеть разногласия, которые могут возникнуть на протяжении жизненного цикла проекта. Группа разработчиков должна согласовать с заказчиком все бизнес-детали, которые необходимо реализовать. Анализ требований также можно выполнять с помощью прототипов и моделей предметной области. Выполнив эту небольшую работу до начала фактической реализации, группа разработки получает отличную отправную точку для своего проекта или итерации разработки. Убедившись до начала реализации, что все заинтересованные стороны достигли консенсуса и каждый член группы одинаково понимает задачу, заказчик и руководство могут быть уверены в получении качественного продукта по завершении цикла разработки.
Анализ и сквозной контроль кода
Анализ кода является одной из наиболее эффективных методик разработки ПО. Он прямо влияет на снижение количества дефектов (позволяя находить ошибки заблаговременно) и повышение качества кода и дизайна ПО. Это уменьшает необходимость значительного рефакторинга и очистки кода в следующих версиях.
Группа может договориться о принципах кодирования и дизайна, учитывающих требования проекта и детали реализации. Этим принципам должна следовать вся группа, и каждый раз после разработки новой функции один или несколько членов группы (кроме автора) должны анализировать новый код с целью поиска ошибок кодирования и дизайна.
Эта методика помогает группе во многих отношениях, в том числе в повышении качества кода и дизайна, а также в минимизации и предотвращении дефектов. Кроме того, она позволяет всем членам группы быть в курсе работы друг друга, облегчает передачу работы и повышает компетентность группы в различных программных компонентах и функциях. Члены группы совместно работают над проверкой и подтверждением качества кода и реализации дизайна. Они получают непосредственную обратную связь от своих коллег. Налицо двойная выгода: повышается качество кода и растет компетентность группы.
Сессионное тестирование
Методика сессионного тестирования, разработанная Джеймсом Бахом (James Bach), заключается в разделении тестовой нагрузки на сеансы, каждый из которых решает свою задачу (получение четко определенных результатов, ожидаемых от данного сеанса). Каждый сеанс имеет определенную продолжительность (от 20 до 40 минут), и тестировщик должен работать непрерывно в течение сеанса.
Тестировщик как бы помещается на некоторое время в замкнутое пространство тестирования, что позволяет ему сосредоточиться на поиске дефектов в программном обеспечении. В ходе сеанса выполняется набор контрольных тестов, но тестировщик может также выполнять тестирование в свободном режиме. Таким образом, сессионное тестирование представляет собой смесь формального и инновационного тестирования, поскольку дает простор исследованию и интуиции - тестировщик получает время и свободу действий, чтобы выявить необычные дефекты или углубиться в конкретные детали программного обеспечения.
В ходе сеанса тестировщик должен документировать поведение ПО, делать снимки состояний и записывать поведение ПО при конкретных входных данных и настройках. После завершения сеанса его стенограмма обсуждается с руководителем группы или техническим менеджером. В ходе обсуждения определяется, какое поведение считать нормальным, а какое нет, и на основе этого обсуждения создаются отчеты о дефектах.
На рисунке 1 изображена методика сессионного тестирования. Для любого изменения в ПО планируются сеансы тестирования, каждый из которых имеет определенные цели и задачи. Во время сеанса тестировщик выполняет либо контрольные тесты, либо свободное тестирование, либо то и другое. После завершения сеанса составляется отчет об обнаруженных дефектах.
Рисунок 1. Процесс сессионного тестирования
Тестирование, основанное на рисках
Обычно группы разработки часто выпускают релизы одного и того же ПО, потому что в процессе разработки происходит много изменений (больших и малых). Для обеспечения качества важно тщательно тестировать ПО после каждого основного релиза. Однако на это уходит много времени, и, кроме того, трудно выполнить полный набор регрессионных тестов для всего ПО для каждого релиза. Можно, конечно, тестировать только измененные функции или резко сократить набор контрольных тестов, но это опасно. Исправление ошибки в каком-нибудь фрагменте может нарушить в коде что-нибудь еще.
Компромиссным вариантом является тестирование, основанное на рисках. Его основная идея состоит в упорядочении функций и видов отказов ПО в убывающем порядке, от самых важных или рискованных до проверенных функций и простых рисков (одним из инструментов, позволяющих это сделать, является методология FMEA - анализ видов и последствий отказов). В условиях сжатых сроков тестирования нового релиза тестировщик с помощью такого списка может сосредоточиться на проверке недавно внесенных изменений. Это позволит убедиться, что изменения не нарушили наиболее важные функции и не привели к наиболее серьезным рискам.
Заключение
Каждая компания стремится занять самое высокое положение на ИТ-рынке, а потому должна прилагать усилия для создания хорошего программного обеспечения, которое нравится пользователям. К сожалению, иногда давление клиентов или нетерпение руководства заставляет разработчиков пренебрегать качеством программного обеспечения, и они поставляют готовый продукт, не отвечающий ожиданиям. Низкое качество проявляется только когда программное обеспечение перестает работать.
Практики и методики, обсуждаемые в данной статье, охватывают весь жизненный цикл разработки - анализ требований, проектирование, разработку и тестирование. Они показывают, что предотвратить дефекты гораздо проще, чем тушить пожар в конце проекта, когда технический долг и стоимость изменений высоки.
В статье освещаются роль и значение качества ПО, а также показывается, что игнорирование качества может существенно затруднить компаниям достижение их бизнес-целей. Кроме того, статья знакомит читателя с наиболее простыми и эффективными методиками, которые позволяют группам разработки экономить время, деньги и усилия, одновременно повышая качество продукта.