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

Селиверстова Наталия

Часть 1. Тестовая документация

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

1. До тестирования: Тест-кейс, Чек-лист, Тест-план
2. После тестирования: Отчет

Тест-кейс

Тест-кейс - одна конкретная проверка

1. Есть шаги
2. Есть ожидаемый результат

Плюсы и минусы тест-кейсов

Плюсы: однозначные, подробные, понятные

Минусы: сложно поддерживать, эффект пестицида

Эффект пестицида

Эффект пестицида

Применение одних и тех же тестов и методов приводит к тому, что в программе остаются дефекты, против которых эти методы неэффективны.

Как избежать эффекта пестицида?

1. Меняться задачами в группе тестирования
2. Тестировать в парах
3. Обсуждение идей для проверок
4. Тест-ревью
5. Читать чужие дефекты
6. Пробовать новые подходы, читать статьи

Ресурс про тестирование ПО

software-testing.ru

В каких случаях используют ТК?

1. Регрессионное тестирование
2. Нужно проверить что-то очень важное
3. Прогонять ТК будет кто-то малознакомый с системой
4. Для написания автотестов

Чек-лист

список проверок без деталей

Чек-лист

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

Пример чек-листа

Блок истории просмотров

Декомпозировали

1. Список и прокрутка
2. Карточка товара

Чек-лист истории просмотров

1. Список и прокрутка

Чек-лист истории просмотров

2. Карточка товара

Еще пример чек-листа

Где хранят чек-листы?

1. в таблицах
2. в специально предназначенной системе
3. в корпоративной wiki
4. в mindMap схемах

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

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

Минусы чек-листа

1. Не отражает в полной мере что и как проверялось
2. Не подходят для обучения и для джуниоров

Плюсы чек-листа

1. Важные проверки не будут пропущены
2. Меньше рутины и затрат на поддержку документации
3. Уменьшает эффект пестицида, расширяет покрытие

Тест-план

Документ, описывающий весь объем работ по тестированию

Другими словами: список проверок + сроки, риски, ресурсы, методы и тд

Тест-план

1. Что и где тестируем?
2. Как тестируем?
3. Когда тестируем?

Что и где тестируем?

1. Описание системы/приложения и ее функций
2. Декомпозированный список проверок для функций
3. Какие тестовые среды используем
4. Что тестирует, а что НЕ тестируем

Как тестируем?

1. Какие области наиболее приоритетны
2. Инструменты и среды тестирования
3. Какие виды тестирования используем

Когда тестируем?

1. Сколько у нас ресурсов
2. Когда начать и когда закончить тестирование
3. Последовательность проведения работ

Пример тест-плана

Пример тест-плана

Пример тест-плана

Когда нужен тест-план?

1. Нужно четко договориться о целях и стратегии тестирования
2. Есть распределенная команда и нужно разделить работу
3. Обосновать ресурсы и сроки заказчику

Итог

Тест-кейс - одна конкретная проверка

Чек-лист - список проверок без подробностей

Тест-план - список проверок + сроки, ресурсы, методы

Когда используем какую документацию?

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

1. До тестирования : Тест-кейс, Чек-лист, Тест-план
2. После тестирования: Отчет

Отчет

Получается из тест-плана, чек-листов и наборов тест-кейсов

Отчет

1. Что проверили
2. Дефекты / "ок"
3. Сколько времени потратили

Чек-лист истории просмотров

Список и прокрутка

Чек-лист истории просмотров

Карточка товара

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

Документация после тестирования: что еще?

1. комментарий в тикете
2. апрув релиза

Документация после тестирования

Зачем?

Сообщить о результатах тестирования

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

Предоставить обратную связь о состоянии продукта

Результат тестирования

"Все ок" или список дефектов/улучшений - это тоже результат тестирования

Но вспомнишь ли ты потом, что проверял?

А поможет ли это составить полную картину проведенных тестов?

Точно ли такой обратной связи достаточно?

Результат тестирования

Нужно хотя бы иметь список того, что проверял

Исследовательское тестирование

Не предусматривается в тест-плане

Одновременно и техника, и вид тестирования

Исследовательское тестирование

1. Разработка и выполнение тестов в одно и то же время
2. Тесты изменяются во время выполнения
3. Следующий тест выбирается по результатам предыдущего
4. Одновременно происходит изучение тестируемой системы

Исследовательское тестирование

Плюсы: Можно найти новые дефекты; изучить продукт; уточнить существующие тесты

Минусы: Непонятно, как планировать; не всегда подойдет для джуниоров

Когда применять

1. При изучении нового
2. На ранних этапах разработки
3. Для расширения/разнообразия тестов из плана

Часть 2. Требования к ПО

• 2.1 Требования и ожидаемый результат
• 2.2 Как тестировать требования

2.1 Требования и ожидаемый результат

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

Проверка соответствия программы требованиям

Требования

Или ТЗ, документация, спецификация - это описание того, как система должна работать

Пример: wiki-разметка

((https://ya.ru/ Яндекс))

Яндекс

Пример

То же самое, но в виде двух полей для редактирования

Название указывать не обязательно, оно для удобства

Яндекс            https://ya.ru/

Пример: После сохранения

Значения в поле "Источник" - ссылки

ТЗ: Поиск по гиперссылке

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

Тестовые данные

Обнаружилось

При поиске по значению https://ya.ru - только один результат.

Потому что в требовании было написано: "Поиск как по значению, так и по названию"

Программа, соответствущая плохому ТЗ, непригодна

А бывает наоборот

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

Правильность работы программы нельзя доказать логически.

Отсюда следует

Чтобы хорошо протестировать программу, недостаточно сравнить реализацию с ТЗ, потому что:

1. ТЗ может быть неправильным
2. ТЗ вообще может не быть
3. Требования могут быть неявные

Явные требования

Требования, которые явным образом описаны в ТЗ, спецификации

Неявные требования

Не описаны явным образом в ТЗ, но подчиняются жизненным реалиям, законам математики/физики и тд, и зависят от явных требований

Явное требование

Поле "Адрес доставки" являетяс обязательным. Покупатель с него может ввести Города, Улицы и дома

Неявное требование

Не во всех городах есть улицы (Зеленоград), а иногда нужно ввести еще район

Тестовые оракулы

Тестовые оракулы

Способ распознавания правильного и неправильного поведения продукта

или

Способ генерации ожидаемого результата теста

History

История

Сравнить с предыдущей версией

Image

Имидж, бренд

Система соответствует имиджу организации, ее бренду или репутации.

Comparable products

Похожие продукты

Сравнить с похожими продукатами/услугами/системами

Claims

Требования

Соответствует требованиям, как зафиксированным в докуметации/ТЗ, так и обсужденным на встречах

Users expectations

Ожидания пользователей

Система соответствует ожиданиям пользователей

Product

Продукт / Внутренняя согласованность

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

Purpose

Предназначение

Система выполняет функции, для которых она предназначена.

Standarts, statutes

Стандарты и законы

Система соответствует законам или стандартам, которые имеют отношение к продукту.

Familar problems

Схожие проблемы

Нет проблем похоижих на те, с которыми мы уже сталкивались

Explainability

Объяснимость

Поведение системы объяснимо

World

Мир

Система соответствует представлениям о мире

Тестовые оракулы

1. history
2. image
3. comparable products
4. claims
5. users expectations
6. product
7. purpose
8. standarts, statutes
9. familar problems
10. explainability
11. world

Тестовые оракулы

Программный код оракулом быть не может!

Требование и тест-кейс: чем отличаются?

ТЗ описывает общие правила, а тестовый случай - это одна конкретная ситуация из множества, которые описаны в этом требовании

Пример ТЗ

Для всех элементов добавления товара в корзину должен быть тултип с текстом “Положить товар в корзину” (товар не в корзине) и “перейти в корзину” (этот товар уже в корзине)

Пример проверки

1. Открыть карточку товара, который уже в корзине
2. Навести курсор на иконку "В корзине"
3. Появился тултип с текстом "Перейти в корзину"

2.2 Тестирование требований

Зачем?

Корректность

Требование не содержит фактических ошибок

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

Однозначность

Требование нельзя понять двояко

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

Полнота

Требование содержит исчерпывающую информация о том, что должна и делать система

Совместимость

Требование не должно противоречить другим требованиям и ограничениям системы

Плохой пример: Система должна запрашивать из социальных сетей адрес электронной почты пользователя.

Понятность

Требование должно быть понятно всей команде разработки и заказчику

Плохой пример: Передатчик телефона должен использовать амплитудно-фазовую модуляцию с несущими от 2 до 7,5 МГц с шагом 500 кГц

Осуществимость

Требование можно реализовать с приемлимыми трудозатратами в рамках существующих технологий

Пример: невозможно требовать от системы отклик в 1 миллисекунду при больших нагрузках

Проверяемость

Требование можно проверить

Плохой пример: Система должна работать быстро

Критерии качества требований

1. Корректность
2. Однозначность
3. Полнота
4. Совместимость
5. Понятность
6. Осуществимость
7. Проверяемость

Как тестировать требования?

1. Предварительное беглое чтение
2. Техники тест-дизайна
3. Тест-кейсы
4. Макеты и прототипы интерфейсов
5. Понимание предметной области
6. Знание уже реализованной части системы

Итог

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

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

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

выбранных определенным образом.

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

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

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

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

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

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

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

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

Спасибо. Вопросы?

Домашнее задание

MindMap для чата Ki1ogram

• Требований нет
• Готового продукта еще нет

Задача: Составить схему, декомпозирующую продукт для предстоящего тестирования

Литература

• Oracles
• Исследовательские туры
• Быстрое тестирование, Калбертсон
• Использование MindMap
• Плохие требования - кошмар тестировщика