SlideShare a Scribd company logo
Идентификация рисков и проблем тестирования Александр Александров. УЦ Люксофт
Немного о себе 1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник) 1999-2005 – Люксофт (руководитель группы тестирования, тест-менеджер) 2006 -200 7 –  Auriga  (директор по качеству) C 200 8  –  Люксофт (эксперт по управлению качеством ПО) Кандидат физико-математических наук, доцент, старший научный сотрудник Сертифицированный инструктор университета  Carnegie Mellon  по тематике  Quality Assurance
Опыт работы Более  30  лет работы в области тестирования и обеспечения качества (МГУ ,  Люксофт , Auriga ) Более  5  лет работы в области управления качеством (Люксофт , Auriga ) Опыт  c ертификации  ISO 9001  (Люксофт),  CMM ,  CMMI  (Люксофт, Аурига) Опыт внедрения процессов в рамках модели  CMMI  (Люксофт, Аурига)   Сертификат обучения  Project Management  от  Project Management Institute (2000) Сертификат обучения  Introduction to Capability Maturity Model Integration v. 1.2  от  ProceXpert (2007)
Область проекта Название проблемы Комментарий 1 Комментарий 2 … Риск 1 Риск 2 … Рекомендация 1 Рекомендация 2 …
Подготовка проекта Неполое планирование и оценка трудозатрат Производится только  планирование и  оценка трудозатрат всего проекта менеджером проекта Специалисты по тестированию не привлекаются ни к проведению, ни к ревью получивш ихся   результатов Недостаток ресурсов тестирования Недостаток  времени для активностей тестирования Привлекать тестировщиков для ревью плана-графика и трудозатрат Проводить независимую оценку трудозатрат тестировщиками ( PCB/PPB,  методики, литература)
Подготовка проекта Неполнота  scope  тестирования  Необоснованные предположения о   наличии / отсутствии конкретных видов тестирования (нагрузочного, конфигурационного и др.) Отказ от системного тестирования (достаточно интеграционного и компонентного) Только динамическое тестирование Необходимость перепланирования в условиях нехватки ресурсов Низкое качество объекта тестирования Проводить детальный анализ  scope  проекта Делать обоснованные предположения о наличии неявных требований, которые оказывают влияние на  scope  тестирования
Подготовка проекта Игнорирование внутренних рисков   тестирования  Отсутствие буфера, который допускает возможность сдвига сроков проведения системного тестирования Отсутствие буфера, который допускает возможность сдвига сроков разработки планов тестирования Необходимость перепланирования в условиях нехватки ресурсов   при наступлении риска Низкое качество объекта тестирования Проводить мониторинг плана-графика проекта Включить и проводить мониторинг указанных рисков
Стратегия тестирования Стратегия тестирования отсутствует / не поддерживается Отсутствие согласованного понимания порядка подготовки и проведения тестирования в проекте Хаотичная передача версий на тестирование Нет базы тестирования Низкое качество тестирования Риск нехватки ресурсов тестирования Разрабатывать стратегию тестирования Согласовывать  и утверждать стратегию тестирования
Стратегия тестирования Критерии начала и завершения тестирования  Отсутствуют критерии начала тестирования Отсутствие / Нечеткость классификации серьезности дефектов Нет понятия готовности объекта тестирования (модульное тестирование,  BATS  …) Коммуникационные проблемы с разработчиками (тестирование) и заказчиком (приемка) Разработать однозначные критерии начала и завершения тестирования для каждого этапа проекта
Стратегия тестирования Риски тестирования  Не рассматриваются и не анализируются наряду с остальными проектными рисками Не используется исторический опыт рисков тестирования Тестирование становится неадекватно высоко рисковой частью проекта Высока вероятность неуспешного тестирования Совместно с менеджером проекта анализировать, рассматривать и отслеживать риски тестирования наряду со всеми проектными рисками
Стратегия тестирования Особенности объекта тестирования  Не учитываются особенности объекта тестирования (например, отсутствие пользовательского интерфейса, необходимость специальной среды тестирования) Нехватка  (специально подготовленных) ресурсов тестирования Неадекватная среда тестирования Низкое качество тестирования Совместно с менеджером проекта анализировать особенности объекта тестирования и отражать принятые решения в стратегии тестирования
Стратегия тестирования Проблемы, с которыми вы сталкивались когда-либо...
Анализ требований Требования анализируются разрабатываются и изменяются без участия тестировщиков Участвуют только аналитики и проектировщики Тестировщики привлекаются после утверждения первой версии требований Тестировщики плохо знают предметную область проекта Замедление работы тестировщиков: приложение готово, план тестирования – нет Часть требований нельзя протестировать Проводить ревью требований тестировщиками Обучать тестировщиков предметной области проекта в рамках обучения проектной команды Выполнять анализ тестируемости требований до их утверждения
Анализ требований Требования не ранжированы по приоритетам Сомнительно, что все требования имеют одинаковый приоритет Нет возможности упорядочить и указать приоритеты для разработки и прогона тестовых сценариев Невозможность проведения первоочередного / тщательного тестирования ключевых требований Провести анализ существующих требований и определить приоритеты требований Учитывать эти приоритеты при определении очередности разработки и тестовых сценариев и покрытии требований тестовыми сценариями
Анализ требований Требований в проекте нет / они постоянно изменяются Ситуация в принципе невозможная / нормальная  Имеется в виду либо отсутствие документально зафиксированных требований либо их высокая изменчивость Невозможность проведения тестирования по плану Невозможность адекватной оценки качества объекта тестирования Провести анализ существующих требований и способа их представления Разработать планы тестирования Применять планы тестирования
Анализ требований Нет аналитика – некому поддерживать требования Или «Давайте будем поддерживать все» Разница между ролью и ресурсом Невозможность создания актуального плана тестирования Невозможность адекватной оценки качества объекта тестирования Предусмотреть в плане-графике работы по сбору, анализу и поддержанию требований Наделить конкретный проектный ресурс ролью аналитика
Дизайн Архитектура системы не учитывается при разработке стратегии тестирования Необходимо для повышения эффективности тестирования (например, нужен ли и как организовать доступ на уровне СУБД) Необходимо для организации интеграционного тестирования Неэффективное тестирование (большие затраты при скромных результатах) Знакомство тестировщиков с архитектурой системы Планирование тестирования с учетом архитектуры системы
Дизайн Нет единого решения по пользовательским интерфейсам Неоправданный разнобой в реализации интерфейсов приложения Неудобство для заказчика Замечания тестировщиков на это тему игнорируются («Такого требования нет!») Низкое качество  Usability  объекта тестирования Не удается найти дефекты  Usability  Использовать как явные, так и подразумеваемые требования Специфицировать интерфейсы (документ ,  прототип ,   CLAF… )
Дизайн У объекта тестирования отсутствует пользовательский интерфейс Непонятно, как «подобраться» к объекту тестирования Непонятно, как визуализировать фактический результат для сравнения с ожидаемым Замечания тестировщиков на это тему игнорируются  Невозможность провести тестирование Использовать заглушки / тест-драйверы Планировать их разработку в стратегии тестирования и плане-графике проекта
Дизайн Нет требований к окружению системы Требования к окружению не сформулированы явно, а определяются в процессе разработки системы Требования неизвестны тестировщикам и не учитываются при создании среды тестирования Большое число «ложных» дефектов Низкое качество тестирования Зафиксировать требования к тестовой среде Проводить тестирование при соблюдении (в некоторых случаях – и при несоблюдении) этих требованиях Отразить требования в описании инсталляции и пользовательской документации
План тестирования Не анализируется покрытие требований тестовыми сценариями Нет соответствия приоритетов требований и степени их покрытия тестовыми сценариями   Затруднительно установление соответствия дефекта требованию, которое он нарушает Низкое качество тестирования Низкое качество (скорость и эффективность) описания и исправления дефектов Покрытие требований тестовыми сценариями с учетом приоритетов
План тестирования Не проводится оценка качества плана тестирования в процессе разработки Как определить, что разработка плана тестирования завершена   Как определить качество разработанного плана тестирования Низкое качество плана тестирования – низкое качество тестирования Результаты ревью плана тестирования позволяют оценить его качество  (PCB/PPB  …)
План тестирования Не проводится оценка качества плана тестирования   в процессе применения Тестовые сценарии не находят дефектов Тестовые сценарии не находят существенных дефектов Тестовые сценарии находят одни и те же дефекты Неоправданно большие затраты на поиск дефектов Большое число пропущенных дефектов Пропущены существенные дефекты Мониторинг результативности тестирования Коррекция плана тестирования
План тестирования Ревью плана тестирования не планируется / не производится Считается сильно затратным Считается неэффективным План тестирования содержит дефекты Про эти дефекты никто не знает Они обнаруживаются при тестировании (хорошо, если это так) Планировать ревью плана тестирования аналитиками Планировать ревью требований тестировщиками
План тестирования Тестовые сценарии не содержат деталей Конкретные действия тестировщика / инженера по автоматизации придумываются во время тестирования Затраты на воспроизведение действий при воспроизведении дефекта Низкое качество тестирования из-за неполного набора действий Невозможность проверки степени покрытия пользовательского интерфейса Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности
План тестирования Тестовые сценарии содержат детали Изменение требований и дизайна вызывает объемные изменения планов тестирования Затраты на обеспечение актуальности планов тестирования Затраты на переучивание тестировщиков Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности Использовать двухуровневую структуру плана тестирования – тестовый сценарии + тесты
План тестирования Проектирование и разработка тестовых данных не планируется и не производится Данные придумываются во время тестирования Данных недостаточно (например, используются только корректные данные) Тестирование миграции без проектирования тестовых данных невозможно Затраты на воспроизведение данных для воспроизведения дефекта Низкое качество тестирования из-за малого набора тестовых данных Проектировать и разрабатывать тестовые данные с использованием классов эквивалентности и граничных значений
Автоматизация тестирования Автоматизация функционального тестирования применима в любом проекте Завышенные требования к команде тестировщиков Заниженная оценка трудозатрат на тестирование   Невозможность проведения автоматизированного тестирования Поздний переход на ручное тестирование Детальный анализ целесообразности автоматизации тестирования
Автоматизация тестирования Автоматизация функционального тестирования применима только для регрессионного тестирования Как правило, но не всегда Пример: проекты  redevelopment  Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования
Автоматизация тестирования Автоматизация функционального тестирования применима только при большом числе раундов тестирования Как правило, но не всегда Пример: проекты  mission-critical Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования
Автоматизация тестирования Раннее проведение нагрузочного тестирования Исправление функциональных дефектов, как правило, вызывает перезапись и повторный прогон нагрузочных скриптов Как правило, но не всегда Пример: нагрузочное тестирование прототипа Необходимость выделения ресурсов для повторного проведения нагрузочного тестирования Детальное планирование момента проведения нагрузочного тестирования
Автоматизация тестирования Неадекватная модель нагрузки Совокупность: ролей (кто работает) характеристических сценариев (что делает) профилей (доля и частота) не соответствует бизнесу заказчика Неадекватные результаты нагрузочного тестирования Несоответствие ожиданием заказчика Согласование модели нагрузки с заказчиком
Среда тестирования Тестирование выполняется в среде разработки одного или нескольких проектов Путаница версий Нестабильность объекта тестирования (исправления «на лету») Невозможность обнаружения части дефектов Низкое качество тестирования Сложность коммуникаций с разработчиками (невозможность воспроизвести дефект) Создание обособленной среды тестирования Сборка объекта тестирования из  baseline
Тестирование Дефекты, найденные вне плана тестирования, не приводят к его корректировке Сложности их повторной проверки Можно забыть, что такие дефекты были найдены Низкое качество регрессионного тестирования Повышенные требования к квалификации тестировщиков Регулярный анализ необходимости и проведение корректировки плана тестирования
Тестирование Не хватает ресурсов тестирования Проанализировать, почему Невозможность выполнить запланированные работы в срок Установление причины нехватки ресурсов (заниженные оценки, низкое качество объекта тестирования, незнание требований и предметной области, изменение сроков тестирования) Перепланирование активностей тестирования Привлечение дополнительных ресурсов
Тестирование Невозможно идентифицировать версию объекта тестирования Неясно, был ли обновлен объект тестирования Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Невозможно понять, например, обнаружен дефект или нереализованная функциональность Соглашение об идентификации версий Разработка и применение  BATS (Build Acceptance Test Suite)
Тестирование Объект тестирования не работоспособен Сбой в процессе сборки Отсутствие четкой регламентации процесса сборки (путаница версий кода) Потеря времени на тестирование неработоспособного объекта тестирования Неэффективное тестирование и большое количество «ложных» дефектов Разработка и применение  BATS (Build Acceptance Test Suite)
Тестирование Дефекты возникают из-за неверной конфигурации системы / среды тестирования Непонятно, как идентифицировать, где найден и где исправлен дефект Непонятно, как отличать от дефектов кода Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Принятие решения о регистрации и учете таких дефектов на корпоративном / проектном уровнях Классификация локализации дефекта (например, «Требования», «Дизайн», «Код», «Конфигурация», «Пользовательская документация» и др.)
Тестирование Протоколы тестирования не создаются В них нет описания дефектов Если дефекты не найдены, то создание протоколов – пустая трата времени Нет данных об объеме проведенного тестирования Нет данных о качестве системы (непонятно, проверяли ли работу конкретной функциональности) Фиксировать результаты тестирования в максимально удобной для проектной команды форме (например, в матрице  Test Run Coverage) Использовать автоматические средства протоколирования ручного тестирования
Тестирование Как оформлять описание дефекта В протоколе тестирования + регистрация в системе управления дефектами В системе регистрации дефектов вместе с регистрацией В отдельном документе   + регистрация в системе управления дефектами Неразбериха с неоднородным оформлением дефектов Дополнительные затраты на поиск описания Принятие решения в рамках проекта (проектов), исходя из удобства и эффективности для всех членов проектной команды (и заказчика, если необходимо)
Тестирование Метрики тестирования не используются Качественной оценки может быть недостаточно Трудно анализировать динамику выполнения проекта Работа с метриками требует проектной культуры   Неточное / неверное представление о качестве объекта тестирования Выбрать / применить набор понятных и эффективных метрик тестирования (плотность дефектов, доля трудозатрат, эффективность поиска, доля серьезных дефектов и др.)
Тестирование Сокрытие дефектов ЧП! Негативные последствия для всей проектной команды Ничего не дает – заказчик все равно этот дефект обнаружит! Недостоверные данные о качестве объекта тестирования Не допускать возникновения такой ситуации Оперативно с ней бороться   (в том числе и эскалацией проблемы) Разъяснять, что обнаруженный и исправленный дефект – это гораздо лучше, чем отсутствие дефекта
Тестирование Пользовательская документация не тестируется Не запланировано тестирование документации (включая  Help) Нет ресурсов для тестирования Тестируют только тестировщики - технические писатели ревью не проводят Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования
Тестирование Не проводится системное тестирование Системное тестирование не планируется Нет времени для системного тестирования Допустимо в проектах сопровождения Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования
Приемка Не согласована процедура приемки Что предшествует и что следует за приемо-сдаточными испытаниями Каковы ожидания заказчика на момент приемки Кто принимает решение об успешном завершении проекта со стороны заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая приемо-сдаточные испытания)
Приемка Верификация и валидация Разница этих понятий Ликвидация (минимизация) расхождений между требованиями и ожиданиями заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Поддержка актуальности и приоритетов требований и  их учет в плане приемо-сдаточных испытаний
Приемка План приемо-сдаточных испытаний Несоответствие объемов приемо-сдаточных испытаний и системного тестирования Нет ничего, кроме плана приемо-сдаточного тестирования Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая разработку и модификацию плана приемо-сдаточных испытаний) с начала проекта
Приемка График приемо-сдаточных испытаний Определение перечня представителей заказчика, участвующих в проведении приемо-сдаточных испытаний, и их ожиданий Оптимистичные оценки времени и ресурсов для исправления дефектов, найденных во время приемо-сдаточных испытаний Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование графика приемки
Приемка Ожидания заказчика Неизвестны актуальные потребности бизнеса заказчика Неизвестны ожидание представителей заказчика Проблемы во время приемки (отсутствие взаимопонимания со стороны заказчика) Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая персоналии заказчика и их ожидания)
Приемка Лицо, принимающее решение Дистанция между техническим этапом (успешное завершение приемо-сдаточных испытаний) и организационным этапом  ( подписание акта приемки-сдачи проекта) приемки Необходимость участия компании-разработчика в организационном этапе приемки Задержка сдачи проекта и оплаты заказчиком Планирование и согласование процедуры приемки
Подробнее … Подготовка проекта TST-006 –  Управление тестированием на примере реальных проектов Стратегия тестирования TST-004 –  Управление тестированием TST-005 –  Управление тестированием, углубленный курс TST-027 –  Тестирование в  Agile  проектах Анализ требований TST-010 –  Основы тест-дизайна TST-016 –  Тест-дизайн, практические рекомендации
Подробнее … Дизайн TST-016 –  Тест-дизайн, практические рекомендации TST-019 –  Тестирование  Usability  TST-020 –  Тестирование  Web- приложений План тестирования TST-016 –  Тест-дизайн, практические рекомендации TST-022 –  Статическое тестирование на практике
Подробнее … Автоматизация тестирования TST-012 –  Основы автоматизированного тестирования … Тренинги по конкретным инструментам Семейство  Mercury Семейство  Rational  и  IBM Rational Семейство  Silk TestComplete Selenium FIT …
Подробнее … Среда тестирования TST-004 –  Основы управления тестированием Тестирование TST-001 –  Основы тестирования TST-014 –  Основы практического тестирования TST-052 –  Практикум по использованию  Rational Clear Quest Приемка TST-004 –  Основы управления тестированием TST-006 –  Управление тестированием на примере реальных проектов
Спасибо  за внимание! Вопросы? Учебный Центр  Luxoft : Школа Менеджера Проекта Школа Аналитика Школа Тестировщика Школа Архитектора и Разработчика

More Related Content

What's hot

Варианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовВарианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектов
SQALab
 
Роли, в которые играют тестировщики
Роли, в которые играют тестировщикиРоли, в которые играют тестировщики
Роли, в которые играют тестировщики
SQALab
 
Как оценить проект, чтобы не было мучительно больно...потом
Как оценить проект, чтобы не было мучительно больно...потомКак оценить проект, чтобы не было мучительно больно...потом
Как оценить проект, чтобы не было мучительно больно...потом
Vladymyr Rudenko
 
Test labs 2016. Пренебрежение лучшими практиками тестирования
Test labs 2016. Пренебрежение лучшими практиками тестированияTest labs 2016. Пренебрежение лучшими практиками тестирования
Test labs 2016. Пренебрежение лучшими практиками тестирования
Sasha Soleev
 
Risk-based testing management. От теории к современной практике
Risk-based testing management. От теории к современной практикеRisk-based testing management. От теории к современной практике
Risk-based testing management. От теории к современной практике
SQALab
 
Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...
Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...
Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...
SQALab
 
Test labs 2016. QA в тотальном аутсорсе
Test labs 2016. QA в тотальном аутсорсеTest labs 2016. QA в тотальном аутсорсе
Test labs 2016. QA в тотальном аутсорсе
Sasha Soleev
 
Waterfall revisited: практические метрики тестирования
Waterfall revisited: практические метрики тестированияWaterfall revisited: практические метрики тестирования
Waterfall revisited: практические метрики тестирования
SQALab
 
2.3 Тестирование: процесс, роли, артефакты
2.3 Тестирование: процесс, роли, артефакты2.3 Тестирование: процесс, роли, артефакты
2.3 Тестирование: процесс, роли, артефакты
Natalia Odegova
 
Планирование трудозатрат на тестирование
Планирование трудозатрат на тестированиеПланирование трудозатрат на тестирование
Планирование трудозатрат на тестирование
SQALab
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требований
SQALab
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требований
Artem Shapoval
 
Человеко-дни на тестирование или как не ошибиться с оценкой
Человеко-дни на тестирование или как не ошибиться с оценкойЧеловеко-дни на тестирование или как не ошибиться с оценкой
Человеко-дни на тестирование или как не ошибиться с оценкой
SQALab
 
Тест-дизайн: проще читать или проще писать
Тест-дизайн: проще читать или проще писатьТест-дизайн: проще читать или проще писать
Тест-дизайн: проще читать или проще писать
SQALab
 
Невыносимая переносимость кроссплатформенных приложений на примере десктопных...
Невыносимая переносимость кроссплатформенных приложений на примере десктопных...Невыносимая переносимость кроссплатформенных приложений на примере десктопных...
Невыносимая переносимость кроссплатформенных приложений на примере десктопных...
SQALab
 
Serious+performance+testing
Serious+performance+testingSerious+performance+testing
Serious+performance+testing
Alexei Lupan
 
Оценки имеют значение. Практические советы по оценке задач
Оценки имеют значение. Практические советы по оценке задачОценки имеют значение. Практические советы по оценке задач
Оценки имеют значение. Практические советы по оценке задач
Gleb Rybalko
 
Михаил Павлов - is a tester responsible for quality
Михаил Павлов - is a tester responsible for qualityМихаил Павлов - is a tester responsible for quality
Михаил Павлов - is a tester responsible for quality
Alexei Lupan
 
Риски в тестировании
Риски в тестированииРиски в тестировании
Риски в тестировании
ISsoft
 
Артефакты тестирования: быть или не быть?
Артефакты тестирования: быть или не быть?Артефакты тестирования: быть или не быть?
Артефакты тестирования: быть или не быть?
Maksim Grinevich
 

What's hot (20)

Варианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовВарианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектов
 
Роли, в которые играют тестировщики
Роли, в которые играют тестировщикиРоли, в которые играют тестировщики
Роли, в которые играют тестировщики
 
Как оценить проект, чтобы не было мучительно больно...потом
Как оценить проект, чтобы не было мучительно больно...потомКак оценить проект, чтобы не было мучительно больно...потом
Как оценить проект, чтобы не было мучительно больно...потом
 
Test labs 2016. Пренебрежение лучшими практиками тестирования
Test labs 2016. Пренебрежение лучшими практиками тестированияTest labs 2016. Пренебрежение лучшими практиками тестирования
Test labs 2016. Пренебрежение лучшими практиками тестирования
 
Risk-based testing management. От теории к современной практике
Risk-based testing management. От теории к современной практикеRisk-based testing management. От теории к современной практике
Risk-based testing management. От теории к современной практике
 
Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...
Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...
Мастер Тест План / Тестовая Стратегия: Что это? Зачем? Как его создать?-От А ...
 
Test labs 2016. QA в тотальном аутсорсе
Test labs 2016. QA в тотальном аутсорсеTest labs 2016. QA в тотальном аутсорсе
Test labs 2016. QA в тотальном аутсорсе
 
Waterfall revisited: практические метрики тестирования
Waterfall revisited: практические метрики тестированияWaterfall revisited: практические метрики тестирования
Waterfall revisited: практические метрики тестирования
 
2.3 Тестирование: процесс, роли, артефакты
2.3 Тестирование: процесс, роли, артефакты2.3 Тестирование: процесс, роли, артефакты
2.3 Тестирование: процесс, роли, артефакты
 
Планирование трудозатрат на тестирование
Планирование трудозатрат на тестированиеПланирование трудозатрат на тестирование
Планирование трудозатрат на тестирование
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требований
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требований
 
Человеко-дни на тестирование или как не ошибиться с оценкой
Человеко-дни на тестирование или как не ошибиться с оценкойЧеловеко-дни на тестирование или как не ошибиться с оценкой
Человеко-дни на тестирование или как не ошибиться с оценкой
 
Тест-дизайн: проще читать или проще писать
Тест-дизайн: проще читать или проще писатьТест-дизайн: проще читать или проще писать
Тест-дизайн: проще читать или проще писать
 
Невыносимая переносимость кроссплатформенных приложений на примере десктопных...
Невыносимая переносимость кроссплатформенных приложений на примере десктопных...Невыносимая переносимость кроссплатформенных приложений на примере десктопных...
Невыносимая переносимость кроссплатформенных приложений на примере десктопных...
 
Serious+performance+testing
Serious+performance+testingSerious+performance+testing
Serious+performance+testing
 
Оценки имеют значение. Практические советы по оценке задач
Оценки имеют значение. Практические советы по оценке задачОценки имеют значение. Практические советы по оценке задач
Оценки имеют значение. Практические советы по оценке задач
 
Михаил Павлов - is a tester responsible for quality
Михаил Павлов - is a tester responsible for qualityМихаил Павлов - is a tester responsible for quality
Михаил Павлов - is a tester responsible for quality
 
Риски в тестировании
Риски в тестированииРиски в тестировании
Риски в тестировании
 
Артефакты тестирования: быть или не быть?
Артефакты тестирования: быть или не быть?Артефакты тестирования: быть или не быть?
Артефакты тестирования: быть или не быть?
 

Similar to риски тестирования

Test management
Test managementTest management
Test management
QA Guards
 
Istqb lesson 5
Istqb lesson 5Istqb lesson 5
Istqb lesson 5
Eugene Bulba
 
Оценка трудозатрат на тестирование в проектах сопровождения
Оценка трудозатрат на тестирование в проектах сопровожденияОценка трудозатрат на тестирование в проектах сопровождения
Оценка трудозатрат на тестирование в проектах сопровождения
SQALab
 
доклад на SQADays 2011 в Казани
доклад на SQADays  2011 в Казанидоклад на SQADays  2011 в Казани
доклад на SQADays 2011 в Казани
margo-qa
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в Scrum
Denis Petelin
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в Scrum
Denis Petelin
 
Улучшение процесса тестирования: контентные модели
Улучшение процесса тестирования: контентные моделиУлучшение процесса тестирования: контентные модели
Улучшение процесса тестирования: контентные модели
SQALab
 
Александр Александров: Процессный консалтинг - как и зачем это делается и ког...
Александр Александров: Процессный консалтинг - как и зачем это делается и ког...Александр Александров: Процессный консалтинг - как и зачем это делается и ког...
Александр Александров: Процессный консалтинг - как и зачем это делается и ког...
Luxoft Education Center
 
SQA Days-13 @ Piter v3.1 web
SQA Days-13 @ Piter v3.1 webSQA Days-13 @ Piter v3.1 web
SQA Days-13 @ Piter v3.1 web
Oleg Tatarchuk
 
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыМаргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
SQALab
 
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизацияQA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QAFest
 
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Andrey Ladutko
 
QA процесс, часть 2
QA процесс, часть 2QA процесс, часть 2
QA процесс, часть 2
DressTester
 
Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?
SQALab
 
Alexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качествомAlexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качеством
rit2010
 
Academy IBS Studying process improvements
Academy IBS Studying process improvementsAcademy IBS Studying process improvements
Academy IBS Studying process improvements
DmiVas
 
Что было, что есть, что будет: Current State vs. Common Sense
Что было, что есть, что будет: Current State vs. Common SenseЧто было, что есть, что будет: Current State vs. Common Sense
Что было, что есть, что будет: Current State vs. Common Sense
SQALab
 

Similar to риски тестирования (20)

Test management
Test managementTest management
Test management
 
Istqb lesson 5
Istqb lesson 5Istqb lesson 5
Istqb lesson 5
 
Оценка трудозатрат на тестирование в проектах сопровождения
Оценка трудозатрат на тестирование в проектах сопровожденияОценка трудозатрат на тестирование в проектах сопровождения
Оценка трудозатрат на тестирование в проектах сопровождения
 
Test design print
Test design printTest design print
Test design print
 
доклад на SQADays 2011 в Казани
доклад на SQADays  2011 в Казанидоклад на SQADays  2011 в Казани
доклад на SQADays 2011 в Казани
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в Scrum
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в Scrum
 
презентация планов
презентация плановпрезентация планов
презентация планов
 
презентация планов
презентация плановпрезентация планов
презентация планов
 
Улучшение процесса тестирования: контентные модели
Улучшение процесса тестирования: контентные моделиУлучшение процесса тестирования: контентные модели
Улучшение процесса тестирования: контентные модели
 
Александр Александров: Процессный консалтинг - как и зачем это делается и ког...
Александр Александров: Процессный консалтинг - как и зачем это делается и ког...Александр Александров: Процессный консалтинг - как и зачем это делается и ког...
Александр Александров: Процессный консалтинг - как и зачем это делается и ког...
 
SQA Days-13 @ Piter v3.1 web
SQA Days-13 @ Piter v3.1 webSQA Days-13 @ Piter v3.1 web
SQA Days-13 @ Piter v3.1 web
 
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыМаргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
 
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизацияQA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
 
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
 
QA процесс, часть 2
QA процесс, часть 2QA процесс, часть 2
QA процесс, часть 2
 
Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?
 
Alexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качествомAlexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качеством
 
Academy IBS Studying process improvements
Academy IBS Studying process improvementsAcademy IBS Studying process improvements
Academy IBS Studying process improvements
 
Что было, что есть, что будет: Current State vs. Common Sense
Что было, что есть, что будет: Current State vs. Common SenseЧто было, что есть, что будет: Current State vs. Common Sense
Что было, что есть, что будет: Current State vs. Common Sense
 

More from sef2009

технопарк бнту метолит
технопарк бнту метолиттехнопарк бнту метолит
технопарк бнту метолит
sef2009
 
распознавание для Web
распознавание для Webраспознавание для Web
распознавание для Web
sef2009
 
персональные риски аналитика
персональные риски аналитикаперсональные риски аналитика
персональные риски аналитика
sef2009
 
ксуп кейс
ксуп кейсксуп кейс
ксуп кейс
sef2009
 
блинов Java Belarus 2009
блинов   Java Belarus 2009блинов   Java Belarus 2009
блинов Java Belarus 2009
sef2009
 
александров обучение в сфере Software Engineering
александров   обучение в сфере Software Engineeringалександров   обучение в сфере Software Engineering
александров обучение в сфере Software Engineering
sef2009
 
Sef Sivakou Tezisy
Sef Sivakou TezisySef Sivakou Tezisy
Sef Sivakou Tezisy
sef2009
 
Sef Sivakou Prezentacia
Sef Sivakou PrezentaciaSef Sivakou Prezentacia
Sef Sivakou Prezentacia
sef2009
 
Sef Sivakou Doklad
Sef Sivakou DokladSef Sivakou Doklad
Sef Sivakou Doklad
sef2009
 
Sef презентация
Sef презентацияSef презентация
Sef презентация
sef2009
 
Sef Kolotygin.V4
Sef Kolotygin.V4Sef Kolotygin.V4
Sef Kolotygin.V4
sef2009
 
Sef 2009
Sef 2009Sef 2009
Sef 2009
sef2009
 
Sef 2009 Itsm
Sef 2009 ItsmSef 2009 Itsm
Sef 2009 Itsm
sef2009
 
Alexandrov Alex Quality
Alexandrov Alex QualityAlexandrov Alex Quality
Alexandrov Alex Quality
sef2009
 
Denisv Teamwork April 23
Denisv Teamwork April 23Denisv Teamwork April 23
Denisv Teamwork April 23
sef2009
 
Content Migration Framework
Content Migration FrameworkContent Migration Framework
Content Migration Framework
sef2009
 
25.04.09 Sidorov
25.04.09 Sidorov25.04.09 Sidorov
25.04.09 Sidorov
sef2009
 
21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef
sef2009
 
якимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложенийякимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложений
sef2009
 

More from sef2009 (20)

технопарк бнту метолит
технопарк бнту метолиттехнопарк бнту метолит
технопарк бнту метолит
 
распознавание для Web
распознавание для Webраспознавание для Web
распознавание для Web
 
персональные риски аналитика
персональные риски аналитикаперсональные риски аналитика
персональные риски аналитика
 
ксуп кейс
ксуп кейсксуп кейс
ксуп кейс
 
блинов Java Belarus 2009
блинов   Java Belarus 2009блинов   Java Belarus 2009
блинов Java Belarus 2009
 
александров обучение в сфере Software Engineering
александров   обучение в сфере Software Engineeringалександров   обучение в сфере Software Engineering
александров обучение в сфере Software Engineering
 
Sef Sivakou Tezisy
Sef Sivakou TezisySef Sivakou Tezisy
Sef Sivakou Tezisy
 
Sef Sivakou Prezentacia
Sef Sivakou PrezentaciaSef Sivakou Prezentacia
Sef Sivakou Prezentacia
 
Sef Sivakou Doklad
Sef Sivakou DokladSef Sivakou Doklad
Sef Sivakou Doklad
 
Sef презентация
Sef презентацияSef презентация
Sef презентация
 
Sef
SefSef
Sef
 
Sef Kolotygin.V4
Sef Kolotygin.V4Sef Kolotygin.V4
Sef Kolotygin.V4
 
Sef 2009
Sef 2009Sef 2009
Sef 2009
 
Sef 2009 Itsm
Sef 2009 ItsmSef 2009 Itsm
Sef 2009 Itsm
 
Alexandrov Alex Quality
Alexandrov Alex QualityAlexandrov Alex Quality
Alexandrov Alex Quality
 
Denisv Teamwork April 23
Denisv Teamwork April 23Denisv Teamwork April 23
Denisv Teamwork April 23
 
Content Migration Framework
Content Migration FrameworkContent Migration Framework
Content Migration Framework
 
25.04.09 Sidorov
25.04.09 Sidorov25.04.09 Sidorov
25.04.09 Sidorov
 
21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef
 
якимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложенийякимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложений
 

риски тестирования

  • 1. Идентификация рисков и проблем тестирования Александр Александров. УЦ Люксофт
  • 2. Немного о себе 1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник) 1999-2005 – Люксофт (руководитель группы тестирования, тест-менеджер) 2006 -200 7 – Auriga (директор по качеству) C 200 8 – Люксофт (эксперт по управлению качеством ПО) Кандидат физико-математических наук, доцент, старший научный сотрудник Сертифицированный инструктор университета Carnegie Mellon по тематике Quality Assurance
  • 3. Опыт работы Более 30 лет работы в области тестирования и обеспечения качества (МГУ , Люксофт , Auriga ) Более 5 лет работы в области управления качеством (Люксофт , Auriga ) Опыт c ертификации ISO 9001 (Люксофт), CMM , CMMI (Люксофт, Аурига) Опыт внедрения процессов в рамках модели CMMI (Люксофт, Аурига) Сертификат обучения Project Management от Project Management Institute (2000) Сертификат обучения Introduction to Capability Maturity Model Integration v. 1.2 от ProceXpert (2007)
  • 4. Область проекта Название проблемы Комментарий 1 Комментарий 2 … Риск 1 Риск 2 … Рекомендация 1 Рекомендация 2 …
  • 5. Подготовка проекта Неполое планирование и оценка трудозатрат Производится только планирование и оценка трудозатрат всего проекта менеджером проекта Специалисты по тестированию не привлекаются ни к проведению, ни к ревью получивш ихся результатов Недостаток ресурсов тестирования Недостаток времени для активностей тестирования Привлекать тестировщиков для ревью плана-графика и трудозатрат Проводить независимую оценку трудозатрат тестировщиками ( PCB/PPB, методики, литература)
  • 6. Подготовка проекта Неполнота scope тестирования Необоснованные предположения о наличии / отсутствии конкретных видов тестирования (нагрузочного, конфигурационного и др.) Отказ от системного тестирования (достаточно интеграционного и компонентного) Только динамическое тестирование Необходимость перепланирования в условиях нехватки ресурсов Низкое качество объекта тестирования Проводить детальный анализ scope проекта Делать обоснованные предположения о наличии неявных требований, которые оказывают влияние на scope тестирования
  • 7. Подготовка проекта Игнорирование внутренних рисков тестирования Отсутствие буфера, который допускает возможность сдвига сроков проведения системного тестирования Отсутствие буфера, который допускает возможность сдвига сроков разработки планов тестирования Необходимость перепланирования в условиях нехватки ресурсов при наступлении риска Низкое качество объекта тестирования Проводить мониторинг плана-графика проекта Включить и проводить мониторинг указанных рисков
  • 8. Стратегия тестирования Стратегия тестирования отсутствует / не поддерживается Отсутствие согласованного понимания порядка подготовки и проведения тестирования в проекте Хаотичная передача версий на тестирование Нет базы тестирования Низкое качество тестирования Риск нехватки ресурсов тестирования Разрабатывать стратегию тестирования Согласовывать и утверждать стратегию тестирования
  • 9. Стратегия тестирования Критерии начала и завершения тестирования Отсутствуют критерии начала тестирования Отсутствие / Нечеткость классификации серьезности дефектов Нет понятия готовности объекта тестирования (модульное тестирование, BATS …) Коммуникационные проблемы с разработчиками (тестирование) и заказчиком (приемка) Разработать однозначные критерии начала и завершения тестирования для каждого этапа проекта
  • 10. Стратегия тестирования Риски тестирования Не рассматриваются и не анализируются наряду с остальными проектными рисками Не используется исторический опыт рисков тестирования Тестирование становится неадекватно высоко рисковой частью проекта Высока вероятность неуспешного тестирования Совместно с менеджером проекта анализировать, рассматривать и отслеживать риски тестирования наряду со всеми проектными рисками
  • 11. Стратегия тестирования Особенности объекта тестирования Не учитываются особенности объекта тестирования (например, отсутствие пользовательского интерфейса, необходимость специальной среды тестирования) Нехватка (специально подготовленных) ресурсов тестирования Неадекватная среда тестирования Низкое качество тестирования Совместно с менеджером проекта анализировать особенности объекта тестирования и отражать принятые решения в стратегии тестирования
  • 12. Стратегия тестирования Проблемы, с которыми вы сталкивались когда-либо...
  • 13. Анализ требований Требования анализируются разрабатываются и изменяются без участия тестировщиков Участвуют только аналитики и проектировщики Тестировщики привлекаются после утверждения первой версии требований Тестировщики плохо знают предметную область проекта Замедление работы тестировщиков: приложение готово, план тестирования – нет Часть требований нельзя протестировать Проводить ревью требований тестировщиками Обучать тестировщиков предметной области проекта в рамках обучения проектной команды Выполнять анализ тестируемости требований до их утверждения
  • 14. Анализ требований Требования не ранжированы по приоритетам Сомнительно, что все требования имеют одинаковый приоритет Нет возможности упорядочить и указать приоритеты для разработки и прогона тестовых сценариев Невозможность проведения первоочередного / тщательного тестирования ключевых требований Провести анализ существующих требований и определить приоритеты требований Учитывать эти приоритеты при определении очередности разработки и тестовых сценариев и покрытии требований тестовыми сценариями
  • 15. Анализ требований Требований в проекте нет / они постоянно изменяются Ситуация в принципе невозможная / нормальная Имеется в виду либо отсутствие документально зафиксированных требований либо их высокая изменчивость Невозможность проведения тестирования по плану Невозможность адекватной оценки качества объекта тестирования Провести анализ существующих требований и способа их представления Разработать планы тестирования Применять планы тестирования
  • 16. Анализ требований Нет аналитика – некому поддерживать требования Или «Давайте будем поддерживать все» Разница между ролью и ресурсом Невозможность создания актуального плана тестирования Невозможность адекватной оценки качества объекта тестирования Предусмотреть в плане-графике работы по сбору, анализу и поддержанию требований Наделить конкретный проектный ресурс ролью аналитика
  • 17. Дизайн Архитектура системы не учитывается при разработке стратегии тестирования Необходимо для повышения эффективности тестирования (например, нужен ли и как организовать доступ на уровне СУБД) Необходимо для организации интеграционного тестирования Неэффективное тестирование (большие затраты при скромных результатах) Знакомство тестировщиков с архитектурой системы Планирование тестирования с учетом архитектуры системы
  • 18. Дизайн Нет единого решения по пользовательским интерфейсам Неоправданный разнобой в реализации интерфейсов приложения Неудобство для заказчика Замечания тестировщиков на это тему игнорируются («Такого требования нет!») Низкое качество Usability объекта тестирования Не удается найти дефекты Usability Использовать как явные, так и подразумеваемые требования Специфицировать интерфейсы (документ , прототип , CLAF… )
  • 19. Дизайн У объекта тестирования отсутствует пользовательский интерфейс Непонятно, как «подобраться» к объекту тестирования Непонятно, как визуализировать фактический результат для сравнения с ожидаемым Замечания тестировщиков на это тему игнорируются Невозможность провести тестирование Использовать заглушки / тест-драйверы Планировать их разработку в стратегии тестирования и плане-графике проекта
  • 20. Дизайн Нет требований к окружению системы Требования к окружению не сформулированы явно, а определяются в процессе разработки системы Требования неизвестны тестировщикам и не учитываются при создании среды тестирования Большое число «ложных» дефектов Низкое качество тестирования Зафиксировать требования к тестовой среде Проводить тестирование при соблюдении (в некоторых случаях – и при несоблюдении) этих требованиях Отразить требования в описании инсталляции и пользовательской документации
  • 21. План тестирования Не анализируется покрытие требований тестовыми сценариями Нет соответствия приоритетов требований и степени их покрытия тестовыми сценариями Затруднительно установление соответствия дефекта требованию, которое он нарушает Низкое качество тестирования Низкое качество (скорость и эффективность) описания и исправления дефектов Покрытие требований тестовыми сценариями с учетом приоритетов
  • 22. План тестирования Не проводится оценка качества плана тестирования в процессе разработки Как определить, что разработка плана тестирования завершена Как определить качество разработанного плана тестирования Низкое качество плана тестирования – низкое качество тестирования Результаты ревью плана тестирования позволяют оценить его качество (PCB/PPB …)
  • 23. План тестирования Не проводится оценка качества плана тестирования в процессе применения Тестовые сценарии не находят дефектов Тестовые сценарии не находят существенных дефектов Тестовые сценарии находят одни и те же дефекты Неоправданно большие затраты на поиск дефектов Большое число пропущенных дефектов Пропущены существенные дефекты Мониторинг результативности тестирования Коррекция плана тестирования
  • 24. План тестирования Ревью плана тестирования не планируется / не производится Считается сильно затратным Считается неэффективным План тестирования содержит дефекты Про эти дефекты никто не знает Они обнаруживаются при тестировании (хорошо, если это так) Планировать ревью плана тестирования аналитиками Планировать ревью требований тестировщиками
  • 25. План тестирования Тестовые сценарии не содержат деталей Конкретные действия тестировщика / инженера по автоматизации придумываются во время тестирования Затраты на воспроизведение действий при воспроизведении дефекта Низкое качество тестирования из-за неполного набора действий Невозможность проверки степени покрытия пользовательского интерфейса Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности
  • 26. План тестирования Тестовые сценарии содержат детали Изменение требований и дизайна вызывает объемные изменения планов тестирования Затраты на обеспечение актуальности планов тестирования Затраты на переучивание тестировщиков Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности Использовать двухуровневую структуру плана тестирования – тестовый сценарии + тесты
  • 27. План тестирования Проектирование и разработка тестовых данных не планируется и не производится Данные придумываются во время тестирования Данных недостаточно (например, используются только корректные данные) Тестирование миграции без проектирования тестовых данных невозможно Затраты на воспроизведение данных для воспроизведения дефекта Низкое качество тестирования из-за малого набора тестовых данных Проектировать и разрабатывать тестовые данные с использованием классов эквивалентности и граничных значений
  • 28. Автоматизация тестирования Автоматизация функционального тестирования применима в любом проекте Завышенные требования к команде тестировщиков Заниженная оценка трудозатрат на тестирование Невозможность проведения автоматизированного тестирования Поздний переход на ручное тестирование Детальный анализ целесообразности автоматизации тестирования
  • 29. Автоматизация тестирования Автоматизация функционального тестирования применима только для регрессионного тестирования Как правило, но не всегда Пример: проекты redevelopment Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования
  • 30. Автоматизация тестирования Автоматизация функционального тестирования применима только при большом числе раундов тестирования Как правило, но не всегда Пример: проекты mission-critical Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования
  • 31. Автоматизация тестирования Раннее проведение нагрузочного тестирования Исправление функциональных дефектов, как правило, вызывает перезапись и повторный прогон нагрузочных скриптов Как правило, но не всегда Пример: нагрузочное тестирование прототипа Необходимость выделения ресурсов для повторного проведения нагрузочного тестирования Детальное планирование момента проведения нагрузочного тестирования
  • 32. Автоматизация тестирования Неадекватная модель нагрузки Совокупность: ролей (кто работает) характеристических сценариев (что делает) профилей (доля и частота) не соответствует бизнесу заказчика Неадекватные результаты нагрузочного тестирования Несоответствие ожиданием заказчика Согласование модели нагрузки с заказчиком
  • 33. Среда тестирования Тестирование выполняется в среде разработки одного или нескольких проектов Путаница версий Нестабильность объекта тестирования (исправления «на лету») Невозможность обнаружения части дефектов Низкое качество тестирования Сложность коммуникаций с разработчиками (невозможность воспроизвести дефект) Создание обособленной среды тестирования Сборка объекта тестирования из baseline
  • 34. Тестирование Дефекты, найденные вне плана тестирования, не приводят к его корректировке Сложности их повторной проверки Можно забыть, что такие дефекты были найдены Низкое качество регрессионного тестирования Повышенные требования к квалификации тестировщиков Регулярный анализ необходимости и проведение корректировки плана тестирования
  • 35. Тестирование Не хватает ресурсов тестирования Проанализировать, почему Невозможность выполнить запланированные работы в срок Установление причины нехватки ресурсов (заниженные оценки, низкое качество объекта тестирования, незнание требований и предметной области, изменение сроков тестирования) Перепланирование активностей тестирования Привлечение дополнительных ресурсов
  • 36. Тестирование Невозможно идентифицировать версию объекта тестирования Неясно, был ли обновлен объект тестирования Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Невозможно понять, например, обнаружен дефект или нереализованная функциональность Соглашение об идентификации версий Разработка и применение BATS (Build Acceptance Test Suite)
  • 37. Тестирование Объект тестирования не работоспособен Сбой в процессе сборки Отсутствие четкой регламентации процесса сборки (путаница версий кода) Потеря времени на тестирование неработоспособного объекта тестирования Неэффективное тестирование и большое количество «ложных» дефектов Разработка и применение BATS (Build Acceptance Test Suite)
  • 38. Тестирование Дефекты возникают из-за неверной конфигурации системы / среды тестирования Непонятно, как идентифицировать, где найден и где исправлен дефект Непонятно, как отличать от дефектов кода Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Принятие решения о регистрации и учете таких дефектов на корпоративном / проектном уровнях Классификация локализации дефекта (например, «Требования», «Дизайн», «Код», «Конфигурация», «Пользовательская документация» и др.)
  • 39. Тестирование Протоколы тестирования не создаются В них нет описания дефектов Если дефекты не найдены, то создание протоколов – пустая трата времени Нет данных об объеме проведенного тестирования Нет данных о качестве системы (непонятно, проверяли ли работу конкретной функциональности) Фиксировать результаты тестирования в максимально удобной для проектной команды форме (например, в матрице Test Run Coverage) Использовать автоматические средства протоколирования ручного тестирования
  • 40. Тестирование Как оформлять описание дефекта В протоколе тестирования + регистрация в системе управления дефектами В системе регистрации дефектов вместе с регистрацией В отдельном документе + регистрация в системе управления дефектами Неразбериха с неоднородным оформлением дефектов Дополнительные затраты на поиск описания Принятие решения в рамках проекта (проектов), исходя из удобства и эффективности для всех членов проектной команды (и заказчика, если необходимо)
  • 41. Тестирование Метрики тестирования не используются Качественной оценки может быть недостаточно Трудно анализировать динамику выполнения проекта Работа с метриками требует проектной культуры Неточное / неверное представление о качестве объекта тестирования Выбрать / применить набор понятных и эффективных метрик тестирования (плотность дефектов, доля трудозатрат, эффективность поиска, доля серьезных дефектов и др.)
  • 42. Тестирование Сокрытие дефектов ЧП! Негативные последствия для всей проектной команды Ничего не дает – заказчик все равно этот дефект обнаружит! Недостоверные данные о качестве объекта тестирования Не допускать возникновения такой ситуации Оперативно с ней бороться (в том числе и эскалацией проблемы) Разъяснять, что обнаруженный и исправленный дефект – это гораздо лучше, чем отсутствие дефекта
  • 43. Тестирование Пользовательская документация не тестируется Не запланировано тестирование документации (включая Help) Нет ресурсов для тестирования Тестируют только тестировщики - технические писатели ревью не проводят Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования
  • 44. Тестирование Не проводится системное тестирование Системное тестирование не планируется Нет времени для системного тестирования Допустимо в проектах сопровождения Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования
  • 45. Приемка Не согласована процедура приемки Что предшествует и что следует за приемо-сдаточными испытаниями Каковы ожидания заказчика на момент приемки Кто принимает решение об успешном завершении проекта со стороны заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая приемо-сдаточные испытания)
  • 46. Приемка Верификация и валидация Разница этих понятий Ликвидация (минимизация) расхождений между требованиями и ожиданиями заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Поддержка актуальности и приоритетов требований и их учет в плане приемо-сдаточных испытаний
  • 47. Приемка План приемо-сдаточных испытаний Несоответствие объемов приемо-сдаточных испытаний и системного тестирования Нет ничего, кроме плана приемо-сдаточного тестирования Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая разработку и модификацию плана приемо-сдаточных испытаний) с начала проекта
  • 48. Приемка График приемо-сдаточных испытаний Определение перечня представителей заказчика, участвующих в проведении приемо-сдаточных испытаний, и их ожиданий Оптимистичные оценки времени и ресурсов для исправления дефектов, найденных во время приемо-сдаточных испытаний Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование графика приемки
  • 49. Приемка Ожидания заказчика Неизвестны актуальные потребности бизнеса заказчика Неизвестны ожидание представителей заказчика Проблемы во время приемки (отсутствие взаимопонимания со стороны заказчика) Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая персоналии заказчика и их ожидания)
  • 50. Приемка Лицо, принимающее решение Дистанция между техническим этапом (успешное завершение приемо-сдаточных испытаний) и организационным этапом ( подписание акта приемки-сдачи проекта) приемки Необходимость участия компании-разработчика в организационном этапе приемки Задержка сдачи проекта и оплаты заказчиком Планирование и согласование процедуры приемки
  • 51. Подробнее … Подготовка проекта TST-006 – Управление тестированием на примере реальных проектов Стратегия тестирования TST-004 – Управление тестированием TST-005 – Управление тестированием, углубленный курс TST-027 – Тестирование в Agile проектах Анализ требований TST-010 – Основы тест-дизайна TST-016 – Тест-дизайн, практические рекомендации
  • 52. Подробнее … Дизайн TST-016 – Тест-дизайн, практические рекомендации TST-019 – Тестирование Usability TST-020 – Тестирование Web- приложений План тестирования TST-016 – Тест-дизайн, практические рекомендации TST-022 – Статическое тестирование на практике
  • 53. Подробнее … Автоматизация тестирования TST-012 – Основы автоматизированного тестирования … Тренинги по конкретным инструментам Семейство Mercury Семейство Rational и IBM Rational Семейство Silk TestComplete Selenium FIT …
  • 54. Подробнее … Среда тестирования TST-004 – Основы управления тестированием Тестирование TST-001 – Основы тестирования TST-014 – Основы практического тестирования TST-052 – Практикум по использованию Rational Clear Quest Приемка TST-004 – Основы управления тестированием TST-006 – Управление тестированием на примере реальных проектов
  • 55. Спасибо за внимание! Вопросы? Учебный Центр Luxoft : Школа Менеджера Проекта Школа Аналитика Школа Тестировщика Школа Архитектора и Разработчика