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

Вопрос 9 Уровни тестирования по

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

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

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

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

Вопрос 10 Статическое и динамическое тестирование

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

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

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

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

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

Тестирование «белого ящика» и «чёрного ящика»

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

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

Источник

9. Тестирование программного обеспечения. Уровни тестирования. Статическое и динамическое тестирование.

Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

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

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

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

С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.

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

По объекту тестирования:

· Функциональное тестирование (functional testing)

· Тестирование производительности (perfomance/stress testing)

· Тестирование стабильности (stability/load testing)

· Тестирование удобства использования (usability testing)

· Тестирование интерфейса пользователя (UI testing)

· Тестирование безопасности (security testing)

· Тестирование локализации (localization testing)

· Тестирование совместимости (compatibility testing)

· Тестирование чёрного ящика (black box)

· Тестирование белого ящика (white box)

· Тестирование серого ящика (gray box)

По степени автоматизированности:

· Ручное тестирование (manual testing)

· Автоматизированное тестирование (automated testing)

· Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

· Компонентное (модульное) тестирование (component/unit testing)

· Интеграционное тестирование (integration testing)

· Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

· Альфа тестирование (alpha testing)

· Тестирование при приёмке (smoke testing)

· Тестирование новых функциональностей (new feature testing)

· Регрессионное тестирование (regression testing)

· Тестирование при сдаче (acceptance testing)

· Бета тестирование (beta testing)

По признаку позитивности сценариев:

· Позитивное тестирование (positive testing)

· Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

· Тестирование по документации (formal testing)

· Эд Хок (интуитивное) тестирование (ad hoc testing)

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

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

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

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

Статическое и динамическое тестирование

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

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

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

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

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

Виды статического тестирования:

– вычитка исходного кода программы;

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

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

Динамическое тестирование является частью процесса валидации программного обеспечения.

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

• Доступа к коду (тестирование черным, белым и серым ящиками).

• Уровня тестирования (модульное интеграционное, системное, и приемочное тестирование).

• Сферы использования приложения (функциональное, нагрузочное, тестирование

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

Принципы тестирования

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

Этапы тестирования:

Программный продукт проходит следующие стадии:

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

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

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

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

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

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Источник

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

Существует 4 уровня тестирования [1]:

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

Начнем с простого примера.

Давай вспомним, что такое конструктор LEGO.

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

Обычно, процесс сборки игрушки выглядит так:

Программное обеспечение очень похоже на такой конструктор.

Но оно намного круче, ведь мы сами можем создавать любые детали и использовать детали (и даже блоки), созданные другими людьми (привет Open Source) 😉

Если посмотреть на процесс сборки с точки зрения тестирования, его можно описать так:

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

Благодаря этому подходу ты никогда не попадешь в ситуацию, когда «колеса не того размера», «двери не от той машины» или «мы хотели самолет, а получили вертолет, платить не будем» 🙂

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

Что такое уровень тестирования?

Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.

К характеристикам относятся:

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

Пример реальной задачи по разработке

Предположим, перед вашей командой ставят задачу:

Создать страницу Contact Us на сайте Х. После отправки формы отдел поддержки должен получить Email, содержащий введенные данные и контактную информацию клиента.

Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)

Первым делом разработчики прорабатывают дизайн системы.

Он может представлять собой следующую схему:

Дизайн системы Contact Us

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

* логика проверки (валидации данных) опущена для упрощения схемы. Но, это не означает, что ее нет!
** логика отправки Email опущена для упрощения схемы

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

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

Модульное / Компонентное / Unit тестирование

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

Module / Component / Unit testing: A test level that focuses on individual hardware or software components [ISTQB Glossary]

Характеристики модульного тестирования

Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок

Объект: модуль / компонент / unit

Базис: дизайн системы, код, спецификация компонента

Типичные ошибки: ошибка в реализации требований, ошибка в коде

Ответственный: разработчик (редко тестировщик)

На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях. Эти проверки всегда автоматизированы и выполняются очень быстро (несколько тысяч тестов в минуту).

Unit тесты, кроме поиска ошибок, также помогают оценивать качество кода, измерять покрытие кода тестами, сокращать время и затраты на тестирование.

Продолжая рассмотрение примера со страницей сайта, мы можем выделить следующие модули:

Для примера, рассмотрим модуль «страница Contact Us».
Требования:

В свою очередь, требования к модулю «Contact Us Controller»:

Все описанные выше требования должны проверяться Unit тестами.

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

Интеграционное тестирование

Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / под-системами / системами.

Выделяют 2 подтипа:

Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. [ISTQB Glossary]

Component integration testing. Testing performed to expose defects in the interfaces and interaction between integrated components. [ISTQB Glossary]

System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet). [ISTQB Glossary]

Характеристики интеграционного тестирования

Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы

Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы

Базис: дизайн системы, архитектура системы, описание связей компонентов

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

Ответственный: разработчик и тестировщик

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

Продолжим рассмотрение примера.

Теперь, обратим внимание на связи между компонентами / под-системами:

Интеграционное тестирование

Начнем с компонентного интеграционного тестирования.

Обрати внимание на стрелки 5 и 7.

Они описывают связь между компонентами Contact Us Controller и Email Sender внутри под-системы Backend.

Contact Us Controller обращается к Email Sender с запросом для отправки Email сообщения (5), Email Sender отправляет письмо (6) и отвечает Contact Us Controller что все прошло удачно (7). Если при отправке (6) произошла ошибка, в ответе (7) вернется информация об ошибке.

В нашем случае интеграционные тесты проверят, что описанный выше процесс работает и что модуль Contact Us Controller инициирует отправку Email сообщения, а не SMS.

Тестирование интерфейсов (частично) и тестирование API являются примерами интеграционного компонентного тестирования.

В случае с тестированием API мы «имитируем» запрос от клиента — (3) и анализируем ответ сервера — (9), таким образом проверяя интеграцию всех задействованных модулей для конкретного API Endpoint внутри Backend.

Interface Testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB Glossary]

API testing. Testing performed by submitting commands to the software under test using programming interfaces of the application directly. [ISTQB Glossary]

Далее посмотрим на системное интеграционное тестирование.

Обрати внимание на стрелки 3 и 9.

Они описывают связь между двумя под-системами: Frontend, который формирует и отправляет запрос со страницы Contact Us с данными формы, и Backend, который обрабатывает и реагирует на запрос.

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

В нашем случае для проверки правильности достаточно написать 1 тест: отправить форму Contact Us с ожидаемым результатом в виде показанного сообщения об успешной отправке — (10) и полученного Email сообщения с данными, оставленными с формы Contact Us.

Теперь, когда мы проверили интеграции компонентов внутри под-систем и интеграции под-систем, мы можем двигаться дальше.

Системное тестирование

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

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

Системное тестирование может проверять выполнение стандартов или законодательных / нормативных требований.

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

System testing The process of testing an integrated system to verify that it meets specified requirements. [ISTQB Glossary]

Характеристики системного тестирования

Цель: проверка работы системы в целом

Объект: система, конфигурации системы, рабочее окружение

Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции

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

Ответственный: тестировщик

Системное тестирование для нашего примера может включать в себя такие типы тестирования:

Системное тестирование системы Contact Us

* слово «тестирование» — убрано с изображения для упрощения 🙂

Помимо проверки отправки формы Contact Us, получения Email сообщения на почту суппорта и показа Success сообщения, в ходе системного тестирования мы должны ответить на вопросы:

На этом уровне тестирования создаются end-to-end тесты, имитирующие бизнес процессы, Use Cases и Use Stories от начала до конца.

Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п. — все здесь).

E2e тесты очень медленные (обычно 5-10 тестов в минуту) и коварные, с их автоматизацией нужно быть очень осторожным 😉

Системное тестирование — одна из самых творческих и объемных областей тестирования. Кроме end-to-end (e2e) тестирования, к этому уровню относятся все виды нефункционального тестирования.

Очень часто начинающие тестировщики видят только одно направление развития: автоматизация.

Но на самом деле направлений много.

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

End-to-End Testing A type of testing in which business processes are tested from start to finish under production-like circumstances. [ISTQB Glossary]

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

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

Приемочное тестирование фокусируется на готовности всей системы в целом.

Существуют несколько форм приемочного тестирования:

Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.

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

Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов.

Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.

Бета-тестирование проводится реальными пользователями системы.

Acceptance testing A test level that focuses on determining whether to accept the system. [ISTQB Glossary]

User acceptance testing (UAT) A type of acceptance testing performed to determine if intended users accept the system. [ISTQB Glossary]

Contractual acceptance testing A type of acceptance testing performed to verify whether a system satisfies its contractual requirements. [ISTQB Glossary]

Alpha testing A type of acceptance testing performed in the developer’s test environment by roles outside the development organization. [ISTQB Glossary]

Beta testing A type of acceptance testing performed at an external site to the developer’s test environment by roles outside the development organization. [ISTQB Glossary]

Характеристики приемочного тестирования

Цель: проверка готовности системы

Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика

Базис: системные требования, бизнес требования, сценарии использования, User Stories

Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта

Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик

Завершая рассмотрение примера можем написать приемочный тест, который выполнит заказчик:

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

В Agile разработке, конкретно в Scrum, для всех User Stories обязательно прописываются Acceptance Criteria. Именно они являются основой для приемочных тестов и показывают, что команда сделала именно то, что было нужно.

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

Резюме

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

Мы рассмотрели пример тестирования формы Contact Us.

Мы поняли, что тестирование нужно начинать с самых маленьких частей системы — компонентов / модулей.

Далее стоит проверить взаимосвязи между компонентами и всю систему в целом.

А завершает тестирование — заказчик, выполняя приемочное тестирование.

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

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

Если тебе интересна тема тестирования и ты хотел бы получать актуальную информацию по этой теме — подписывайся на наш Телеграм канал! Там интересно: статьи, тесты, опросы, нет спама 😉

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

Если у тебя возникли вопросы или есть предложения по статье — обращайся к нам в Телеграм, будем рады 🙂

Источники

Что такое уровень тестирования?

Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.

Что такое компонентное тестирование (unit testing)?

Компонентное / модульное / unit testing — фокусируется на компонентах / модулях / классах, которые могут быть проверены изолированно / отдельно.

Что такое интеграционное тестирование (integration testing)?

Интеграционное тестирование / integration testing — фокусируется на взаимодействии между компонентами / модулями, системами.

Что такое системное тестирование (system testing)?

Системное тестирование / system testing — фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.

Что такое приемочное тестирование (acceptance testing)?

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

Источник