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

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), хочется понимать, а как на итоговый результат может повлиять организационная структура команд(ы) разрабатывающей продукт. Это исследование описывает влияние всех этих метрик. Организационные метрики получились достаточно запутанными, и я в них пока не въехал :)

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

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

Комментарии

  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 uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объек

План "Б" или как прикольно провести субботний день

Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а" Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно ча

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после  вчерашнего выступления . Uncle Bob : " Flipping the Bit " Подробнее постараюсь перевести чуть позже, пока только это: Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :) Мантра: Сможете ли вы выполнить работу быстрее используя TDD? ДА Существуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТ Я понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективе Что если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДА В любом случае? ДА Есть ли случаи, когда вам не нужно использовать TDD? НЕТ Представьте себе что вы на звездном корабле Enterprise ( Star track ) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы и