Технический долг: взгляд и действия со стороны 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

Дмитрий Химион Руководитель

направления АТ

Вопросы?

[email protected]

Технический долг: взгляд и действия со стороны qa / qc&at

Software

debt tech

debt sca

debt iso

debt iso

debt picasso

review build

review extbuild

static code analysis