Можете накидать ссылок про реальную эффективность внедренной автоматиз
#1
Отправлено 04 марта 2016 - 07:26
"Мы внедрили автоматизацию и в результате сэкономили денег/времени, улучшили качество" и пр.?
#2
Отправлено 04 марта 2016 - 08:29
Василий, Дмитрий, а можете накидать ссылок на статьи или выступления, где люди рассказывают про реальную эффективность внедренной автоматизации.
"Мы внедрили автоматизацию и в результате сэкономили денег/времени, улучшили качество" и пр.?
Статьи и выступления это одно, а реальность, к сожалению, немного другая.
В большинстве случаев автоматизировать функционально тестирование не выгодно.
И я уже давно не ходил по конференциям, а так, на SQADays каждый год можно услышать доклады об успехах в автоматизации, я даже как-то сам собирался выступить.
#3
Отправлено 04 марта 2016 - 08:34
А так же там можно услышать Сергея Мартыненко с противоположным мнением))
Недавно было подобное сообщение на форуме - поищу.
#5
Отправлено 04 марта 2016 - 08:40
Так о том, что это обычно невыгодно, я и сам знаю на своем, к сожалению, опыте.В большинстве случаев автоматизировать функционально тестирование не выгодно.
И не только на своем. Вижу, как некоторые команды мучаются, автоматизируют, а потом это никому не надо, кроме менеджеров, которые показывают в отчетах 98% автоматизированных тест-кейсов :)
Поэтому хочу посмотреть, когда люди получили реальную пользу от автоматизации. Каким образом-то? Где секрет? :)
"Мы сделали свой крутой фреймворк, у нас сценарии, бдд и все автоматизировано!" еще не есть эффективная автоматизация.
#6
Отправлено 04 марта 2016 - 08:42
Да, но ответа на текущий вопрос там все равно нет :)Вот ветка, но вы там были:)
http://software-test...avtomatizatcii/
#7
Отправлено 04 марта 2016 - 08:46
Мой личный опыт и опыт отдела говорит, что задачи в итоге решаются быстрее, да. Но я не считал стоимость рабочего времени относительно стоимости инструмента. Так что финансовая сторона у меня не обоснована.
Еще автоматизировали вещи, которые руками проверять практически нереально - огромные таблицы чисел. Помощь в тестировании - да. Но трудоемкость разработки там тоже колоссальная и где выгода в итоге сказать сложно.
#8
Отправлено 04 марта 2016 - 09:17
Предлагаю обсуждения того, "выгодно ли заниматься автоматизацией" или "стоит ли учиться автоматизировать" вынести в отдельную тему, потому что это не связано с оригинальным вопросом.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#9
Отправлено 04 марта 2016 - 09:25
Традиционно в подобных темах рекомендую посмотреть вот этот мой спич:
http://software-test...-05-23-08-31-31
Не поленитесь, всего 20 минут :)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#10
Отправлено 04 марта 2016 - 11:31
У меня был опыт успешной автоматизации:
Система с неустоявшейся архитектурой, но фиксированным входом и выходом.
Инструментарий: Jenkins, Rake, Cucumber, Ruby
В результате у меня были:
1) Инструмент по настройке тестового окружения который позволял мне эффективно переключаться между ветками разработки и поддерживать актуальность установленных сервисов (~20 сервисов на 5 серверах) - использовался до 5 раз в день для подготовки среды для ручных тестов.
2) E2E тесты - регистрация в системе 2-х типов ресурсов, получение доступа к ресурсам со стороны клиента. За 10 месяцев существования этих тестов они выстрелили порядка 30 раз.
3) Помимо этого, под эту же систему был написан скрипт проверки доступности контента через CDN ~ 10 запросов авторизации и 40 обращений за контентом. За год существования этого скрипта выстреливал он раз 20, в том числе и на продакшене, причем фикс был готов раньше чем хелпдеск сообщил о наличии проблемы. После этого скрипт был включен в систему мониторинга продакшена.
4) + еще пачка скриптов генерирующая нагрузку по заданному профилю.
5) Генератор тестового потока данных.
п1 Реально сильно экономил время ибо новые версии подтягивал сам, а в разных бранчах даже конфигурации стендов были разные + сокращал время предоставления фидбека за счет удешевления переключения между бранчами.
п2 Значительно сокращал время обнаружения ошибок. Тесты запускались с утра, по сборке каких-то значимых пакетов и как смок перед релизом. Практически был случай, когда тесты не запускались 2 недели и поломка основного функционала оставалась незамеченной неделю (не на продакшене).
п3 По факту тесты интеграции с 3-й стороной. Ловили и наши косяки и проблемы поставщиков услуг. Были признаны ценными и включены в мониторинг продакшена.
п4 Генерация специфичной для сервиса нагрузки с управляемыми профилями нагрузки. Использовалась в нагрузочных тестах отдельных сервисов, дисковых подсистем серверов, в оценке производительности и масштабируемости решений. Выкопали несколько реальных ботлнеков, в том числе и настройку дисковых подсистем, нашли плавающую проблему с многопоточностью в одном сервисе, оценили масштабируемость решения, использовали как метрику при тюнинге производительности системы.
п5 Было проведено исследование клиентов на способность обрабатывать ошибки в потоке. Использовался как генератор "проблемного" потока для разработчиков одной из платформ с которой мы работали (реальный поток давал проблему раз в 2-6 часов, генератор - раз в минуту).
В сумме на разработку этого добра у меня ушло ~30 человекодней за почти 2 года. Здесь отражен не весь профит полученный от этой разработки. Как минимум, кроме результата получилось 4 класса позволяющие высокохудожественно мучить систему с замером времен ответов и прочими шашечками, они-же использовались для batch - обработки проблемного контента.
#11
Отправлено 04 марта 2016 - 11:43
Спасибо!У меня был опыт успешной автоматизации:
Система с неустоявшейся архитектурой, но фиксированным входом и выходом.
Инструментарий: Jenkins, Rake, Cucumber, Ruby
А что из себя представляли входы-выходы? Какие-то API, файлы, GUI или еще что-то?
Вам однозначно плюс, но вот разработчикам минус, если продакшен отваливается так часто :)был написан скрипт проверки доступности контента через CDN ~ 10 запросов авторизации и 40 обращений за контентом. За год существования этого скрипта выстреливал он раз 20, в том числе и на продакшене, причем фикс был готов раньше чем хелпдеск сообщил о наличии проблемы. После этого скрипт был включен в систему мониторинга продакшена.
Но при этом, как я понимаю, выделенной команды, большой структуры автоматизированного тестирования и пр. у вас не было?
#12
Отправлено 04 марта 2016 - 11:44
То есть тестирование производительности и стабильности?В сумме на разработку этого добра у меня ушло ~30 человекодней за почти 2 года. Здесь отражен не весь профит полученный от этой разработки. Как минимум, кроме результата получилось 4 класса позволяющие высокохудожественно мучить систему с замером времен ответов и прочими шашечками, они-же использовались для batch - обработки проблемного контента.
#13
Отправлено 04 марта 2016 - 12:59
Могу рассказать как рядовой автоматизатор. Я не считал эффективности и всего такого, но есть одно наблюдение:
- В командах, где пытаются рассчитать эффективность заранее или на ранних стадиях, как правило, отказываются от автоматизации. Ну или занимаются ей спорадически, когда возникают тесты действительно технически сложные, или нужно перебирать много данных.
- В командах, где вводят постоянную позицию автоматизатора (а чаще 2 и больше, с целью бэкапа), она работает. Но эффект в виде денег/времени никто не считает. Опять же, мой опыт может быть ограниченным, но такие постоянные позиции обычно внедряются при поддержке, и даже прямом желании, заказчика.
Думаю, что так происходит, т.к. вообще нереально посчитать стоимость тестирования на долгий срок вперед, если продукт постоянно меняется. А развитую структуру автотестов быстро не создашь, уж точно нужно больше года.
Теперь, что я имел в виду под словами "она работает".
Сэкономили денег? Вряд ли. Всё-таки, ввели позицию инженера, и не самую дешевую, + оказываются нужны дополнительные ресурсы, например, в виде стендов под автоматизацию и виртуалок в облаке.
Сэкономили время? Тоже вряд ли. Тесты на новую функциональность долго писать, т.к. надо добавлять инструментарий. Тесты постоянно ломаются, и их нужно долго отлаживать. (Да, мы тупые и пишем плохие тесты, но умных не найдешь. Умные идут в разработчики, там тоже нехватка кадров.). Тесты надо адаптировать к новым версиям. Нужно делать рефакторинг, когда в структуре проекта начала образовываться свалка. И так далее, например, когда тестов просто много, то просто много времени уходит на их настройку и анализ прогонов.
Но вот оказывается, что прошло 2-3 года, и:
- есть смок, который стабильно запускается для каждого нового билда, и действительно находит проблемы, если билд косячный.
- есть стабильный набор регрессионных тестов, который прогоняется регулярно за 3-4 часа, тогда как раньше вся команда делала их 2 недели.
- есть тесты, которые проверяют сотни опций, которые руками просто проверить нереально, и легко было бы пропустить ошибку в продакшен.
- если оглянуться назад, то почти все тесты, которые делались 2-3 года назад вручную, гоняются автоматически (пусть и не без full-time поддержки), а команда мануальщиков проверяет уже совершенно новые вещи.
Но конечно, это только для больших "долгостроев". Если неизвестно, просуществует ли проект следующие год-полтора, то наверное, нужно рассчитывать эффективность.
#14
Отправлено 04 марта 2016 - 13:08
Спасибо!У меня был опыт успешной автоматизации:
Система с неустоявшейся архитектурой, но фиксированным входом и выходом.
Инструментарий: Jenkins, Rake, Cucumber, Ruby
А что из себя представляли входы-выходы? Какие-то API, файлы, GUI или еще что-то?
Вам однозначно плюс, но вот разработчикам минус, если продакшен отваливается так часто :)был написан скрипт проверки доступности контента через CDN ~ 10 запросов авторизации и 40 обращений за контентом. За год существования этого скрипта выстреливал он раз 20, в том числе и на продакшене, причем фикс был готов раньше чем хелпдеск сообщил о наличии проблемы. После этого скрипт был включен в систему мониторинга продакшена.
Но при этом, как я понимаю, выделенной команды, большой структуры автоматизированного тестирования и пр. у вас не было?
Вход - видео в виде файлов или мультикаста
Выход - то-же самое видео нарезанное на кусочки, в нескольких качествах с плейлистами и защитой контента
+API для авторизации и запроса ссылки на контент.
Конкретно в этом ключе продакшен отвалился по нашей вине всего однажды. Когда-то кому-то показалось что 2015 год - это очень далеко и нереально и он захардкодил его в expire. Так что одна из 3-х систем доставки контента контент отдавать перестала. В основном ломали авторизацию доставки на тесте, несколько раз глючили CDN и раз потеряли резервную точку входа в пререлиз
Нет, больших команды и инфраструктуры не было. Всей команды было: 2 питониста, плюсовик, архитектор, 2 админа, 2 тестировщика, менеджер и кофеварка.
То есть тестирование производительности и стабильности?В сумме на разработку этого добра у меня ушло ~30 человекодней за почти 2 года. Здесь отражен не весь профит полученный от этой разработки. Как минимум, кроме результата получилось 4 класса позволяющие высокохудожественно мучить систему с замером времен ответов и прочими шашечками, они-же использовались для batch - обработки проблемного контента.
Да, хотя замер времени оказался мало востребованным, точкой входа в систему работал nginx и статистику оказалось удобнее собирать из его лога.
#15
Отправлено 10 марта 2016 - 09:04
Традиционно в подобных темах рекомендую посмотреть вот этот мой спич:
http://software-test...-05-23-08-31-31
Не поленитесь, всего 20 минут :)
Спасибо, посмотрел.
Про стратегию - хорошо, про тактику - не очень :)
#16
Отправлено 10 марта 2016 - 09:06
А потом выходные файлы каким образом анализировались?Вход - видео в виде файлов или мультикаста
Выход - то-же самое видео нарезанное на кусочки, в нескольких качествах с плейлистами и защитой контента
Была ли проверка, что файл не побился, что нет рассинхрона видео и звука и пр.?
#17
Отправлено 10 марта 2016 - 10:25
А потом выходные файлы каким образом анализировались?Вход - видео в виде файлов или мультикаста
Выход - то-же самое видео нарезанное на кусочки, в нескольких качествах с плейлистами и защитой контента
Была ли проверка, что файл не побился, что нет рассинхрона видео и звука и пр.?
Анализировались только плейлисты.
Работа сегментора (нарезка контента на кусочки) и стримера (контейнеризация, шифрация и отдача контента) проверялась только вручную. Изменения там были нечастые, разработчик грамотный, ну и сами проверки слишком нетривиальные.
#18
Отправлено 10 марта 2016 - 10:35
Спасибо.Анализировались только плейлисты.
Работа сегментора (нарезка контента на кусочки) и стримера (контейнеризация, шифрация и отдача контента) проверялась только вручную. Изменения там были нечастые, разработчик грамотный, ну и сами проверки слишком нетривиальные.
Просто была когда-то подобная задача, но на выходе был flash-контент. В результате были только базовые проверки типа наличия выходного файла, его размера и пр., времени обработки, контент тоже не стали анализировать автоматом. А основной целью была проверка стабильности работы обработчика.
#19
Отправлено 29 марта 2016 - 11:20
По последнему проекту.
Автоматизировался некоторый набор регресс-тестов.
На ручное прохождение этого набора тестов закладывается около 120 ч/ч, т.е. около 2х недель 2 человека проверяют.
Тесты же проходили где-то за сутки - результат по времени на лицо (конечно же можно подрезать время на ручную проверку, т.к. 120 ч/ч многовато, но это другая история).
По прикидкам затрат на разработку автотестов - после 8-9 запусков тестов автоматизация уже окупалась (+ конечно ещё 1 рабочий день на анализ результатов, перепроверка упавшего).
Так что в данном случае - автоматизация чёткого среза тестов - очень помогает.
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных