В чем цель тестирования

Что такое тестирование и почему мы должны его делать?

В первой статье в этой серии из пяти частей о тестировании в JavaScript мы рассмотрим, что такое тестирование и почему мы должны это делать. Если вас интересует тестирование в контексте Vue.js, то обратите внимание на книгу «Тестирование компонентов Vue.js с помощью Jest».

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

Тесты выполняют проверки программного обеспечения, проверяя, что полученный результат соответствует спецификациям, учитывая разные входные данные. Каждая из этих проверок называется тестовым сценарием (test case). В рабочем процессе agile каждая пользовательская история должна иметь набор тестовых сценариев. Простой пример:

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

Скорее всего, если вы читаете эту статью, вы знаете, что такое тестирование и TDD, но если вы новичок в тестировании, у вас может возникнуть вопрос, который был в своё время у всех нас:

Не занимает ли тестирование слишком много времени? Нужно ли мне тестировать всё?

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

Зачем писать тесты?

Говоря о том, зачем нужно тестирование, можно упомянуть следующие его преимущества:

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

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

Типы тестов

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

У нас есть три основных типа тестов:

End-to-end-тесты (сокращённо — E2E) или сквозные тесты, как их называют при переводе: тестируют систему в целом, эмулируя реальную пользовательскую среду. В интернете это тесты, запущенные в браузере, имитирующие щелчки мышью и нажатия клавиш. В общем, набор таких тестов не должен быть большим, так как они дороги для обслуживания и могут легко устареть из-за тестирования системы в целом.
Интеграционные тесты: цель данных тестов состоит в том, чтобы убедиться, что несколько зависимых друг от друга модулей кода работают вместе, и их взаимодействие работает должным образом.
Модульные тесты: они тестируют определённую функциональность изолированно. Их легче всего создавать и обслуживать, поэтому большинство тестовых наборов — это модульные тесты.

Пирамида описывает баланс различных типов тестов. Нижняя часть — это самые быстрые, простые и самые изолированные тесты, а верхние — самые дорогие, самые медленные и охватывают всё приложение в целом.

Интеграционный слой можно даже разделить на ещё большее количество слоёв:

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

Статический анализ

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

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

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

Давайте сравним типизированную версию и не типизированную версию функции sum :

Версия функции без указания типов не мешает нам вызывает её со строчными входными данными, в результате возвращая нам конкатенацию строк. Например, вызов sum('1', '2') возвращает '12' . Однако, если мы используем статическую типизацию, мы получаем ошибку, такую как Argument of type '"1"' is not assignable to parameter of type 'number' (Аргумент этого типа '"1"' не может быть присвоен параметру типа 'number'), и эта ошибка типизации предотвращает нас во время компиляции совершить вызов функции, который вернёт неверный результат, поскольку мы ожидаем сложение чисел, а не конкатенацию строк.

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

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

В качестве примера, если вы используете правило no-var в ESLint и напишите следующий код:

Вы получите ошибку Unexpected var, используйте let или const вместо (no-var) (Неожиданный var, используйте let или const вместо него (no-var)).

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

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

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

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

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

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

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

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

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

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

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

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

проверка готовности ПО к релизу;
проверка соответствия требований и качества данного проекта.

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

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

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

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

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

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

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

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

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

Анализ продукта
Работа с требованиями
Разработка стратегии тестирования и планирование процедур контроля качества
Создание тестовой документации
Тестирование прототипа
Основное тестирование
Стабилизация
Эксплуатация

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

анализ требований к проекту;
проектирование;
реализация;
тестирование продукта;
внедрение и поддержка.

Требования

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

Атрибуты требований:

Корректность — точное описание разрабатываемого функционала.
Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Недвусмысленность — требование должно содержать однозначные формулировки.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
Атомарность — требование нельзя разбить на отдельные части без потери деталей.
Модифицируемость — в каждое требование можно внести изменение.
Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

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

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

Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
Вложения (Attachments) — скриншоты, видео или лог-файлы.
Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
Окружение (Environment) – окружение, на котором воспроизвелся баг.

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

Скриншот

Severity vs Priority

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

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

Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

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

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
Задача (task) — техническая задача, которую делает один из членов команды.
Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
Баг (bug) — задача, которая описывает ошибку в системе.

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

Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
Продакшн среда (Production Env) – среда, в которой работают пользователи.

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

Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
Release: финальная версия программы, которая готова к использованию.

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

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

Скриншот

Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Техники тест-дизайна

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

Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

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

Скриншот

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

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

тестирование, основанное на анализе внутренней структуры компонента или системы;
тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

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

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

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

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

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

Что необходимо протестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.

Идентификатор тест плана (Test plan identifier);
Введение (Introduction);
Объект тестирования (Test items);
Функции, которые будут протестированы (Features to be tested;)
Функции, которые не будут протестированы (Features not to be tested);
Тестовые подходы (Approach);
Критерии прохождения тестирования (Item pass/fail criteria);
Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
Результаты тестирования (Test deliverables);
Задачи тестирования (Testing tasks);
Ресурсы системы (Environmental needs);
Обязанности (Responsibilities);
Роли и ответственность (Staffing and training needs);
Расписание (Schedule);
Оценка рисков (Risks and contingencies);
Согласования (Approvals).

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

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

Теория тестирования от А до Я.

Вопросы на собеседованиях Trainee/Junior/Middle Manual QA в среднем на 50% состоят из теории тестирования.

Навигация: ��

1. Тестирование. Качество ПО

2. Валидация vs Верификация

3. Цели тестирования

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

5. Тест-план

6. Тест-дизайн

7. Техники тест-дизайна

8. Продвинутые техники тест-дизайна

9. Бонусные и Авторские Техники тест-дизайна

10. Exploratory vs Ad-hoc testing

11. Test Case (Тестовый случай)

12. Check-list (Чек-лист)

13. Bug Report (Баг-репорт)

14. Severity vs Priority

15. Traceability Matrix (Матрица соответствия требований)

16. Defect / Error / Bug / Failure

17. Уровни тестирования (Levels of Testing)

18. Виды / Типы тестирования (Testing Types)

19. Принципы тестирования (Principles of Testing)

20. Статическое и Динамическое тестирование

21. Требования (Requirements)

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

23. Жизненный цикл разработки ПО

24. Методологии разработки

1. Тестирование. Качество ПО ��

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

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

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

— это одна из техник контроля качества, включающая в себя активности по:

Test Management (планированию работ)
Test Design (проектирование тестов)
Test Execution (выполнение тестов)
Test Analysis (анализ результатов тестирования)

Качество ПО (Software Quality)

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

2. Валидация vs Верификация ��

Верификация (verification)

— оценка соответствия продукта требованиям (спецификации).

Отвечает на вопрос: “Система работает в соответствии с требованиями?”

Валидация (validation)

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

Отвечает на вопрос: “Требования удовлетворяют ожидания пользователя?”

3. Цели тестирования ��

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

4. Этапы тестирования ��

Анализ продукта
Работа с требованиями
Разработка тест плана
Создание тестовой документации
Тестирование
Отчет о тестировании (test report)
Стабилизация
Эксплуатация

5. Тест план ��

Test Plan — это документ, описывающий весь объем работ по тестированию

https://amdy.su/wp-admin/options-general.php?page=ad-inserter.php#tab-8

Отвечает на вопросы:

Что?
Когда?
Критерии начала/окончания тестирования.
Окружение (environment) dev/staging/production?
Подходы/техники/инструменты/виды тестирования?
Браузеры/версии/OS/разрешения экрана?
Кто? Обязанности? Ресурсы? Обучение?
Сроки?
График?
Стратегия тестирования.
Ссылки на документацию.
Ссылки на требования.

6. Тест дизайн ��

Test design — это этап процесса тестирования ПО, на котором проектируются и создаются тест кейсы, в соответствии с критериями качества и целями тестирования.

Тест аналитик — определяет «ЧТО тестировать?»
Тест дизайнер — определяет «КАК тестировать?»
Реальность — все делает 1 человек 🙂

7. Техники тест дизайна ��

Эквивалентное Разделение (Equivalence Partitioning)

Как пример, у вас есть диапазон допустимых значений от 1.00 до 10.00 долларов, вы должны выбрать одно любое верное значение внутри интервала, скажем, 5.00, и любые неверные значения вне интервала, например 0.99 и 11.00.

test design equvivalence

Анализ Граничных Значений (Boundary Value Analysis)

Как пример, у вас есть диапазон допустимых значений от 1.00 до 10.00 долларов.
Two value (двузначный) BVA: валидные граничные значения 1.00, 10.00, и невалидные значения 0.99 и 10.01.
Three/Full value (трехзначный) BVA: валидные граничные значения 1.00, 1.01, 10.00, 9.99, и невалидные значения 0.99 и 10.01.

test design BVA

Причина / Следствие (Cause/Effect)

ввод комбинаций условий (причин), для получения ответа от системы (следствие).
Например, вы проверяете возможность добавлять клиента:
Причина: необходимо заполнить поля «Имя», «Адрес», «Номер Телефона» и нажать кнопку «Добавить».
Следствие: После нажатия на кнопку «Добавить», система добавляет клиента в базу данных и показывает его номер на экране.

Предугадывание ошибки (Error Guessing)

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

Например, спецификация говорит: «пользователь должен ввести код».

Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код?»…

test design error guessing

8. Продвинутые техники тест дизайна ��

Удиви интервьюера. Вааааау.

Попарное тестирование (Pairwise Testing)

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

Звучит сложно, но на практике использовать эту технику очень просто и логично.

Суть техники — мы не проверяем все сочетания всех значений, но проверяем ВСЕ ПАРЫ значений.

test design pair wise

Таблица принятия решений (Decision table)

В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию/решению.

test design decision table

Диаграмма (граф) состояний-переходов (State Transition diagram)

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

State transition diagram

Use case (пользовательский сценарий)

Это сценарий взаимодействия пользователя с системой для достижения определенной цели.

Use case содержит:

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

9. Бонусные и авторские техники тест дизайна ��

Просвети интервьюера. Открой ему глаза.

Семи-Исчерпывающее тестирование (Semi-Exhaustive Testing)

проверка всех возможных комбинаций входных значений. Как правило, на практике применение техники Exhaustive Testing не представляется возможным. (см. принцип тестирования №2 Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible))

Иногда на практике встречаются случаи, когда стандартные техники не дают достаточного уровня уверенности в работоспособности системы. Например, в системах связанных с медициной или авиа сферами, иногда стоит применять Semi-Exhaustive Testing.

Не забываем про принцип тестирования №6 Тестирование зависит от контекста (Testing is context dependent). Думаем головой, когда уместно применение этой техники, а когда нет.

Блок-схема (block scheme/diagram)

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

test design block schema

Шляпы / роли

Техника “Шляпы / роли” чем-то схожа с техникой составления тест кейсов по Use Case.

Принцип: одеваем шляпу определенной роли пользователя и представляем себя в его роли.

Пример: “одеваем” шляпу Кастинг Директора и размышляем как новый функционал будет работать для этой роли. Представляем, какие могут быть зависимости и особенности системы для Кастинг Директора. Размышляем, какие бизнес цели преследует Кастинг директор в нашей системе и как поведение системы может отличаться от других ролей. Потом “одеваем” шляпу Актера, Агента, Админа…

test design hats roles

Техники тест дизайна, о которых пока нигде не слышал: ��

Каждый имеет право придумать свою технику тест дизайна. Тестирование — это не бездумное применение всем известных техник. © Илларион

О техниках “Разговорчики-driven”, “Analytics-driven”, “Bug-driven” я пока нигде не слышал.

⚠️ Интервьюеры могут быть отличниками, которые ограничиваются только книжными понятиями и не выходят за рамки (thinking out of the box). Поэтому будьте аккуратны с озвучиванием этих техник интервьюеру, особенно, если у вас проблемы с объяснением и примерами)) Не ограничивайте себя существующими техниками, думайте, фантазируйте.

Разговорчики-driven (talks-driven)

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

Если фантазия не работает, то задаем Wh-вопросы:

what, when, where, who, whom, which, whose, why and how — что, когда, где, кто, кому, какой, чей, почему, как

Для продвинутых: сначала собираем всех по одному, а потом по несколько человек. Не выпускаем, пока не получим все ответы и не решим какие тесты проектировать.

Аналитика-driven (analytics-driven)

Если на проекте используется аналитика, например при кликах на кнопки или при открытии страниц отправляются ивенты (events) в систему для аналитики, то можно использовать данные аналитики для составления тест кейсов.

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

Баг-driven (bugs-driven)

Принцип тестирования №4 Скопление дефектов (Defects clustering) гласит, что “большая часть дефектов содержится в небольшом количестве модулей”.

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

Дополнительно можно посидеть над найденными багами и подумать “а может ли аналогичный баг быть в другой части системы?”.

10. Exploratory vs Ad-hoc testing ��

Исследовательское тестирование (exploratory testing)

это одновременное изучение системы, проектирование тестов (тест дизайн) и непосредственно тестирование.
Данная техника базируется на опыте тестировщика (experience based).
Пример: приходит тестировщик на новый проект и начинает одновременно изучать сайт, писать чек-лист и проходить этот чек-лист (тестировать).

Ad-hoc тестирование

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

11. Test Case (тестовый случай) ��

Test Case

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

Test Case

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

Test Case

— это описание проверки системы на соответствие требованиям.

Тест кейс состоит из:

ID (идентификатор)
Title (название)
Type (тип)
Priority (приоритет)
Preconditions (предусловия)
Steps (шаги)
Expected Result (ожидаемый результат)
Post conditions (пост условия) — например очистка данных или возвращение системы в первоначальное состояние.

Тест кейсы разделяются на позитивные и негативные:

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

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

12. Check-list (Чек-лист) ��

Check list

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

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

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

13. Bug report (баг репорт) ��

Bug Report

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

Основные составляющие Bug report:

ID (идентификатор)
Название (Title)
Короткое описание (Summary)
Проект (Project)
Компонент приложения (Component)
Номер версии (Version)
Серьезность (Severity)
Приоритет (Priority)
Статус (Status)
Автор (Author)
Назначен на (Assignee)
Окружение (Environment: dev/test/staging/prod/etc.)
App/build version (версия билда/приложения)
Шаги воспроизведения (Steps to Reproduce)
Фактический Результат (Actual Result)
Ожидаемый результат (Expected Result)

Дополнительные составляющие Bug report:

Screenshots (скриншоты)
Video (видео)
Credentials (login + password)
Browser console errors (логи с браузера)
Mobile app logs (логи с мобилки)

Server logs (логи с сервера)

Database queries (запросы в базу)

Link tasks/bugs (подвязка других задач/багов к текущему)

14. Severity vs Priority ��

Серьезность (Severity)

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

В теории Severity выставляется тестировщиком.

Градация Severity:

S1 Блокирующая (Blocker)
S2 Критическая (Critical)
S3 Значительная (Major)
S4 Незначительная (Minor)
S5 Тривиальная (Trivial)

Приоритет (Priority)

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

Чем выше приоритет, тем быстрее нужно исправить дефект.

В теории Priority выставляется менеджером, тимлидом или заказчиком.

Градация Priority:

P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)

Реальность: на всех проектах, где я работал, был только priority 🙂

Реальность: на разных проектах разные градации.

Пример вопроса на собеседовании про Severity / Priority —

15. Traceability matrix (Матрица соответствия требований) ��

Traceability matrix — это двумерная таблица, содержащая соответствие функциональных требований и тест кейсов.

В заголовках колонок таблицы расположены требования, а в заголовках строк — ID тест кейсов.

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

16. Defect / Error / Bug / Failure ��

Дефект (он же баг)

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

Bug (defect)

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

Например, когда никак не контролируется ввод пользователя, в результате неверные данные вызывают краши (crash) или иные «приколы» в работе программы. Либо программа построена так, что изначально не соответствует тому, что от неё ожидается.

Error (ошибка)

— действие, которое привело к неправильному результату.

Пример 1 — ввод букв в поля, где требуется вводить цифры (возраст, количество товара и т.п.). Error: “поле должно содержать только цифры”.

Пример 2 — регистрация с уже существующим в системе емейлом. Error: “этот емейл уже используется”.

Failure

— сбой (причём необязательно аппаратный) в работе компонента, всей программы или системы.

То есть, существуют такие дефекты, которые приводят к сбоям. И существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

17. Уровни Тестирования (Levels of testing) ��

1. Модульное тестирование (Unit Testing)

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

2. Интеграционное тестирование (Integration Testing)

Тестирование взаимодействия между несколькими классами, функциями, модулями. Например тестирование API через Postman.

3. Системное тестирование (System Testing)

Проверка как функциональных, так и нефункциональных требований к системе.

4. Приемочное тестирование (Acceptance Testing)

Проверка соответствия системы требованиям и проводится с целью:

определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком/менеджером принимается приложение или нет.

18. Виды / типы тестирования (Testing types) ��

18.1. Функциональные виды тестирования

Функциональное тестирование (Functional testing)
Тестирование пользовательского интерфейса (GUI Testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)

18.2. Нефункциональные виды тестирования

Все виды тестирования производительности (Performance):
- нагрузочное тестирование (Load Testing) — много пользователей.
- стрессовое тестирование (Stress Testing) — очень много данных и/или пользователей (пиковые значения).
- объемное тестирование (Volume Testing) — много данных.
- тестирование стабильности или надежности (Stability / Reliability Testing)
18.3. Связанные с изменениями виды тестирования
- Дымовое тестирование (Smoke Testing)
- Регрессионное тестирование (Regression Testing)
- Повторное тестирование (Re-testing)
- Тестирование сборки (Build Verification Test)
- Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)
19. Принципы тестирования (Principles of testing) ��

1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)

Тестирование может показать, что дефекты присутствуют в системе, но не может доказать, что их нет.

2. Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)

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

3. Раннее тестирование (Early testing)

Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки.

4. Скопление дефектов (Defects clustering)

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

5. Парадокс пестицида (Pesticide paradox)

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

6. Тестирование зависит от контекста (Testing is context dependent)

Тестирование выполняется по-разному в зависимости от контекста.

7. Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)

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

20. Cтатическое и динамическое тестирование ��

Статическое (static) тестирование

Производится БЕЗ запуска кода программы.

Примеры: тестирование требований/документации, код ревью, статические анализаторы кода.

Динамическое (dynamic) тестирование

Производится С запуском кода программы.

21. Требования (requirements) ��

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

Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. “Что”, а не “как”.

Требования к требованиям:
1. корректность
2. недвусмысленность
3. полнота
4. непротиворечивость
5. упорядоченность по важности и стабильности
6. проверяемость (тестопригодность)
7. модифицируемость
8. трассируемость
9. понимаемость
22. Жизненный цикл бага ��

23. Жизненный цикл разработки ПО ��

Software Development Life Cycle (SDLC):
1. Идея (Idea)
2. Сбор и анализ требований (Planning and Requirement Analysis)
3. Документирование требований (Defining Requirements)
4. Дизайн (Design Architecture)
5. Разработка (Developing)
6. Тестирование (Testing)
7. Внедрение/развертывание (Deployment)
8. Поддержка (Maintenance)
9. Смерть (Death)
24. Методологии разработки ��

Предложения и пожелания ��

Всегда рад получать конструктивную критику по контенту лекций и этой статье. Не стесняйтесь �� ☀️

Цели и задачи тестирования?

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

В чем отличие тестирования от отладки?

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

Тестирование позволяет выявить эти ошибки.

Что такое Верификация (verification) и что такое Валидация (validation)?

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

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

Какие стратегии\подходы тестирования Вы знаете? Перечислите их.

Подходы

Black Box (нет доступа к исходному коду, тестирование с точки зрения конечного пользователя)

White Box (есть доступ к исходному коду, позволяет проверить внутреннюю структуру программы, анализ приложения на уровне кода)

Grey Box (есть доступ к части кода, смешанная методика)

Какие уровни тестирования Вы знаете? Перечислите их.

Уровни

Модульное (Unit-testing) — тестирование независимых элементов кода

Интеграционное (Integration-testing) – тестирование интерфейсов между протестированными модулями

Приемочное (Acceptance-testing) — тестирование на стороне заказчика

Какие виды тестирования Вы знаете? Перечислите их.

Тестирование производительности (performance testing)

Нагрузочное тестирование (load testing)

Стресс-тестирование (stress testing)

Перечислите основные этапы процесса тестирования.

Planning (планирование – определение целей, стратегии, подготовка тестового окружения, расстановка приоритетов)

Test-case design & creation (разработка тест-кейсов)

Test-case execution (выполнение тест-кейсов в соответствии с приоритетами)

Test-case review (просмотр кейсов другим тестером, внесение предложений)

Bug verification (инициализация ошибок)

Reporting & Metrics (оценка, метрики – проектные, процессные, product-метрики)

Что такое требование к ПО?

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

Какие бывают типы требований?

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

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

Функциональные требования — определяют что должен реализовать продукт. Описывается в системной спецификации. Определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе». Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

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

Что такое Test Case?

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

Что должно быть в описании тест-кейса (приведите пример)?

Preconditions (предусловия) — список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния

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

Expected Result (ожидаемый результат) – результат, который должен получиться после выполнения тест-кейса в соответствии с требованиями

Что такое Test Matrix (Тестовая матрица)?

Тестовая матрица – это матрица, в которой хранятся test cases со всеми необходимыми параметрами для их описания:
Похожие публикации: