Тестовая документация (лекция - 4)

Закрепление материалов лекции №2

Содержание:
Тестовая документация: Acceptance Sheet, Test Survey, Check List
Чек-лист для тестирования веб-приложений
Test Cases: структура и детализация. Инструменты управления тестами

Виды тестовой документации

КТО?
КОМУ?
ЗАЧЕМ?
Виды тестовой документации

Виды тестовой документации

Checklist
Определение:
Не формализованный высокоуровневый список проверок (самых важных), набор правил и критериев, по которым проводится тестирование приложения. В качестве высокоуровневого списка могут выступать названия модулей, самая важная функциональность.
Проверки: Самые важные и приоритетные
Наличие проверок для отдельно взятой функциональности (по умолчанию): Нет, но может быть расширен
Ожидаемый результат проверки: Нет
Затраты на составление и поддержание: Минимальные
Плюсы: Проверки легко могут быть подправлены, если изменилась функциональность
Особенности:
Данный вид ТД используется, когда проект достаточно небольшой и сам тестировщик хорошо ориентируется в приложении.

Пример Checklist

Acceptance Sheet
Определение:
Это документ, который содержит подробный перечень ВСЕХ модулей и функций приложения, а также результаты тестов данных функций. Как правило, содержит статистику по наиболее важным показателям каждой сборки, определяющим ее качество.
Проверки: Список всей функциональности
Наличие проверок для отдельно взятой функциональности (по умолчанию): Нет, но может быть расширен
Ожидаемый результат проверки: Нет
Затраты на составление и поддержание: Средние
Плюсы: Содержит список всей функциональности, которую нужно проверить
Особенности:
Через этот тип ТД можно показать работу заказчику, что было протестировано
Удобен для MAT

Пример Acceptance Sheet

Пример Acceptance Sheet

Test Survey
Определение:
Это документ, который содержит подробный перечень всех модулей и функций приложения, конкретные проверки для каждой функциональности,а также результаты всех тестов. В некоторых случаях для проверок может быть указан ожидаемый результат.
Как правило, содержит статистику по наиболее важным показателям каждой сборки, определяющим ее качество.
Проверки: Список всей функциональности, со списком всех под проверок для данной функциональности
Наличие проверок для отдельно взятой функциональности (по умолчанию): Да
Ожидаемый результат проверки: Да
Затраты на составление и поддержание: Большие
Плюсы: Удобен, если команда нестабильная, т.к. проще проверять, когда описаны все проверки для каждой функциональности
Наглядность работы
Особенности:
Показать работу заказчику, что было протестировано и какими проверками покрывалась та или иная функциональность; Удобен для АТ

Пример Test Survey

Пример Test Survey

А теперь тренировка!
Какие виды тестовой документации мы уже рассмотрели?
Давайте представим , что у нас с вами появились клиенты. Ваша задача подобрать для них тестовую документацию, в зависимости от проекта.

Test Case
Определение:
Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы, или же для проверки соответствия определенному требованию.
Ожидаемый результат проверки: Да (может быть как проверки, так и каждого шага)
Затраты на составление и поддержание: Самая дорогая документация, больше всего тратится денег на её составление и поддержание в актуальном статусе
Особенности:
Проверки с большим количеством шагов и наличием предусловий
Сложная бизнес логика
Удобен при нестабильной команде

Пример Test Cases

Пример Test Cases

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

Критерии выбора тестовой документации
При выборе тестовой документации следует руководствоваться следующими критериями:
Стабильность функциональности
Если она будет стабильна, то её можно описывать более детальной и трудозатратной документацией. Если же нестабильна, то более простой и дешёвой.
Сложность бизнес-логики
При сложной бизнес-логике лучше использовать наиболее детальную документацию, чтобы избежать пропуска дефектов.
Размер проекта
Если размер проекта большой, то при использовании мало детализированной документации есть шанс, что не все проверки будут проведены.
Стабильность команды
Если команда не стабильна, то на сложном проекте придётся затрачивать много времени на инвестигейт, что увеличит трудозатраты.
Бюджет
Зачастую заказчики хотят минимум вложений, но максимум отдачи, и поэтому приходится выбирать менее трудозатратную документацию. Если бюджет позволяет, то можно выбрать более детализированную.
Время разработки проекта
Нет смысла писать дорогую и объёмную документацию на краткосрочный проект, можно взять более простой вариант (например AS)
Желание заказчика

Давайте опишем проверки для этой формы для AS/TS/Test Case.
Домашнее задание