STLC — Обзор

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

• STLC является неотъемлемой частью жизненного цикла разработки программного обеспечения (SDLC). Но STLC имеет дело только с этапами тестирования.

• STLC запускается, как только требования определены или SRD (Документ с требованиями к программному обеспечению) передается заинтересованным сторонам.

• STLC предоставляет пошаговый процесс для обеспечения качества программного обеспечения.

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

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

STLC является неотъемлемой частью жизненного цикла разработки программного обеспечения (SDLC). Но STLC имеет дело только с этапами тестирования.

STLC запускается, как только требования определены или SRD (Документ с требованиями к программному обеспечению) передается заинтересованным сторонам.

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

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

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

Фазы STLC

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

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

• Анализ требований — Когда SRD готов и представлен заинтересованным сторонам, группа тестирования начинает анализ высокого уровня, касающийся AUT (тестируемого приложения).

• Планирование тестирования — Команда тестирования планирует стратегию и подход.

• Проектирование тест-кейсов — Разработка тест-кейсов на основе объема и критериев.

• Настройка тестовой среды — когда интегрированная среда готова для проверки продукта.

• Выполнение теста — проверка продукта в режиме реального времени и поиск ошибок.

• Закрытие теста — После завершения тестирования матрица, отчеты, результаты документируются.

Анализ требований — Когда SRD готов и представлен заинтересованным сторонам, группа тестирования начинает анализ высокого уровня, касающийся AUT (тестируемого приложения).

Планирование тестирования — Команда тестирования планирует стратегию и подход.

Проектирование тест-кейсов — Разработка тест-кейсов на основе объема и критериев.

Настройка тестовой среды — когда интегрированная среда готова для проверки продукта.

Выполнение теста — проверка продукта в режиме реального времени и поиск ошибок.

Закрытие теста — После завершения тестирования матрица, отчеты, результаты документируются.

СРАВНЕНИЕ — STLC и SDLC

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

• STLC является частью SDLC. Можно сказать, что STLC является подмножеством набора SDLC.

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

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

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

STLC является частью SDLC. Можно сказать, что STLC является подмножеством набора SDLC.

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

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

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

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

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

STLC — Тестирование основополагающих принципов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсутствие ошибки — ошибка

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

STLC — анализ требований

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

• Критериями входа на этом этапе является предоставление SRS (Спецификация требований к программному обеспечению); также рекомендуется, чтобы архитектура приложения была удобной.

• На этом этапе команда QA на более высоком уровне анализирует, что тестировать и как тестировать.

• Команда QA проводит консультации с различными заинтересованными сторонами, такими как Business Analyst, System Architecture, Client, Test Manager / Lead, в случае, если для понимания требования требуется какой-либо запрос или уточнение.

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

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

Критериями входа на этом этапе является предоставление SRS (Спецификация требований к программному обеспечению); также рекомендуется, чтобы архитектура приложения была удобной.

На этом этапе команда QA на более высоком уровне анализирует, что тестировать и как тестировать.

Команда QA проводит консультации с различными заинтересованными сторонами, такими как Business Analyst, System Architecture, Client, Test Manager / Lead, в случае, если для понимания требования требуется какой-либо запрос или уточнение.

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

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

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

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

Определение области

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

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

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

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

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

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

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

STLC — критерии входа и выхода

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

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

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

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

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

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

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

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

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

• Документ с требованиями должен быть доступен.
• Полное понимание потока приложения не требуется.
• Документ плана испытаний должен быть готов.

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

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

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

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

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

STLC — критерии приемки

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

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

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

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

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

• Функциональная правильность и полнота
• Целостность данных
• Конверсия данных
• Юзабилити
• Спектакль
• своевременность
• Конфиденциальность и доступность
• Возможность установки и обновления
• Масштабируемость
• Документация

STLC — Планирование испытаний

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

Что входит в план тестирования?

План испытаний включает в себя следующее.

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

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

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

• В идеале, аналитик (ведущий) / менеджер по тестированию готовит документ с описанием стратегии тестирования / плана тестирования.

• Анализ больше ориентирован на данные / информацию, связанные с применением.

• Это первая фаза актуальных задач тестирования.

• Эта фаза отвечает «ЧТО должно быть проверено» и «КАКИЕ РЕСУРСЫ необходимы для тестирования».

• Основным критерием входа на этом этапе является предоставление Документов с требованиями (обновленная версия неясных / отсутствующих / уточненных требований) вместе с Матрицей прослеживаемости требований.

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

• Критериями выхода из этого этапа являются завершение Документа о стратегии тестирования / Плана тестирования и Документа об оценке усилий по тестированию.

В идеале, аналитик (ведущий) / менеджер по тестированию готовит документ с описанием стратегии тестирования / плана тестирования.

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

Это первая фаза актуальных задач тестирования.

Эта фаза отвечает «ЧТО должно быть проверено» и «КАКИЕ РЕСУРСЫ необходимы для тестирования».

Основным критерием входа на этом этапе является предоставление Документов с требованиями (обновленная версия неясных / отсутствующих / уточненных требований) вместе с Матрицей прослеживаемости требований.

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

Критериями выхода из этого этапа являются завершение Документа о стратегии тестирования / Плана тестирования и Документа об оценке усилий по тестированию.

Аспекты этапа планирования испытаний

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

Объем поставки

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

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

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

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

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

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

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

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

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

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

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

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

• Планирование руководителем проекта
• Запрос подан руководителем проекта
• Утвердить / изменить / отклонить с помощью диспетчера ресурсов
• Завершено — закрытие запроса после выхода из диспетчера ресурсов

STLC — разработка тестового примера

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

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

• На этом этапе команда QA пишет тестовый пример с пошаговым подходом. Затем контрольный пример подписывается бизнес-аналитиком после проверки или переделки контрольных примеров в случае необходимости внесения изменений.

• Как только контрольные примеры готовы, команда QA готовит Тестовые данные на основе предварительных условий.

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

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

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

На этом этапе команда QA пишет тестовый пример с пошаговым подходом. Затем контрольный пример подписывается бизнес-аналитиком после проверки или переделки контрольных примеров в случае необходимости внесения изменений.

Как только контрольные примеры готовы, команда QA готовит Тестовые данные на основе предварительных условий.

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

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

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

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

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

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

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

• Перечислите возможных пользователей, их действия и цели.

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

• Перечислите системные события и то, как система обрабатывает такие запросы.

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

• Читайте о похожих системах и их поведении.

• Изучение жалоб на продукцию конкурентов и их предшественников.

Перечислите возможных пользователей, их действия и цели.

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

Перечислите системные события и то, как система обрабатывает такие запросы.

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

Читайте о похожих системах и их поведении.

Изучение жалоб на продукцию конкурентов и их предшественников.

Написание тестовых примеров

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

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

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

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

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

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

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

STLC — настройка тестовой среды

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

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

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

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

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

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

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

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

• Готовность тестовой среды может быть подтверждена дымовыми испытаниями и проведена командой QA.

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

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

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

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

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

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

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

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

Готовность тестовой среды может быть подтверждена дымовыми испытаниями и проведена командой QA.

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

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

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

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

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

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

• Определите, нуждается ли тестовая среда в архивировании для создания резервных копий.

• Проверьте конфигурацию сети.

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

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

Определите, нуждается ли тестовая среда в архивировании для создания резервных копий.

Проверьте конфигурацию сети.

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

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

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

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

Тестирование дыма

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

STLC — выполнение теста

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

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

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

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

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

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

• Критерии выхода требуют успешной проверки всех тестовых случаев; Дефекты должны быть закрыты или отложены; Выполнение теста и сводный отчет о дефектах должны быть готовы.

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

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

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

Критерии выхода требуют успешной проверки всех тестовых случаев; Дефекты должны быть закрыты или отложены; Выполнение теста и сводный отчет о дефектах должны быть готовы.

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

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

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

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

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

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

Примечание. При тестировании SIT команда QA старается найти как можно больше дефектов для обеспечения качества. Основная цель здесь — найти как можно больше ошибок.

Отчет о дефектах

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

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

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

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

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

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

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

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

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

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

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

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

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

• Финальные регрессионные тесты — «Финальное регрессионное тестирование» выполняется для проверки сборки, которая не претерпела изменений в течение определенного периода времени. Эта сборка развернута или отправлена ​​клиентам.

• Регрессионные тесты — нормальное регрессионное тестирование выполняется для проверки, не сломала ли сборка какие-либо другие части приложения недавними изменениями кода для исправления дефектов или для улучшения.

Финальные регрессионные тесты — «Финальное регрессионное тестирование» выполняется для проверки сборки, которая не претерпела изменений в течение определенного периода времени. Эта сборка развернута или отправлена ​​клиентам.

Регрессионные тесты — нормальное регрессионное тестирование выполняется для проверки, не сломала ли сборка какие-либо другие части приложения недавними изменениями кода для исправления дефектов или для улучшения.

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

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

STLC — жизненный цикл дефекта

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

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

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

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

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

• Новое — потенциальный дефект, который обнаружен и еще не подтвержден.

• Назначено — Назначено против команды разработчиков, подлежащей решению.

• Активно — Дефект решается разработчиком, и расследование продолжается. На этом этапе возможны два исхода — отложенный или отклоненный.

• Тест / Исправлено / Готово к повторному тестированию — Дефект исправлен и готов к тестированию.

• Проверено — дефект, который повторно проверен, и тест был подтвержден QA.

• Закрыто — окончательное состояние дефекта, которое может быть закрыто после повторного тестирования QA или может быть закрыто, если дефект дублируется или считается НЕ дефектом.

• Повторно открыт — когда дефект НЕ устранен, QA повторно открывает / активирует дефект.

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

• Отклонено — Дефект может быть отклонен по любой из трех причин — дублированный дефект, НЕ дефект, невоспроизводимый.

Новое — потенциальный дефект, который обнаружен и еще не подтвержден.

Назначено — Назначено против команды разработчиков, подлежащей решению.

Активно — Дефект решается разработчиком, и расследование продолжается. На этом этапе возможны два исхода — отложенный или отклоненный.

Тест / Исправлено / Готово к повторному тестированию — Дефект исправлен и готов к тестированию.

Проверено — дефект, который повторно проверен, и тест был подтвержден QA.

Закрыто — окончательное состояние дефекта, которое может быть закрыто после повторного тестирования QA или может быть закрыто, если дефект дублируется или считается НЕ дефектом.

Повторно открыт — когда дефект НЕ устранен, QA повторно открывает / активирует дефект.

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

Отклонено — Дефект может быть отклонен по любой из трех причин — дублированный дефект, НЕ дефект, невоспроизводимый.

STLC — классификация дефектов

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

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

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

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

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

Приоритет можно классифицировать следующими способами:

• Низкий — этот дефект может быть исправлен после исправления критических.

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

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

• Срочно . Дефект должен быть устранен немедленно, поскольку он серьезно влияет на применение или продукт, и продукт нельзя использовать до тех пор, пока он не будет устранен.

Низкий — этот дефект может быть исправлен после исправления критических.

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

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

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

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

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

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

Уровень серьезности

Степень серьезности можно классифицировать следующими способами:

• Критическое / Серьезность 1 — Дефект влияет на наиболее важные функциональные возможности приложения, и команда QA не может продолжить проверку приложения без его исправления. Например, приложение / продукт часто аварийно завершают работу.

• Major / Severity 2 — Дефект воздействует на функциональный модуль; команда QA не может протестировать этот конкретный модуль, но продолжает проверку других модулей. Например, бронирование авиабилетов не работает.

• Средняя / Серьезность 3 — Дефект имеет проблему с одним экраном или связан с одной функцией, но система все еще функционирует. Дефект здесь не блокирует какую-либо функциональность. Например, Ticket # является представлением, которое не следует за правильными буквенно-цифровыми символами, такими как первые пять символов и последние пять как числовые.

• Низкая / Серьезность 4 — не влияет на функциональность. Это может быть косметический дефект, несоответствие пользовательского интерфейса для поля или предложение улучшить взаимодействие с конечным пользователем со стороны пользовательского интерфейса. Например, цвет фона кнопки «Отправить» не совпадает с цветом кнопки «Сохранить».

Критическое / Серьезность 1 — Дефект влияет на наиболее важные функциональные возможности приложения, и команда QA не может продолжить проверку приложения без его исправления. Например, приложение / продукт часто аварийно завершают работу.

Major / Severity 2 — Дефект воздействует на функциональный модуль; команда QA не может протестировать этот конкретный модуль, но продолжает проверку других модулей. Например, бронирование авиабилетов не работает.

Средняя / Серьезность 3 — Дефект имеет проблему с одним экраном или связан с одной функцией, но система все еще функционирует. Дефект здесь не блокирует какую-либо функциональность. Например, Ticket # является представлением, которое не следует за правильными буквенно-цифровыми символами, такими как первые пять символов и последние пять как числовые.

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

STLC — Закрытие цикла испытаний

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

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

Критерии для прохождения теста включают следующее:

• Указанный охват достигнут.
• Нет шоу-стоперов или критических дефектов
• Существует очень мало известных дефектов со средним или низким приоритетом. Это не влияет на использование продукта.

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

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

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

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

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

• Идентификатор итогового отчета теста
• Резюме
• Дисперсии
• Итоговые результаты
• оценка
• Запланированные против фактических усилий
• выйти

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

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

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

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

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

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

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