testomat.io управление авто тестамиИ все таки, мои опасения оправдываются. Большую часть регрессии до сих пор еще выполняют руками.
Как вы выполняете регрессионное тестирование?
Интересно, почему такая ситуация?
руками, так как наш тим и сами кастомеры не доверяют автоматиации, эх ((
Зачастую это просто невыгодно. Мало того, что надо накупить кучу софта (весьма недешевого), так еще и надо потратить кучу усилий на формирование и поддержку всей инфраструктуры. + для этого нужны специалисты, которые весьма недешевы, при этом их мало и круг задач у них сильно ограничен.
То есть, одних лозунгов типа "автоматизация - это круто" или "это экономит время" слишком мало. Нужно конкретно смотреть, чем это круто и насколько реально экономится время и затраты (если экономятся). И далеко не всегда эти преимущества таковыми являются.
Вопрос недоверия стоит очень остро. Человек не может доверять тому, что он плохо понимает.
А автоматизацию зачастую понимают плохо.
"Динамо-машина" автоматизации постепенно набирает свой ход - нашим менеджерам просто нужно дать немного времени для осознания плюсов автоматизации, а тем более плюсов автоматизации регрессии. Я уверен, что в каждой компании, в которой используется мануальное тестирование, к тестерам-автоматизаторам относятся как к "первопроходцам", у которых или получается - и автоматизацию начинают конкретно развивать на практике и задействовать в проектах, или не получается - и автоматизацию начинают рассматривать как что-то лишнее и такое, к чему еще не готовы. Т.е. все зависит от профессионализма и желания "первопроходцев".
так если просто ждать, то менеджеры будут еще очень долго понимать что это такое и не факт, что поймут, потому что им это не так интеренсно, как например считать бюджет.
а как, по твоему мнению, можно изменить недоверие к автоматизации?
а был ли у тебя опыт с "невыгодной автоматизацией"? если да, почему ее там начали?
Еще интересные факт, сколько людей не проводят регрессионное тестирование!
Уже насобиралось два человека.
Хотелось бы посмотреть на их проект и процессы.
где то б посмотреть примеры расчета окупаемости процессов тестироная.Например сколько денег пойдет на менуал а сколько на автоматизацию…
Если регрессионное тестирование проводится вручную, то тогда ещё один вопрос - а насколько часто оно проводится? И насколько такое тестирование обширно, какую область продукта оно затрагивает?
Ведь далеко не вседа заказчик хочет тратить деньги и время на полноценный регрешн. Что скажите?
На нашем проекте сразу была сделана ставка на автоматизацию. Конечно, тестирование осуществлялось и вручную, но что касается регрессии, то ее исключительно получали автоматически. Не скажу, что наш уровень автоматизации самый превосходный, он далек от совершенства. Например, не удается внедрить модульное тестирование и регрессию на уровне сборок.
Пока мы осуществляем скажем так "бизнес" регрессионное тестирование. В настоящее время у нас более 700 тестовых процедур, которые при одном прогоне занимают более суток. Для обеспечение своевременного получения результата действуем так:
каждая машина (хост) разбита на два стенда - один физический - сам хост, другой на виртуальной машине. Эмпирически подобрали, что для наших целей подходит конфигурация:
- два независимых диск, каждый стенд на отдельном диске
- не менее 4 гигабайт памяти
- минимум два процессора
В результате прогон занимает примерно 12 часов, надо сказать, что мощность машины имеет значение, 4-х ядерный процессор дает прирост в 30% и более производительности.
Подобная система тестовых процедур изготавливалась примерно 3 года с тремя серьезными (процентов на 60%) переделками общей архитектуры. Разработкой тестов занимаемся весьма профессионально.
Сейчас совершенно не представляю как можно было бы обеспечивать такой уровень проверки, без автоматизации. Тут либо никакой регрессии не получали, либо нужно было бы нанимать целый полк тестировщиков.
Однако недостатки автоматизации очевидны:
- сложность разработки и поддержки
- требования к тестировщику практически как к программисту
- регрессионные тесты имеют особенность стремительно разрастаться, что увеличивает затраты на поддержку
- автоматизированные тесты нуждаются в постоянном рефакторинге и переделке, иначе теряют свою тестовую силу
- к сожалению не удается эту систему тестов отчуждать
Видно, что у Вас серьейзный подход к автоматизации, не то что у некоторых, например у моей компании. И не знаю плакать от этого или смеяться (( ))
Там, где это было изначально невыгодно, мы просто автоматизацию не начинали :-)
Ответ очень прост и очевиден.
Нужно чтобы менеджмент понимал автоматизацию.
И за этим стоит целый комплекс усилий и действий. На прошлом проекте мне повезло. Во первых сам наш менеджер команды автоматизации был автором крутого фреймворка на базе SilkTest. Все наши изменения, идеи и код проходили через него, и поэтому он был в курсе всего.
С другой стороны, у него всегда была возможность подойти ко всем заинтересованным людям со стороны заказчика и разъяснить, что происходит и почему автоматизации можно доверять.
Но, на разных проектах почва для автоматизации не настолько благотворна и приходится вкладывать массу усилий для того, чтобы люди на проекте сначала начинали понимать автоматизацию, а потом, возможно, ей доверять.
Я с недавнего времени перешел на новый проект, в котором реально по-умному построена связь девелопер-тестер: изначально при разработке продукта девелоперам было дано задание абсолютно каждому элементу на странице присваивать айдишник (учитывая то, что это пригодится всем, главное - автоматизаторам). Исходя из этого, тестер-автоматизатор уже не копается в поисках локатора, а все элементы "на виду" - Page Objects Pattern в таких условиях применять просто "сам Бог велел". Авто-тесты в таких условиях пишутся быстро и ненавязчиво. Регрессия тестов экономит кучу времени. Я как вспомню старые проекты, где из локаторов можно было воспользоваться разве что XPath'ом, причем он все время динамично изменялся - это был ужас! Так что побольше бы таких девелоперов и проект-менеджеров, и было бы намного легче!