'

Оценка трудозатрат на тестирование в проектах сопровождения (Два стандартных вопроса в Luxoft) Александр Александров, Luxoft www.luxoft.com

Понравилась презентация – покажи это...





Слайд 0

Оценка трудозатрат на тестирование в проектах сопровождения (Два стандартных вопроса в Luxoft) Александр Александров, Luxoft www.luxoft.com


Слайд 1

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


Слайд 2

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


Слайд 3

Содержание Введение Особенности проектов сопровождения Особенности тестирования Метрики Исходные данные для метрик Использование метрик Оценка трудозатрат на тестирование Два стандартных вопроса в Luxoft Заключение


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

Потребность в метриках От команды тестирования ждут оценку трудозатрат Соотношение трудозатрат на тестирование и разработку в проектах не проходит Похожих прецедентов, как правило, нет (каждый проект сопровождения уникален) Тем не менее, ничего лучше имеющегося собственного опыта у нас нет Как правильно его использовать? «Кто управляет прошлым, тот управляет будущим» (с) Дж. Оруэлл


Слайд 8

Исходные данные для метрик Как правило, исходные изменения для построения и применения метрик включают: Фактические трудозатраты в разрезах ролей и процессов Количество дефектов в разрезах статуса и серьезности Размер кода Эти измерения: Накапливаются Статистически обрабатываются Используются для оценки будущих проектов Но этого может быть мало Может пригодиться число требований (с учетом гранулярности)


Слайд 9

Использование метрик Напомним известные метрики тестирования: Плотность дефектов (SDD = Число дефектов / Размер кода) Плотность дефектов после поставки (PDDD = Число дефектов после поставки / Размер кода) «Убойность» тестов (DP = Число дефектов / Число тестов) Эффективность тестирования (TE = Число дефектов / Трудозатраты тестирования) Плотность покрытия требований (RCD = Число тестов / Число требований) Доля повторно открытых дефектов (RDR = Число повторно открытых дефектов / Число дефектов )


Слайд 10

Оценка трудозатрат (1/2) Вход Объективные данные о релизе Новая/изменяемая функциональность (оформление - требования, владельцы знаний - аналитики) Затрагиваемые области (оформление - спецификации и код, владельцы знаний – разработчики) История проекта (эффективность тестирования) Корпоративные исторические данные (PPB) Допущения


Слайд 11

Оценка трудозатрат (2/2) Выход Оценка трудозатрат на тестирование по активностям Два последовательных этапа для оценки: Формирование релиза (минимальные сведения) Детализация релиза (полное описание функциональности и технических деталей реализации)


Слайд 12

Шаблон оценки трудозатрат (1/3)


Слайд 13

Шаблон оценки трудозатрат (2/3)


Слайд 14

Шаблон оценки трудозатрат (3/3)


Слайд 15

Два типичных вопроса в Luxoft Какого хрена? Почему на тестирование этой ерунды требуется целых 20 минут/часов/дней? Почему разработчикам хватит двух дней, а тестировщикам надо три дня? Почему нельзя быстрее? Где бабло? Как объяснить/продать заказчику то, что тестировщики будут делать все эти 20 минут/часов/дней? Как объяснить/продать заказчику, что в результате работы тестировщиков он сократить свои расходы?


Слайд 16

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


Слайд 17

Спасибо за внимание! Вопросы? Luxoft www.luxoft.com


×

HTML:





Ссылка: