Основы тестирования. Проектирование тестов

1.

Основы
тестирования.
Проектирование
тестов
Преподаватель: Колесников П.В.
г.Москва

2.

Тест анализ
Анализ и декомпозирование требований, User Story

3.

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

4.

Продуктная документация
Тест-кейсы и наборы тест-кейсов
План проекта
Требования к программному продукту
Технические спецификации
Архитектура и дизайн

5.

Проектная документация
Пользовательская и сопроводительная
документация
Маркетинговая документация

6.

Источники и пути выявления требований
Интервью, опросы, анкетирование.
Мозговой штурм, семинар.
Наблюдение за производственной деятельностью,
«фотографирование» рабочего дня.
Анализ нормативной документации.
Анализ моделей деятельности.
Анализ конкурентных продуктов.
Анализ статистики использования предыдущих версий
системы.
Совещание.
Use case.

7.

Анкетирование
Преимущества:
Высокая скорость получения результатов.
Сравнительно небольшие материальные затраты.
Недостатки:
Данный метод не подходит для выявления неявных
требований.
При составлении опросника физически невозможно
учесть все необходимые вопросы.

8.

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

9.

Анализ нормативной документации
Плюс:
Быстрое получение информации.
Компонентное
(модульное/unit)
тестирование
Интеграционное
тестирование
Системное
тестирование
Приемочное
тестирование
Минус:
Данный способ не применим при наличии в
компании только базовых документов (или при их
полном отсутствии) или, если в компании заказчика
не поддерживается актуальность документации.

10.

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

11.

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

12.

Use case
Плюсы:
Позволяет проработать все варианты развития
сценария (основной и альтернативные сценарии).
Минусы:
Метод не применим для сбора нефункциональных
требований.

13.

Параметры тестирования документации
1. Четкость и ясность
2. Актуальность
3. Логика
4. Возможные сценарии
5. Интеграция

14.

Тестирование документации
Полнота и соответствие действительности
Навигация
Инструкции должны присутствовать везде
Термины и их значение
Доступность пользователю

15.

Свойства качественных требований
Атомарность, единичность
Непротиворечивость, последовательность
Недвусмысленность
Модифицируемость (modifiability)
Проранжированность по
важности, стабильности,
срочности (ranked for importance,
stability, priority)
Обязательность,
нужность (obligatoriness) актуальность (up-to-date)
Прослеживаемость (traceability)
Корректность (correctness)
ипроверяемость(verifiability)

16.

Техники тестирования требований
Взаимный просмотр (peer review)
Беглый просмотр (walkthrough)
Технический просмотр (technical review)
Вопросы
Формальная инспекция (inspection)

17.

Два основных вида декомпозиции
Вертикальная
Горизонтальная
Функциональное
Нефункциональное
тестирование
декомпозиция
– это разделение тестирование
целого на части
Структурное
тестирование
Тестирование
изменений

18.

Структура любой декомпозиции должна
соответствовать определенным принципам:
1.Конечные этапы достижения цели должны быть
максимально упрощены.
2.Каждая подзадача должна быть четко
сформулирована и понятна для исполнителя.
3.Декомпозиция не должна быть перегружена
большим количеством мелких задач, т.к. это
усложняет контроль и управление.
4.Составляя новый уровень декомпозиции, нужно
оценивать необходимость следующего и
квалификацию исполнителя, т.к. более опытный
справится с упрощенной версией декомпозиции,
менее квалифицированному исполнителю
желательно предоставлять расширенную схему.
5.Все задачи должны подчиняться верхнему
уровню.
6.Конечный результат – это 100%.

19.

Разбиение задач
Понимание сроков
Минимизация рисков
Конкретизация плана
Определение ресурсов
Экономия времени

20.

Методы декомпозиции:
Декомпозиция этапов работ
Приоритизация цели
Декомпозиция по ролям и сценарию
пользователя
Декомпозиция измеримых показателей
Дерево зависимостей
Одношаговая декомпозиция

21.

Основные этапы:
определение главной цели;
разделение цели на несколько задач;
разделение задач на подзадачи;
проведение анализа каждого уровня;
удаление несущественных задач;
формирование итоговой схемы.
Редакторы:
Miro.
XMind.
LucidChart.
MindJet Mindmanager.
Draw.io.
MindMeister.

22.

Практические советы по написанию user story
•Лучше написать побольше небольших историй, чем
несколько объемных.
•Писать user story лучше всей командой, чтобы не
пропустить важные для продукта, бизнеса и
пользователей вещи.
•Пользовательскую историю нужно писать простым
языком, без рабочего сленга (по возможности).
Благодаря этому она будет понятна всем людям,
занятым в проекте.
•Нужно точно описать потребности пользователя.
•Юзер стори нужно писать так, чтобы по ней можно
было тестировать.
•Код пишется после тестов.
•В написании user story не стоит жестко
привязываться к каким-то элементам
пользовательского интерфейса.
•В каждой истории должна быть оценка сложности
реализации, а также времени, которое потребуется
на реализацию.
•User story должна содержать описание конечного
результата.
•Хорошая user story соответствует модели INVEST.

23.

Модель INVEST
INVEST – слово, использующееся для запоминания
критериев качественной истории:
I – independent. История должна быть независима
от других историй.
N – negotiable. История обсуждаема, в ней
отражается суть, а не детали или конкретные шаги
по реализации.
V
– valuable. История представляет ценность для
Статический
Динамический
клиентов и бизнеса.
метод Пригодность для оценки: метод
E – estimable.
историю
можно оценить по сложности и трудозатратам.
S – small. Хорошая история маленькая, ее можно
реализовать за одну итерацию.
T – testable. История имеет критерии приемки и ее
можно протестировать.

24.

Вопросы?