Планирование тестирования Планируем тестирование Виды планирования

Планирование тестирования

Планируем тестирование

Виды планирования Стратегическое Направление движения Перечень задач Приоритеты Оперативное Оценка ресурсозатраты Обновление планов Контроль результатов

Стратегическое планирование Зачем? Достижение целей Дехаотизация Как? IEEE, RUP – стандартные шаблоны В свободной форме Где применимо? Везде.

Цели стратегического планирования Учитывать все условия Сохранять здравый рассудок Резервировать ресурсы Ничего не забыть Возможность выбрать наиболее важное Обосновывать руководству

Тестовая Стратегия - Что Это? Стратегия - общий, не детализированный план какой-либо деятельности, охватывающий длительный период времени, способ достижения сложной цели.

Тестовая Стратегия - Что Это? Стратегия Тестирования ПО – это общий, не детализированный план контроля качества ПО, охватывающий длительный период времени, главная цель которого достижение и обеспечение высокого качества ПО.

Тестовая стратегия ЭТО синонимы: Мастер тест план Master Plan Master Test Plan В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.

Что пишем в стратегию?

1. Описание проекта и продукта Описание Процесс и инфраструктура Документация Стадия разработки Модель взаимодействия Команда

2. Подход к тестированию Предотвращающий Реактивный

3. Что тестируем? Продукты и их части Технологии и инструменты

4. Тестовые окружения

5. Уровни тестирования Компонентное тестирование Интеграционное тестирование Системное тестирование Приемочное тестирование GUI/Not-GUI функциональность Инструменты Подходы

6. Типы тестирования

7. Техники тестирования (сложные) Decision tables State-based Pairwise testing tests Classification trees Checklist-based … tests

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

9. Инфраструктура тестирования Инструмент управления задачами и дефектами: Google Docs Багтрекер Outlook Тест менеджмент инструмент: Zephyr Test. Rail Google Docs Документ менеджмент Wiki Google Docs Хранилище данных Dropbox Shared folders Google Docs Шаблоны и др. Wiki

10. Артефакты тестирования Тестовая План итерации (для SCRUM) Набор User стратегия или тест план тестов story Отчеты о проблемах Отчеты о выполнении и качестве продукта Описание инфраструктуры разработки необходимой для тестирования Политика автоматического тестирования

11. Риски продукта и риски проекта Возможный Вес ущерб и вероятность появления рисков Предотвращающие действия О рисках будет чуть позже

12. Метрики тестирования Критичность имеющихся дефектов Рекомендации относительно того какие дефекты исправлять Тестовое покрытие и глубина тестирования Типы тестирования Тестовые окружения Покрытие Unit тестами и % ошибок Про метрики еще немного в конце

13. Автоматизация тестирования Что автоматизировать и как? С какими приоритетами? Какие инструменты? Какие подходы? Инфраструктура

14. Команда 1) Размер 2) Роли и Обязанности 3) Разбивка команды по функциональности и типам тестов

15. Необходимость в тренингах и др.

16. Расписание и оценка работ

План тестирования Часть мастер плана Отдельный документ На проекте может быть несколько Может быть без мастер плана

Кому создавать тест-план? Руководителю проекта по тестированию Руководителю группы Руководителю направления (автоматизации, тест-дизайна и т. д. ) Тестировщику, работающему в одиночку

Создаём тест-план – IEEE 1. Test Plan Identifier 2. Introduction 3. Test Items 4. Features To Be Tested 5. Features Not To Be Tested 6. Approach 7. Item Pass/Fail Criteria 8. Suspension Criteria and Resumption Requirements 9. Test Deliverables 10. Environmental Needs 11. Responsibilities 12. Staffing and Training Needs 13. Schedule 14. Risks and Contingencies 15. Approvals

Создаём тест-план – RUP Introduction Purpose Background Scope Project Identification Requirements for Test Strategy Resources Roles System Project Milestones Deliverables Test Model Test Logs Defect Reports

Что всегда нужно в тест-плане? Что тестировать Как это тестировать Что НЕ тестировать Трудозатраты на тестирование Приоритеты Последовательности Риски Всякие формальности

Что всегда нужно в тест-плане? Фича Математические функции Инсталляция Справка Новая фича #113: Кнопка Сохранить» Что тестировать Все базовые тесты Установку на Win 7 и Win Vista Ничего Полный цикл Что не тестировать Приоритет Детальные тесты с приоритетом ниже 3 Установку на другие ОС 1 Стандартные тесты 16 часов 3 Стандартные тесты 8 часов 4 Стандартные тесты 2 Стратегия • Проверить работу после различных операций • Использование разными пользователями • . . Для тестирования необходимо создать чек-листы и автоматизировать тесты с приоритетом >3 Трудо-затраты Тестирование – 8 ч Написание тестов – 8 ч Автоматизация тестов – 18 ч

Проектные риски Выявляем Подключаем других участников Определяем стоимость Определяем вероятность Определяем стратегию работы с риском Превентивные меры Учитывать риск в планах Оставить всё как есть Проработать «План Б»

Успех создания тест-плана Понимание целей: не «для галочки» Согласование с заинтересованными лицами Поддержка И в актуальном состоянии опыт, сын ошибок трудных

Способы оценки трудозатрат Экспертный способ оценки Я угадаю эту мелодию с трёх нот! Тщательная декомпозиция подзадач Связать свитер = сделать 28000 петель Классификация задач «Простая» мелодия угадывается с трёх нот «Сложная мелодия» угадывается с пяти нот Сбор метрик В среднем, свитер вяжется за 4 недели Все способы – взаимодополняющие!

Экспертный способ оценки «Я протестирую этот функционал за 4 дня» Гарантий – ноль (-) Срок обычно подстраивается под требования, ожидания (-) Индекс ошибки у сотрудников предсказуем (+)

Декомпозиция задачи «Для тестирования нам надо выполнить 250 тест-кейзов» Невозможно дать ответ руководству за 10 секунд (-) Высокая точность планирования пропорционально глубине декомпозиции (+)

Классификация задач Для тестирования, нам надо выполнить 4 задачи «А» и 6 задач «Б» Нужен предварительный сбор статистики и «отладка» (-) Наиболее точный и быстрый способ планирования при наличии метрик (+)

Инструменты для планирования Стратегическое планирование MS Word MS Project Планирование оперативных задач MS Project Testlink / HP QC / Jira / Test management systems Сбор статистики MS Project Excel Test. Link/QC/TMS

Контроль результатов По задачам в средстве планирования Daily reports, Weekly reports Сотрудники в тонусе Вы в курсе Регулярность контроля – атрибут задачи ОБНОВЛЯЕМ ПЛАНЫ!

Планирование – выводы Планирование – это ИНВЕСТИЦИЯ Наличие планов – залог того, что мы потратим ресурсы эффективно Ключевые параметры планов: Набор задач Риски и их решения Приоритеты задач Трудозатраты Планы должны актуализироваться Инструменты зависят от условий Задачи всегда должны идти от большего к меньшему

Составляем тест-план

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

Тест план для проверки калькулятора может быть таким Name Проверка основной функциональности Ввод данных Проверка арифметических операций Проверка вывода результата на экран Проверка работы интерфейса пользователя Проверка работы на различных ОС Операции с памятью Закрытие программы Проверка работы с минимальными правами Корректность обработки ошибок Ввод некорректных символов Арифметические операции с некорректными данными Ввод больших данных Работа при нехватке системных ресурсов Нагрузочное тестирование Запуск нескольких копий калькулятора Операции с большими данными Проверка на наличие утечек Проверка документации

Как планируют в Google

«Волшебный» метод ACC Расшифровывается просто: Attribute Component Capability

Все тот же калькулятор

Никогда до этого мы его не видели

Определяем атрибуты (Attribute) Ключевая характеристика системы Прилагательное (дело вкуса!) Небольшое количество Обычно прилагательное Описывает основные крутые особенности системы.

Как выделить Атрибуты? Спросить у отдела маркетинга Спросить у ПМа Поспрашивать у программистов Реклама продукта Интуиция Если изменятся в ходе работы – не страшно

Пример атрибутов калькулятора Простой Удобный Настраиваемый Надёжный

Определяем компоненты (Component) Модуль или часть системы Не очень крупный Не слишком мелкий Число больше, чем у Атрибутов

Как разбить систему на Компоненты? Поговорить с разработчиками Интуиция – всему голова Можно дополнить позже

Компоненты калькулятора Арифметические операции Память Строка ввода-вывода Преобразование единиц Журнал операций Встроенные листы (я тоже о них не знала) View -> Worksheets ☺

Атрибуты готовы Компоненты готовы Тест-план уже готов?

Нет, готова только таблица!

И тут появляются Capabilities Это почти как фичи, только: Относятся к Компонентам системы Обеспечивают Атрибуты системы Возможности, фактически, это фичи системы. Отличия только в вводе в ACC

Характеристики Возможностей Частота отказов – 5 ступеней Критичность отказов – 5 ступеней

Выглядит всё это так

Критерии установки характеристик Уже найденные ошибки Сложность реализации Важность для пользователя Новизна и изученность Главный вопрос как эти характеристики определять?

Вводим Возможности в систему

Получаем результат

Можно привязать тесты и баги К каждой добавленной возможности можно легко привязать тесты и баги из багтрекера и tms соответственно. В текущей версии работает не очень.

Результат налицо Получили наглядную карту рисков Узнали обо всех возможностях программы Получили список возможностей по атрибутам и компонентам Наладили учёт багов и тест-кейсов для возможностей системы Найденные ошибки учитываются при расчёте рисков

«Скрытые» результаты Картина продукта «на расстоянии» Представление о наименее надёжных модулях Возможность приоритизации по рискам и атрибутам Надёжная и удобная основа для тестовых сценариев и тестпланов Просто поддерживать в актуальном состоянии

Где посмотреть, потрогать ACC Веб-приложение с открытым исходным кодом – Test. Analytics http: //code. google. com/p/test-analytics/ Попробовать можно тут https: //test-analytics. appspot. com/

РИСКИ

Как работать с рисками

Структура следующих слайдов Название проблемы Комментарий 1 Комментарий 2 … Риск 1 Риск 2 … Рекомендация 1 Рекомендация 2 …

Стратегия тестирования отсутствует/не поддерживается Отсутствие согласованного понимания порядка подготовки и проведения тестирования в проекте Хаотичная передача версий на тестирование Нет базы тестирования Низкое качество тестирования Риск нехватки ресурсов тестирования Разрабатывать стратегию тестирования Согласовывать и утверждать стратегию тестирования

Стратегия тестирования Критерии начала и завершения тестирования Отсутствуют критерии начала тестирования Отсутствие / Нечеткость классификации серьезности дефектов Нет понятия готовности объекта тестирования (модульное тестирование, BATS …) Коммуникационные проблемы с разработчиками (тестирование) и заказчиком (приемка) Разработать однозначные критерии начала и завершения тестирования для каждого этапа проекта

Стратегия тестирования Риски тестирования Не рассматриваются и не анализируются наряду с остальными проектными рисками Не используется исторический опыт рисков тестирования Тестирование становится неадекватно высоко рисковой частью проекта Высока вероятность неуспешного тестирования Совместно с менеджером проекта анализировать, рассматривать и отслеживать риски тестирования наряду со всеми проектными рисками

Стратегия тестирования Особенности объекта тестирования Не учитываются особенности объекта тестирования (например, отсутствие пользовательского интерфейса, необходимость специальной среды тестирования) Нехватка (специально подготовленных) ресурсов тестирования Неадекватная среда тестирования Низкое качество тестирования Совместно с менеджером проекта анализировать особенности объекта тестирования и отражать принятые решения в стратегии тестирования

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

Анализ требований Требования не ранжированы по приоритетам Сомнительно, что все требования имеют одинаковый приоритет Нет возможности упорядочить и указать приоритеты для разработки и прогона тестовых сценариев Невозможность проведения первоочередного / тщательного тестирования ключевых требований Провести анализ существующих требований и определить приоритеты требований Учитывать эти приоритеты при определении очередности разработки и тестовых сценариев и покрытии требований тестовыми сценариями

Анализ требований Требований в проекте нет/они постоянно изменяются Ситуация в принципе невозможная/нормальная Имеется в виду либо отсутствие документально зафиксированных требований либо их высокая изменчивость Невозможность проведения тестирования по плану Невозможность адекватной оценки качества объекта тестирования Провести анализ существующих требований и способа их представления Разработать планы тестирования Применять планы тестирования

Анализ требований Нет аналитика – некому поддерживать требования Или «Давайте будем поддерживать все» Разница между ролью и ресурсом Невозможность создания актуального плана тестирования Невозможность адекватной оценки качества объекта тестирования Предусмотреть в плане-графике работы по сбору, анализу и поддержанию требований Наделить конкретный проектный ресурс ролью аналитика

Дизайн Архитектура системы не учитывается при разработке стратегии тестирования Необходимо для повышения эффективности тестирования (например, нужен ли и как организовать доступ на уровне СУБД) Необходимо для организации интеграционного тестирования Неэффективное тестирование (большие затраты при скромных результатах) Знакомство тестировщиков с архитектурой системы Планирование тестирования с учетом архитектуры системы

Дизайн Нет единого решения по пользовательским интерфейсам Неоправданный разнобой в реализации интерфейсов приложения Неудобство для заказчика Замечания тестировщиков на это тему игнорируются ( «Такого требования нет!» ) Низкое качество Usability объекта тестирования Не удается найти дефекты Usability Использовать как явные, так и подразумеваемые требования Специфицировать интерфейсы (документ, прототип …)

Дизайн У объекта тестирования отсутствует пользовательский интерфейс Непонятно, как «подобраться» к объекту тестирования Непонятно, как визуализировать фактический результат для сравнения с ожидаемым Замечания тестировщиков на это тему игнорируются Невозможность провести тестирование Использовать заглушки / тест-драйверы Планировать их разработку в стратегии тестирования и плане-графике проекта

Дизайн Нет требований к окружению системы Требования к окружению не сформулированы явно, а определяются в процессе разработки системы Требования неизвестны тестировщикам и не учитываются при создании среды тестирования Большое число «ложных» дефектов Низкое качество тестирования Зафиксировать требования к тестовой среде Проводить тестирование при соблюдении (в некоторых случаях – и при несоблюдении) этих требованиях Отразить требования в описании инсталляции и пользовательской документации

План тестирования Не анализируется покрытие требований тестовыми сценариями Нет соответствия приоритетов требований и степени их покрытия тестовыми сценариями Затруднительно установление соответствия дефекта требованию, которое он нарушает Низкое качество тестирования Низкое качество (скорость и эффективность) описания и исправления дефектов Покрытие требований тестовыми сценариями с учетом приоритетов

План тестирования Не проводится оценка качества плана тестирования в процессе разработки Как определить, что разработка плана тестирования завершена Как определить качество разработанного плана тестирования Низкое качество плана тестирования – низкое качество тестирования Результаты ревью плана тестирования позволяют оценить его качество

План тестирования Не проводится оценка качества плана тестирования в процессе применения Тестовые сценарии не находят дефектов Тестовые сценарии не находят существенных дефектов Тестовые сценарии находят одни и те же дефекты Неоправданно большие затраты на поиск дефектов Большое число пропущенных дефектов Пропущены существенные дефекты Мониторинг результативности тестирования Коррекция плана тестирования

План тестирования Ревью плана тестирования не планируется/не производится Считается сильно затратным Считается неэффективным План тестирования содержит дефекты Про эти дефекты никто не знает Они обнаруживаются при тестировании (хорошо, если это так) Планировать ревью плана тестирования аналитиками Планировать ревью требований тестировщиками

План тестирования Тестовые сценарии не содержат деталей Конкретные действия тестировщика / инженера по автоматизации придумываются во время тестирования Затраты на воспроизведение действий при воспроизведении дефекта Низкое качество тестирования из-за неполного набора действий Невозможность проверки степени покрытия пользовательского интерфейса Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности

План тестирования Тестовые сценарии содержат детали Изменение требований и дизайна вызывает объемные изменения планов тестирования Затраты на обеспечение актуальности планов тестирования Затраты на переучивание тестировщиков Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности Использовать двухуровневую структуру плана тестирования – тестовый сценарии + тесты

План тестирования Проектирование и разработка тестовых данных не планируется и не производится Данные придумываются во время тестирования Данных недостаточно (например, используются только корректные данные) Тестирование миграции без проектирования тестовых данных невозможно Затраты на воспроизведение данных для воспроизведения дефекта Низкое качество тестирования из-за малого набора тестовых данных Проектировать и разрабатывать тестовые данные с использованием классов эквивалентности и граничных значений

Автоматизация тестирования (повторяем) Автоматизация функционального тестирования применима в любом проекте Завышенные требования к команде тестировщиков Заниженная оценка трудозатрат на тестирование Невозможность проведения автоматизированного тестирования Поздний переход на ручное тестирование Детальный анализ целесообразности автоматизации тестирования

Автоматизация тестирования (повторяем) Автоматизация функционального тестирования применима только для регрессионного тестирования Как правило, но не всегда Пример: проекты redevelopment Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования

Автоматизация тестирования (повторяем) Автоматизация функционального тестирования применима только при большом числе раундов тестирования Как правило, но не всегда Пример: проекты mission-critical Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования

Автоматизация тестирования (повторяем) Раннее проведение нагрузочного тестирования Исправление функциональных дефектов, как правило, вызывает перезапись и повторный прогон нагрузочных скриптов Как правило, но не всегда Пример: нагрузочное тестирование прототипа Необходимость выделения ресурсов для повторного проведения нагрузочного тестирования Детальное планирование момента проведения нагрузочного тестирования

Автоматизация тестирования (повторяем) Неадекватная модель нагрузки Совокупность: ролей (кто работает) характеристических профилей сценариев (что делает) (доля и частота) не соответствует бизнесу заказчика Неадекватные результаты нагрузочного тестирования Несоответствие ожиданием заказчика Согласование модели нагрузки с заказчиком

Среда тестирования Тестирование выполняется в среде разработки одного или нескольких проектов Путаница версий Нестабильность объекта тестирования (исправления «на лету» ) Невозможность обнаружения части дефектов Низкое качество тестирования Сложность коммуникаций с разработчиками (невозможность воспроизвести дефект) Создание обособленной среды тестирования Сборка объекта тестирования из baseline

Тестирование Дефекты, найденные вне плана тестирования, не приводят к его корректировке Сложности их повторной проверки Можно забыть, что такие дефекты были найдены Низкое качество регрессионного тестирования Повышенные требования к квалификации тестировщиков Регулярный анализ необходимости и проведение корректировки плана тестирования

Тестирование Не хватает ресурсов тестирования Проанализировать, почему Невозможность выполнить запланированные работы в срок Установление причины нехватки ресурсов (заниженные оценки, низкое качество объекта тестирования, незнание требований и предметной области, изменение сроков тестирования) Перепланирование активностей тестирования Привлечение дополнительных ресурсов

Тестирование Невозможно идентифицировать версию объекта тестирования Неясно, был ли обновлен объект тестирования Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Невозможно понять, например, обнаружен дефект или нереализованная функциональность Соглашение об идентификации версий Разработка и применение BATS (Build Acceptance Test Suite)

Тестирование Объект тестирования не работоспособен Сбой в процессе сборки Отсутствие четкой регламентации процесса сборки (путаница версий кода) Потеря времени на тестирование неработоспособного объекта тестирования Неэффективное тестирование и большое количество «ложных» дефектов Разработка и применение BATS (Build Acceptance Test Suite)

Тестирование Дефекты возникают из-за неверной конфигурации системы / среды тестирования Непонятно, как идентифицировать, где найден и где исправлен дефект Непонятно, как отличать от дефектов кода Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Принятие решения о регистрации и учете таких дефектов на корпоративном / проектном уровнях Классификация локализации дефекта (например, «Требования» , «Дизайн» , «Код» , «Конфигурация» , «Пользовательская документация» и др. )

Тестирование Протоколы тестирования не создаются В них нет описания дефектов Если дефекты не найдены, то создание протоколов – пустая трата времени Нет данных об объеме проведенного тестирования Нет данных о качестве системы (непонятно, проверяли ли работу конкретной функциональности) Фиксировать результаты тестирования в максимально удобной для проектной команды форме (например, в матрице Test Run Coverage) Использовать автоматические средства протоколирования ручного тестирования

Тестирование Как оформлять описание дефекта В протоколе тестирования + регистрация в системе управления дефектами В системе регистрации дефектов вместе с регистрацией В отдельном документе + регистрация в системе управления дефектами Неразбериха с неоднородным оформлением дефектов Дополнительные затраты на поиск описания Принятие решения в рамках проекта (проектов), исходя из удобства и эффективности для всех членов проектной команды (и заказчика, если необходимо)

Тестирование Метрики тестирования не используются Качественной оценки может быть недостаточно Трудно анализировать динамику выполнения проекта Работа с метриками требует проектной культуры Неточное / неверное представление о качестве объекта тестирования Выбрать / применить набор понятных и эффективных метрик тестирования (плотность дефектов, доля трудозатрат, эффективность поиска, доля серьезных дефектов и др. )

Тестирование Сокрытие дефектов ЧП! Негативные последствия для всей проектной команды Ничего не дает – заказчик все равно этот дефект обнаружит! Недостоверные данные о качестве объекта тестирования Не допускать возникновения такой ситуации Оперативно с ней бороться (в том числе и эскалацией проблемы) Разъяснять, что обнаруженный и исправленный дефект – это гораздо лучше, чем отсутствие дефекта

Тестирование Пользовательская документация не тестируется Не запланировано тестирование документации (включая Help) Нет ресурсов для тестирования Тестируют только тестировщики - технические писатели ревью не проводят Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования

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

Приемка Не согласована процедура приемки Что предшествует и что следует за приемо-сдаточными испытаниями Каковы ожидания заказчика на момент приемки Кто принимает решение об успешном завершении проекта со стороны заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая приемо-сдаточные испытания)

Приемка Верификация и валидация Разница этих понятий Ликвидация (минимизация) расхождений между требованиями и ожиданиями заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Поддержка актуальности и приоритетов требований и их учет в плане приемо-сдаточных испытаний

Приемка План приемо-сдаточных испытаний Несоответствие объемов приемо-сдаточных испытаний и системного тестирования Нет ничего, кроме плана приемо-сдаточного тестирования Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая разработку и модификацию плана приемо-сдаточных испытаний) с начала проекта

Приемка График приемо-сдаточных испытаний Определение перечня представителей заказчика, участвующих в проведении приемо-сдаточных испытаний, и их ожиданий Оптимистичные оценки времени и ресурсов для исправления дефектов, найденных во время приемо-сдаточных испытаний Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование графика приемки

Приемка Ожидания заказчика Неизвестны актуальные потребности бизнеса заказчика Неизвестны ожидание представителей заказчика Проблемы во время приемки (отсутствие взаимопонимания со стороны заказчика) Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая персоналии заказчика и их ожидания)

Приемка Лицо, принимающее решение Дистанция между техническим этапом (успешное завершение приемо-сдаточных испытаний) и организационным этапом (подписание акта приемки-сдачи проекта) приемки Необходимость участия компании-разработчика в организационном этапе приемки Задержка сдачи проекта и оплаты заказчиком Планирование и согласование процедуры приемки

Метрики

Согласно международному стандарту ISO 14598: Метрика - это количественный масштаб и метод, который может использоваться для измерения. Введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования.

Классификация задач: процесс

Примеры метрик

Сбор статистики Что собирать: Отличие план/факт Что сколько времени занимает Связь с внешними метриками Зачем собирать: Чтобы найти оптимальные способы планирования Чтобы не повторять ошибок в планировании

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

Метрика 1 Метрика: Доля повторно открытых дефектов. Повторно открытые дефекты = заново открытые / открытые в первый раз (на одной итерации тестирования) Ограничение: Не считаем дефекты, критичность которых ниже чем «незначительные» . Обоснование: Повторно открытые дефекты это двойная работа, это потенциально опасные места, т. к. после закрытия такого бага нет гарантии, что он не всплывет у клиента. Ведутся в таблице с предположением что делать если метрика больше нормы меньше нормы и т. д.

Метрика 2 Метрика: Убойность тестов = число дефектов*100 / число тестов. Убойность тестов – это количество дефектов на 100 тестов Число дефектов – все дефекты, которые были найдены по шагам из тестов на данной итерации тестирования. Число тестов – все тесты, которые были пройдены за итерацию. Ограничение: Не считаем дефекты критичность которых ниже чем «незначиельные. » Обоснование: Эта метрика косвенно отображает качество нашей работы, или работы программистов.

Метрика 3 Метрика: Число дефектов найденных вне теста. (антиубойность) Число дефектов найденных вне теста = число дефектов, найденных вне тестов*100 / число тестов Требует введение следующего Правила: «Нельзя приписывать тесту найденный дефект, если шаги для воспроизведения этого дефекта отличаются больше чем на 30% от шагов, описанных в тесте» . . . (ограничения и определения пропущены) Обоснование: Эта метрика напрямую отображает недостатки методики (тестов). Идеальным было бы, чтобы все баги находились при прохождении шагов по тесту.

Метрика 4 Метрика: Эффективность тестирования = число дефектов/трудозатраты (чел/ч). Определение. Эффективность тестирования – это число дефектов, найденных за один час одним человеком. Обоснование: Эта метрика отображает эффективность использования ресурсов Метрики хранились в Access базе было написано приложение в котором тестировщики вовремя или по завершению тестирования вносили данные приложение само раскидывала числа по табличкам.

Итог жизни четырех метрик Предполагалось в течении полугода пособирать числа для статистики, после уже считать что то и делать выводы, пособирали пару месяцев для интереса считали цифры (с умным видом их обсуждали : )). Потом руководитель отдела свернул эту работу в виду нехватки ресурсов для поддержания системы.

Поймите для чего вы хотите что-то мерить!!! Метрики должны иметь своей целью УЛУЧШЕНИЕ процесса. Для этого надо знать КРИТЕРИИ УСПЕШНОСТИ этого самого процесса. После чего необходимо заполучить инструменты, позволяющие выяснить ПРИЧИНУ проблем, чтобы работать с их корнями.

Перед измерением метрик Сначала надо проводить грамотные пост мортемы, обсуждать, выяснять, с какими проблемами столкнулись. Анализировать их: как они повредили, как вы можете оценить масштабы их вреда и т. д. Благодаря пост мортемам можно: выявить проблемы и договориться о путях улучшения Потом выяснить, что считать проблемами, и как это измерять - то есть, заложить базис для системы метрик. Затем уже что-то мерять…

Зачем вообще что-то мерять? Непрерывно оценивать качество процесса, продукта , услуги Улучшать процессы Делать приемку товаров, услуг Оценивать достижение целей Принимать обоснованные решения - управлять

Зачем вообще что-то мерять? Зачем непрерывно оценивать качество процесса, продукта , услуги? Инструментарий. Контрольная диаграмма (Control Chart) Пример. Количество дефектов в очередной итерации, спринте, релизе

Зачем вообще что-то мерять? Зачем улучшать процессы, продукт, сервис? Инструментарий. Процесс улучшений Пример. Улучшить эффективность устранения дефектов.

Зачем вообще что-то мерять? Зачем Ддлать приемку товаров/услуг Инструментарий. Договорные обязательства, специфический инструментарий, запланированные процедуры контроля критериев Примеры: Программный продукт должен содержать не более 10 несущественных дефектов Вебсайт должен быть доступен не менее 99. 8% времени Отчет А в среде Б должен формироваться не более чем за В секунд

Зачем вообще что-то мерять? Зачем оценивать достижение целей? Инструментарий. План действий и система измерений отражающие текущее, промежуточные и целевое состояния Пример: Бизнес план для выхода на валовую прибыль Х в очередном году

Зачем вообще что-то мерять? Принимать обоснованные решения - Управлять

Условия успеха для внедрения метрик

Условия успеха Люди В предметной области измерений В метриках, применимых к предметной области В адекватном выборе метрик В процессах Подготовленные (обученные) В инструментарии Доступные Деятельность, ответственности и полномочия утверждены Выделяется достаточно времени

Условия успеха Процессы Должны быть внедрены и настроены Должны отвечать нуждам бизнеса Им должны следовать Должны быть измеримыми Должны быть открытыми для улучшений

Условия успеха Инструментарий Репозитории: Документированных стандартных процессов, шаблонов, инструкций Документов и кода, результатов инспекций документов и кода Контроля качества (документация или системы управления дефектами) Системы автоматизированной инспекции кода Системы планирования Средства оценки объема работ Системы учета рабочего времени Процедуры (желательно автоматические) сбора данных для метрик Реестры метрик, автоматизированные системы обработки и представления метрик Важно! Нужно стремиться к максимальной автоматизации.

Основные Концепции Метрик Измерения должны давать ответы, что стоит за ними, т. е. быть полезными Измерения должны быть интегрированы в инженерные и управленческие процессы Измерения должны быть ориентированы на конкретные цели и помогать бизнесу быть успешным Ловушкой многих программ измерений является отсутствие взаимосвязи между целями бизнеса и этой программы. Лучший способ контролировать успешность проекта это установить формальные цели (содержание, расписание, бюджет, качество) в виде измеримых величин и контролировать их

Основные Концепции Метрик

Основные Концепции Метрик

Основные Концепции Метрик

Основные Концепции Метрик

Основные Концепции Метрик

Размер – условная единица объема работы

Понятие Размера (Size) Оценка размера (Size Estimate) в некоторых условных единицах используя определенные методики. Методики и единицы: Функциональные единицы (Function Points Analysis - FPA) и разновидности FPA Единицы вариантов использования (Use Case Points - UCP) Строки кода (LOC, KLOC) Story points (SCRUM) Любые другие единицы работы, которые могут осмысленно выразить общий объем работ или его существенную часть (веб страница для верстки, страница текста для перевода, одно требование в спецификации, один шаг тестового сценария, класс, и т. п. )

Понятие Размера (Size) Зачем нужен Size: Абстрагирование от уровня знаний и опыта исполнителей Отображение реального объема работ Использования в метриках, KPI для оценки производительности, качества Оценки производительности команды или персональной Для прогнозирования: времени, качества, расходов Для использования в Модели размера - учета многочисленных факторов (сложность, определенность требований, производительность системы, уровни зрелости как разработчиков так и пользователей, и т. п. ) Оценки временн. Ых затрат (Effort Estimate)

Понятие Размера (Size) Размер спецификаций Способы измерения размера спецификаций: По количеству требований, договоренность об уровне декомпозиции По количеству страниц, договоренность о стиле, шаблоны По количеству разделов По весу напечатанных требований ☺

Понятие Размера (Size) Размер тестирования Способы измерения размера тестирования: По количеству шагов в тест кейсах/сценариях По количеству пунктов в чек листах По необходимости подготовки предусловий По необходимости и количеству отчетности По типам тестирования

Модель размера. Пример

Измерения по фазам жизненного цикла

Измерения по фазам жизненного цикла Шаблоны обнаружения дефектов (Defect Arrival Patterns)

Измерения по фазам жизненного цикла

Измерения по фазам жизненного цикла Встроенные измерения качества исключительно важны! Они позволяют: Своевременно оценивать качество продукта в процессе его производства путем оценки промежуточных артефактов Оценивать проблемные фазы и принимать корректирующие меры Уменьшать затраты (время, деньги, ресурсы) на устранение дефектов Прогнозировать уровень качества продукта Повысить качество конечного продукта и как следствие удовлетворение заказчика

Модель реестра метрик Состав реестра метрик Описание метрики (метрик) представленных в реестре, их назначение, взаимосвязь с целями проекта, компании, заказчика Формула метрики Источники измерений Частота сбора измерений Формат представления измерений и метрик – таблицы, графики Анализ поведения метрик – допустимые пределы; желаемые показания, тренды; корректирующие воздействия при достижении допустимых пределов и т. п.

Модель реестра метрик

Модель реестра метрик

Инспектирование документов

Функциональное тестирование Основные характеристики качества: Плотность дефектов (Defect Density) – степень качества, количество дефектов на единицу размера Эффективность устранения дефектов (Defect Removal Efficiency) – степень качества для заказчика Происхождение дефектов (Defect Origin) – показывает, на какой стадии был внесен дефект

Функциональное тестирование Defect density (степень качества) Плотность дефектов (Defect Density) – количество дефектов на единицу размера. На весь продукт, на часть функционала, на релиз, на итерацию, на спринт, на документ, на объем трудозатрат и т. п. DD = Σ Дефектов / Релиз DD = Σ Дефектов / Σ KLOC DD = Σ Дефектов / Σ Story_Points_per_Sprint DD = Σ Дефектов / Σ Шагов_Тест. Кейсов DD = Σ Дефектов / Σ Размер_Спецификации

Функциональное тестирование Эффективность устранения дефектов (Defect Removal Efficiency) – соотношение количества устраненных дефектов до окончания стадии и общего количества найденных дефектов DRE = Σ Устраненные_Дефекты ÷ (Σ Устраненные_Дефекты + Σ Обнаруженные_Позже) * 100%

Функциональное тестирование Происхождение дефектов (Defect Origin) – показывает, на какой стадии был внесен дефект, необходимо для выявления наиболее проблемных процессов с целью принятия фокусных улучшений

Функциональное тестирование При подсчете плотности дефектов (Defect Density) и эффективность устранения дефектов (Defect Removal Efficiency) можно использовать их ≪тяжесть≫ (Severity): Считать DD и DRE отдельно по разным категориям ≪тяжести≫ (High, Middle, Low), и/или Ввести весовые коэффициенты ≪тяжести≫, например: High = 5, Middle = 3, Low = 1 IEEE J-STD-016 -1995 предлагает такую классификацию дефектов: 1 – Критические ошибки; 2 – Ошибка, которую нельзя обойти ; 3 – Ошибка, которую можно обойти; 4 – Неточность; 5 – Запрос об изменении; 6 – Консультация

Функциональное тестирование Оценка качества тестирования: Аудит – выборочное ре-тестирование (5 -10%? ) Эффективность устранения дефектов (DRE) Степень покрытия тестированием функциональности продукта Матрица прослеживаемости требований (Requirements Traceability Matrix - RTM). Инструмент – MS Excel, Testlink, и т. п. Покрытие = (Колич. Покр. Треб/Колич. Всех. Треб)*100%

Burn up/down charts Burn down. Инструмент анализа и визуализации Прогресс команды внутри итерации Спринт, релиз, проект Burn up. Инструмент анализа и визуализации Прогресс команды и предсказание завершения в Проекте, релизе Размер Product Backlog Решения о перепланировании Решения о приоритетах Единицы размера Часы трудозатрат Story Points Др. единицы

Задание Составить стратегию и план тестирования для приложения Paint