Опубликовано

Процесс тестирования програмного обеспечения (ПО).

Процесс тестирования програмного обеспечения (ПО)

Цель QA тестирования – убедиться, что ПО работает согласно задекларированным требованиям к ПО. Это включает в себя поиск несоответствий между полученным и ожидаемым результатом. Задача тестирования – систематическое обнаружение дефектов, с минимальной затратой времени и усилий, минимизация количества дефектов, найденных клиентом.
В QA процессе под “тестированием” подразумевается проверка того, что требований соблюдены и правильно реализованы. Трудоёмкость тестирования зависит от специфики проекта и его фазы.
Процесс тестирования плотно связан с процессом разработки, и идёт параллельно с ним.
Процесс тестирования итеративен. В каждой итерации интенсивность тестирования и специфика могут отличаться.
1 Критерии входа
До возможности начала QA тестирования должны быть выполнены следующие критерии:

  • QA инженеры проинформированы об объеме проекта, сути, оценке, графике, составе проектной группы, задачах и обязанностях её членов.
  • Все требования к ПО определены и приняты (зафиксированы в ТЗ и спецификациях, причём достаточно детализированы).
  • Есть план разработки по версиям.
  • Разработчики выполняют тестирование кода (Unit, Stress и Integration тестирование).
  • Определён подход к тестированию.
  • Установлена среда тестирования.

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

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

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

2.2 Планирование тестирования
Для проекта составляется план тестирования, включающий в себя стратегию и подход, компоненты и конкретные требования, подлежащие тестированию, критерии приёмки системы, вид и глубину тест кейсов и сценариев.
Подробнее о проектном документе тест план написано здесь: http://www.seolux.com.ua/archives/89.

2.3 Тест дизайн
Подробнее тест дизайн описан здесь: http://www.seolux.com.ua/archives/103.

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

2.3.2 Функциональные тест кейсы
Подробнее о функциональных тест кейсах написано здесь: http://www.seolux.com.ua/archives/110.

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

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

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

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

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

2.6 Оценка качества
После окончания тестирования каждой версии проводится оценка результатов тестирования, и в итоге создается Test Summary Report (Итоговый отчет по тестированию). Отчет содержит следующую информацию:

  • Выполненный объем тестирования
  • Статистика и перечень дефектов
  • Заключение о качестве продукта

На основании этих данных QA инженер делает заключение о версии – выполнены ли предъявленные к данной версии приёмочные критерии.

3 Критерии выхода
Следующие критерии показывают, может ли продукт тестирования выйти из фазы QA:

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

Функциональные тесты, тест кейсы.

Функциональные тесты, тест кейсы

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

Каждая функциональность определяется:

  • введенными данными;
  • последовательностью операций;
  • выходными данными.

Форма тест кейса может изменяться в зависимости от проекта и специфической функциональности.

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

# Описание тест кейса Шаги Ожидаемые результаты

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

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

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

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

Опубликовано

Тест дизайн

Тест дизайн

Тест дизайн – очень важный и трудоемкий процесс. Тест дизайн состоит из трех частей:

  1. Дизайн вида тест кейсов.
  2. Создание запланированных тест кейсов в соответствующей форме.
  3. Подготовка тестовых данных.

Тест кейс — это список шагов, описывающих, как протестировать определённые требования.

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

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

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

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

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

Опубликовано

Тест план, пример и шаблон.

Тест план пример и шаблон

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

Тест план предназначен показать:

Подход к тестированию:

Фокусирование усилий на тестирование (Test Focus)

Тестовое покрытие (Test Coverage)

Типы тестов (Test Types)

Процесс тестирования (Testing Workflow)

Тест дизайн (Test Design)

Компоненты системы, подлежащие тестированию

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

Риски и допущения

Среда тестирования

Требования, подлежащие тестированию

Требования, не подлежащие тестированию

Критерии для начала работы QA

Условия прохождения/не прохождения тестов

Критерии прохождения QA

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

Тест кейсы

Отчёт о результатах тестирования

Проектная группа и контакты

График работ по контролю качества

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