Презентация Техники тест-дизайна. Планирование, оценка трудозатрат. Отчетность. Лекция 5 онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Техники тест-дизайна. Планирование, оценка трудозатрат. Отчетность. Лекция 5 абсолютно бесплатно. Урок-презентация на эту тему содержит всего 73 слайда. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Презентации » Устройства и комплектующие » Техники тест-дизайна. Планирование, оценка трудозатрат. Отчетность. Лекция 5
Оцените!
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:73 слайда
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:2.56 MB
- Просмотров:149
- Скачиваний:7
- Автор:неизвестен
Слайды и текст к этой презентации:
№6 слайд
![Техники черного ящика Техники](/documents_6/780add062fc3d4ef72cd27a682f5b600/img5.jpg)
Содержание слайда: Техники черного ящика:
Техники черного ящика:
Эквивалентное Разделение (Equivalence Partitioning - EP).
Анализ Граничных Значений (Boundary Value Analysis - BVA).
Тестирование: Таблицы Альтернатив (Decision Table Testing - DTT).
Тестирование: Диаграмма Состояний и Переходов (State Transition Testing - STT).
Тестирование: Сценарии использования (Use Case Testing - UCT).
№11 слайд
![Эквивалентное разделение,](/documents_6/780add062fc3d4ef72cd27a682f5b600/img10.jpg)
Содержание слайда: Эквивалентное разделение, алгоритм использования техники:
Эквивалентное разделение, алгоритм использования техники:
Необходимо определить класс эквивалентности. Это главный шаг техники. От него во многом зависит эффективность её применения.
Затем нужно выбрать одного представителя от каждого класса. На этом шаге из каждого эквивалентного набора тестов мы выбираем один тест.
Нужно выполнить тесты. На этом шаге мы выполняем тесты от каждого класса эквивалентности.
№12 слайд
![Пример Пример Функцию](/documents_6/780add062fc3d4ef72cd27a682f5b600/img11.jpg)
Содержание слайда: Пример:
Пример:
Функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
За 5 суток до вылета комиссия составляет 0%.
Меньше 5 суток, но больше 24 часов – 50%.
Меньше 24 часов, но до вылета – 75%.
После вылета – 100%.
№13 слайд
![Плюсы и минусы техники](/documents_6/780add062fc3d4ef72cd27a682f5b600/img12.jpg)
Содержание слайда: Плюсы и минусы техники анализа классов эквивалентности:
Плюсы и минусы техники анализа классов эквивалентности:
К плюсам можно отнести заметное сокращение времени и улучшение структурированности тестирования.
К минусам можно отнести то, что, при неправильном использовании техники, мы рискуем потерять баги.
№14 слайд
![Задача Определить классы](/documents_6/780add062fc3d4ef72cd27a682f5b600/img13.jpg)
Содержание слайда: Задача: Определить классы эквивалентности
Задача: Определить классы эквивалентности
Существует некоторая система - которая принимает на вход численное значение и после анализа введенных данных, выдает ответ. Если ввести числа меньше 3, ответ системы - Отказано в правах доступа. Если ввести числа меньше 18 но больше 3, ответ системы - Права с ограниченным доступом. Если ввести числа меньше 60 но больше 18, ответ системы - Права доступа предоставлены. Если ввести числа больше 60, ответ системы - Права доступа предоставлены, супер пользователь!
№16 слайд
![Примерный алгоритм](/documents_6/780add062fc3d4ef72cd27a682f5b600/img15.jpg)
Содержание слайда: Примерный алгоритм использования техники анализа граничных значений:
Примерный алгоритм использования техники анализа граничных значений:
Во-первых, нужно выделить классы эквивалентности. Опять же, это очень важный шаг и от правильности разбиения на классы эквивалентности зависит эффективность тестов граничных значений.
Далее нужно определить граничные значения этих классов.
Нам нужно понять, к какому классу будет относиться каждая граница.
Для каждой границы нам нужно провести тесты по проверке значения до границы, на границе, и сразу после границы.
№17 слайд
![Пример Пример Функцию](/documents_6/780add062fc3d4ef72cd27a682f5b600/img16.jpg)
Содержание слайда: Пример:
Пример:
Функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
За 5 суток до вылета комиссия составляет 0%.
Меньше 5 суток, но больше 24 часов – 50%.
Меньше 24 часов, но до вылета – 75%..
После вылета – 100%
№19 слайд
![Задача Определить граничные](/documents_6/780add062fc3d4ef72cd27a682f5b600/img18.jpg)
Содержание слайда: Задача: Определить граничные значения
Задача: Определить граничные значения
Существует некоторая система - которая принимает на вход численное значение и после анализа введенных данных, выдает ответ. Если ввести числа меньше 3, ответ системы - Отказано в правах доступа. Если ввести числа меньше 18 но больше 3 включительно, ответ системы - Права с ограниченным доступом. Если ввести числа меньше 60 но больше 18 включительно, ответ системы - Права доступа предоставлены. Если ввести числа 60 и больше, ответ системы - Права доступа предоставлены, супер пользователь!
№23 слайд
![Плюсы и минусы техники Плюсы](/documents_6/780add062fc3d4ef72cd27a682f5b600/img22.jpg)
Содержание слайда: Плюсы и минусы техники:
Плюсы и минусы техники:
К плюсам можно отнести то, что она выявляет комбинации условий, которые могли быть не проверены при тестировании. Помогает определить несоответствия в требованиях, может быть применена во всех ситуациях и на любом уровне, где поведение программного обеспечения зависит от комбинации условий.
К минусам можно отнести то, что, при неправильном использовании техники, мы рискуем потерять баги.
№29 слайд
![Подходы к оценке и измерению](/documents_6/780add062fc3d4ef72cd27a682f5b600/img28.jpg)
Содержание слайда: Подходы к оценке и измерению тестового покрытия:
Подходы к оценке и измерению тестового покрытия:
Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту, путем построения матриц трассировки (traceability matrix).
Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
Тестовое покрытие на базе анализа потока управления - оценка покрытия основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.
№34 слайд
![Планирование спринта - это](/documents_6/780add062fc3d4ef72cd27a682f5b600/img33.jpg)
Содержание слайда: Планирование спринта - это ограниченная по времени встреча в начале спринта, на которой команда и владелец продукта (ВП) обсуждают и принимают решение о том, какая работа будет завершена в спринте.
Планирование спринта - это ограниченная по времени встреча в начале спринта, на которой команда и владелец продукта (ВП) обсуждают и принимают решение о том, какая работа будет завершена в спринте.
№35 слайд
![ЧАСТЫЕ ПРОБЛЕМЫ ЧАСТЫЕ](/documents_6/780add062fc3d4ef72cd27a682f5b600/img34.jpg)
Содержание слайда: ЧАСТЫЕ ПРОБЛЕМЫ:
ЧАСТЫЕ ПРОБЛЕМЫ:
Владелец продукта сам определяет и решает, какая работа будет завершена.
Беклог продукта не актуален, не приоритезирован или не готов к обсуждению.
В конце планирования все слишком детализировано и вся работа уже распределена по исполнителям (эту проблему трудно преодолеть).
Никто не понимает, что означает статус "Готово".
Встреча слишком длинная.
Встреча не включает участников в процесс.
Некоторым людям сложно проявляться.
Неподходящая среда, команда не чувствует поддержки или безопасности.
Нет доверия или уважения с обеих сторон.
Команда не понимает, для чего нужна эта встреча.
№36 слайд
![Длительность встречи зависит](/documents_6/780add062fc3d4ef72cd27a682f5b600/img35.jpg)
Содержание слайда: Длительность встречи зависит от длины спринта, чем дольше спринт, тем больше времени нужно для его планирования. Для ориентира:
Длительность встречи зависит от длины спринта, чем дольше спринт, тем больше времени нужно для его планирования. Для ориентира:
Однонедельный спринт - 2 часа.
Двухнедельный спринт - 4 часа.
Спринт длиной в 1 месяц - 8 часов.
Длительность также очень зависит от зрелости и эффективности команды и владельца продукта, от объема предварительной подготовки.
№38 слайд
![Производительность команды](/documents_6/780add062fc3d4ef72cd27a682f5b600/img37.jpg)
Содержание слайда: Производительность команды:
Производительность команды:
Достаточно взять среднее последних 3 спринтов, как руководство.
Обсудите часы доступности команды, отпуска, режим работы членов команды.
Помните, что спринты не бывают одинаковыми!
Не пытайтесь быть слишком детальными - это бесполезная трата времени, т.к. количество неизвестных слишком велико.
Команда все равно согласовывает объем работы.
Оставьте некоторое время для решения пока неизвестных вопросов и проблем. Так команда получает больше свободы действия.
Проще добавить работу в спринт, если у вас хорошо проработан беклог, чем убрать ее.
№39 слайд
![Capacity мкость Capacity](/documents_6/780add062fc3d4ef72cd27a682f5b600/img38.jpg)
Содержание слайда: Capacity(Ёмкость):
Capacity(Ёмкость):
Capacity прогноз - количество идеальных часов, доступное в следующем спринте.
Понимание, сколько часов у нас есть на работу: на написание кода, тестирование, т.д.
Как правило, участник проекта работает не более пяти часов в день.
Эффективное распределение задач.
Нет смысла планировать задачи на тех, кто будет в отпуске или занят другими активностями.
Мало пользы принесет технический анализ задачи, выполненный участником проекта, который в следующем спринте будет отсутствовать.
Аккуратное и точное планирование.
Мы оцениваем задачи в часах и берем в спринт столько, сколько соответствует нашей capacity.
№40 слайд
![Velocity Scrum Как и в](/documents_6/780add062fc3d4ef72cd27a682f5b600/img39.jpg)
Содержание слайда: Velocity Scrum
Как и в движении на автомобиле, скорость можно измерять и в Scrum, и называется это Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из поставленных отметок, как через каждые 60 минут было какое-то количество километров.
Velocity Scrum
Как и в движении на автомобиле, скорость можно измерять и в Scrum, и называется это Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из поставленных отметок, как через каждые 60 минут было какое-то количество километров.
График Velocity, отображающий по горизонтальной оси количество Sprints, а по вертикальной - Story Points.
№41 слайд
![В таком графике, по сути,](/documents_6/780add062fc3d4ef72cd27a682f5b600/img40.jpg)
Содержание слайда: В таком графике, по сути, изображено Story Points и на основе этих показателей выстраивается среднее значение скорости. Однако, график Velocity может быть и иной, с простым отображением Story Points, на основе которых визуально видна тенденция.
В таком графике, по сути, изображено Story Points и на основе этих показателей выстраивается среднее значение скорости. Однако, график Velocity может быть и иной, с простым отображением Story Points, на основе которых визуально видна тенденция.
№42 слайд
![Трудозатраты - количество](/documents_6/780add062fc3d4ef72cd27a682f5b600/img41.jpg)
Содержание слайда: Трудозатраты - количество рабочего времени, необходимого для выполнения работы (выражается в человеко-часах).
Трудозатраты - количество рабочего времени, необходимого для выполнения работы (выражается в человеко-часах).
Перед выполнением каждого задания, возникают следующие вопросы:
Как много времени понадобится на выполнение работы?
Когда всё будет готово?
Можно ли гарантированно выполнить работу к такому-то сроку?
Каковы наиболее оптимистичный и пессимистичный прогнозы по времени?
№44 слайд
![Алгоритм обучения](/documents_6/780add062fc3d4ef72cd27a682f5b600/img43.jpg)
Содержание слайда: Алгоритм обучения формированию оценки:
Алгоритм обучения формированию оценки:
Сформируйте оценку.
Запишите полученную оценку.
Выполните работу.
Сверьте реальные результаты с ранее сформированной оценкой.
Учтите ошибки при формировании новых оценок.
Повторяйте этот алгоритм как можно чаще для самых различных областей жизни.
№45 слайд
![Полезные идеи по формированию](/documents_6/780add062fc3d4ef72cd27a682f5b600/img44.jpg)
Содержание слайда: Полезные идеи по формированию оценки трудозатрат:
Полезные идеи по формированию оценки трудозатрат:
добавляйте небольшой «буфер» (по времени, бюджету или иным критическим ресурсам) на непредвиденные обстоятельства;
выясните свой «коэффициент искажения»;
принимайте во внимание не зависящие от Вас обстоятельства;
задумывайтесь заранее о необходимых ресурсах;
ищите способы организовать параллельное выполнение задач;
периодически сверяйтесь с планом, вносите корректировки в оценку и уведомляйте заинтересованных лиц о внесённых изменениях заблаговременно;
используйте инструментальные средства.
№46 слайд
![Структурная декомпозиция -](/documents_6/780add062fc3d4ef72cd27a682f5b600/img45.jpg)
Содержание слайда: Структурная декомпозиция - иерархическая декомпозиция объёмных задач на всё более и более малые подзадачи с целью упрощения оценки, планирования и мониторинга выполнения работы.
Структурная декомпозиция - иерархическая декомпозиция объёмных задач на всё более и более малые подзадачи с целью упрощения оценки, планирования и мониторинга выполнения работы.
Использование структурной декомпозиции позволяет:
описать весь объём работ с точностью, достаточной для чёткого понимания сути задач, формирования достаточно точной оценки трудозатрат и выработки показателей достижения результатов.
определить весь объём трудозатрат как сумму трудозатрат по отдельным задачам (с учётом необходимых поправок).
от интуитивного представления перейти к конкретному перечню отдельных действий, что упрощает построение плана, принятие решений о распараллеливании работ и т.д.
№51 слайд
![Задача Оценить время на](/documents_6/780add062fc3d4ef72cd27a682f5b600/img50.jpg)
Содержание слайда: Задача: Оценить время на выполнение тестирования, задачу про ответы системы в зависимости от возраста
Задача: Оценить время на выполнение тестирования, задачу про ответы системы в зависимости от возраста
Метод маек:
xs - 0,5 дня
s - 1 день
m - 1,5 дня
l - 2 дня
xl - 2,5 дня
№52 слайд
![Когда Scrum Team способна](/documents_6/780add062fc3d4ef72cd27a682f5b600/img51.jpg)
Содержание слайда: Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за Диаграммой сгорания задач, рано или поздно (или с самого начала работы) абсолютно все оценки будут вестись в Story Points.
Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за Диаграммой сгорания задач, рано или поздно (или с самого начала работы) абсолютно все оценки будут вестись в Story Points.
№54 слайд
![Цели проведения ретроспективы](/documents_6/780add062fc3d4ef72cd27a682f5b600/img53.jpg)
Содержание слайда: Цели проведения ретроспективы спринта:
Цели проведения ретроспективы спринта:
инспекция прошедшего спринта применительно к людям, отношениям, процессам и инструментам. Обнаружение и упорядочение того, что прошло хорошо и того, что нуждается в улучшении;
создание плана внедрения улучшений в процесс работы скрам-команды.
№56 слайд
![В ходе Sprint Review Meeting](/documents_6/780add062fc3d4ef72cd27a682f5b600/img55.jpg)
Содержание слайда: В ходе Sprint Review Meeting проект оценивается в отношении цели спринта, которая была определена во время планирования. В идеале, команда выполнила все задачи из Product Backlog, помещенные в Sprint, но это не самое важное, а важно то, что была достигнута цель спринта.
В ходе Sprint Review Meeting проект оценивается в отношении цели спринта, которая была определена во время планирования. В идеале, команда выполнила все задачи из Product Backlog, помещенные в Sprint, но это не самое важное, а важно то, что была достигнута цель спринта.
На что смотрит заказчик на Sprint Review Meeting:
Команда передала законченный продукт.
Работа команды завершена.
Показатели проекта (завершенность кода и тд.).
Работоспособность выполненных задач.
Обзор приоритетов (для следующих итераций / спринтов).
№57 слайд
![Отчётность - сбор и](/documents_6/780add062fc3d4ef72cd27a682f5b600/img56.jpg)
Содержание слайда: Отчётность - сбор и распространение информации о результатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации).
Отчётность - сбор и распространение информации о результатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации).
К высокоуровневым задачам отчётности относятся:
Сбор, агрегация и предоставление в удобной для восприятия форме объективной информации о результатах работы.
Формирование оценки текущего статуса и прогресса (в сравнении с планом).
Обозначение существующих и возможных проблем (если такие есть).
Формирование прогноза развития ситуации и фиксация рекомендаций по устранению проблем и повышению эффективности работы.
№58 слайд
![Отчёт о результатах](/documents_6/780add062fc3d4ef72cd27a682f5b600/img57.jpg)
Содержание слайда: Отчёт о результатах тестирования включает следующие разделы:
Отчёт о результатах тестирования включает следующие разделы:
Краткое описание.
Команда тестировщиков.
Описание процесса тестирования.
Расписание.
Статистика по новым дефектам.
Список новых дефектов.
Статистика по всем дефектам.
Рекомендации.
Приложения. Фактические данные (как правило, значения метрик и графическое представление их изменения во времени).
№59 слайд
![Definition of Done это набор](/documents_6/780add062fc3d4ef72cd27a682f5b600/img58.jpg)
Содержание слайда: Definition of Done — это набор критериев, которые позволяют понять, сделано ли то, что было целью разработки. Формат Definition of Done может быть любым, но чаще всего это простой список с перечнем активностей, которые должны быть успешно завершены, чтобы функционал мог считаться готовым.
Definition of Done — это набор критериев, которые позволяют понять, сделано ли то, что было целью разработки. Формат Definition of Done может быть любым, но чаще всего это простой список с перечнем активностей, которые должны быть успешно завершены, чтобы функционал мог считаться готовым.
Например:
код написан;
юнит-тесты написаны и успешно выполнены;
код прошел ревью;
документация обновлена;
функциональное тестирование успешно завершено;
регрессионное тестирование успешно завершено.
Чем больше и объемнее Definition of Done, тем более строгим оно считается. И тем больше нужно времени и усилий, чтобы наш функционал добрался до желаемого состояния «сделано». И тем выше вероятность, что функционал будет работать в соответствии с ожиданиями бизнеса.
Баланс между потерями на первое и вероятностью второго — это беспощадное поле брани, на котором было сломано много копий, команд, проектов, продуктов и сервисов.
№60 слайд
![В большинстве своем мы](/documents_6/780add062fc3d4ef72cd27a682f5b600/img59.jpg)
Содержание слайда: В большинстве своем мы привыкли к графикам идущими вверх, что означает положительную динамику, однако они могут идти и вниз, и также показывать положительную динамику.
В большинстве своем мы привыкли к графикам идущими вверх, что означает положительную динамику, однако они могут идти и вниз, и также показывать положительную динамику.
Одним из таких ярких примеров является Диаграмма сгорания задач (Burndown chart). Само сочетание Burn Down дословно переводится как «гореть вниз» и действительно это так.
Данный график является основным средством для отслеживания выполненных задач в спринте или во всем проекте. Хотя по сути он может использоваться как угодно, но мы его рассматриваем внутри методологии Scrum.
№61 слайд
![Синим на диаграмме сгорания](/documents_6/780add062fc3d4ef72cd27a682f5b600/img60.jpg)
Содержание слайда: Синим на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и следует опираться.
Синим на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и следует опираться.
Красным отмечена реальная история выполнения задач.
По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные часы, количество задач и так далее.
По шкале X отмечают количество дней до окончания Sprint.
Как может показаться на первый взгляд – данная Диаграмма сгорания задач / Burndown chart служит всего лишь для самоконтроля и самоотчета, однако ее использование может рассказать об очень многом.
№62 слайд
![Burndown Chart Слишком рано](/documents_6/780add062fc3d4ef72cd27a682f5b600/img61.jpg)
Содержание слайда: Burndown Chart: Слишком рано
Burndown Chart: Слишком рано
По Диаграмме сгорания задач / Burndown chart отчетливо видно, что команда все задачи выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает ряд совершенных проблем:
Команда сделала неправильную оценку предстоящей работы.
В случае быстрого выполнения задач, разработчики не добавляли задачи из следующего спринта.
Команда сильно перестраховалась, включив изначально дополнительный срок.
В случае такой проблемы, чаще всего Scrum Master спрашивает команду о возможности добавления дополнительных задач из Product Backlog.
№63 слайд
![Burndown Chart Опоздали](/documents_6/780add062fc3d4ef72cd27a682f5b600/img62.jpg)
Содержание слайда: Burndown Chart: Опоздали
Burndown Chart: Опоздали
Также один из видов негативных диаграмм сгорания задач.
Одной из возможных причин здесь может быть постоянное добавление новых задач во время спринта, что увеличило нагрузку.
Второй частой проблемой является недоделанность задач, когда задачи сделаны наполовину. Такие задачи, как выразился Джефф Сазерленд – являются хламом.
В такой ситуации, на Daily Scrum Meeting обязательно нужно говорить о проблемах, мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла выше, сразу надо решать проблему – это также один из постулатов методологии Scrum.
№64 слайд
![Burndown Chart Без оценок](/documents_6/780add062fc3d4ef72cd27a682f5b600/img63.jpg)
Содержание слайда: Burndown Chart: Без оценок
Burndown Chart: Без оценок
Может быть даже команда и работала, только забыла или не захотела использовать Диаграмму сжигания задач, что является прямо сказать дурным тоном и противоречит эффективной работе.
Команда не может контролировать себя, не может совершенствоваться и так далее.
№65 слайд
![Burndown Chart Конечная](/documents_6/780add062fc3d4ef72cd27a682f5b600/img64.jpg)
Содержание слайда: Burndown Chart: Конечная оценка
Burndown Chart: Конечная оценка
Собственно, ситуация равна предыдущей. Не смотря на законченный Sprint, все итоговые оценки были внесены в диаграмму сгорания в самый последний день после завершения работы. Это равносильно тому, когда вообще законченные задачи не вносятся.
По данному графику невозможно сделать вывода о правильности работы команды, и даже более того, можно предположить, что команда не стремится к развитию.
№66 слайд
![Burndown Chart Zero Burndown](/documents_6/780add062fc3d4ef72cd27a682f5b600/img65.jpg)
Содержание слайда: Burndown Chart: Zero
Burndown Chart: Zero
Отсутствие показателя реальных задач в диаграмме не является поводом считать, что работа не производилась, ведь она могла быть просто не оценена.
Как и в предыдущих пунктах, такая позиция не позволяет контролировать работу собственной команды и совершенствоваться.
№67 слайд
![Burndown Chart Релаксирующая](/documents_6/780add062fc3d4ef72cd27a682f5b600/img66.jpg)
Содержание слайда: Burndown Chart: Релаксирующая команда
Burndown Chart: Релаксирующая команда
Этот пример диаграммы сгорания задач уже значительно лучше нежели другие, ведь в нем можно увидеть, как усовершенствовать команду. Возможные проблемы здесь такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой.
№68 слайд
![Burndown Chart](/documents_6/780add062fc3d4ef72cd27a682f5b600/img67.jpg)
Содержание слайда: Burndown Chart: Совершенствование
Burndown Chart: Совершенствование
Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в самом начале были трудности, но вовремя Daily Scrum Meeting все вопросы вскрывались и Scrum Master исправлял работу ведя команду к цели.
Также возможно группа делала принципиальное ускорение, для достижения цели.
Еще одной причиной, к примеру, может быть то, что команда брала дополнительные задачи.
№71 слайд
![Матрица соответствия](/documents_6/780add062fc3d4ef72cd27a682f5b600/img70.jpg)
Содержание слайда: Матрица соответствия требований (Requirements Traceability Matrix) – это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).
Матрица соответствия требований (Requirements Traceability Matrix) – это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).
В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы.
Матрица соответствия требований используется QA-инженерами для валидации покрытия требований по продукту тестами. Цель «Traceability Matrix» состоит в том, чтобы выяснить:
какие требования «покрыты» тестами, а какие нет.
избыточность тестов (одно функциональное требование покрыто большим количеством тестов).
Данный тестовый артефакт является неотъемлемой частью тестирования.
Скачать все slide презентации Техники тест-дизайна. Планирование, оценка трудозатрат. Отчетность. Лекция 5 одним архивом:
Похожие презентации
-
Тестовое покрытие. Техники тест-дизайна
-
Оценка сложности вычислительных алгоритмов. Лекция 22
-
Тест дизайн
-
Тестирование и тест-дизайн. Основы функционального тестирования. Модульные тесты
-
Анализ и оценка времени выполнения параллельных алгоритмов. (Лекция 4)
-
Тестовое задание на позицию Младший Игровой Дизайнер (Junior Game Designer)
-
Manual QA course. Автоматизация тестирования. (Лекция 28)
-
Тестирование мобильных приложений. (Лекция 19)
-
Тестирование. Пакет JUnit. Java. (Лекция 24)
-
Введение в профессию. Тест-драйв профессии веб дизайнер