Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
Оценка трудозатрат на тестирование в проектах сопровождения ( Два стандартных вопроса в  Luxoft) Александр Александров,  Luxoft   www.luxoft.com
Немного о себе 1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник) 1999-2005 –  Luxoft  (руководитель группы тестирования, тест-менеджер) 2006 -200 7 –  Auriga  (директор по качеству) С  200 8  – Luxoft  (эксперт по управлению качеством ПО) C 2011 – Luxoft  (тест-менеджер домена  Payloads) Кандидат физико-математических наук, доцент, старший научный сотрудник Сертифицированный инструктор университета  Carnegie Mellon  по тематике  Quality Assurance Член коллегии  RSTQB
Опыт работы Более  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)
Содержание Введение Особенности проектов сопровождения Особенности тестирования Метрики  Исходные данные для метрик Использование метрик Оценка трудозатрат на тестирование Два стандартных вопроса в  Luxoft Заключение
Введение Вопросы, всегда возникающие при оценке трудозатрат на тестирование: Каково соотношение трудозатрат на разработку и тестирование в проекте Каково соотношение численности разработчиков и тестировщиков в проектной команде Ответы на эти вопросы: Показывают их зависимость Отличаются большим разбросом Имеют существенные отличия для проектов разработки и проектов сопровождения
Особенности проектов сопровождения Как правило, это изменение уже работающей функциональности Затрагивается большое число проектных компонентов Изменения затрагивают всю вертикальную структуру проекта: Базу денных Сервер приложений Клиентское ПО Интерфейсы с внешними системами Значительная часть системы должна работать так же, как и раньше Сильные ограничения на сроки и бюджет
Особенности тестирования Непредсказуемость работ по тест-дизайну (изменению существующих тестовых сценариев) Непредсказуемость объема регрессионного тестирования Примеры: Изменение хранимой процедуры Добавление поля на экран(ы) и в отчет(ы) Рефакторинг всей системы Невозможность использования: Соотношения трудозатрат на разработку и тестирование в проекте Соотношения численности разработчиков и тестировщиков в проектной команде
Потребность в метриках От команды тестирования ждут оценку трудозатрат Соотношение трудозатрат на тестирование и разработку в проектах не проходит Похожих прецедентов, как правило, нет (каждый проект сопровождения уникален) Тем не менее, ничего лучше имеющегося собственного опыта у нас нет Как правильно его использовать? «Кто управляет прошлым, тот управляет будущим» (с) Дж. Оруэлл
Исходные данные для метрик Как правило, исходные изменения для построения и применения метрик включают: Фактические трудозатраты в разрезах ролей и процессов Количество дефектов в разрезах статуса и серьезности Размер кода Эти измерения: Накапливаются Статистически обрабатываются Используются для оценки будущих проектов Но этого может быть мало Может пригодиться число требований (с учетом гранулярности)
Использование метрик Напомним известные метрики тестирования: Плотность дефектов ( SDD  = Число дефектов  /  Размер кода ) Плотность дефектов после поставки ( PDDD  = Число дефектов после поставки  /  Размер кода ) «Убойность» тестов ( DP =  Число дефектов  /  Число тестов) Эффективность тестирования ( TE =  Число дефектов  /  Трудозатраты тестирования) Плотность покрытия требований ( RCD =  Число тестов  /  Число требований) Доля повторно открытых дефектов ( RDR =  Число повторно открытых дефектов  /  Число дефектов  )
Оценка трудозатрат (1 /2) Вход Объективные данные о релизе Новая/изменяемая функциональность (оформление -  требования, владельцы знаний - аналитики) Затрагиваемые области (оформление - спецификации и код, владельцы знаний – разработчики) История проекта (эффективность тестирования) Корпоративные исторические данные ( PPB) Допущения
Оценка трудозатрат ( 2/2) Выход Оценка трудозатрат на тестирование по активностям Два последовательных этапа для оценки: Формирование релиза (минимальные сведения) Детализация релиза (полное описание функциональности и технических деталей реализации)
Шаблон оценки трудозатрат (1 / 3) Test Effort Estimation (High Level) Input data Value Comment Assumptions New/updated use cases and reports 0 Analyst estimation   Configuration factor 1 Increasing testing efforts because of testing on several platforms (hardware, OS, browsers etc.)   Test environment preparation, person-hours 0 Release engineer estimation   User documentation, pages 0 Technical writer / Analyst estimation   Regression test cases 0 Test lead estimation   Online help testing, person-hours 0 Analyst estimation   Other types of testing, person-hours 0 Test lead estimation     Output data Value Comment Assumptions Total TC to run 0 Both new/updated and regression test cases   Total defects 0 On the basis of test runs and testing productivity   Documentation testing, person-hours 0 Both documents and online help testing           Efforts Value Comment Assumptions Test design (including test data design), person-hours 0 Including development and review   Test setup, person-hours 3 Including test environment preparation   Testing, person-hours 0 Including all types of testing   Defect management, person-hours 0 Including defect submitting and verification   Total testing engineering efforts, person-hours 3 Sum of all testing engineering activities   Test management, person-hours 1 Test strategy development, planning and monitoring, communications, reporting           Total efforts,  person-hours 4 Including test management and reporting   
Шаблон оценки трудозатрат (2 / 3) Test Effort Estimation (Detailed) Input data Value Comment Assumptions New use cases and reports (low complexity) 0 Requirements documents   New use cases and reports (regular complexity) 5 Requirements documents   New use cases and reports (high complexity) 0 Requirements documents   Updated use cases and reports (low complexity) 0 Requirements documents   Updated use cases and reports (regular complexity) 0 Requirements documents   Updated use cases and reports (high complexity) 0 Requirements documents   Affected use cases and reports (low complexity) 0 Analyst / Developer estimations   Affected use cases and reports (regular complexity) 0 Analyst / Developer estimations   Affected use cases and reports (high complexity) 0 Analyst / Developer estimations   Additional affected areas to be tested, test cases 0 Not included affected areas mentioned above   Configuration factor 1 Increasing testing efforts because of testing on several platforms (hardware, OS, browsers etc.)   Test environment preparation, person-hours  0 Release engineer estimation   New/updated user documentation, pages 0 User guides documents   Online help testing, person-hours 0 Draft analyst estimation   Installation testing, person-hours  0 Installation documents   Other types of testing, person-hours  0 Test lead estimation   Total project efforts, person-hours  0 Project manager estimation  
Шаблон оценки трудозатрат (3 / 3) Test Effort Estimation (Calibration)       High Level Estimation       Parameter Value Comments / Assumptions Number of test cases for one UC 2 PCB and  historical data Efforts for TC development, person-hours 2 Including efforts for test data preparation Efforts for one TC review, person-hours 1 In accordance with number of review rounds Test run for one TC, person-hours 1 Project-specific Number of test rounds on main platform 3 Project-specific Documenting one defect, person-hours 1 Including efforts for defect submitting and verification  Testing productivity, defects/person-hours 2 PCB and  historical data Efforts for testing one page of user documentation, person-hours 0,5 PCB and  historical data Test management, strategy and reporting ratio, % 20% PCB and  historical data   Detailed Estimation       Parameter Value Comments / Assumptions Testing activities ratio in the total project efforts, % 15% PCB and  historical data Test management and corresponding activities ratio in total testing efforts, % 20% Usually, the recommended default value is used. Number of test cases for one use case (low complexity) 2 Depends on test plan granularity. For example, it is possible to introduce the granularity coefficient of 1.5 and increase the value Number of test cases for one use case (regular complexity) 2 Depends on test plan granularity. For example, it is possible to introduce the granularity coefficient of 1.5 and increase the value
Два типичных вопроса в  Luxoft Какого хрена? Почему на тестирование этой ерунды требуется целых 20 минут/часов/дней? Почему разработчикам хватит двух дней, а тестировщикам надо три дня? Почему нельзя быстрее? Где бабло? Как объяснить / продать заказчику то, что тестировщики будут делать все эти 20 минут/часов/дней? Как объяснить / продать заказчику, что в результате работы тестировщиков он сократить свои расходы?
Заключение Учет специфики проектов сопровождения Определение объема регрессионного тестирования Сбор и использование исторических данных Использование метрик Индивидуальный подход на основе специфики проектов Защита оценок на основе объективных данных
Спасибо за внимание! Вопросы? Luxoft www.luxoft.com

More Related Content

Оценка трудозатрат на тестирование в проектах сопровождения

  • 1. Оценка трудозатрат на тестирование в проектах сопровождения ( Два стандартных вопроса в Luxoft) Александр Александров, Luxoft www.luxoft.com
  • 2. Немного о себе 1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник) 1999-2005 – Luxoft (руководитель группы тестирования, тест-менеджер) 2006 -200 7 – Auriga (директор по качеству) С 200 8 – Luxoft (эксперт по управлению качеством ПО) C 2011 – Luxoft (тест-менеджер домена Payloads) Кандидат физико-математических наук, доцент, старший научный сотрудник Сертифицированный инструктор университета Carnegie Mellon по тематике Quality Assurance Член коллегии RSTQB
  • 3. Опыт работы Более 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)
  • 4. Содержание Введение Особенности проектов сопровождения Особенности тестирования Метрики Исходные данные для метрик Использование метрик Оценка трудозатрат на тестирование Два стандартных вопроса в Luxoft Заключение
  • 5. Введение Вопросы, всегда возникающие при оценке трудозатрат на тестирование: Каково соотношение трудозатрат на разработку и тестирование в проекте Каково соотношение численности разработчиков и тестировщиков в проектной команде Ответы на эти вопросы: Показывают их зависимость Отличаются большим разбросом Имеют существенные отличия для проектов разработки и проектов сопровождения
  • 6. Особенности проектов сопровождения Как правило, это изменение уже работающей функциональности Затрагивается большое число проектных компонентов Изменения затрагивают всю вертикальную структуру проекта: Базу денных Сервер приложений Клиентское ПО Интерфейсы с внешними системами Значительная часть системы должна работать так же, как и раньше Сильные ограничения на сроки и бюджет
  • 7. Особенности тестирования Непредсказуемость работ по тест-дизайну (изменению существующих тестовых сценариев) Непредсказуемость объема регрессионного тестирования Примеры: Изменение хранимой процедуры Добавление поля на экран(ы) и в отчет(ы) Рефакторинг всей системы Невозможность использования: Соотношения трудозатрат на разработку и тестирование в проекте Соотношения численности разработчиков и тестировщиков в проектной команде
  • 8. Потребность в метриках От команды тестирования ждут оценку трудозатрат Соотношение трудозатрат на тестирование и разработку в проектах не проходит Похожих прецедентов, как правило, нет (каждый проект сопровождения уникален) Тем не менее, ничего лучше имеющегося собственного опыта у нас нет Как правильно его использовать? «Кто управляет прошлым, тот управляет будущим» (с) Дж. Оруэлл
  • 9. Исходные данные для метрик Как правило, исходные изменения для построения и применения метрик включают: Фактические трудозатраты в разрезах ролей и процессов Количество дефектов в разрезах статуса и серьезности Размер кода Эти измерения: Накапливаются Статистически обрабатываются Используются для оценки будущих проектов Но этого может быть мало Может пригодиться число требований (с учетом гранулярности)
  • 10. Использование метрик Напомним известные метрики тестирования: Плотность дефектов ( SDD = Число дефектов / Размер кода ) Плотность дефектов после поставки ( PDDD = Число дефектов после поставки / Размер кода ) «Убойность» тестов ( DP = Число дефектов / Число тестов) Эффективность тестирования ( TE = Число дефектов / Трудозатраты тестирования) Плотность покрытия требований ( RCD = Число тестов / Число требований) Доля повторно открытых дефектов ( RDR = Число повторно открытых дефектов / Число дефектов )
  • 11. Оценка трудозатрат (1 /2) Вход Объективные данные о релизе Новая/изменяемая функциональность (оформление - требования, владельцы знаний - аналитики) Затрагиваемые области (оформление - спецификации и код, владельцы знаний – разработчики) История проекта (эффективность тестирования) Корпоративные исторические данные ( PPB) Допущения
  • 12. Оценка трудозатрат ( 2/2) Выход Оценка трудозатрат на тестирование по активностям Два последовательных этапа для оценки: Формирование релиза (минимальные сведения) Детализация релиза (полное описание функциональности и технических деталей реализации)
  • 13. Шаблон оценки трудозатрат (1 / 3) Test Effort Estimation (High Level) Input data Value Comment Assumptions New/updated use cases and reports 0 Analyst estimation   Configuration factor 1 Increasing testing efforts because of testing on several platforms (hardware, OS, browsers etc.)   Test environment preparation, person-hours 0 Release engineer estimation   User documentation, pages 0 Technical writer / Analyst estimation   Regression test cases 0 Test lead estimation   Online help testing, person-hours 0 Analyst estimation   Other types of testing, person-hours 0 Test lead estimation     Output data Value Comment Assumptions Total TC to run 0 Both new/updated and regression test cases   Total defects 0 On the basis of test runs and testing productivity   Documentation testing, person-hours 0 Both documents and online help testing           Efforts Value Comment Assumptions Test design (including test data design), person-hours 0 Including development and review   Test setup, person-hours 3 Including test environment preparation   Testing, person-hours 0 Including all types of testing   Defect management, person-hours 0 Including defect submitting and verification   Total testing engineering efforts, person-hours 3 Sum of all testing engineering activities   Test management, person-hours 1 Test strategy development, planning and monitoring, communications, reporting           Total efforts, person-hours 4 Including test management and reporting  
  • 14. Шаблон оценки трудозатрат (2 / 3) Test Effort Estimation (Detailed) Input data Value Comment Assumptions New use cases and reports (low complexity) 0 Requirements documents   New use cases and reports (regular complexity) 5 Requirements documents   New use cases and reports (high complexity) 0 Requirements documents   Updated use cases and reports (low complexity) 0 Requirements documents   Updated use cases and reports (regular complexity) 0 Requirements documents   Updated use cases and reports (high complexity) 0 Requirements documents   Affected use cases and reports (low complexity) 0 Analyst / Developer estimations   Affected use cases and reports (regular complexity) 0 Analyst / Developer estimations   Affected use cases and reports (high complexity) 0 Analyst / Developer estimations   Additional affected areas to be tested, test cases 0 Not included affected areas mentioned above   Configuration factor 1 Increasing testing efforts because of testing on several platforms (hardware, OS, browsers etc.)   Test environment preparation, person-hours 0 Release engineer estimation   New/updated user documentation, pages 0 User guides documents   Online help testing, person-hours 0 Draft analyst estimation   Installation testing, person-hours 0 Installation documents   Other types of testing, person-hours 0 Test lead estimation   Total project efforts, person-hours 0 Project manager estimation  
  • 15. Шаблон оценки трудозатрат (3 / 3) Test Effort Estimation (Calibration)       High Level Estimation       Parameter Value Comments / Assumptions Number of test cases for one UC 2 PCB and historical data Efforts for TC development, person-hours 2 Including efforts for test data preparation Efforts for one TC review, person-hours 1 In accordance with number of review rounds Test run for one TC, person-hours 1 Project-specific Number of test rounds on main platform 3 Project-specific Documenting one defect, person-hours 1 Including efforts for defect submitting and verification Testing productivity, defects/person-hours 2 PCB and historical data Efforts for testing one page of user documentation, person-hours 0,5 PCB and historical data Test management, strategy and reporting ratio, % 20% PCB and historical data   Detailed Estimation       Parameter Value Comments / Assumptions Testing activities ratio in the total project efforts, % 15% PCB and historical data Test management and corresponding activities ratio in total testing efforts, % 20% Usually, the recommended default value is used. Number of test cases for one use case (low complexity) 2 Depends on test plan granularity. For example, it is possible to introduce the granularity coefficient of 1.5 and increase the value Number of test cases for one use case (regular complexity) 2 Depends on test plan granularity. For example, it is possible to introduce the granularity coefficient of 1.5 and increase the value
  • 16. Два типичных вопроса в Luxoft Какого хрена? Почему на тестирование этой ерунды требуется целых 20 минут/часов/дней? Почему разработчикам хватит двух дней, а тестировщикам надо три дня? Почему нельзя быстрее? Где бабло? Как объяснить / продать заказчику то, что тестировщики будут делать все эти 20 минут/часов/дней? Как объяснить / продать заказчику, что в результате работы тестировщиков он сократить свои расходы?
  • 17. Заключение Учет специфики проектов сопровождения Определение объема регрессионного тестирования Сбор и использование исторических данных Использование метрик Индивидуальный подход на основе специфики проектов Защита оценок на основе объективных данных
  • 18. Спасибо за внимание! Вопросы? Luxoft www.luxoft.com