t.me/atinfo_chat Telegram группа по автоматизации тестирования

Метрики автоматизации тестирования. Опрос и зачем мы их собираем.

Теги: #<Tag:0x00007f748863f430> #<Tag:0x00007f748863f340>

Сегодня пролистывал статьи в интернете и наткнулся на очередную статью о сборах метрик в автоматизации тестировании.

Например, автор кроме сбора появившихся дефектов считает метрику касательно user stories

A graph like this contains a lot of information so it will need a bit of explanation when showing to the team and especially to managers. On a per sprint basis this graph shows:

  • Blue bars: the amount of story points delivered per sprint (the actual delivery, not the committed amount!) set off against the left vertical axis
  • White bars: the cumulative amount of automated tests run on these stories and run as regression set off against the right vertical axis.
  • Black line: a trend line of the overall amount of automated tests
  • Green line: the actual amount of production issue occurences after releasing a sprint worth of code to production.

ссылка на статью http://martijndevrieze.net/2012/06/08/test-automation-metrics-mashing-up-non-test-data/

Соответственно у меня к вам мини-опрос:

Используете ли Вы метрики для оценки автоматизации тестирования?

  • да :heavy_check_mark:
  • нет :heavy_multiplication_x:

0 участников

Считаете ли Вы необходимостью собирать метрики для автоматизации тестирования?

  • да :heavy_check_mark:
  • нет :heavy_multiplication_x:

0 участников

Кто у Вас занимается сбором метрик по автоматизации тестирования?

  • тестировщики
  • автоматизаторы
  • тим лиды
  • тест менеджеры
  • проектные менеджеры

0 участников

Для чего собираются метрики автоматизации тестированию в вашем случае?

  • чтобы контролировать процесс автоматизации
  • чтобы доказать эффективность автоматизации
  • чтобы начальство видело результаты
  • чтобы отслеживать критерии качества продукта
  • другая причина сбора метрик
  • мы их собираем, но не знаю зачем
  • не собираем

0 участников

И если Вы используете какие-то метрики, отпишитесь плиз какие и зачем Вы их собираете?

1 Симпатия

ИМХО. Имеет смысл возится с метриками, когда это нужно показывать и в этом есть толк. На проектах менее 100-200 тестов это делать лишняя возня. А вот на более крупных и долгостройных - действительно нужно. Сам метрику не делаю, ибо забот хватает, но веду статистику запусков некую, просто пишу в лог результаты тестов.

Простая метрика - фейленых тестов дожно быть ~ 0

1 Симпатия

Ну эта метрика тяжело реализуется в средне-сложных проектах с большим количеством зависимости. Для таких случаев у меня есть минимальный порог прохождения тестов, предположим 95%, 5% могут быть различные плавающие проблемы.

И смысл таких тестов? Можно наклепать так, что они всегда зеленые, только проблем не отлавливают. На графиках будет всегда зеленый столбик и Passed, а баги в ПО они не ловят. Авто-тесты как и само ПО требуют поддержки, актуализации. По итогам этих самых падений часто принимается решения, нужно ли доработать тест или же это ошибка в новой сборке тестируемого ПО.

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

@polusok @Mihail_Bratuhin
А мне кажется, это всё отмазки.
У нас все тесты стабильно зелёные, и ничего. Мы просто уделяем этому достаточно внимания, потому что считаем это очень важным.

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

Андрей, как бы я не ищу себе оправданий. Реалии своего проекта и своих способностей я знаю.
Судя по вашим докладам - вы разработчик, а не тестировщик.
И с ваших же слов у вас тесты фейлятся, причем постоянно и каждый день. В этих случаях правятся либо тесты, либо код который их ломает. Так вот внимание вопрос - если код приложения, который ломает ваши тесты по каким-то причинам сейчас не правится, а вы не разработчик, то что вы будете делать с тестом? Вот так и скапливаются тесты, которые могут “стабильно падать”. На них могут быть вполне быть открыты некритичные/среднекритичные тикеты в JIRA (или любой другой схожей системе контроля) и жить такие дефекты могут очень долго.
Другая причина “плохих” тестов - интеграции и частые установки, кривые настройки и т.д. У вас скорее всего в качестве тестов имеются ввиду в первую очередь Unit-тесты, но не ими одними заканчивается автоматизация и многие проблемы выявляются именно на этапах интеграции систем, а не на этапе системного и юнит-тестирования.

@Mihail_Bratuhin Да, я разработчик, однако мы пишем и юнит-, и UI тесты. Я всё-таки все их имею в виду. Потому что говорить о скорости или стабильности юнит-тестов глупо: и так понятно, что они быстрые и стабильные.

У меня встречный вопрос: если код приложения не правится, то зачем запускать тесты?
Когда код меняется, надо запускать билд в дженкинсе на каждый коммит и прогонять все тесты. Если коммитов не было - нафига запускать тесты?

Странные вопросы, если честно. Обычно в рамках одного коммита правится не больше одной задачи/дефекта. А многие дефекты правятся далеко не сразу.

Не понял ответа. И что?
Запускать тесты для приложения, которое не меняется?

Запускаются тесты для приложения, которое изменилось. Но при этом далеко не факт, что все тесты пройдут успешно. Потому что не все исправления были сделаны в тестируемой сборке или не были внесены новые дефекты. И упавшие тесты это отобразят. Мы же тут вели разговор о критерии сфейленных тестов, которых должно быть 0%.
В реальности же цифра успешных тестов стремиться к 100% и иногда даже достигает этого значения, особенно в предрелизных этапах. Но по факту обычно есть некоторый процент допустимых падений, как писал выше @polusok и я при прохождении 95% тестов изучаю чем были вызваны падения оставшихся 5%, но в целом если там нет прям уж совсем криминала, то сборка считается более-менее нормальной и с ней можно успешно дальше работать. В том числе и ставить на интеграционный стенд для ручных тестировщиков.

Тут же на форуме с некоторой периодичностью появляются статьи о том, сколько раз нужно перезапускать тесты в случае падения, чтобы возможно при повторном прохождении они были уже зелеными. Люди правдами и неправдами пытаются пропихнуть тесты в зеленый статус. И в том числе про данную ситуацию был мой изначальный комментарий. Не очень понимаю в чем у нас с вами расхождения во мнениях по данному вопросу. Какие-то параллельные вещи относительно изначального обсуждения.

@Mihail_Bratuhin Да, мы ушли от темы, это точно. :slight_smile:

Да, я понимаю, о чём вы говорите. В такой ситуации, когда

  1. сначала разрабы всё задевелопили, смержили и отправили админам
  2. админы сделали “сборку”, поставили на тест-сервер
  3. вы запустили автотесты на этом тест-сервере
  4. автотесты сломались

действительно, чтобы исправить автотест, придётся возвращаться на шаг 1, а это очень долго. И типа уже некогда, и разрабы уже другими вещами успели заняться, и админам неохота новую сборку делать… Да, я вас понимаю, что в такой ситуации действительно тесты часто и остаются надолго красными.

Но я как раз это и хочу сказать, что этот процесс сам по себе неправильный. В правильном процессе

  1. дженкинс должен запустить все тесты ещё ДО того, как разрабы всё смержили и отправили админам.
  2. Админы в принципе не должны делать “сборку”, если в дженкинсе есть красные тесты.
  3. Отделу QA в принципе не должны отдавать на тестирование билд, в котором есть красные автотесты.

Вот тогда не будет этого вопроса “а какой процент красных тестов допустим” и “как помечать тесты, которые красные, но это типа так и должно быть”.

1 Симпатия