Матрица покрытия требований тестами

1.

2. Повторение урока№7

-
Что такое методология?
-
Какие методологии разработки ПО мы знаем?
Кто принимает решение о выборе методологиии для
проекта?
В чем преймущества и недостатки каждой их них?

3. Матрица покрытия требований тестами

Traceability matrix
Полное название - Requirement Traceability Matrix – RTM
- это матрица покрытия функциональных требований тесткейсами.
- Используется:
при разработке тестов четко ориентироваться какие из
требований уже покрыты тестами, а какие еще нет;
- при выполнении тестирования ориентироваться какие из
требований прошли все написанные для них тесты успешно, а
какие - еще нет.
- при обновлении ТС в случае изменений требований в
специфиакациях.
зная конкретный изменившийся RQ и
соответствующий(покрывающий) его тест легко быстро
вносить изменения.

4.

5.

Оценка времени (estimate) – это
глубокий анализ документации
проекта для предоставления
необходимого времени и ресурсов
для выполнения задачи

6. Учимся оценивать время

Случай 1: «Вот ТЗ, сколько времени уйдет на написание
тестовых сценариев?»

7.

В этом случае важно ответить на следующие вопросы:
Кто будет писать ТС?
oКаков уровень человека?
oКаков уровень знания
технологий?
oКаков уровень знания
предметной области?

8.

Зачем и для кого пишутся ТС?
oДля себя
oДля клиента
oДля приемочного тестирования
oДля автоматизации
oДля души

9. Варианты оценки

1. Грубая экспертная
Например на 1 страницу ТЗ мы пишем 5 ТС
1 тс мы пишем 20 мин
В ТЗ 300 страниц
5х20х300=30000 мин
2. Индуктивно-опытная
Разделяем ТЗ по функционалу
Пишем несколько ТС для каждой части
На основе этого определяем время для полного покрытия ТС
для каждой части
Складываем все части вместе

10.

Случай 2: «Вот кусок функционала, сколько времени уйдет на
тестирование?»

11.

Можно смотреть, сколько времени обычно у нас уходит на
тестирование похожего функционала.
Можно смотреть на тот же функционал, если мы уже раньше
тестировали такой.
Дедуктивная оценка
если мы знаем, сколько этот функционал занимает места в общем
функционале, мы просто видим, что тестирование этой
функционала займет, например, пятую часть от всего времени.
Индуктивная оценка
Например на прохождение 1 ТС мы тратим 20мин
Смотрим на общее кол-во ТС, например 300
20х300=6000

12.

Случай 3: «Почему вы ничего не успеваете?!»

13.

Чтобы показать, чем мы занимаемся, можем для каждого проекта
выписать все-все задачи, которые выполняются за один спринт, и
расписать их по дням: посчитать, сколько времени уходит на
каждую задачу в тот или иной день. Так можно увидеть среднюю,
максимальную и минимальную загрузку.
Не всегда нагрузка может быть оптимально распределена — иногда
загрузка большая, а иногда пол дня вообще нечего делать. Это
позволяет сделать определенные выводы и как-то оптимизировать
процесс, распределить нагрузку — например, какие-то вещи делать
заранее, даже если это не совсем согласуется с логикой процесса.
Например, если в начале спринта у нас много свободного времени,
мы можем уже начать писать пользовательские истории к
следующему спринту. Хоть мы и не знаем структуру следующего
спринта, все же мы, скорее всего, можем предугадать, что вот эти
вот две-три истории в него точно войдут — обычно они самые
критичные, обычно их все равно приходится переписывать, поэтому
это хорошее упражнение.

14.

15. Важно помнить

На что еще нужно время?
• Время на приемочное тестирование
• Время на заведение дефектов
• Время на регрессионное тестирование
• Время на смоук тестирование
• На тестирование кроссбраузерности
• На тестирование производительности

16. А так же..

1.Анализ требований
2.Консультации с аналитиками, разработчиками, тест-лидом
3.Подготовка тестовой документации
4.Время на тестирование
5.Время на регресионное тестирование
6.Буфер/Риски

17. PERT

Program (Project) Evaluation and Review Technique (сокращенно
PERT) —
техника оценки и анализа программ (проектов), которая
используется при управлении проектами.
PERT обеспечивает оценку и анализ времени выполнения,
трудозатрат и потребности в других ресурсах проекта, на
основе соответствующих характеристик и зависимостей
входящих в него задач.
В особенности, анализа и оценки времени, которое требуется
для выполнения каждой отдельной задачи, а также
минимально необходимого времени для выполнения всего
проекта.

18.

Оптимистическое время (optimistic time) (O): минимально
возможное время выполнения задачи, в предположении, что
все происходит наилучшим образом.
Пессимистическое время (pessimistic time) (P): максимально
возможное время требующееся для выполнения задачи, в
предположении, что все происходит наихудшим образом
(исключая крупные катастрофы).
Наиболее вероятное время (most likely time) (M): оценка
времени, требующегося для выполнения задачи, в
предположении, что все происходит как обычно.
Ожидаемое время (expected time) (TE): лучшая оценка
времени, требуемого для выполнения задачи, учитывая, что
вещи не всегда происходят как обычно. (Ожидаемое среднее
время выполнения задачи, если она будет повторяться
многократно).

19.

*
TE = (O + 4M + P)/6

20. Практическое задание

1. Посчитать время на написание тест кейсов.
2. Посчитать время на тестирование.
3. Создать и предоставить тест смету

21. Практическое задание:

Требования
Web-приложение «Университет».
Должно содержать:
1. Справочник студентов (добавление, изменение, удаление).
Атрибуты – фамилия, имя, отчество, стипендия (признак), дата
рождения.
2. Справочник преподавателей (добавление, изменение, удаление).
• Атрибуты – фамилия, имя, отчество, зп, дата рождения. • При
перемещении по справочнику преподавателей, должна обновляться
подчиненная таблица студентов, кот. обучаются у данного
преподавателя. • Должна быть возможность добавить в эту
подчиненную таблицу существующего студента из справочника или
удалить его из этой подчиненной таблицы (не из справочника).
Один студент может обучаться у нескольких преподавателей (по
разным дисциплинам).