К основному контенту

Software-Engineering Myth Busters (покрытие кода тестами, TDD, организация и распределенные команды)

Наткнулся недавно на подборку интересных исследований проведенных Empirical Software Engineering and Measurement Research Group.

Товарищи на примере деятельности команд разработки Microsoft попытались получить хоть какие-то цифры отражающие влияние различных инженерных практик и процессов, например TDD, на качество получаемых продуктов.

Сюда вынес наиболее интересные результаты исследований.
Ниже, в качестве критерия качества рассматривается количество ошибок обнаруженных после релиза и требующих зачинок (как самых дорогих для исправления).

Влияние покрытия кода тестами на качество
Покрытие кода рассчитывается, как процент (отношение) строчек кода, которые вызываются при запускаемых тестах к их общему количеству.
Казалось бы логичным считать, что чем больше покрытие - тем лучше качество. Но результаты показали, что не все так просто (кто бы мог подумать).
Одна метрика не может характеризовать качество для любых продуктов. Процент покрытия кода сам по себе ничего не говорит, если не учитывать сложность кода и частоту его использования.
Если 99% кода протестировано, но оставшийся 1% кода постоянно используется, то от 99% толку мало. Также влияет сложность кода: сложный код сложнее тестировать и добиваться высокого процента покрытия.
Итого: важно получить большое покрытие для сложного и часто используемого кода, чем "просто некий" процент покрытия.
Еще интересная статья про покрытие: How to Misuse Code Coverage
И еще про TDD и покрытие

Влияние TDD на качество
В исследовании рассматривались результаты команды практикующих TDD и не использующих эту практику, при этом подчиняющихся одному менеджеру (видимо, чтобы убрать наводку менеджерской активности на результаты). Эти команды разрабатывают Windows, Visual Studio и MSN (в самом исследовании есть еще результаты команд IBM).
Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.
Рекомендую глянуть само исследование подробней. Там приведены исходные данные в виде размера команд разработки, их опыта, применяемых языков программирования и сроков разработки.
Итог получился в виде такой табличке

Использование проверок в коде (assertions) и как оно помогает
Еще одно интересное исследование. В качестве подопытных выступили две команды двух разных компонентов Visual Studio. Тут подробно расписывать не буду, дока немаленькая. Вывод закономерен: больше ассертов - меньше багов. Но интересно, что при внедрении этой практики настойчиво рекомендуется не вводить метрик в виде отношения количества ассертов к количеству строк. Разработчик должен "чувствовать" и осознавать необходимость использования таких проверок. Кстати, статический анализ тоже поможет.

Следующие два исследования анализировали влияние организационной структуры и распределенности команды на качество кода
Кроме влияния традиционных метрик кода (code churn, code complexity, code dependencies), хочется понимать, а как на итоговый результат может повлиять организационная структура команд(ы) разрабатывающей продукт. Это исследование описывает влияние всех этих метрик. Организационные метрики получились достаточно запутанными и я в них пока не въехал :)

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

В общем, кому охота прогрузиться цифрами на выходных - вам сюда.

Update: еще одно исследование "Test Code Quality and Its Relation to Issue

Комментарии

  1. >>Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.

    Сколько опечаток в словосочетании "нехорошо спланировали разработку" :).

    ОтветитьУдалить
  2. :) даже не знаю, что и ответить. То есть ты думаешь, что используя TDD можно писать и качественней, и быстрее?
    Согласен, интересный момент, медленнее "сейчас" или "быстрее" потом (в следующих релизах, фиксах и тп). Поэтому они и пишут про "these are decisions that managers have to make—where should they take the hit? But now, they actually have quantified data for making those decisions."

    ОтветитьУдалить
  3. Мне кажется что у каждого более менее жесткого подхода (TDD, SpecByExample) который ограничивает и явно задает условия проверки в начале есть свойство удлинения сроков. Свойство это видно внешнему наблюдателю - менеджеру, например.

    Другое дело что это же свойство в более расхлябанных процессах проявляется как затягивание сроков тестирования.


    То есть если ты как менеджер понимаешь количественный размер бедствия (удлинение сроков на разработку на 15-30% или удлинение сроков тестирования и уже не факт что на 15-30% ) то в принципе нет никакой количественной разницы.




    Другое дело разница качественная, да вот беда - как ее померять ?

    ОтветитьУдалить
  4. Ну там есть как раз качественная разница: количество пост-релизных багов с TDD на 60-90% меньше. Можно это считать за качественную разницу? Ты же не считаешь, что в тех командах, где не было TDD не было и тестирования :)

    ОтветитьУдалить
  5. "Но, при этом время на разработку увеличивалось на 15-30%." - тут учитывались только голое время на разработку или суммарное время на разработку, тестирование, багфикс, поддержку и доработку? По второму критерию TDD по-любому быстрее. А если оценивали по первому критерию, то это шулерство.

    ОтветитьУдалить
  6. Если я правильно понял, то смотрелось время до релиза (с учетом того, что в качестве критерия брались баги после релиза, но без поддержки и доработок). И скорее всего это правдоподобно - выгода (в т.ч. и в ускорении) проявляется не в первый релиз, а в последующие и как раз при поддержке для фиксов. У меня так обычно было.
    Хотя в доке не указан какой релиз подряд они TDD юзают.
    Но можешь еще раз pdf перечитать, может я ошибаюсь :)

    ОтветитьУдалить
  7. Спасибо автору за интересные материалы и хороший пост! Заставили меня задуматься о метриках, которые мы используем. Метрики - дело тонкое, и часто их используют с прицелом на подтверждение какой-то гипотезы. В данном случае гипотезой может быть: "TDD (или другая практика) позитивно сказывается на качестве продукта". Каждая практика может быть полезной, но попытки рассчитать ее полезность или оценить затраты/выгоду - это почти всегда примерные и субъективные расчеты. Возможно я просто негативно отношусь к метрикам, которые очень часто используются неправильно.

    ОтветитьУдалить
  8. Роман, спасибо. Я тоже, мягко говоря, не фанат метрик. Но интересно когда они используются подобным образом - просто как дополнительные цифры для тех кто их любит. Меня часто спрашивают, а в чем польза автоматических тестов. Многим подобные факты с цифрами нравятся.

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.