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

Технический долг:
взгляд и действия со стороны
QA / QC&AT
Дмитрий
Химион
Руководитель направления
автоматизации тестирования

Дмитрий Химион
руководитель направления
автоматизации тестирования
Performance Lab
Докладчик на конференциях:
SQA Days 13
ITSM Forum
SQA Days 14
SQA Days 15
SQA Days 16
Представлюсь

1. Что такое технический долг?
2. Примеры влияния на проекты
3. Как относится к тестированию?
4. Как измерить и контролировать?
5. Внедрение
План доклада

Говард Каннингем – автор термина «технический долг»
Технический долг - это разница между идеальным
техническим решением и тем решением, которое
принимается сейчас (англ.яз - tech.debt).
Что такое технический долг?

• Осознанный (умышленный) – программист отказывается от гибкости кода или от
покрытия кода тестами, выигрывая время.
• Не осознанный – неопытность программиста в использовании конструкций языка
программирования или применении Framework-ов или платформ.
• Технологический – затягивание с обновлением версии платформы и framework
• Архитектурный – необходимость переработки архитектуры под новые требования
Разновидности технического долга

Проект:
• Публичный гос.проект
• Целевая аудитория – жители РФ
Проблема:
• При нагрузке избыточная утилизация
аппаратных ресурсов
• Оптимизация критичных по производительности
компонент не помогает.
Примеры технического долга

Причина проблемы - ошибка уровня normal-major
в использовании конструкции кода

DDT на функцию кода:
• mode = ‘debug’
build = ‘debug’
extBuild = ‘-debug’
themeBuild = ‘-debug’
• mode = ‘review’
build = ‘review’
• mode = ‘anyOtherKey’
build = ‘review’

break;
Не осознанный технический долг

Не осознанный технический долг

• Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt

Стандарт - ISO 9126

ISO 9126 (ISO 25010) аспекты:
• Функциональность
• Надежность
• Практичность
• Эффективность
• Сопровождаемость
• Переносимость

ISO 9126 (ISO 25010) аспекты:
• Функциональность
• Надежность
• Практичность
• Эффективность
• Сопровождаемость
• Переносимость
Аспект «Сопровождаемость»:
• Analyzability
• Changeability
• Testability
• Stability

Инструменты измерения tech.debt
Analyzability
SCA* Code review
Changeability
SCA Code review
Testability
Test coverage Mutation testing
* – статический анализ кода (static code analysis)

Analyzability
SCA Code review
Changeability
SCA Code review
Testability
Инструменты:
• SCA
• Code review
• Test coverage
• Mutation testing
• …
Инфраструктура разработки

Analyzability
SCA Code review
Changeability
SCA Code review
Testability
Разработка
Тестирование
• SCA
• Code review
• Test coverage
• …

Analyzability
SCA Code review
Changeability
SCA Code review
Testability
• SCA
• Code review
• Test coverage
• …
Разработка
Тестирование

SCA инструменты:
• Cppcheck
• PVS-studio
• Coverity
• Pylint
• Sonarqube
• FindBugs
• Resharper

Встраивание в инфраструктуру
quality gates – методология обеспечения качества

Измерение:
1. Анализа кода проекта
Измерение технического долга
Исходные
коды
• Получить
SCA
• Развернуть
• Настроить
Результат

Измерение:
Исходные
коды
• Получить
SCA
• Развернуть
• Настроить
Результат
Доступа к сорцам
может не быть
• Настроить GUI
• Установить плагины
• Интеграция с VCS
• Виртуалка или железка
• Установить ПО

Измерение:
2. Принятие релевантных метрик*
* – проводится совместно с программистами
** – строк кода (Line Of Code)
Дублирование кода
Bugs per 1000 LOC*
Документирование кода
Комплексность кода
Составные метрики

Измерение:
** – строк кода (Line Of Code)
Дублирование кода
Bugs per 1000 LOC*
Документирование кода
Комплексность кода
Составные метрики
70% и более
Не больше 5%

Измерение:
3. Устранение «шума» в измерениях*

Измерение:
151000 срабатываний на
сторонние библиотеки

Измерение:
150000 срабатываний на
сторонние библиотеки
92% ложных срабатываний

Измерение:
• Positive false
• Не актуальные инспекции
• Ложный приоритет инспекций
• Проблемы с кодировками
• …

Измерение:
4. Задать приемлемый уровень метрик*

Измерение:
4. Задать приемлемый уровень метрик*
Единая стилистика кода

1. Инспектирование кода на периодической основе
2. Включение обсуждения «долгов» в планирование проекта
3. Прецедентная работы над приоритетами инспекций
Контроль tech.debt

1. Слежение за трендами и метриками
2. Регулярный критический просмотр результатов
3. Работа по прецедентам*
Контроль tech.debt

Не стоит внедрять, если ваш проект:
• Выводится из эксплуатации;
• Не планируется поддерживать после разработки;
• Прототип;
• Личный проект.
Внедрение в рабочий процесс

Внедрение в рабочий процесс
Обсудить выгоды от котроля tech.debt с руководством проекта:
1. Исправление дефектов на ранней стадии разработки;
2. Прогнозирование рефакторинга;
3. Исключение нелепых ошибок.

• Нет инструмента всеобъемлюще измеряющего tech.debt
• Измерение и контроль tech.debt – процесс итеративный
• Мониторинг tech.debt задача отдела контроля качества
• Измерение проблем проекта - «Осведомлён – значит вооружён»
Итоги
Предсказуемость влияния изменений на программу
Зрелость процессов
Прозрачность разработки и внесения изменений

Picasso-key
Дмитрий Химион Руководитель
направления АТ
Вопросы?
d.khimion@pflb.ru

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

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

More from CodeFest

More from CodeFest (20)

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