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

1.

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

2.

Тестирование на основе тест-кейсов (scripted testing, test
case based testing) — формализованный подход, в котором
тестирование производится на основе заранее подготовленных
тест-кейсов, наборов тест-кейсов и иной документации.
Подходы к
тестированию
19.03.2025
Исследовательское тестирование (exploratory testing) —
частично формализованный подход, в рамках которого
тестировщик выполняет работу с приложением по выбранному
сценарию, который, в свою очередь, дорабатывается в
процессе выполнения с целью более полного исследования
приложения.
Свободное (интуитивное) тестирование (ad hoc testing) —
полностью неформализованный подход, в котором не
предполагается использования ни тест-кейсов, ни чек-листов,
ни сценариев. Тестировщик полностью опирается на свой
профессионализм и интуицию (experience-based testing) для
спонтанного выполнения с приложением действий, которые, как
он считает, помогут обнаружить ошибку.

3.

чек-лист (check list) — набор/лист проверок, который описан
верхнеуровнево, без детализации.
Чек-лист
Тестирование на основе чеклиста — методика, основанная на
опыте, при которой опытный
тестировщик использует список
высокоуровневых пунктов,
которые необходимо записать,
проверить или запомнить, или
набор правил или критериев, в
соответствии с которыми должен
быть проверен продукт.
19.03.2025
Что очень важно при составлении чек-листа?
➔ Логичность.
➔ Последовательность.
➔ Структурированность.
➔ Полнота и неизбыточность.

4.

#
Проверка
Страница регистрации
Основные
поля чеклиста
1
2
3
Страница авторизации
1
В случае, если проект и реализация
часто меняется, возможно есть смысл
составлять набор проверок без
ожидаемого результата.
2
3
Главная страница
1
2
19.03.2025
3
Ожидаемый результат

5.

Примеры чеклистов
Каждый тестировщик видя
подобный чек-лист будет
проводить тестирование
последовательно по пунктам, но
тестовые данные и порядок
переходов (по ссылкам,
картинкам) у каждого будут свои.
19.03.2025
Пример 1 “Наш сайт”
● Главная
● Новости
● Личный кабинет
● О нас
Здесь мы составили верхне уровневый чек-лист. А
можем каждый пункт разбить на отдельный чек-лист.
Пример 2 “Главная страница”
● Соответствие макету
● Опечатки
● Header (заголовок страницы)
● Строка поиска
● Footer (подвал страницы)
● Rout (проверка переходов по ссылкам или на
другие вкладки/страницы нашего приложения)
● Кликабельность картинок

6.

Преимущества и недостатки чек-листов
Основные преимущества чек-листа:
● Быстро создается
● Легко поддерживать в актуальном состоянии
● Структурирует информацию
● Дает однозначное понимание задач, что надо
тестировать
● Экономит время. Чек-лист можно использовать
повторно
Недостатки чек-листа:
● Пункты в чек-листе довольно общие
● Поскольку нет информации, как именно
тестировать, то чек-лист не подходит для новых
членов команды
● Неопытный тестировщик для покрытия
обобщенного чек-листа может потратить в
несколько раз больше времени, чем в случае с
тест-кейсом (когда есть конкретные шаги и
тестовые данные)
● Не указаны факторы, влияющие на проведение
тестов
● Невозможность применения для тестирования
сложных систем
19.03.2025

7.

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

8.

➔ Структурировать и систематизировать подход к
тестированию.
➔ Вычислять метрики тестового покрытия.
➔ Принимать меры по увеличению тестового
покрытия.
Цели
написания
тест-кейсов
➔ Отслеживать соответствие текущей ситуации
плану.
➔ Уточнить взаимопонимание между заказчиком,
разработчиками и другими специалистами.
➔ Хранить информацию для длительного
использования и обмена опытом между
сотрудниками и командами.
➔ Проводить регрессионное тестирование.
➔ Повышать качество требований.
➔ Быстро вводить в курс дела нового сотрудника.
19.03.2025

9.

Идентификатор (identifier, ID) представляет собой уникальное
значение, позволяющее однозначно отличить один тест-кейс от
другого и используемое во всевозможных ссылках. В общем случае
идентификатор тест-кейса может представлять собой просто
уникальный номер, но может быть и куда сложнее: включать
префиксы, суффиксы и иные осмысленные компоненты,
позволяющие быстро определить цель тест-кейса и часть
приложения (например: 20190621-1 или просто ID — 7).
Атрибуты (или
поля) тест-кейса
Заголовок (Name) тест-кейса (title) призвано упростить и ускорить
понимание основной идеи (цели) тест-кейса без обращения к его
остальным атрибутам. Заголовок тест-кейса может быть
полноценным предложением или фразой, или набором
словосочетаний — главное, чтобы выполнялись следующие
условия:
1. Информативность.
2. Относительная уникальность (чтобы не путать разные тесткейсы).
19.03.2025

10.

Краткое описание (Summary) — часть тест-кейса, в которой в
краткой форме описывается его основная суть. Иногда вместо
Summary присутствует поле Description.
Исходные данные (Preconditions), необходимые условия для
начала выполнения тест-кейса (precondition, preparation, initial data,
setup), позволяют описать то, что должно быть подготовлено до
начала выполнения тест-кейса, например:
Атрибуты (или
поля) тест-кейса
19.03.2025
● Состояние базы данных.
● Состояние файловой системы и её объектов.
● Состояние серверов и сетевой инфраструктуры.
Статус тест-кейса показывает его текущее состояние. У тесткейса может быть несколько статусов. В случае TestLink это:
Черновик.
Готов для проверки.
Проверка в процессе.
Переработка.
Устаревший.
Готов.

11.

Приоритет (Priority или Importance) показывает важность тесткейса. Он может быть выражен:
● буквами (A, B, C, D, E),
● цифрами (1, 2, 3, 4, 5),
● словами («крайне высокий»,
«низкий», «крайне низкий»).
Атрибуты (или
поля) тест-кейса
«высокий»,
«средний»,
Тип выполнения — ручной или автоматический. Если тест-кейс
выполняется вручную, то выбирается Manual. Если тест-кейс
автоматизирован, выбирается Automated.
Оценочное время выполнения (Duration, Estimated execution
duration) — поле, в котором указывается оценочное время
выполнения/прохождения тест-кейса.
Шаги тест-кейса (steps) описывают последовательность действий,
которые необходимо реализовать в процессе его выполнения.
19.03.2025
Ожидаемые результаты (expected results) по каждому шагу тесткейса описывают реакцию приложения на действия, описанные в
поле «шаги тест-кейса». Номер шага соответствует номеру
результата.

12.

Преимущества:
Тест-кейсы можно доверить выполнять новичку или призванному на
помощь коллеге из другого отдела, который видит проект в первый
раз. Дополнительных вопросов будет по минимуму.
Преимущества
и недостатки
тест-кейсов
19.03.2025
Недостатки:
● Много повторяющегося текста
● Сложно поддерживать
● Утрата актуальности
Указанные недостатки устраняются при помощи программных
инструментов для создания тест-кейсов, где можно создать «общие
шаги» и использовать их в нескольких тест-кейсах, причем, при
актуализации общих шагов, актуализируются все тест-кейсы, эти шаги
использующие.
● Тест-кейсы со временем устаревают и становятся неактуальными.
Тестировщик, который уже год как работает на проекте, поймёт и
неактуальный кейс, тем более, если он выполняет их подряд, начиная
с первого. А тестировщик, который ничего о проекте не знает и
получил пару кейсов по распределению, не сможет понять, о чём в
них идет речь.
Чтобы тест-кейсы выполняли свою роль, их надо держать в
актуальном состоянии: поддерживать, периодически проверять на
правильность и дорабатывать. Это затратная, с точки зрения сил и
времени, деятельность.

13.

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

14.

Свойства
качественных
тест-кейсов
➔
Демонстративность.
➔
Прослеживаемость.
➔
Возможность повторного использования.
➔
Повторяемость.
➔
Ожидаемый результат для каждого шага
тест-кейса.
19.03.2025

15.

Наборы тесткейсов
19.03.2025

16.

Преимущества свободных наборов:
Тест-кейсы можно выполнять в любом удобном порядке, а
также создавать «наборы внутри наборов».
Наборы тесткейсов
Test suite — набор тест-кейсов,
которые должны быть выполнены
в определённом тестовом цикле.
19.03.2025
Если какой-то тест-кейс завершился ошибкой, это не
повлияет на возможность выполнения других тест-кейсов.
Преимущества последовательных наборов:
Каждый следующий в наборе тест-кейс в качестве входного
состояния приложения получает результат работы
предыдущего тест-кейса, что позволяет сильно сократить
количество шагов в отдельных тест-кейсах.
Длинные последовательности действий куда лучше
имитируют работу реальных пользователей, чем отдельные
«точечные» воздействия на приложение.

17.

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

18.

Логические
ошибки
➔ Ссылка на другие тест-кейсы или шаги других тесткейсов.
➔ Детализация, не соответствующая уровню
функционального тестирования.
➔ Расплывчатые двусмысленные описания действий и
ожидаемых результатов.
➔ «Выдумывание» особенностей поведения приложения.
➔ Отсутствие описания приготовления к выполнению тесткейса.
➔ Полное дублирование (копирование) одного и того же
тест-кейса на уровнях дымового тестирования,
тестирования критического пути, расширенного
тестирования.

19.

➔ Некорректное наименование элементов интерфейса
Логические
ошибки
или их свойств.
➔ Непонимание принципов работы приложения и
вызванная этим некорректность тест-кейсов.
➔ Проверка типичной «системной» функциональности.
➔ Неверное поведение приложения как ожидаемый
результат.
➔ Неверное разбиение наборов данных на классы
эквивалентности.
➔ Тест-кейсы, не относящиеся к тестируемому
приложению.
➔ Формальные и/или субъективные проверки.

20.

Принципы тестирования
1. Тестирование зависит от контекста.
2. Исчерпывающее тестирование невозможно.
3. Кластеризация дефектов.
4. Тестирование показывает наличие дефектов.
5. Заблуждение в отсутствие ошибок.
6. Раннее тестирование.
7. Принцип парадокса.