Основы теории разработки ПО и тестирования:

1. Модели разработки ПО. Этапы в зависимости от вида.

Сравнение моделей разработки ПО;
Модель разработки ПО (Software Development Model, SDM) — структура,
систематизирующая различные виды проектной деятельности, их взаимо-действие и
последовательность в процессе разработки ПО. Выбор той или иной модели зависит
от масштаба и сложности проекта, предметной области, доступных ресурсов и
множества других факторов.
Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя
выбор стратегии, расписание, необходимые ресурсы и т.д.

Моделей разработки ПО много, но в общем случае классическими можно считать

водопадную, v-образную, итерационную инкрементальную, спиральную и гибкую.
Водопадная модель (waterfall model19) сейчас представляет скорее истори-ческий
интерес, т.к. в современных проектах практически неприменима. Она пред-полагает
однократное выполнение каждой из фаз проекта, которые, в свою оче-редь, строго
следуют друг за другом (рисунок 2.1.a). Очень упрощённо можно ска-зать, что в
рамках этой модели в любой момент времени команде «видна» лишь предыдущая и
следующая фаза. В реальной же разработке ПО приходится «видеть весь проект
целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или
что-то уточнить.
19 In a waterfall model, each phase must be completed fully before the next phase can begin. This type of model is basically used
Рисунок 2.1.a — Водопадная модель разработки ПО
 К недостаткам водопадной модели принято относить тот факт, что участие пользователей
ПО в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии
однократного сбора требований. С точки зрения же тестирования эта модель плоха тем,
что тестирование в явном виде появляется здесь лишь с середины развития проекта,
достигая своего максимума в самом конце.

Тем не менее водопадная модель часто интуитивно применяется при выпол-нении

относительно простых задач, а её недостатки послужили прекрасным отправ-ным пунктом
для создания новых моделей. Также эта модель в несколько усовер-шенствованном виде
используется на крупных проектах, в которых требования очень стабильны и могут быть
хорошо сформулированы в начале проекта (аэро-космическая область, медицинское ПО и
т.д.)
V-образная модель (V-model22) является логическим развитием водопад-ной. Можно
заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v-образная
модели жизненного цикла ПО могут содержать один и тот же набор ста-дий, но
принципиальное отличие заключается в том, как эта информация исполь-зуется в
процессе реализации проекта.

Очень упрощённо можно сказать, что при использовании v-образной модели на каждой
стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей
стадии «на подъёме». Тестирование здесь появляется уже на са-мых ранних стадиях
развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить
множество потенциальных проблем до того, как они станут проблемами реальными.

Итерационная инкрементальная модель (iterative model25, incremental model26)

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

Ключевой особенностью данной модели является разбиение проекта на от-носительно

небольшие промежутки (итерации), каждый из которых в общем случае может включать в
себя все классические стадии, присущие водопадной и v-образной моделям (рисунок
2.1.c). Итогом итерации является приращение (инкре-мент) функциональности продукта,
выраженное в промежуточном билде (build27).

Длина итераций может меняться в зависимости от множества факторов, од-нако сам

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

Итерационная инкрементальная модель очень хорошо зарекомендовала себя на

объёмных и сложных проектах, выполняемых большими командами на про-тяжении
длительных сроков. Однако к основным недостаткам этой модели часто относят высокие
накладные расходы, вызванные высокой «бюрократизированно-стью» и общей
громоздкостью модели.
Спиральная модель (spiral model30) представляет собой частный случай
итерационной инкрементальной модели, в котором особое внимание уделяется
управлению рисками, в особенности влияющими на организацию процесса разра-
ботки проекта и контрольные точки.
Схематично суть спиральной модели представлена на рисунке 2.1.d. Обра-тите
внимание на то, что здесь явно выделены четыре ключевые фазы:
 проработка целей, альтернатив и ограничений;
 анализ рисков и прототипирование;
 разработка (промежуточной версии) продукта;
 планирование следующего цикла.
С точки зрения тестирования и управления качеством повышенное внимание рискам
является ощутимым преимуществом при использовании спиральной мо-дели для
разработки концептуальных проектов, в которых требования естествен-ным образом
являются сложными и нестабильными (могут многократно меняться по ходу
выполнения проекта).

Автор модели Barry Boehm в своих публикациях31, 32 подробно раскрывает эти вопросы и
приводит множество рассуждений и рекомендаций о том, как применять спиральную
модель с максимальным эффектом.

Гибкая модель (agile model35) представляет собой совокупность различных подходов

к разработке ПО и базируется на т.н. «agile-манифесте» 36:
 Люди и взаимодействие важнее процессов и инструментов.
 Работающий продукт важнее исчерпывающей документации.
 Сотрудничество с заказчиком важнее согласования условий контракта.
 Готовность к изменениям важнее следования первоначальному плану.

Как несложно догадаться, положенные в основу гибкой модели подходы яв-ляются

логическим развитием и продолжением всего того, что было за десятилетия создано и
опробовано в водопадной, v-образной, итерационной инкрементальной, спиральной
и иных моделях. Причём здесь впервые был достигнут ощутимый ре-зультат в
снижении бюрократической составляющей и максимальной адаптации процесса
разработки ПО к мгновенным изменениям рынка и требований заказчика.
 Очень упрощённо (почти на грани допустимого) можно сказать, что гибкая модель
представляет собой облегчённую с точки зрения документации смесь ите-рационной
инкрементальной и спиральной моделей (рисунки 2.1.e37, 2.1.f); при этом следует
помнить об «agile-манифесте» и всех вытекающих из него преимуществах и
недостатках.
Главным недостатком гибкой модели считается сложность её применения к крупным
проектам, а также частое ошибочное внедрение её подходов, вызванное
недопониманием фундаментальных принципов модели.

Тем не менее можно утверждать, что всё больше и больше проектов начи- нают
использовать гибкую модель разработки.
Вкратце можно выразить суть моделей разработки ПО таблицей 2.1.a.
Таблица 2.1.a — Преимущества Недостатки Тестирование
Сравнение
моделей
разработки ПО
Модель
Водопадная
 У каждой стадии  Полная неспособ-  С середины про-
есть чёткий прове- ность адаптировать екта.
ряемый результат. проект к измене-
 В каждый момент ниям в требова-
времени команда ниях.
выполняет один вид  Крайне позднее
работы. со- здание работаю-
 Хорошо работает щего продукта.
для небольших за-
дач.

V-образная
 У каждой стадии  Недостаточная  На переходах
есть чёткий прове- гиб- кость и между стадиями.
ряемый результат. адаптируе- мость.
 Внимание тестиро-  Отсутствует
ванию уделяется с раннее
первой же стадии. прототипирование.
 Хорошо работает  Сложность устра-
для проектов со нения проблем,
стабильными тре- пропущенных на
бованиями. ранних стадиях
развития проекта.

Итерационная
инкре-ментальная  Достаточно  Недостаточная В
раннее гиб-кость внутри определённые
прототипировани итера-ций. моменты
е.  Сложность итераций.
 Простота устра-нения  Повторное
управле-ния проблем, тестиро-вание
итерациями. пропущенных на (после дора-
 Декомпозиция ранних стадиях ботки) уже прове-
 про-екта на развития ренного ранее.
управляе-мые проекта.
итерации.

Спиральная
 Глубокий анализ рисков.
 Подходит для круп-ных
проектов.
 Достаточно раннее
прототипирование.
 Высокие накладные
расходы.
 Сложность приме-нения
для неболь-ших проектов.
 Высокая зависи-мость
успеха от ка-чества анализа
рисков.

Гибкая
 Максимальное во-  Сложность реали-  В определённые
влечение заказ-чика. зации для больших моменты итераций и
 Много работы с проектов. в любой необхо-
требованиями.  Сложность постро- димый момент.
 Тесная интеграция ения стабильных
тестирования и процессов.
разработки.
 Минимизация доку-
ментации.

2. Что такое баг. Структура и содержание «идеального» бага;

баг (bug) — это отклонение фактического результата (actualresult) от ожидаемого
результата (expected result).

3. Что такое тест-кей с. Структура и содержание

«идеального» тест-кей са;
Тест кейс (тестовый случай) — это самая маленькая часть тест документации, это ситуация которая
проверяет конкретно взятое условие из требований. Одно условие может проверятся
несколькими Тестовыми Случаями (позитивными и негативными).

Из каких основных полей состоят тест кейсы:

 ID

В это поле записывается номер кейса или номер вместе с какой-то аббревиатурой к
примему «PD_Sync_123»служит для их уникальной идентификации среди других кейсов.

 Summary

Cюда записывают краткое описание проблемы. Summary (описание) должно содержать

ответ на вопрос что произошло и при каких условиях работает не верно.
  Steps

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

 Expected Result

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

 Pass/Fail

Поле служит для проставления статуса каждому тест кейсу. Если ожидаемый результат
совпадает с реальным, то проставляем pass, в противном случае ставим fail. Возможно еще
несколько статусов в зависимости от процессов и правил в IT компании

Возможны дополнительные поля для комментариев, ссылок на Баг репорт.

Виды и типы тестирования. Различные классификации
тестирования.
Типы тестирования

Принято подразделять тестирование на виды по следующим категориям:

      - по объектам (элементам) тестирования, часто разделение на виды тестов по данному

критерию называют разделением тестирования на уровни;

      - по глубине тестирования, то есть разделение тестовых испытаний на типы проводится в

зависимости от количества времени и объема тестируемых компонент программного продукта;

      - в соответствие с традиционными показателями качества, которые проверяются с их

помощью.

      Уровни тестирования

      Модульное тестирование (Автономное или Unit-тестирование). На данном уровне тестируются

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

      Комплексное тестирование (Сборочное тестирование, integration testing или interface testing).
На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей
системы, чаще всего некоторая взаимодействующая между собой группа элементов.

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

      Приемочное тестирование (Приемо-сдаточное тестирование или acceptance testing). На

данном уровне завершенное приложение (система) тестируется заказчиком.
      Операционное тестирование (Release Testing). Даже если система удовлетворяет всем
требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет
свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы.
Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести
операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде
эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими
системами, смежными в области бизнеса или в программных и электронных окружениях;.

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

      Виды тестирования

      Инсталляционное тестирование (Installation testing). Проверка правильности установки

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

     Дымовое тестирование (проверка на дым, Smoke testing). Первый прогон программы (после
написания или после внесения существенных изменений). Как правило, используется для
определения, готова ли программа для проведения более обширного тестирования. Основная
цель такого тестирования - выявление проблем «лежащих на поверхности» – тестируется чаще
всего основная бизнес логика программы.

      Функциональное тестирование (Functional testing). Под данным типом тестирования

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

      Регрессионное тестирование (Regression testing). Повторное тестирование после внесения

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

      Интеграционное тестирование (Integration testing). Проверка скомбинированных компонентов

прикладной программы с целью определения корректности их совместного функционирования

      Тестирование графического интерфейса пользователя (User Interface testing). Тестирование

интерфейса – экранов, кнопок и т.д. Цель - обнаружение ошибок в интерфейсе и поиск ошибок в
функциональности посредством интерфейса

     Тестирование производительности (Performance testing). Проверка скорости работы системы в

имитационной и реальной средах.

      Нагрузочное тестирование (Load testing). цель этого тестирования – оценить способность
системы правильно функционировать при некотором превышении планируемых нагрузок при
реальной эксплуатации (система имеет некоторый «запас прочности»).

      Стресс тестирование (Stress testing). Является одним из разновидностей тестирования на

производительность, при которой проверяется, что система адекватно реагирует нате или иные
стрессовые ситуации, например при недостатке ресурсов (дискового пространства, обрывов сети и
т.д.).
      Конфигурационное тестирование (Configuration testing). Конфигурационное тестирование –
тестирование работы на различных платформах. Различные варианты аппаратной конфигурации,
версии операционной системы и окружения.

      Классификация тестов на виды производится в соответствие с традиционными показателями

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

      Для проверки функциональности (functionality) ПО необходимо испытать приложение на

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

      Тестирование надежности (reliability) ПО производится с целью проверки нефункциональных

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

      Тестирование удобства использования (usability) ПО (нефункциональные требования)

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

      Тестирование производительности (performance) ПО выполняется с целью удостовериться, что

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

По запуску кода на исполнение:

o Статическое тестирование — без запуска.
o Динамическое тестирование — с запуском.

 По доступу к коду и архитектуре приложения:

o Метод белого ящика — доступ к коду есть.
o Метод чёрного ящика — доступа к коду нет.
o Метод серого ящика — к части кода доступ есть, к части — нет.

 По степени автоматизации:
o Ручное тестирование — тест-кейсы выполняет человек.
o Автоматизированное тестирование — тест-кейсы частично или полно-стью
выполняет специальное инструментальное средство.

 По уровню детализации приложения (по уровню тестирования):

o Модульное (компонентное) тестирование — проверяются отдельные небольшие
части приложения.
o Интеграционное тестирование — проверяется взаимодействие между несколькими
частями приложения.
o Системное тестирование — приложение проверяется как единое це-лое.
 По (убыванию) степени важности тестируемых функций (по уровню функци-
онального тестирования):
o Дымовое тестирование (обязательно изучите этимологию термина — хотя бы в
Википедии109) — проверка самой важной, самой ключевой функциональности,
неработоспособность которой делает бессмыс-ленной саму идею использования
приложения.

Тестирование критического пути — проверка функциональности, ис-пользуемой

типичными пользователями в типичной повседневной де-ятельности.
o Расширенное тестирование — проверка всей (остальной) функцио-нальности,
заявленной в требованиях.

 По принципам работы с приложением:

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

4. Задачи тестировщика на этапах разработки ПО;

 обеспечить очищения ПО от ошибок (Вы не можете предоставить 100% покрытие,
но Вы должны сделать все возможное, и гарантировать, что очевидные ошибки
исправлены);
 убедить, что ПО отвечает оригинальным требованиям и спецификации;
 обеспечить уверенность в ПО (пользователям, заказчикам и т.д.).

Из каких этапов состоит процесс

тестирования?
Инициация – событие, которое извещает команду тестирования о необходимости сессии
тестирования, а также гарантирует выполнение требований к продукту для проведения
тестирования.

Выявление требований – пожалуй, один из главных шагов в процессе тестирования. Неизвестны

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

Отбор тестовых случаев – отбор наиболее показательных, значимых и воспроизводимых тестовых

случаев.
Проведение проверок –
Фиксация результатов – создание внутренней и внешней тестовой документации в
формализованном виде или в виде записей и т. п.
Анализ результатов – вынесение решения о соответствии проверенного продукта требованиям.
Формализация данного решения и его обоснование в виде отчета о тестировании.
Передача информации о соответствии продукта требованиям. Формально: передача внешней
тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии
тестирования.

Документы, создаваемые тестировщиком на различных

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

Внешняя документация:

 Замечание – короткая записка, комментарий о небольшой неточности в реализации

продукта.
 Баг-репорт – описание выявленного случая несоответствия производимого
продукта требованиям, к нему выдвигаемым – ошибки или ее проявления.
 Запрос на изменение (улучшение) – описание неявных/некритичных косвенных
требований, которые не были учтены при планировании/реализации продукта, но
несоблюдение, которых может вызвать неприятие у конечного потребителя. И
пути/рекомендации по модификации продукта для соответствия им.
 Отчет о тестировании (тест репорт) – документ, предоставляющий сведения о
соответствии/ несоответствии продукта требованиям. Может так же содержать
описание некоторых подробностей проведенной сессии тестирования, например,
затраченное время, использованные виды тестирования, перечень проверенных
случаев и т. п. В идеальном варианте фраза вида «Тест пройден. Ошибка не
воспроизводится/Функционал работает корректно/Соответствует требованиям»
означает, что продукт или его часть полностью соответствует требованиям прямым
и косвенным (в производстве ПО).

Внутренняя документация:

 Тест-план (план тестирования) – формализованное и укрупненное описание одной

сессии тестирования по одному или нескольким направлениям проверок. Т.е.
перечень направлений проверок, которые должны быть проведены в рамках сессии
тестирования (и, сообразных этим направлениям, требований). Также может
содержать в себе необходимую информацию об окружении, методике, прочих
условиях важных для показательности данной сессии тестирования. Под
направлением проверок также может пониматься более детализированная тестовая
документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые
сценарии, на которую необходимо опираться при проведении сессии тестирования.
Основная цель документа – описать границы сессии тестирования,
стабилизировать показательность данной сессии.
 Тестовый сценарий – последовательность действий над продуктом. Фактически
при успешном прохождении всего тестового сценария мы можем сделать
заключение о том, что продукт может выполнять ту или иную возложенную на
него функцию.
 Тестовый комплект – некоторый набор формализованных тестовых случаев
объединенных между собой по общему логическому признаку.
  Чек-лист (лист проверок) – это документ, описывающий что должно быть
протестировано.
 Тестовый случай (тест-кейс) – формализованное описание одной показательной
проверки на соответствие требованиям прямым или косвенным.

Хорошо структурированная, поддерживаемая, читаемая, организованная и

доступная тестовая документация позволяет в долгосрочной перспективе:

Продуктная документация (product documentation, development documenta-tion 52)

используется проектной командой во время разработки и поддержки продукта. Она
включает:
o План проекта (project management plan53) и в том числе тестовый план (test plan54).
o Требования к программному продукту (product requirements document, PRD55) и
функциональные спецификации (functional specifications56 doc-ument, FSD57; software
requirements specification, SRS58).
o Архитектуру и дизайн (architecture and design59).
o Тест-кейсы и наборы тест-кейсов (test cases60, test suites61).
o Технические спецификации (technical specifications 62), такие как схемы баз данных,
описания алгоритмов, интерфейсов и т.д.

 Проектная документация (project documentation63) включает в себя как про-

дуктную документацию, так и некоторые дополнительные виды документа-ции и
используется не только на стадии разработки, но и на более ранних и поздних
стадиях (например, на стадии внедрения и эксплуатации). Она вклю-чает: