Управление тестированием. Анализ типичных проблем Александр Александров. УЦ Люксофт.

Презентация:



Advertisements
Похожие презентации
Идентификация рисков и проблем тестирования Александр Александров. УЦ Люксофт.
Advertisements

Идентификация рисков и проблем тестирования Идентификация рисков и проблем тестирования Александр Александров УЦ Luxoft
Как возникают ловушки заказного тестирования Как возникают ловушки заказного тестирования Александр Александров УЦ Luxoft
Обучение в сфере Software Engineering Александр Александров. УЦ Люксофт.
Положение об отделе В.Андреев, Д.Сатин. Штат отдела начальник отдела; бизнес-аналитик; проектировщик пользовательских интерфейсов; специалист по анализу.
Процессный консалтинг: - зачем и как делается - когда приносит пользу.
Учебный Центр Luxoft Обучение от экспертов программной инженерии.
Учебный курс Стандартизация и сертификация программного обеспечения Лекция 7 доктор технических наук, профессор, проректор по информатизации, заведующий.
Виды и методы тестирования на разных стадиях разработки ПО.
Жизненный цикл программного обеспечения Подготовил студент 1 курса Лось Павел.
Тестирование программных средств Сафронов Сергей, 2008 год.
Организация процесса тестирования ПО Петренко Ольга QA Team Leader.
РАСПРОСТРАНЕННЫЕ ОШИБКИ В ИДЕОЛОГИИ, ПЛАНИРОВАНИИ И ПРОВЕДЕНИИ ТЕСТИРОВАНИЯ 2.
Microsoft Solutions Framework Технологии программирования. Курс на базе Microsoft Solutions Framework Семинар 4. Прохождение фазы выработки концепции в.
Лекция 1 Учебные вопросы : Вопрос 1. История возникновения и понятие CASE- технологии. Вопрос 2. Особенности внедрения CASE- технологии. Вопрос 3. Основные.
Контроля качества ПО. развития службы Три ступени Докладчик: Гринкевич Сергей
ТЕСТИРОВАНИЕ МЕТОД «ЧЕРНОГО ЯЩИКА» ВЫПОЛНИЛ СТУДЕНТ ГР. ИВТ-51 з БАННИКОВА Н.Р.
ТЕСТИРОВАНИЕ МЕТОД «ЧЕРНОГО ЯЩИКА» ВЫПОЛНИЛ СТУДЕНТ ГР. ИВТ-51 з БАННИКОВА Н.Р.
Внедрение Когда разрабатываемая система обладает начальной функциональностью, проект переходит на фазу внедрения. Менеджер проекта полагает, что система.
Testschool Тестирование ПО: Модели разработки ПО. Уровни и типы тестирования. Воронеж, 2012 год.
Транксрипт:

Управление тестированием. Анализ типичных проблем Александр Александров. УЦ Люксофт

Немного о себе –МГУ, НИВЦ (студент … старший научный сотрудник) – Люксофт (руководитель группы тестирования, тест-менеджер) – Аурига (директор по качеству) C 2008 – Люксофт (Учебный Центр, эксперт по управлению качеством ПО) К.ф.м.н., ст. научн. сотр., доцент Инструктор по тематике Quality Assurance, авторизованный университетом Carnegie Mellon

Опыт работы Более 30 лет работы в области тестирования и обеспечения качества (МГУ, Люксофт, Auriga) Более 5 лет работы в области управления качеством (Люксофт, Auriga) Опыт внедрения процессов (Люксофт, Аурига) Опыт сертификации ISO 9001 (Люксофт), CMM, CMMI (Люксофт, Аурига)

Подготовка проекта Неполная оценка трудозатрат – Тестировщики не привлекаются ни к проведению оценки, ни к ревью получившейся оценки, ни к планированию проекта Недостаток ресурсов тестирования Привлекать тестировщиков для ревью трудозатрат Проводить независимую оценку трудозатрат тестиров ания (PCB/PPB, методики, литература)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее … Подготовка проекта TST-006 – Управление тестированием на примере реальных проектов TST-006 – Управление тестированием на примере реальных проектов Стратегия тестирования TST-004 – Управление тестированием TST-004 – Управление тестированием TST-005 – Управление тестированием, углубленный курс TST-005 – Управление тестированием, углубленный курс TST-027 – Тестирование в Agile проектах TST-027 – Тестирование в Agile проектах Анализ требований TST-010 – Основы тест-дизайна TST-016 – Тест-дизайн, практические рекомендации

Подробнее … Дизайн TST-016 – Тест-дизайн, практические рекомендации TST-016 – Тест-дизайн, практические рекомендации TST-019 – Тестирование Usability TST-019 – Тестирование Usability TST-020 – Тестирование Web-приложений TST-020 – Тестирование Web-приложений План тестирования TST-016 – Тест-дизайн, практические рекомендации TST-016 – Тест-дизайн, практические рекомендации TST-022 – Статическое тестирование на практике TST-022 – Статическое тестирование на практике

Подробнее … Автоматизация тестирования TST-012 – Основы автоматизированного тестирования … Тренинги по конкретным инструментам Семейство Mercury Семейство Rational и IBM Rational Семейство Silk TestComplete FIT …

Подробнее … Среда тестирования TST-004 – Основы управления тестированием Тестирование TST-001 – Основы тестирования TST-014 – Основы практического тестирования TST-052 – Практикум по использованию Rational Clear Quest Приемка TST-004 – Основы управления тестированием TST-006 – Управление тестированием на примере реальных проектов

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