Почему тестирование разбито на отдельные этапы?

Ответ из ISTQB Foundation Level Exam: У каждого этапа своя цель.

В большинстве случаев тестирование разбивается на несколько этапов в зависимости от развития самого кода и стремления к эффективному использованию ресурсов. Давайте рассмотрим пример приложения, которое включает в себя как службы REST, так и веб-интерфейс, в agile команде, которая предоставляет набор user stories, которые в конечном итоге будут развернуты как производственный выпуск.

Если команда следует Acceptance Test Driven Development (ATDD), то члены команды будут совместно работать над дизайном тестов историй. Это происходит до начала разработки (одна из характеристик ATDD). Допустим, Мэри - разработчик, который напишет код для служб REST, и допустим, что она практикует разработку через тестирование (TDD). Она строит модульные тесты, по одному, сначала позволяя тесту не пройти, а затем пишет достаточно кода для прохождения теста. Когда имеется достаточное количество тестов для удовлетворения всех требований к истории и эти тесты проходят, тогда разработка и модульное тестирование завершаются. Затем Мэри может написать автоматизированные тесты, которые включают базу данных и, возможно, другие зависимости вне ее кода. Это интеграционные тесты. Поскольку команда использует ATDD, у нее уже есть набор приемочных тестов, поэтому она основывает свои автоматизированные тесты на них. Когда код Мэри проверяется и объединяется в общую ветвь разработки, в процессе сборки выполняются автоматические регрессионные тесты, чтобы убедиться, что существующие функциональные возможности не были нарушены работой Мэри. Эти тесты часто представляют собой просто набор автоматических приемочных испытаний, проводимых в течение месяцев или лет.

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

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

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

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

Источники:

● What is Software Testing Life Cycle (STLC)

● What Is Software Testing Life Cycle (STLC)?

● What is Software Testing Life Cycle (STLC) & STLC Phases

● Why is testing split into distinct stages?

Модели разработки ПО

Чтобы лучше разобраться в том, как тестирование соотносится с программированием и иными видами проектной деятельности, для начала рассмотрим самые основы — модели разработки (lifecycle model) ПО (как часть жизненного цикла (software lifecycle) ПО). При этом сразу подчеркнем, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке.

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

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

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

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

V-образная модель (V-model)

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

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

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

Инкрементная модель разработки (incremental development model): Модель жизненного цикла разработки, в которой проект разделен на серию приращений, каждое из которых добавляет часть функциональности в общих требованиях проекта. Требования приоритезированы и внедряются в порядке приоритетов. В некоторых (но не во всех) версиях этой модели жизненного цикла каждый подпроект следует «мини V-модели» со своими собственными фазами проектирования, кодирования и тестирования. (ISTQB)

Итеративная модель разработки (iterative development model): Модель жизненного цикла разработки, в которой проект разделен обычно на большое количество итераций. Итерация это полный цикл разработки, завершающийся выпуском (внутренним или внешним) рабочего продукта, являющегося частью конечного разрабатываемого продукта, который разрастается от итерации к итерации. (ISTQB)

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

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

Спиральная модель (spiral model)

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

Обратите внимание на то, что здесь явно выделены четыре ключевые фазы:

● проработка целей, альтернатив и ограничений;

● анализ рисков и прототипирование;

● разработка (промежуточной версии) продукта;

● планирование следующего цикла.

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

Гибкая модель (agile model)

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

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

 

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

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

В некоторых источниках можно найти еще пару моделей:

Prototype Model

Prototype Model - это модель, в которой прототип разрабатывается раньше, чем фактическое программное обеспечение. Модели-прототипы обладают ограниченными функциональными возможностями и неэффективной производительностью по сравнению с реальным программным обеспечением. Фиктивные функции используются для создания прототипов. Это ценный механизм для понимания потребностей клиентов. Внедряются отзывы, и прототип снова проверяется заказчиком на предмет любых изменений. Этот процесс продолжается до тех пор, пока модель не будет принята заказчиком. После сбора требований создается быстрый дизайн и создается прототип, который представляется заказчику для оценки. Отзывы клиентов и уточненные требования используются для модификации прототипа и снова представляются заказчику для оценки. После того, как заказчик утверждает прототип, он используется в качестве требования для создания реального программного обеспечения. Фактическое программное обеспечение построено с использованием подхода модели водопада.

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

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

Модель Большого Взрыва (Big Bang Model)

Big Bang Model не имеет определенного процесса. Деньги и усилия объединяются, поскольку вход и выход представляют собой разработанный продукт, который может совпадать, а может и не совпадать с тем, что нужно заказчику. Модель Большого Взрыва не требует особого планирования и составления графиков. Разработчик выполняет анализ требований и кодирование, а также разрабатывает продукт в соответствии с его пониманием. Эта модель используется только для небольших проектов. Нет команды тестирования и формального тестирования не проводится, и это может быть причиной провала проекта.

Преимущества модели большого взрыва: Это очень простая модель. Требуется меньше планирования и составления графиков. Разработчик может создавать собственное программное обеспечение.

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

Источники:

● Святослав Куликов “Тестирование программного обеспечения. Базовый курс”. Глава 2.

● SDLC (Software Development Life Cycle) Phases, Process, Models

Agile

Agile - это способность создавать и реагировать на изменения. Это способ справиться с неопределенной и неспокойной средой и в конечном итоге преуспеть в ней. Авторы Agile Manifesto выбрали «Agile» в качестве названия всей этой идеи, потому что это слово олицетворяет адаптивность и реакцию на изменения, которые так важны для их подхода. На самом деле речь идет об осмыслении того, как вы можете понять, что происходит в среде, в которой вы находитесь сегодня, определить, с какой неопределенностью вы сталкиваетесь, и выяснить, как вы можете адаптироваться к этому по мере продвижения.

Гибкая разработка программного обеспечения - это больше, чем такие фреймворки, как Scrum, Extreme Programming или Feature-Driven Development (FDD). Гибкая разработка программного обеспечения - это больше, чем такие практики, как парное программирование, разработка на основе тестирования, стендапы, сессии планирования и спринты.

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

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

В конечном итоге Agile - это образ мышления, основанный на ценностях и принципах Agile Manifesto. Эти ценности и принципы содержат указания о том, как создавать изменения и реагировать на них, а также как справляться с неопределенностью. Можно сказать, что первое предложение Agile Manifesto заключает в себе всю идею: «Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это». Когда вы сталкиваетесь с неуверенностью, попробуйте что-то, что, по вашему мнению, может сработать, получите обратную связь и внесите соответствующие коррективы. При этом помните о ценностях и принципах. Позвольте вашему контексту определять, какие рамки, практики и методы вы используете для сотрудничества со своей командой и предоставления ценности вашим клиентам.

Если Agile - это образ мышления, то что это говорит об идее Agile-методологий? Чтобы ответить на этот вопрос, вам может быть полезно иметь четкое определение методологии. Алистер Кокберн предположил, что методология - это набор условностей, которым команда соглашается следовать. Это означает, что у каждой команды будет своя собственная методология, которая будет в малой или большой степени отличаться от методологии любой другой команды. Таким образом, Agile-методологии - это условности, которым команда решает следовать в соответствии с ценностями и принципами Agile. Вы, наверное, скажете: «Подождите, - я думал, что Scrum и XP - это Agile-методологии». Алистер применил термин “framework” к этим концепциям. Они, безусловно, родились на основе методологии одной команды, но они стали фреймворками, когда были обобщены для использования другими командами. Эти фреймворки помогают понять, где команда начинает свою методологию, но они не должны быть ее методологией. Команде всегда необходимо адаптировать использование фреймворка, чтобы оно соответствовало его контексту.

Ключевые концепции Agile

● Пользовательские истории (User Stories): после консультации с заказчиком или владельцем продукта команда делит работу, которую необходимо выполнить, на функциональные этапы, называемые «пользовательскими историями». Ожидается, что каждая пользовательская история внесет свой вклад в ценность всего продукта;

● Ежедневные собрания (Daily Meeting): каждый день в одно и то же время группа собирается, чтобы ознакомить всех с информацией, которая имеет жизненно важное значение для координации: каждый член команды кратко описывает все «завершенные» вклады и любые препятствия, стоящие на их пути;

● Персонажи (Personas): когда этого требует проект - например, когда пользовательский опыт является основным фактором результатов проекта - команда создает подробные синтетические биографии фиктивных пользователей будущего продукта: они называются personas;

● Команда (Team): «Команда» в Agile понимании - это небольшая группа людей, назначенных на один и тот же проект или effort, почти все из них на постоянной основе. Незначительное меньшинство членов команды может работать неполный рабочий день или иметь конкурирующие обязанности;

● Инкрементальная разработка (Incremental Development): почти все Agile-команды отдают предпочтение стратегии инкрементального развития; в контексте Agile это означает, что можно использовать каждую последующую версию продукта, и каждая основывается на предыдущей версии, добавляя видимые для пользователя функциональные возможности;

● Итеративная разработка (Iterative Development): Agile-проекты являются итеративными, поскольку они намеренно позволяют «повторять» действия по разработке программного обеспечения и потенциально «пересматривать» одни и те же рабочие продукты;

● Ретроспектива (Milestone Retrospective): после того, как проект был запущен в течение некоторого времени или в конце проекта, все постоянные члены команды (не только разработчики) вкладывают от одного до трех дней в подробный анализ значимых событий проекта.

The Agile Manifesto:

● люди и взаимодействие важнее процессов и инструментов;

● работающий продукт важнее исчерпывающей документации;

● сотрудничество с заказчиком важнее согласования условий контракта;

● готовность к изменениям важнее следования первоначальному плану.

Основополагающие принципы Agile Manifesto:

● наивысшим приоритетом признается удовлетворение заказчика за счет ранней и бесперебойной поставки ценного программного обеспечения;

● изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

● частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода);

● общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта;

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

● самый эффективный метод обмена информацией в команде — личная встреча;

● работающее программное обеспечение — лучший измеритель прогресса;

● спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

● постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость;

● простота как искусство не делать лишней работы очень важна;

● лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд;

● команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс.

Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:

● Agile Modeling - набор понятий, принципов и приемов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирование и тестирование, не включает вопросы управления проектом, развертывания и сопровождения системы. Однако включает в себя проверку модели кодом.

● Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.

● Agile Data Method— группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд.

● DSDM основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.

● Essential Unified Process (EssUP).

● Экстремальное программирование (Extreme programming, XP).

● Feature driven development (FDD) — функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.

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

● OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как легкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.

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

● Бережливая разработка программного обеспечения (lean software development) использует подходы из концепции бережливого производства.

Манифест тестирования в Agile:

● постоянное тестирование, а не только в конце разработки;

● предотвращение багов более значимо, чем их поиск;

● понимание тестируемого продукта выше проверки функционала;

● построение лучшей системы в связке с командой выше поиска методов ее сломать;

● вся команда отвечает за качество, а не только тестировщик.