STLC - Краткое руководство

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

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

Фазы STLC

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

Есть 6 основных этапов STLC -

Requirement Analysis - Когда SRD готов и передается заинтересованным сторонам, группа тестирования начинает высокоуровневый анализ AUT (Тестируемое приложение).
Test Planning - Команда тестирования планирует стратегию и подход.
Test Case Designing - Разработайте тестовые примеры на основе области применения и критериев.
Test Environment Setup - Когда интегрированная среда готова к валидации продукта.
Test Execution - Проверка продукта и поиск ошибок в реальном времени.
Test Closure - После завершения тестирования матрица, отчеты и результаты документируются.

В этой главе мы поймем факторы сравнения между STLC и SDLC. Давайте рассмотрим следующие моменты и тем самым сравним STLC и SDLC.

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

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

Фаза	SDLC	STLC
Сбор требований	Бизнес-аналитик собирает требования. Команда разработчиков анализирует требования. После высокого уровня команда разработчиков начинает анализ с точки зрения архитектуры и дизайна.	Группа тестирования просматривает и анализирует документ SRD. Определяет требования к тестированию - ключевые моменты объема, проверки и валидации. Рассматривает требования к логической и функциональной взаимосвязи между различными модулями. Это помогает выявить пробелы на ранней стадии.
дизайн	Архитектура SDLC помогает вам разрабатывать высокоуровневый и низкоуровневый дизайн программного обеспечения на основе требований. Business Analyst работает над макетом UI-дизайна. После завершения проектирования он подписывается заинтересованными сторонами.	В STLC либо архитектор тестирования, либо руководитель тестирования обычно планируют стратегию тестирования. Определяет точки тестирования. Распределение ресурсов и сроки уточняются здесь.
Развитие	Команда разработчиков приступает к разработке программного обеспечения. Интегрируйтесь с разными системами. После завершения интеграции предоставляется готовое к тестированию программное обеспечение или продукт.	Команда тестирования пишет сценарии тестирования для проверки качества продукта. Подробные тестовые примеры написаны для всех модулей вместе с ожидаемым поведением. Здесь указаны предварительные условия и критерии входа и выхода тестового модуля.
Настройка среды	Команда разработчиков создает тестовую среду с разработанным продуктом для проверки.	Группа тестирования подтверждает, что среда настроена на основе предварительных требований. Выполняет дымовые испытания, чтобы убедиться, что окружающая среда стабильна для тестируемого продукта.
Тестирование	Фактическое тестирование проводится на этом этапе. Он включает модульное тестирование, интеграционное тестирование, системное тестирование, повторное тестирование дефектов, регрессионное тестирование и т. Д. Команда разработчиков исправляет сообщенную ошибку, если таковая имеется, и отправляет ее обратно тестировщику для повторного тестирования. Тестирование UAT выполняется здесь после выхода из тестирования SIT.	Тестирование системной интеграции начинается на основе тестовых примеров. Сообщенные дефекты, если таковые имеются, проходят повторную проверку и исправляются. Здесь выполняется регрессионное тестирование, и продукт подписывается, как только он соответствует критериям выхода.
Развертывание / выпуск продукта	После получения одобрения от различных групп тестирования приложение развертывается в рабочей среде для реальных конечных пользователей.	Тестирование дыма и работоспособности в производственной среде завершается здесь, как только продукт будет развернут. Отчеты об испытаниях и подготовка матриц выполняются командой тестирования для анализа продукта.
Обслуживание	Он охватывает поддержку после развертывания, улучшения и обновления, если таковые имеются.	На этом этапе осуществляется поддержка тестовых примеров, регрессионных костюмов и сценариев автоматизации на основе улучшений и обновлений.

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

Для достижения этих целей дается семь основных принципов тестирования программного обеспечения:

Что показывает тестирование?

Тестирование может показать наличие дефектов, но нет способа доказать, что в продукте нет дефектов. Этапы тестирования позволяют убедиться, что тестируемое приложение работает в соответствии с заданными требованиями, и это помогает снизить вероятность необнаруженных дефектов в приложении. Но, даже если дефектов не обнаружено, это не значит, что это абсолютно правильно. Мы можем предположить, что AUT соответствует нашим критериям выхода и поддерживает требования в соответствии с SRD.

Возможно ли исчерпывающее тестирование?

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

Раннее тестирование

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

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

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

Парадокс пестицидов

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

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

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

Тестирование зависит от контекста

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

Отсутствие ошибки - заблуждение

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

Анализ требований - это первая фаза STLC, которая начинается, как только SRD / SRS передается группе тестирования. Давайте рассмотрим следующие моменты, чтобы понять анализ требований в STLC.

Критериями входа на этот этап является предоставление SRS (Спецификация требований к программному обеспечению); Также рекомендуется, чтобы архитектура приложения была удобной.
На этом этапе команда QA анализирует на более высоком уровне, что тестировать и как тестировать.
Команда QA связывается с различными заинтересованными сторонами, такими как бизнес-аналитик, системная архитектура, клиент, руководитель тестирования / руководитель, в случае, если для понимания требования требуется какой-либо запрос или разъяснение.
Требования могут быть функциональными или нефункциональными, такими как производительность, безопасность, удобство использования и т. Д., Или одновременно функциональными и нефункциональными.
Критериями выхода на этом этапе является заполнение документа RTM, технико-экономического обоснования автоматизации и списка вопросов, если это применимо, для уточнения требований.

Действия, выполняемые для анализа требований

На этом этапе команда QA выполняет три основных действия. Действия описаны ниже.

Определение объема

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

Подготовить RTM

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

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

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

Анализ автоматизации

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

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

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

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

На каждом этапе STLC должны быть определены критерии входа и выхода.

Критерии входа

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

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

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

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

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

Критерии выхода

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

Критерии выхода - это набор ожиданий; это должно быть выполнено до завершения фазы STLC.

Например, чтобы завершить этап разработки тестовых примеров, должны быть выполнены следующие ожидания:

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

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

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

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

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

Критерии приемки определяются на основе следующих атрибутов -

Функциональная правильность и полнота
Целостность данных
Конверсия данных
Usability
Performance
Timeliness
Конфиденциальность и доступность
Возможность установки и обновления
Scalability
Documentation

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

Что включает в себя план тестирования?

План тестирования включает в себя следующее.

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

Важные моменты для планирования тестирования

При планировании тестирования в STLC необходимо учитывать следующие моменты.

В идеале, тестовый аналитик (ведущий) / менеджер готовит стратегию тестирования / документ плана тестирования.
Анализ больше сосредоточен на данных / информации, связанных с приложением.
Это первая фаза реальных тестовых задач.
На этом этапе дается ответ «ЧТО следует тестировать» и «КАКИЕ РЕСУРСЫ требуются для тестирования».
Основными критериями входа на этом этапе являются предоставление Документов с требованиями (обновленная версия неясных / отсутствующих / уточненных требований) вместе с Матрицей отслеживания требований.
Если автоматизация входит в объем работ, необходимо подготовить ТЭО автоматизации перед переходом к этой фазе.
Критериями выхода на этом этапе является заполнение документа стратегии тестирования / плана тестирования и документа оценки усилий по тестированию.

Аспекты фазы планирования тестирования

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

Объем работ

Следующие действия должны быть выполнены, чтобы сделать вывод по объему результатов -

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

Оценка усилий

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

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

Прошлые данные / Прошлый опыт
Доступные документы / знания
Assumptions
Выявленные риски

Четыре основных шага в тестировании оценки:

Оценка размера AUT (Тестируемое приложение).
Оценка трудозатрат в человеко-месяцах или человеко-часах.
Оценка расписания в календарных месяцах.
Оценка стоимости проекта в согласованной валюте.

План ресурсов

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

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

Обычный рабочий процесс для плана ресурсов -

Планирование менеджером проекта
Запрос отправлен менеджером проекта
Утвердить / изменить / отклонить диспетчером ресурсов
Завершено - закрытие запроса после выхода из Resource Manager

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

При разработке тестовых примеров в STLC необходимо учитывать следующие моменты.

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

Действия на этапе разработки тестового примера

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

Идентификация сценариев тестирования

Сценарии упрощают тестирование и оценку сложной системы. Следующие стратегии помогают в создании хороших сценариев -

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

Написание тестовых случаев

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

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

Подготовка тестовых данных

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

Определите тестовые ресурсы или требования
Определите условия / функциональность для тестирования
Установите приоритетные условия тестирования
Выберите условия для тестирования
Определить ожидаемый результат обработки тестовых случаев
Создать тестовые случаи
Документируйте условия тестирования
Провести тест
Проверить и исправить тестовые случаи на основе модификаций

Блок-схема деятельности

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

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

При настройке тестовой среды необходимо учитывать следующие моменты.

Это комбинация аппаратной и программной среды, в которой будут выполняться тесты.
Он включает в себя конфигурацию оборудования, настройки операционной системы, конфигурацию программного обеспечения, тестовые терминалы и другую поддержку для выполнения теста.
Это наиболее важный аспект процесса тестирования. Недоступность или неправильная настройка среды могут испортить все усилия по тестированию.
Практически команда QA не может начать реальную работу, не имея подходящей среды для тестирования.
Это самостоятельная деятельность, которую можно начинать одновременно с разработкой тестового примера.
В большинстве случаев эта деятельность выполняется разработчиками в технических аспектах, в то время как условия требований могут выполняться клиентами / бизнес-аналитиками.
Готовность тестовой среды может быть подтверждена дымовым тестированием и проведена командой QA.
В идеале мы можем сказать, что Критерии входа на этот этап - это предоставление Плана тестирования, готовность кейсов Smoke Test и подготовка тестовых данных.
Критериями выхода на этом этапе является то, что тестовая среда должна быть готова и дымовое тестирование должно быть успешно выполнено с ожидаемыми результатами.

Действия, выполняемые для настройки тестовой среды

На этом этапе выполняются следующие действия.

Дизайн тестовой среды

Следующие факторы играют важную роль при проектировании тестовой среды.

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

Настройка среды

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

Дымовые испытания

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

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

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

При выполнении теста необходимо учитывать следующие моменты.

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

Действия по выполнению теста

Целью этого этапа является проверка AUT в реальном времени перед переходом к производству / выпуску. Чтобы выйти из этого этапа, команда QA выполняет различные типы тестирования, чтобы гарантировать качество продукта. Наряду с этим отчет о дефектах и повторное тестирование также являются важной деятельностью на этом этапе. Ниже приведены важные действия на этом этапе:

Тестирование системной интеграции

Настоящая проверка продукта / AUT начинается здесь. Тестирование интеграции системы (SIT) - это метод тестирования черного ящика, который оценивает соответствие системы заданным требованиям / подготовленным тестовым примерам.

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

Состояние данных на уровне интеграции
Состояние данных на уровне базы данных
Состояние данных на уровне приложения

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

Сообщение о дефектах

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

При выполнении SIT-тестирования команда QA обнаруживает эти типы дефектов, и о них необходимо сообщать соответствующим членам команды. Участники предпринимают дальнейшие действия и устраняют дефекты. Еще одно преимущество отчетности - это упрощение отслеживания статуса дефектов. Существует множество популярных инструментов, таких как ALM, QC, JIRA, Version One, Bugzilla, которые поддерживают создание отчетов и отслеживание дефектов.

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

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

Отображение дефектов

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

Повторное тестирование

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

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

Регрессионное тестирование

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

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

Типы регрессионных тестов

Final Regression Tests- «Окончательное регрессионное тестирование» выполняется для проверки сборки, которая не подвергалась изменениям в течение определенного периода времени. Эта сборка развернута или отправлена клиентам.
Regression Tests - Выполняется обычное регрессионное тестирование, чтобы проверить, НЕ нарушила ли сборка какие-либо другие части приложения из-за недавних изменений кода для исправления дефектов или для улучшения.

Блок-схема деятельности

На следующей блок-схеме показаны важные действия, выполняемые на этом этапе; он также показывает зависимость от предыдущих фаз -

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

Жизненный цикл дефекта - рабочий процесс

На следующей диаграмме показан рабочий процесс жизненного цикла дефекта.

Состояния жизненного цикла дефекта

Ниже приведены различные состояния жизненного цикла дефекта.

New - Возможный дефект, который возник, но еще предстоит проверить.
Assigned - Назначен против команды разработчиков, которую необходимо решить.
Active- Дефект устраняется разработчиком, и расследование продолжается. На этом этапе есть два возможных исхода - отложенный или отклоненный.
Test / Fixed / Ready for Retest - Дефект исправлен и готов к тестированию.
Verified - Дефект, который был протестирован повторно, и тест был проверен QA.
Closed - Конечное состояние дефекта, которое может быть закрыто после повторного тестирования QA или может быть закрыто, если дефект является дублированным или НЕ считается дефектом.
Reopened - Когда дефект НЕ исправлен, QA повторно открывает / активирует дефект.
Deferred - Когда дефект не может быть устранен в этом конкретном цикле, он откладывается до будущего выпуска.
Rejected - Дефект может быть отклонен по любой из трех причин - повторяющийся дефект, НЕ дефект, невоспроизводимый.

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

Что такое приоритет?

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

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

Приоритетный листинг

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

Low - Этот дефект можно исправить после устранения критических.
Medium - Дефект необходимо устранить в последующих сборках.
High - Дефект должен быть устранен немедленно, поскольку дефект в значительной степени влияет на приложение, и соответствующие модули нельзя использовать, пока он не будет исправлен.
Urgent - Дефект должен быть устранен немедленно, поскольку дефект серьезно влияет на приложение или продукт, и продукт нельзя использовать, пока он не будет исправлен.

Что такое серьезность?

Серьезность определяется как серьезность дефекта в приложении и сложность кода для его исправления с точки зрения разработки. Itотносится к аспекту разработки продукта. Степень серьезности может быть определена на основе того, насколько серьезен / серьезен дефект для системы. Статус серьезности может дать представление об отклонении в функциональности из-за дефекта.

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

Список серьезности

Серьезность можно разделить на следующие категории:

Critical /Severity 1- Дефект влияет на наиболее важные функции приложения, и команда QA не может продолжить проверку тестируемого приложения, не исправив его. Например, приложение / продукт часто дает сбой.
Major / Severity 2- Дефект влияет на функциональный модуль; Команда QA не может протестировать этот конкретный модуль, но продолжает проверку других модулей. Например, не работает бронирование авиабилетов.
Medium / Severity 3- Дефект связан с одним экраном или с одной функцией, но система все еще работает. Дефект здесь не блокирует работу. Например, Ticket # - это представление, которое не следует за правильными буквенно-цифровыми символами, такими как первые пять символов, и за последними пятью как числовыми.
Low / Severity 4- Не влияет на функциональность. Это может быть косметический дефект, несогласованность пользовательского интерфейса для поля или предложение улучшить взаимодействие с конечным пользователем со стороны пользовательского интерфейса. Например, цвет фона кнопки «Отправить» не совпадает с цветом фона кнопки «Сохранить».

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

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

Критерии завершения теста включают следующее:

Указанный охват достигнут.
Нет showstoppers или критические дефекты
Известных дефектов среднего или низкого приоритета очень мало. Они не влияют на использование продукта.

Критерии выхода на этом этапе - это предоставление отчетов о завершении испытаний и подготовка матриц, которые затем подписываются клиентом.

Давайте теперь обсудим activities involved in the closure of Test Cycle.

Отчет о завершении теста

Отчеты о завершении тестирования - это процесс, при котором показатели тестирования сообщаются в обобщенном формате для обновления заинтересованных сторон. Это позволяет им принять обоснованное решение.

Отчет о завершении теста содержит следующую информацию.

Идентификатор сводного отчета о тестировании
Summary
Variances
Итоговые результаты
Evaluation
Запланированные и фактические усилия
выйти

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

Матрица завершения теста

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

Количество выполненных тестов
Количество пройденных тестов
Количество неудачных тестов
Количество неудачных тестов для каждого модуля
Количество тестовых дефектов, обнаруженных во время цикла выполнения
Количество принятых тестовых дефектов
Количество отклоненных тестовых дефектов
Количество отложенных тестовых дефектов
Статус активных дефектов
Расчет индекса качества сборки

Результаты теста

При выполнении тестового примера, повторном тестировании дефектов и выполнении регрессионного тестового примера, Test results articulate должны быть сохранены и могут быть созданы вместе с документами закрытия цикла тестирования для поддержки завершения выполнения теста.

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