Полный цикл тестирования. Фазы тестирования. Тестирование документации и требований. Лекция 3

1.

ПОЛНЫЙ ЦИКЛ ТЕСТИРОВАНИЯ.
ФАЗЫ ТЕСТИРОВАНИЯ.
ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ
И ТРЕБОВАНИЙ.
ЛЕКЦИЯ 3.

2.

Модели разработки ПО.

3.

Водопадная модель

4.

V-образная модель

5.

Итерационная инкрементальная модель

6.

Спиральная модель

7.

Гибкая модель (agile)

8.

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

9.

10.

Жизненный цикл тестирования.

11.

12.

Стадия 1 (общее планирование и анализ требований) объективно необходима как минимум для того, чтобы иметь ответ на такие вопросы, как:
- что нам предстоит тестировать;
- как много будет работы;
- какие есть сложности; все ли необходимое у нас есть и т.п.
Стадия 2 (уточнение критериев приемки) позволяет сформулировать или уточнить метрики и признаки возможности или необходимости начала
тестирования, приостановки и возобновления тестирования, завершения или прекращения тестирования.
Стадия 3 (уточнение стратегии тестирования) представляет собой еще одно обращение к планированию, но уже на локальном уровне: рассматриваются и
уточняются те части стратегии тестирования, которые актуальны для текущей итерации
Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке, переработке и прочим действиям с тест-кейсами,
наборами тест-кейсов, тестовыми сценариями и иными артефактами, которые будут использоваться при непосредственном выполнении тестирования
Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно связаны между собой и фактически выполняются параллельно:
дефекты фиксируются сразу по факту их обнаружения в процессе выполнения тест-кейсов
Стадия 7 (анализ результатов тестирования) и стадия 8 (отчетность) Формулируемые на стадии анализа результатов выводы напрямую зависят от
плана тестирования, критериев приемки и уточнения стратегии, полученных на стадиях 1,2 и 3. Полученные выводы оформляются на стадии 8 и
служат основой для стадий 1,2 и 3 следующей итерации тестирования

13.

Тестирование документации и требований.

14.

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

15.

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

16.

17.

18.

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

19.

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

20.

21.

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

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