Сообщений в теме: 24

[Alekssh1ft]

Всем привет!

Пишу письмо руководителю, с целью привлечь внимание к проблемам тестирования и автоматизации.

Подскажите, может у кого был опыт.

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

Может есть какая статья на эту тему?

Буду благодарен за любую инфу.

Спасибо!

 

[Freiman]

Привет!

А в чем заключаются ваши проблемы тестирования и автоматизации?

Что вы хотите автоматизировать? Для чего?

Можете ли вы "на пальцах" показать эффект от автоматизации?

 

Зачем все это? Чтобы вы сами были уверены, что автоматизация вам нужна.

[Alekssh1ft]

Привет!

А в чем заключаются ваши проблемы тестирования и автоматизации?

Что вы хотите автоматизировать? Для чего?

Можете ли вы "на пальцах" показать эффект от автоматизации?

 

Зачем все это? Чтобы вы сами были уверены, что автоматизация вам нужна.

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

[SALar]

Всем привет!

Пишу письмо руководителю, с целью привлечь внимание к проблемам тестирования и автоматизации.

Подскажите, может у кого был опыт.

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

Может есть какая статья на эту тему?

Буду благодарен за любую инфу.

Спасибо!

Да, есть. Буду делать доклад на конференции SQADays-18.

[SALar]

 

 

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

 

Если у вас проблема в ресурсах, то автоматизация тестирования только ухудшит положение.

[Alekssh1ft]

 

 

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

 

Если у вас проблема в ресурсах, то автоматизация тестирования только ухудшит положение.

 

Планируется увеличение штата под это дело, обосновать бы

[Freiman]

 

 

 

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

 

Если у вас проблема в ресурсах, то автоматизация тестирования только ухудшит положение.

 

Планируется увеличение штата под это дело, обосновать бы

 

И сроки еще затянутся

[barancev]

Затраты на автоматизацию расчитываются точно так же, как затраты на любую другую деятельность -- на основании предыдущего опыта собирается некоторая статистика, после чего новая задача оценивается по объёму и сложности относительно этих ранее выполненных задач (сравнивается с ними, на глазок), и на основании этого методом угадывания делаются некоторые предсказания. При этом степень точности угадывания зависит опять таки от опыта предыдущих аналогичных предсказаний.

 

Соответственно, если опыта предыдущего нет -- любая формула, сколь угодно хорошая, даст такую ужасную погрешность, что лучше просто крутнуть колесо рулетки.

 

Откуда взять опыт, хотя бы минимальный? Вариантов несколько:

 

1) Сделать пилотный проект, без обещаний и ожиданий относительтно результатов. Главное, что он даст -- опыт, основания для последующих предсказаний.

 

2) Нанять специалиста, который уже имеет опыт. Можно в штат (для постоянной работы), можно консультанта (на короткое время, чтобы стартовать).

Да, его опыт накоплен в другой компании, с другими продуктами -- это, конечно, увеличит погрешность, но всё равно это лучше, чем ничего. И тогда это будет его задача -- ответить на поставленный вопрос.

 

Если решите прорываться самостоятельно -- учитывайте, что затраты на автоматизацию будут включать в себя также и затраты на набивание шишек, то есть на неудачные попытки.

 

Почитайте для начала, например, историю покорения Южного Полюса :)

 

А если ближе к теме -- во-первых, рекомендую посмотреть вот этот мой спич про формирование стратегии автоматизации.

 

А во-вторых, приходите на тренинг Организация автоматизации тестирования, поможем избежать некоторых типовых граблей.

[Alekssh1ft]

Затраты на автоматизацию расчитываются точно так же, как затраты на любую другую деятельность -- на основании предыдущего опыта собирается некоторая статистика, после чего новая задача оценивается по объёму и сложности относительно этих ранее выполненных задач (сравнивается с ними, на глазок), и на основании этого методом угадывания делаются некоторые предсказания. При этом степень точности угадывания зависит опять таки от опыта предыдущих аналогичных предсказаний.

 

Соответственно, если опыта предыдущего нет -- любая формула, сколь угодно хорошая, даст такую ужасную погрешность, что лучше просто крутнуть колесо рулетки.

 

Откуда взять опыт, хотя бы минимальный? Вариантов несколько:

 

1) Сделать пилотный проект, без обещаний и ожиданий относительтно результатов. Главное, что он даст -- опыт, основания для последующих предсказаний.

 

2) Нанять специалиста, который уже имеет опыт. Можно в штат (для постоянной работы), можно консультанта (на короткое время, чтобы стартовать).

Да, его опыт накоплен в другой компании, с другими продуктами -- это, конечно, увеличит погрешность, но всё равно это лучше, чем ничего. И тогда это будет его задача -- ответить на поставленный вопрос.

 

Если решите прорываться самостоятельно -- учитывайте, что затраты на автоматизацию будут включать в себя также и затраты на набивание шишек, то есть на неудачные попытки.

 

Почитайте для начала, например, историю покорения Южного Полюса :)

 

А если ближе к теме -- во-первых, рекомендую посмотреть вот этот мой спич про формирование стратегии автоматизации.

 

А во-вторых, приходите на тренинг Организация автоматизации тестирования, поможем избежать некоторых типовых граблей.

Алексей, благодарю за конструктив, буду просвещаться! 

[TatyanaV]

 

Привет!

А в чем заключаются ваши проблемы тестирования и автоматизации?

Что вы хотите автоматизировать? Для чего?

Можете ли вы "на пальцах" показать эффект от автоматизации?

 

Зачем все это? Чтобы вы сами были уверены, что автоматизация вам нужна.

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

 

Если касательно аргументации - одним из аргументов может быть то, что однажды написанный регрессионный тест можно запускать:

а) регулярно.

б) в нерабочее время (например, на ночь и/или на выходные).

При этом:

1) один раз написав основу (модель данных, описание страниц, хелперы) можно ощутимо быстрее реализовывать новые тесты уже автоматизированных процессов.

2) тестировщики параллельно с запущенными тестами могут заниматься дальнейшим тестированием функционала (если скрипт бегает в рабочее время).

Да, на разработку - нужно много времени. Зато потом готовый тест - просто бесценен.

[Freiman]

1) один раз написав основу (модель данных, описание страниц, хелперы) можно ощутимо быстрее реализовывать новые тесты уже автоматизированных процессов.
2) тестировщики параллельно с запущенными тестами могут заниматься дальнейшим тестированием функционала (если скрипт бегает в рабочее время).
Да, на разработку - нужно много времени. Зато потом готовый тест - просто бесценен.

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

Как долго выполняются автотесты?
Какая инфраструктура нужна для автотестов?

[SALar]

Если касательно аргументации - одним из аргументов может быть то, что однажды написанный регрессионный тест можно запускать:

а) регулярно.

б) в нерабочее время (например, на ночь и/или на выходные).

При этом:

1) один раз написав основу (модель данных, описание страниц, хелперы) можно ощутимо быстрее реализовывать новые тесты уже автоматизированных процессов.

2) тестировщики параллельно с запущенными тестами могут заниматься дальнейшим тестированием функционала (если скрипт бегает в рабочее время).

Да, на разработку - нужно много времени. Зато потом готовый тест - просто бесценен.

 

Не трассируется на бизнес требования. С высокой вероятностью, это просто сотрясение воздуха.

[SALar]

http://blog.shumoos.com/archives/296

[TatyanaV]

 

1) один раз написав основу (модель данных, описание страниц, хелперы) можно ощутимо быстрее реализовывать новые тесты уже автоматизированных процессов.
2) тестировщики параллельно с запущенными тестами могут заниматься дальнейшим тестированием функционала (если скрипт бегает в рабочее время).
Да, на разработку - нужно много времени. Зато потом готовый тест - просто бесценен.

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

Как долго выполняются автотесты?
Какая инфраструктура нужна для автотестов?

 

 

1. У меня - нисколько :).

У меня есть метод prepareData в общем для всех классе, от которого наследующся все тесты. Изначально объекты создаются уже заполненные рандомными правильными данными. Условно "new Client" будет означать, что у него УЖЕ есть правильное ФИО, ДР, паспорт и прочее.

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

"prepareData(Conditions.withBadPassport())".

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

А дальше - регрессионный тест пишется ОДИН раз и в дальнейшем - просто запускается "как есть". Данные подберутся самостоятельно, если это требуется.

Время - в зависимости от степени сложности. Если логика (с точки зрения бизнес-процесса) легка и понятна - от 5 до 30 мин + тестовый прогон, чтобы убедиться, что все работает. Сложные, либо относящиеся к тому, что я ещё не автоматизировала - сложно сказать. По этой схеме автоматизация новых разделом уже доведена до универсальности и автоматизма и больше зависит от количества объектов и скорости печати.

 

2. Зависит от теста. Чем больше тест, тем больше времени на анализ. В идеале ~1-2 часа максимум. И то, большая часть - на то, чтобы сделать отчет, который нужен по результатам теста. Кстати, может быть и его как-нибудь сделаю автоматически.

 

3. 15 мин на проверку наличия нужных операторов, нужных прав доступа, некоторых специфических настроек. Все это - также можно сделать скриптом, поэтому и этот процесс вероятно автоматизирую чуть позже. Поддержка из-за обновления самого приложения - не требуется. Исключение - новые доработки, которые могут менять структуру БД, либо страниц. Но это - как раз то, что и надо протестировать :).

Сам скрипт, при этом, такие вещи также "обходит" сам. Можно запустить его на окружении с последней версией с новой структурой, а потом его же на более ранней версии - скрипт все равно отработает, т.к. будет знать, что версия другая.

 

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

 

"Инфраструктура" - машина, на которой находится и запускается сам тест + любое тестовое окружение, на котором необходимо эти тесты запустить.

[Freiman]

Татьяна, еще к вам вопросы:
1. Как часто тесты находят проблемы?
2. Как часто тесты не находят проблемы?
3. Насколько критичные проблемы были найдены/не найдены вашими тестами?

[TatyanaV]

В идеале - проблемы не находятся, на то они и регрессионные, чтобы проверять то, что и не должно было сломаться.

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

 

 

В плане критичности, есть две основные возможные проблемы:

1. Тест не прошел, т.к. не появились положенные элементы (например, должна появиться какая либо ссылка, на которую скрипт нажимает, но её нет). (тут есть вариант, что я не донастроила какие-либо права своему пользователю, поэтому и хочу это автоматизировать)

2. Тест прошел, но итоговый результат не соответствует ожидаемому.

 

И то, и то перепроверяю вручную.

Первое - серьезная ошибка т.к. не позволяет системе работать в рамках определенной бизнесом логики. Может быть критичной, если из-за нее в принципе невозможен какой-либо ключевой процесс.

Второе - в любом случае критичная проблема, т.к. с точки зрения пользователя все работает корректно, ошибка визуально не видна и может привести к серьезным проблемам.

[TatyanaV]

 

Если касательно аргументации - одним из аргументов может быть то, что однажды написанный регрессионный тест можно запускать:

а) регулярно.

б) в нерабочее время (например, на ночь и/или на выходные).

При этом:

1) один раз написав основу (модель данных, описание страниц, хелперы) можно ощутимо быстрее реализовывать новые тесты уже автоматизированных процессов.

2) тестировщики параллельно с запущенными тестами могут заниматься дальнейшим тестированием функционала (если скрипт бегает в рабочее время).

Да, на разработку - нужно много времени. Зато потом готовый тест - просто бесценен.

 

Не трассируется на бизнес требования. С высокой вероятностью, это просто сотрясение воздуха.

 

Я говорю про то - что у меня реально и успешно работает. Причем не на простеньких тестах "залогиниться правильными данными, поискать слово в гугле". А на серьезных регрессионных тестах, которые весьма критичны с точки зрения бизнеса.

[Freiman]

В идеале - проблемы не находятся, на то они и регрессионные, чтобы проверять то, что и не должно было сломаться.

Судя по всему, ваши тесты чаще падают из-за проблем взаимодействия с GUI, нежели из-за реальных ошибок. А каждый запуск отнимает у вас до 2 часов времени.

В общем, реальная польза от автоматизации есть? :)

А на серьезных регрессионных тестах, которые весьма критичны с точки зрения бизнеса.

Извините, я не улавливаю связь регрессионных тестов и бизнеса.

[TatyanaV]

 

В идеале - проблемы не находятся, на то они и регрессионные, чтобы проверять то, что и не должно было сломаться.

Судя по всему, ваши тесты чаще падают из-за проблем взаимодействия с GUI, нежели из-за реальных ошибок. А каждый запуск отнимает у вас до 2 часов времени.

В общем, реальная польза от автоматизации есть? :)

А на серьезных регрессионных тестах, которые весьма критичны с точки зрения бизнеса.

Извините, я не улавливаю связь регрессионных тестов и бизнеса.

 

Под запуском я подразумеваю не запуск одного отдельного теста на несколько часов. А запуск нескольких наборов тестов. В каждом из них - несколько десятков отдельных тестов. Падение одного из них - не мешает отработать остальным. Соответственно перезапуск одного упавшего - минут 10.

Реальная польза есть и ещё какая. Вручную то, что смотрят эти скрипты - можно и неделю-полторы проверять. 

 

Я работаю в банке. Автоматизация о которой я говорю, проверяет критичный для бизнеса функционал. Даже если доработки не относятся к этому функционалу - его работоспособность в любом случае перепроверяется и находится на особом контроле.

 

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

[Alekssh1ft]

 

 

В идеале - проблемы не находятся, на то они и регрессионные, чтобы проверять то, что и не должно было сломаться.

Судя по всему, ваши тесты чаще падают из-за проблем взаимодействия с GUI, нежели из-за реальных ошибок. А каждый запуск отнимает у вас до 2 часов времени.

В общем, реальная польза от автоматизации есть? :)

А на серьезных регрессионных тестах, которые весьма критичны с точки зрения бизнеса.

Извините, я не улавливаю связь регрессионных тестов и бизнеса.

 

Под запуском я подразумеваю не запуск одного отдельного теста на несколько часов. А запуск нескольких наборов тестов. В каждом из них - несколько десятков отдельных тестов. Падение одного из них - не мешает отработать остальным. Соответственно перезапуск одного упавшего - минут 10.

Реальная польза есть и ещё какая. Вручную то, что смотрят эти скрипты - можно и неделю-полторы проверять. 

 

Я работаю в банке. Автоматизация о которой я говорю, проверяет критичный для бизнеса функционал. Даже если доработки не относятся к этому функционалу - его работоспособность в любом случае перепроверяется и находится на особом контроле.

 

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

 

Блин, круто что у Вас всё так слаженно работает, как долго пришлось писать такой функционал?