Во сколько вам обходиться поддержка автоматизации

Я думаю довольно обычная ситуация, когда автоматизация разворачивается не как должна, по правилам, а в не кой хаотичности, что в свою очередь приводит к ряду проблем.
Сегодня ко мне подошел коллега и начал задавать вопросы по поддержке и сопровождении автоматизации. Вопросы вполне ожидаемые:

  • Сколько нужно выделять временени на поддержку автоматизации?
  • Как правильно сделать обработку ошибок, чтобы анализ результатов был минимальным?
  • Чем плох подход, когда пишутся тесты, а потом думают над тем, чтобы уменшить время на сопровождение?
  • Как решить проблемы и показать заказчику, что поддержка нужна и она требует времени?
  • ...

А главный вопрос, что над проектом работали 16 человек, при этом писали "лабали" код по черному, а вот о стратегии забыли. А почему забыли, потому что заказчик сказал: "Вперед и поехали, да с ветерком!". Но при этом никто сильно не удосужился должным образом объяснить заказчику, какие проблемы при такой "легкой" автоматизации. 

Теперь у них 700 тест кейзов из которых 60% стабильно падают после каких-то билдов, из-за разных проблем. Соответственно, идентификация дефектов очень не результативна. На анализ полученных результатов нужно 2-3 минут.

(2 мин или 3 мин)*(700*0.6)/60 мин=14-21 часов. Один человек работает где-то 7 часов в день, то значит надо 1 день для 3х людей, чтобы только проанализировать результаты.

Так вот: 3 человека работают с 100% загруженностью уже вторую неделю и не видят ни конца ни края. Заказчик хочет 100% прохождения тестов, а также расширение покрытия.

Собственно, что меня интересуюет - это статистика и ваш личный опыт?

  • Сколько времени вы закладываете на сопровождение?
  • Что делаете, чтобы уменшить время поддержки?
  • Сколько времени реально тратиться на поддержку?
  • Какие механизмы анализа результатов используете?
  • Сколько времени занимает анализ результатов чтобы изолировать и определить дефект?

анализировать результаты тоже нужно автоматически. разработка решения для авт. обработки рез. может занять то 20% времени разработки автоматизации, но оно того стоит - время анализа снижается на 90% (если код писать а не лабать ;-) )

а как строиться такой анализатор? например...

Знаете, в одной компании, в которой я работал не очень любили фиксить мелкие баги, внезапно всплывшие в автотестах. И каждое утро, когда я разбирал логи, приходилось залезать в упавший тест убеждаться, что ничего нового не появилось(!) и переходить к следующему. Через недели две делать одно и то же мне надоело - я решил "спрятать" проблемы, но так, чтобы совсем про них не забыть. Я всё ещё сомневаюсь, что сделал правильно, но я попробовал и это мне сэкономило в итоге кучу времени.

Как это было реализовано.

Чтобы понять, как такое сделать нужно представить автотест в виде сценария, который состоит только из действий, которые выполняются всегда последовательно, друг за другом. После выполнения действия (например, клика по контролу) всегда есть информация - действие завершилось успешно или возникли проблемы(pass/fail). Если посмотреть на логи такого сценария, то можно заметить, что определённые баги вызывают сбой в строго определённых действиях. В действия, которые всегда выдавали fail для конкретного бага я добавил информацию с номером этого бага. По окончанию проигрывания сценария, запустил простенький анализатор логов, который собирал информацию о том, где конкретно произошёл сбой и подходит ли это под какой-либо баг. Проще говоря, если результат действия - pass, то ничего не делаем, если fail - смотрим, есть ли в действии информация о багах, если есть, то "+1" к этому багу. После проверки таким образом всех действий сценария, анализатор сверял, достаточно ли "+1" для того, чтобы сказать "Да, в этом тесте с большой вероятностью воспроизвёлся баг № такой-то" и если достаточно, то действия, которые были "failed" для этого бага помечались "pass", но к информации о результатах прогона всего сценария добавлялась строчка о том, что воспроизведён баг с таким-то номером. Если у какого-то бага не хватало "+1", то скорее всего это проявление какой-то новой проблемы и менять fail на pass не надо. В результате, утром я наблюдал "зелёные" логи и информацию о так и не исправленных проблемах.

Сделаю оговорку, что это не для всех автотестов подходит и не для всех команд - где-то к качеству продуктов отношение лучше.

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

какую баг трекинг систему использовали? скрипт лез наплямую в баг трекинг систему за статусом бага или нет?

Багтрекер у нас самописный был, ни о каком api речи не идёт, веб-морды даже не было. Тратить время ещё и на это я не решился. Про баги внутри багов - истинная правда, но вероятность такого совпадения на практике оказалась не высокой.

Я бы даже предположил, что ситуация хуже -- 60% тестов сбоят, плюс ещё 40% тестов почему-то завершаются успешно, не сигнализируя об ошибках, может быть это ложноотрицательные срабатывания? :)

В общем, две недели -- это ещё не много. Но если не конца ни края -- рефакторинг в руки и вперёд, к светлому будущему!