Сегодня пролистывал статьи в интернете и наткнулся на очередную статью о сборах метрик в автоматизации тестировании.
Например, автор кроме сбора появившихся дефектов считает метрику касательно 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.
ИМХО. Имеет смысл возится с метриками, когда это нужно показывать и в этом есть толк. На проектах менее 100-200 тестов это делать лишняя возня. А вот на более крупных и долгостройных - действительно нужно. Сам метрику не делаю, ибо забот хватает, но веду статистику запусков некую, просто пишу в лог результаты тестов.
Ну эта метрика тяжело реализуется в средне-сложных проектах с большим количеством зависимости. Для таких случаев у меня есть минимальный порог прохождения тестов, предположим 95%, 5% могут быть различные плавающие проблемы.
И смысл таких тестов? Можно наклепать так, что они всегда зеленые, только проблем не отлавливают. На графиках будет всегда зеленый столбик и Passed, а баги в ПО они не ловят. Авто-тесты как и само ПО требуют поддержки, актуализации. По итогам этих самых падений часто принимается решения, нужно ли доработать тест или же это ошибка в новой сборке тестируемого ПО.
Часто бывает, что при разработке тестов имеют “известные” проблемы и допущения, т.к. разработка “железобетонных” тестов будет или излишне сложной и долгой, тесты могут стать к тому же слишком долгими, или наоборот слишком простыми и ничего не отлавливать.
@polusok@Mihail_Bratuhin
А мне кажется, это всё отмазки.
У нас все тесты стабильно зелёные, и ничего. Мы просто уделяем этому достаточно внимания, потому что считаем это очень важным.
(Ну, то есть они каждый день падают по многу раз, когда разработчики меняют код. Но это не “фантомные” падения, а вполне показывающее “нехорошие” изменения)
Андрей, как бы я не ищу себе оправданий. Реалии своего проекта и своих способностей я знаю.
Судя по вашим докладам - вы разработчик, а не тестировщик.
И с ваших же слов у вас тесты фейлятся, причем постоянно и каждый день. В этих случаях правятся либо тесты, либо код который их ломает. Так вот внимание вопрос - если код приложения, который ломает ваши тесты по каким-то причинам сейчас не правится, а вы не разработчик, то что вы будете делать с тестом? Вот так и скапливаются тесты, которые могут “стабильно падать”. На них могут быть вполне быть открыты некритичные/среднекритичные тикеты в JIRA (или любой другой схожей системе контроля) и жить такие дефекты могут очень долго.
Другая причина “плохих” тестов - интеграции и частые установки, кривые настройки и т.д. У вас скорее всего в качестве тестов имеются ввиду в первую очередь Unit-тесты, но не ими одними заканчивается автоматизация и многие проблемы выявляются именно на этапах интеграции систем, а не на этапе системного и юнит-тестирования.
@Mihail_Bratuhin Да, я разработчик, однако мы пишем и юнит-, и UI тесты. Я всё-таки все их имею в виду. Потому что говорить о скорости или стабильности юнит-тестов глупо: и так понятно, что они быстрые и стабильные.
У меня встречный вопрос: если код приложения не правится, то зачем запускать тесты?
Когда код меняется, надо запускать билд в дженкинсе на каждый коммит и прогонять все тесты. Если коммитов не было - нафига запускать тесты?
Запускаются тесты для приложения, которое изменилось. Но при этом далеко не факт, что все тесты пройдут успешно. Потому что не все исправления были сделаны в тестируемой сборке или не были внесены новые дефекты. И упавшие тесты это отобразят. Мы же тут вели разговор о критерии сфейленных тестов, которых должно быть 0%.
В реальности же цифра успешных тестов стремиться к 100% и иногда даже достигает этого значения, особенно в предрелизных этапах. Но по факту обычно есть некоторый процент допустимых падений, как писал выше @polusok и я при прохождении 95% тестов изучаю чем были вызваны падения оставшихся 5%, но в целом если там нет прям уж совсем криминала, то сборка считается более-менее нормальной и с ней можно успешно дальше работать. В том числе и ставить на интеграционный стенд для ручных тестировщиков.
Тут же на форуме с некоторой периодичностью появляются статьи о том, сколько раз нужно перезапускать тесты в случае падения, чтобы возможно при повторном прохождении они были уже зелеными. Люди правдами и неправдами пытаются пропихнуть тесты в зеленый статус. И в том числе про данную ситуацию был мой изначальный комментарий. Не очень понимаю в чем у нас с вами расхождения во мнениях по данному вопросу. Какие-то параллельные вещи относительно изначального обсуждения.
Да, я понимаю, о чём вы говорите. В такой ситуации, когда
сначала разрабы всё задевелопили, смержили и отправили админам
админы сделали “сборку”, поставили на тест-сервер
вы запустили автотесты на этом тест-сервере
автотесты сломались
действительно, чтобы исправить автотест, придётся возвращаться на шаг 1, а это очень долго. И типа уже некогда, и разрабы уже другими вещами успели заняться, и админам неохота новую сборку делать… Да, я вас понимаю, что в такой ситуации действительно тесты часто и остаются надолго красными.
Но я как раз это и хочу сказать, что этот процесс сам по себе неправильный. В правильном процессе
дженкинс должен запустить все тесты ещё ДО того, как разрабы всё смержили и отправили админам.
Админы в принципе не должны делать “сборку”, если в дженкинсе есть красные тесты.
Отделу QA в принципе не должны отдавать на тестирование билд, в котором есть красные автотесты.
Вот тогда не будет этого вопроса “а какой процент красных тестов допустим” и “как помечать тесты, которые красные, но это типа так и должно быть”.
testomat.io управление авто тестами
