В учебных программах по дисциплине "Обеспечение качества и тестирование программ" есть вопросы:

1. "Модели разработки программного обеспечения и место тестирования в них. Процесс разработки программного обеспечения и место тестирования в нем. Модели жизненного цикла программного обеспечения: каскадная, итеративная модели. Современные методологии разработки программного обеспечения".
2. "Жизненный цикл программного обеспечения. Понятие жизненного цикла программного обеспечения и жизненного цикла разработки. Модели жизненного цикла. Методологии разработки".
3. "Модель планирования и ведения процесса тестирования на основе итеративной модели разработки программного обеспечения".
4. "Методологии разработки программного обеспечения".
5. "Гибкие технологии разработки программного обеспечения".

В программе обучения базового уровня International Software Testing Qualifications Board "Сертифицированный тестировщик" указано на необходимость:

1. "Описать связи между разработкой, тестированием и результатами этих работ в жизненного цикла разработки программного обеспечения, приводя примеры проектов и типов работ".
2. "Обосновать, что модели разработки программного обеспечения должны быть адаптированы в контексте проектов, в которых они используются, и характеристик разрабатываемых продуктов".
3. "Назвать характеристики качественного тестирования, которые применимы к любой модели жизненного цикла".

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

«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений», Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 2001. 300-301, 362-363 страницы:

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

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

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

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

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

Модель разработки программного обеспечения — это тот принцип, по которому руководитель проекта составляет план выполнения задач. О клас­сических моделях разработки, их достоинствах и недостатках подробно рассказывалось в главе 12. Пример организации работ по методу водопада приводился в главе 3. Этот же метод мы еще раз рассмотрим с другой точки зрения в главе 14.

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

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

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

"Быстрое тестирование", Роберт Калбертсон, Крис Браун, Гэри Кобб. Издательский дом "Вильямс", 2002. 23, 25, 50, 52, 62/379 страница:

Когда процесс имеет отношение к созданию того или иного продукта, это часто называется жизненным циклом. По той же причине разработка программного про­дукта называется жизненным циклом программного продукта (software life cycle). Жизнен­ный цикл программного продукта может быть описан разными способами, в то же время для этой цели часто используется модель, которая представляет основные свойства процесса, сопровождаемые определенным сочетанием текста и иллюстраций.

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

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

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

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

Прототипы используют в моделях жизненных циклов, отличных от каскадных. По существу, в случае эволюционного прототипа оно может стать основой процесса разработки. Одной из наиболее сложных моделей жизненного цикла является спиральная модель, разработанная Боемом [42]. Спиральная модель реализует подход, учитывающий риски, она разбивает проект на некоторую последовательность "мини-проектов", каждый из которых решает ту или иную крупную задачу. После того как все основные риски будут учтены, модель завершается обычной каскадной разработкой конечного программного продукта.

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

"Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование", Рекс Блэк, Москва, Лори, 2006, 19-23/545 страницы:

Место тестирования в моделях жизненного цикла разработки. Ранее упоминались две методолгии разработки: каскадная модель (и ее вариация - V-модель) и инкрементная модель...

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

Сколько всего существует моделей жизненного цикла? Поверхностный поиск в Интернете выдает ссылки на десятки различных методогий для объектно-ориентированного программирования. Некоторые из этих методолгий говорят об особых жизненных циклах, другие более легковесны, с менее строгими ограничениями на порядок фаз и сами фазы, с большим акцентом на людей, нежели на процессы. На Cetus Links - Object-Orientation представлен целый набор ссылок связанных с объектно-ориентированным программированием, включая ссылки на методологии Object-Oriented Analysis & Design: Methods. Также существуют различные web-сайты, описывающие легкие технологии, рассказывающие о так называемых быстрых методах, в частности об экстремальном программировании (Extreme Programming). Смотрите, например, The New Methodology.

Насколько точно эти модели описывают то, что реально имеет место? Приведем высказывание, на авторство которого претендует и Эдвардс Деминг (William Edwards Deming), и Джордж Бокс (George Box): "Все модели неверные, некоторые модели полезны". До определенной степени расптространение разных моделей указывает на различие взглядов и полемику, существующие вокруг спососбов создания систем. Чем более популярны жизненный цикл и методолгия, тем больший огонь критики они на себя вызывают. Например, некоторые специалисты писали, насколько ужасна V-модель. Тем не менее она по-прежнему широко применяется. Это не просто результат инерционности и ленности мышления. Вариантом, интуитивно понятным, широко известным и более предпрочтительным, нежели хаос, часто является V-модель.

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

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

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

Кодируй и исправляй (Code and Fix). Подход к разработке, исключающий большинство действий по планированию, сбору требований и проектированию, начинающийся непосредственно с кодирования системы с последующим исправлением обнаруженных ошибок. Обнаружение ошибок ведется посредством формального тестирования независимой группой тестировщиков, либо при помощи неформального (ad hoc) тестирования, либо только при отладке. Данная модель может быть удобна для небольших, несложных проектов разработки или поддержки с невысоким уровнем рисков. Модель не подходит для больших, сложных проектов и проектов с высоким уровнем риском.

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

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

«Верификация программного обеспечения», Сергей Владимирович Синицын, Никита Юрьевич Налютин. МИФИ, Курс лекций, 2006, 10 страница:

"Сертифицированный тестировщик Программа обучения Базового уровня". Версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Андрей Конушин (председатель), Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 27/101 страница:

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

V-модель (Последовательная модель разработки). Хотя разновидностей V- модели существует много, все они используют четыре уровня тестирования, соответствующие четырем уровням разработки. Четыре уровня, используемые в данном пособии, это:

1. Компонентное (модульное) тестирование
2. Интеграционное тестирование
3. Системное тестирование
4. Приемочное тестирование

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

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

Итеративно-инкрементные модели разработки. Итеративно-инкрементный процесс разработки – это процесс, основывающийся на требованиях, дизайне, сборке и тестировании системы, созданной в результате серии коротких циклов разработки. Примеры: прототипирование, быстрая разработка приложений (RAD), Rational Unified Process (RUP) и гибкие (agile) методологии разработки. Система, получаемая в результате итерации, может быть протестирована на нескольких уровнях в процессе разработки каждой итерации. Доработка, добавляемая к разработанному ранее, провоцирует расширение системы, которое также должно быть протестировано. Регрессионное тестирование становится все более и более важным от итерации к итерации. Верификация и валидация могут выполняться на каждом этапе доработки системы.

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

1. Каждому процессу разработки соответствует свой процесс тестирования
2. Каждый уровень тестирования имеет свои цели тестирования
3. Анализ и дизайн тестов для какого-либо уровня тестирования должны начинаться одновременно с соответствующей деятельностью разработчиков
4. Тестировщики должны быть вовлечены в процесс просмотра и рецензирования документов, как только становятся доступными их предварительные версии.

Эта заметка-конспект является ответом на один из экзаменационных вопросов по учебной дисциплине "Обеспечение качества и тестирование программ" и вопроса программы обучения базового уровня International Software Testing Qualifications Board "Сертифицированный тестировщик". Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

21.08.2017