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