Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Технический долг: взгляд и действия со стороны QA / QC&AT

Дмитрий Химион, Performance Lab, QA-секция, CodeFest 2015

  • Identifiez-vous pour voir les commentaires

Технический долг: взгляд и действия со стороны QA / QC&AT

  1. 1. Технический долг: взгляд и действия со стороны QA / QC&AT Дмитрий Химион Руководитель направления автоматизации тестирования
  2. 2. Дмитрий Химион руководитель направления автоматизации тестирования Performance Lab Докладчик на конференциях: SQA Days 13 ITSM Forum SQA Days 14 SQA Days 15 SQA Days 16 Представлюсь
  3. 3. 1. Что такое технический долг? 2. Примеры влияния на проекты 3. Как относится к тестированию? 4. Как измерить и контролировать? 5. Внедрение План доклада
  4. 4. Говард Каннингем – автор термина «технический долг» Технический долг - это разница между идеальным техническим решением и тем решением, которое принимается сейчас (англ.яз - tech.debt). Что такое технический долг?
  5. 5. • Осознанный (умышленный) – программист отказывается от гибкости кода или от покрытия кода тестами, выигрывая время. • Не осознанный – неопытность программиста в использовании конструкций языка программирования или применении Framework-ов или платформ. • Технологический – затягивание с обновлением версии платформы и framework • Архитектурный – необходимость переработки архитектуры под новые требования Разновидности технического долга
  6. 6. • Осознанный (умышленный) – программист отказывается от гибкости кода или от покрытия кода тестами, выигрывая время. • Не осознанный – неопытность программиста в использовании конструкций языка программирования или применении Framework-ов или платформ. • Технологический – затягивание с обновлением версии платформы и framework • Архитектурный – необходимость переработки архитектуры под новые требования Разновидности технического долга
  7. 7. Проект: • Публичный гос.проект • Целевая аудитория – жители РФ Проблема: • При нагрузке избыточная утилизация аппаратных ресурсов • Оптимизация критичных по производительности компонент не помогает. Примеры технического долга
  8. 8. Примеры технического долга Причина проблемы - ошибка уровня normal-major в использовании конструкции кода
  9. 9. DDT на функцию кода: • mode = ‘debug’ build = ‘debug’ extBuild = ‘-debug’ themeBuild = ‘-debug’ • mode = ‘review’ build = ‘review’ extBuild = ‘-debug’ themeBuild = ‘-debug’ • mode = ‘anyOtherKey’ build = ‘review’ extBuild = ‘-debug’ themeBuild = ‘-debug’ Примеры технического долга
  10. 10. Примеры технического долга break; Не осознанный технический долг
  11. 11. Примеры технического долга
  12. 12. Примеры технического долга Не осознанный технический долг
  13. 13. • Размер технического долга – показатель качества проекта. • Качество программного обеспечения Тестирование и Tech.debt
  14. 14. • Размер технического долга – показатель качества проекта. • Качество программного обеспечения Тестирование и Tech.debt Стандарт - ISO 9126
  15. 15. • Размер технического долга – показатель качества проекта. • Качество программного обеспечения Тестирование и Tech.debt ISO 9126 (ISO 25010) аспекты: • Функциональность • Надежность • Практичность • Эффективность • Сопровождаемость • Переносимость Стандарт - ISO 9126
  16. 16. • Размер технического долга – показатель качества проекта. • Качество программного обеспечения Тестирование и Tech.debt ISO 9126 (ISO 25010) аспекты: • Функциональность • Надежность • Практичность • Эффективность • Сопровождаемость • Переносимость Стандарт - ISO 9126
  17. 17. • Размер технического долга – показатель качества проекта. • Качество программного обеспечения Тестирование и Tech.debt ISO 9126 (ISO 25010) аспекты: • Функциональность • Надежность • Практичность • Эффективность • Сопровождаемость • Переносимость Стандарт - ISO 9126 Аспект «Сопровождаемость»: • Analyzability • Changeability • Testability • Stability
  18. 18. • Размер технического долга – показатель качества проекта. • Качество программного обеспечения Тестирование и Tech.debt ISO 9126 (ISO 25010) аспекты: • Функциональность • Надежность • Практичность • Эффективность • Сопровождаемость • Переносимость Стандарт - ISO 9126 Аспект «Сопровождаемость»: • Analyzability • Changeability • Testability • Stability
  19. 19. Инструменты измерения tech.debt Analyzability SCA* Code review Changeability SCA Code review Testability Test coverage Mutation testing * – статический анализ кода (static code analysis)
  20. 20. Инструменты измерения tech.debt Analyzability SCA Code review Changeability SCA Code review Testability Test coverage Mutation testing Инструменты: • SCA • Code review • Test coverage • Mutation testing • … Инфраструктура разработки
  21. 21. Инструменты измерения tech.debt Analyzability SCA Code review Changeability SCA Code review Testability Test coverage Mutation testing Инфраструктура разработки Разработка Тестирование Инструменты: • SCA • Code review • Test coverage • Mutation testing • …
  22. 22. Инструменты измерения tech.debt Analyzability SCA Code review Changeability SCA Code review Testability Test coverage Mutation testing Инструменты: • SCA • Code review • Test coverage • Mutation testing • … Инфраструктура разработки Разработка Тестирование
  23. 23. Инструменты измерения tech.debt SCA инструменты: • Cppcheck • PVS-studio • Coverity • Pylint • Sonarqube • FindBugs • Resharper
  24. 24. Встраивание в инфраструктуру quality gates – методология обеспечения качества
  25. 25. Измерение: 1. Анализа кода проекта Измерение технического долга Исходные коды • Получить SCA • Развернуть • Настроить Результат
  26. 26. Измерение: 1. Анализа кода проекта Исходные коды • Получить SCA • Развернуть • Настроить Результат Доступа к сорцам может не быть • Настроить GUI • Установить плагины • Интеграция с VCS • Виртуалка или железка • Установить ПО Измерение технического долга
  27. 27. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* * – проводится совместно с программистами ** – строк кода (Line Of Code) Дублирование кода Bugs per 1000 LOC* Документирование кода Комплексность кода Составные метрики Измерение технического долга
  28. 28. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* * – проводится совместно с программистами ** – строк кода (Line Of Code) Дублирование кода Bugs per 1000 LOC* Документирование кода Комплексность кода Составные метрики Измерение технического долга 70% и более Не больше 5%
  29. 29. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* * – проводится совместно с программистами Измерение технического долга
  30. 30. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* * – проводится совместно с программистами Измерение технического долга
  31. 31. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* * – проводится совместно с программистами Измерение технического долга 151000 срабатываний на сторонние библиотеки
  32. 32. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* * – проводится совместно с программистами Измерение технического долга 150000 срабатываний на сторонние библиотеки 92% ложных срабатываний
  33. 33. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* * – проводится совместно с программистами • Positive false • Не актуальные инспекции • Ложный приоритет инспекций • Проблемы с кодировками • … Измерение технического долга
  34. 34. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* 4. Задать приемлемый уровень метрик* * – проводится совместно с программистами Измерение технического долга
  35. 35. Измерение: 1. Анализа кода проекта 2. Принятие релевантных метрик* 3. Устранение «шума» в измерениях* 4. Задать приемлемый уровень метрик* * – проводится совместно с программистами Измерение технического долга Единая стилистика кода
  36. 36. 1. Инспектирование кода на периодической основе 2. Включение обсуждения «долгов» в планирование проекта 3. Прецедентная работы над приоритетами инспекций Контроль tech.debt
  37. 37. 1. Слежение за трендами и метриками 2. Регулярный критический просмотр результатов 3. Работа по прецедентам* Контроль tech.debt * – проводится совместно с программистами
  38. 38. Не стоит внедрять, если ваш проект: • Выводится из эксплуатации; • Не планируется поддерживать после разработки; • Прототип; • Личный проект. Внедрение в рабочий процесс
  39. 39. Внедрение в рабочий процесс Обсудить выгоды от котроля tech.debt с руководством проекта: 1. Исправление дефектов на ранней стадии разработки; 2. Прогнозирование рефакторинга; 3. Исключение нелепых ошибок.
  40. 40. • Нет инструмента всеобъемлюще измеряющего tech.debt • Измерение и контроль tech.debt – процесс итеративный • Мониторинг tech.debt задача отдела контроля качества • Измерение проблем проекта - «Осведомлён – значит вооружён» Итоги Предсказуемость влияния изменений на программу Зрелость процессов Прозрачность разработки и внесения изменений
  41. 41. Picasso-key Дмитрий Химион Руководитель направления АТ Вопросы? d.khimion@pflb.ru

×