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

metrics
management
Теги: #<Tag:0x00007fedbfeea548> #<Tag:0x00007fedbfeea3e0>

(Mykhailo Poliarush) #1

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

Например, автор кроме сбора появившихся дефектов считает метрику касательно 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 участников

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


Как создавать опросы в темах и комментариях at.info? Используйте [poll]. Инструкция использования.
(Mykhailo Poliarush) #2

(Goshko Nazar) #3

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


(Sergey Pirogov) #4

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


(Mykhailo Poliarush) #5

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


(Михаил Братухин) #6

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

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


(asolntsev) #7

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

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


(Михаил Братухин) #8

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


(asolntsev) #9

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

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


(Михаил Братухин) #10

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


(asolntsev) #11

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


(Михаил Братухин) #12

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

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


(asolntsev) #13

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

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

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

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

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

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

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