Идентификация рисков и проблем тестирования

Идентификация рисков и
проблем тестирования

Александр Александров
УЦ Luxoft www.luxoft-training.ru

Немного о себе
 1963-1999 – Вычислительный центр Московского
Государственного университета им. М.В. Ломоносова
(студент, сотрудник)
 1999-2005 – Luxoft (руководитель группы
тестирования, тест-менеджер)
 2006-2007 – Auriga (директор по качеству)
 С 2008 – Luxoft (эксперт по управлению качеством
ПО)
 Кандидат физико-математических
наук, доцент, старший научный сотрудник
 Сертифицированный инструктор университета
Carnegie Mellon по тематике Quality Assurance

Опыт работы
 Более 30 лет работы в области тестирования и
обеспечения качества (МГУ, Luxoft, Auriga)
 Более 5 лет работы в области управления
качеством (Luxoft, Auriga)
 Опыт cертификации ISO 9001 (Luxoft), CMM, CMMI
(Luxoft, Аурига)
 Опыт внедрения процессов в рамках модели CMMI
(Luxoft, Аурига)
 Сертификат обучения Project Management от Project
Management Institute (2000)
 Сертификат обучения Introduction to Capability
Maturity Model Integration v. 1.2 от ProceXpert
(2007)

Подготовка проекта

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

 Привлекать тестировщиков для ревью трудозатрат
 Проводить независимую оценку трудозатрат
тестировщиками (PCB/PPB, методики, литература)


 Неполнота плана-графика работ по тестированию
Вне связи с остальными работами проекта
Поздний старт активностей по тестированию
Только динамическое тестирование
 Недостаток времени / ресурсов на подготовку и проведение
тестирования
 Низкое качество объекта тестирования

 Проводить ревью плана-графика
 Проводить разработку и согласование плана всех
требуемых активностей по тестированию
 Использовать WBS тестирования

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

Стратегия тестирования

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

 Разрабатывать стратегию тестирования
 Согласовывать и утверждать стратегию


 Неполнота работы с требованиями (на
примере Agile)
Отсутствие формализованного описания требований
(например, в виде СИС) трактуется как отсутствие требований
Требованиями не занимается никто
Нет базы тестирования

 Обучить тестировщиков работе с требованиями,
представленными в любом виде
 Привлекать тестировщиков к работе с требованиями
 Планировать работы по анализу требований

 Неполнота объема тестирования (на примере Agile)
Тестирование производится исключительно в рамках Story tests /
Sprint Backlogs
Не проводится «системное» тестирование
 Нет гарантии работоспособности результата работы в целом
 Проблемы в последующих итерациях / спринтах

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


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

 Зафиксировать перечень объектов тестирования и
объем тестирования для каждого из них
 Связать активности тестирования и активностей
разработки


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


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

 Совместно с менеджером проекта
анализировать, рассматривать и отслеживать риски
тестирования наряду со всеми проектными рисками


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

 Совместно с менеджером проекта анализировать
особенности объекта тестирования и отражать
принятые решения в стратегии теститрования

Анализ требований
 Требования анализируются и разрабатываются без
участия тестировщиков
Участвуют только аналитики и проектировщики
Тестировщики привлекаются после утверждения первой версии
требований
 Тестировщики плохо знают предметную область проекта
 Замедление работы тестировщиков: приложение готово, план
тестирования – нет
 Часть требований нельзя протестировать
 Проводить ревью требований тестировщиками
 Обучать тестировщиков предметной области проекта в рамках
обучения проектной команды
 Выполнять анализ тестируемости требований до их утверждения

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

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


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


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

 Провести анализ существующих изменений требований и
способа их представления
 Разработать актуальные версии планов тестирования
 Применять актуальные версии планов тестирования


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

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

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

 Использовать как явные, так и подразумеваемые
требования
 Специфицировать интерфейсы (документ, прототип,
CLAF…)

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

 Использовать заглушки / тест-драйверы
 Планировать их разработку в стратегии
тестирования и плане-графике проекта

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

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


 Оценка качества плана тестирования в
процессе разработки
Как определить, что разработка плана тестирования
завершена
Как определить качество разработанного плана
 Низкое качество плана тестирования – низкое качество
 Результаты ревью плана тестирования позволяют
оценить его качество (PCB/PPB …)


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

 Мониторинг результативности тестирования
 Коррекция плана тестирования


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

 Планировать ревью плана тестирования
аналитиками
 Планировать ревью требований тестировщиками


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


 Тестовые сценарии содержат детали
Изменение требований и дизайна вызывает объемные изменения
планов тестирования
 Затраты на обеспечение актуальности планов тестирования
 Затраты на переучивание тестировщиков

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


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

 Проектировать и разрабатывать тестовые данные с
использованием классов эквивалентности и граничных
значений

Автоматизация тестирования

 Автоматизация функционального
тестирования применима в любом проекте
Завышенные требования к команде тестировщиков

Заниженная оценка трудозатрат на тестирование

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


тестирования применима только для
регрессионного тестирования
Как правило, но не всегда

Пример: проекты redevelopment

 Невозможность проведения ручного тестирования
 Рост затрат на ручное тестирование


тестирования применима только при большом
числе раундов тестирования
Пример: проекты mission-critical

 Невозможность проведения ручного тестирования
 Рост затрат на ручное тестирование


 Раннее проведение нагрузочного
Исправление функциональных дефектов, как правило,
вызывает перезапись и повторный прогон нагрузочных
скриптов
Пример: нагрузочное тестирование прототипа

 Необходимость выделения ресурсов для повторного
проведения нагрузочного тестирования
 Детальное планирование момента проведения
нагрузочного тестирования


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

 Согласование модели нагрузки с заказчиком

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

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

Тестирование

 Тестирование проводится не по плану
Крайне нежелательно!
Иногда это – единственная возможность (например, для
восстановления требований legacy system)
 Нет уверенности в правильности и полноте тестирования
 Повышенные требования к квалификации тестировщиков

 Детальный анализ невозможности построения
планов тестирования


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

 Регулярный анализ необходимости и проведение
корректировки плана тестирования


 Не хватает ресурсов тестирования
Проанализировать, почему
 Невозможность выполнить запланированные работы в срок

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


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


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


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


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


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


 Коммуникация и исправление дефектов «на
лету»
Преимущество – скорость
Недостатки:
 Отсутствие документирования и высокая вероятность
повторного появления дефекта
 Невозможность идентификации верcии
 Годится как временная мера, в перспективе возникают
проблемы (повторное появление дефектов,
недокументированные дефекты)
 Сочетать с систематическим тестированием


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

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


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


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

Приемка

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

 Планирование и согласование процедуры приемки
(включая приемо-сдаточные испытания)

Приемка

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

 Поддержка актуальности и приоритетов требований
и их учет в плане приемо-сдаточных испытаний

Приемка

 План приемо-сдаточных испытаний
Несоответствие объемов приемо-сдаточных испытаний и
системного тестирования
Нет ничего, кроме плана приемо-сдаточного тестирования
 Увеличение времени приемо-сдаточных испытаний

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

Приемка

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

 Планирование и согласование графика приемки

От обучения …

 Рассматриваются конкретные действия и/или
артефакты (например, риски)
 Реплики слушателей
Попытка их использования закончилась неудачей
Это никем не востребовано
Никто не умеет с этим работать
Никто не знает, зачем это нужно
Работать с этим сложно
Есть что-то похожее, но …
Неизвестно, что это такое

… к консалтингу

 Анализ соответствующего процесса и
рекомендации по его совершенствованию
 Другая интерпретация реплик слушателей
Процесс не дает ожидаемых результатов
У процесса нет владельца
Процессу никто не учит
Никто не знает о преимуществах процесса
Процесс неадекватно сложный / трудоемкий
Есть что-то похожее на процесс, но …
Процесса нет

Риски консалтинга

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

Пример 1
 Проблема
Оценки трудозатрат на тестирование для новых
проектов, получаемые от экспертов, неточны
 Анализ
Доступны сведения о завершенных проектах:
 Объем разработанного кода
 Число найденных дефектов
 Число дефектов, найденных заказчиком
 Суммарные трудозатраты в проекте
 Рекомендации
Использовать доступные сведения для более точной
оценки трудозатрат

Пример 2

Отклонения от плана-графика работ по тестированию
обнаруживаются слишком поздно
 Анализ
Мониторинг проектов не производится
Метрики проектов не собираются и не анализируются
Разработать понятные метрики и использовать их для
анализа хода проекта
Регулярно отслеживать соответствие хода проекта
плану-графику

Пример 3

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

Пример 4

Процессы разработаны и опубликованы, но при
их использование ничего не известно
 Анализ
Служба качества отсутствует
Поэтому контроль процессов не производится
Создать службу качества
Разработать процесс контроля процессов

Пример 5

Процессы разработаны, опубликованы и внедрены,
но используются не в соответствии с бизнес-целями
 Анализ
Совершенствование процессов не ориентировано на
цели компании
Планировать активности по совершенствованию
процессов в соответствии с целями компании
(таймшиты в ресурсных проектах)

Рекомендации

 Проводя обучение, интересоваться состоянием
процессов
 Идентифицировать процессные проблемы и
обращать на них внимание в тренингах
 В рамках консалтинга проводить анализ и
обсуждать активности по совершенствованию
процессов
 Оценивать востребованность этих активностей
 Предостерегать от активностей, которые не дают
преимуществ

Спасибо за внимание!
Вопросы?

УЦ Luxoft www.luxoft-training.ru

Идентификация рисков и проблем тестирования

More Related Content

Similar to Идентификация рисков и проблем тестирования (20)

More from SQALab (20)

Идентификация рисков и проблем тестирования