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

[Darkus]

Позвольте внести свои 3 копейки.
Меня часто удивляет такой момент. Почему, когда говорим об автоматизации тестирования, то подразумеваем сразу тестирование GUI? Тестирование GUI - это один из завершающих этапов. По собственному опыту могу сказать, что проводя такое тестирование с целью найти ошибки в ядре - это большая ошибка! Тесты на GUI должны быть предназначены именно для ошибок интерфейса.
Тестирование нужно начинать с ядра, где как минимум должен быть некий API, через который можно достучаться до функций ядра и писать такие тесты должны люди с высокой квалификацией. Вот это будет действительно автоматизированные тесты, которые не дадут вылезти наружу (по крайней мере, существенно снизят риск) серъёзным багам.
А говорить, что вот у нас было ручное тестирование (читаем - кликали по кнопкам), а сейчас хотим ввести автоматизированное(читаем - программа будет кликать по кнопкам) и ожидать чуда... хм...
Ну даже если вы решили что-то автоматизировать в области GUI, то прежде всего посмотрите, какие тесты убивают больше всего времени и где сложнее всего отследить баги (скажем оттестировать функцию поиска вручную на большом количестве данных - адская ручная работа).
С остальными доводами касаемых времени, денег и т.п. полностью согласен.

[KaNoN]

Позвольте внести свои 3 копейки.
Меня часто удивляет такой момент. Почему, когда говорим об автоматизации тестирования, то подразумеваем сразу тестирование GUI? Тестирование GUI - это один из завершающих этапов. По собственному опыту могу сказать, что проводя такое тестирование с целью найти ошибки в ядре - это большая ошибка! Тесты на GUI должны быть предназначены именно для ошибок интерфейса.
Тестирование нужно начинать с ядра, где как минимум должен быть некий API, через который можно достучаться до функций ядра и писать такие тесты должны люди с высокой квалификацией. Вот это будет действительно автоматизированные тесты, которые не дадут вылезти наружу (по крайней мере, существенно снизят риск) серъёзным багам.

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

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

А кто чуда ожидает? Автоматизация функционалки как минимум просто ускоряет выполнение тестирования. Как минимум здесь выгода. И вот еще интересно, чем тогда хуже автоматизировать то, что сейчас руками делается, если при ручном тестировании выявляются те же баги, при этом за счет большего задействования ресурсов (на этапе выполнения). Если на то пошло, то зачем тогда такое высокоуровневое тестирование проводить, если нет более низкоуровневого, на уровне кода (ну это продолжая вашу логику)? Вам не кажется, что подобные виды тестирования могут устанавливаться параллельно, как раз за счет того, что за разные виды тестирования отвечают разные отделы.

[Darkus]

Если на то пошло, то зачем тогда такое высокоуровневое тестирование проводить, если нет более низкоуровневого, на уровне кода (ну это продолжая вашу логику)?

Вот, вот. Процесс лучше сразу ставить по-нормальному.

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

А вы реально видели, чтобы интерфейс писался параллельно ядру? Я пока ещё нет.
Другое дело, что с определённого момента можно начинать писать требования на интерфейс и по требованиям писать тест-кейсы.
И когда более менее "устаканится" ядро, то можно писать тесты по тест-кейсам на интерфейс.
Это очень гуд, когда несколько отделов и отдел тестирования интерфейса есть, как самостоятельная единица (туда же юзабилити).
Но реалии таковы, что вначале вылизываем функциональность, а потом думаем о "мордочке".
...
В общем хотел уточнить, что под автоматизированными тестами не нужно понимать только и в первую очередь тестирование GUI.

[Case]

Начать автоматизацию тестирования вы должны с ответов на два вопроса...

100%!
Читая RSS так и подумал, что это кто-то из аксакалов отвечает, зашёл проверить, вдруг ещё какая-то звезда на нашем небосклоне зажглась.

[Case]

А вы реально видели, чтобы интерфейс писался параллельно ядру?

По всякому на самом деле бывает. Бывало что писали базовые функции и логику + выводили наружу хвосты чтобы всё можно было согласно спецификациям дёргать, а Вендор на этой основе несколько разных UI прикручивал под совершенно разные задачи для разных своих Клиентов.

[Case]

И использовать автоматизацию уже в процессе разработки ПО, когда есть сроки и ресурсы - нецелесообразно.

Соглашусь в целом + добавлю от себя. Внедрение практик автоматизированного тестирования наиболее целесообразно проводить на уровне компании или подразделения в целом с выделением соотв. рабочей группы, а не на уровне одного проекта, если, конечно, проект не вечный и в нём не работает человека 4-5 только над автоматизацией, к примеру.

[KaNoN]

Если на то пошло, то зачем тогда такое высокоуровневое тестирование проводить, если нет более низкоуровневого, на уровне кода (ну это продолжая вашу логику)?

Вот, вот. Процесс лучше сразу ставить по-нормальному.

То есть, если вы не используете юнит тесты, то тогда вы не тестируете продукт вообще? Лучше ждать, пока все поставится нормально, а до этого времени сдавать заказчику неоттестированный продукт? Я к тому, что хотя бы на каком-то уровне можно проверять функционал отдельно (в частности на уровне ГУИ). Особенно это характерно для небольших продуктов, которые проверяются только вручную и на самом верхнем уровне (это был просто пример. Естественно для таких проектов автоматизация невыгодна).

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

А вы реально видели, чтобы интерфейс писался параллельно ядру? Я пока ещё нет.

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

Другое дело, что с определённого момента можно начинать писать требования на интерфейс и по требованиям писать тест-кейсы.
И когда более менее "устаканится" ядро, то можно писать тесты по тест-кейсам на интерфейс.

Тесты на интерфейс можно писать уже когда устаканится интерфейс. Причем даже запускать их стоит уже на этом этапе (будут ловить баги, пока ядро не устаканится и не будет отлажено).

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

Под отделом тестирования я подразумеваю отдел тестирования, в котором люди не работают с исходным кодом программы, а скорее на уровне конечного пользователя (наиболее распространенное представление о тестировании), то есть не отдельно интерфейс, юзабилити и функционал (его внешнее проявление) т.п. Соответственно, таким людям незачем раздумывать над тестированием на уровне API, это не их задача. И всё это "надувание щек" с юнит-тестами и т.п. - это просто в данном случае лишний повод поумничать, но не более. Так что не этим людям надо "отвечать на 2 или более вопросов", а кому-то повыше, если он хочет автоматизировать тестирование все и полностью. В данном же случае есть проблема спрыгнуть с ручного тестирования на автоматическое во вполне конкретной сфере тестирования, как минимум для того, чтобы ускорить этот процесс.

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

Естественно, но ведь нужно рассматривать и контекст.

[Darkus]

По всякому на самом деле бывает. Бывало что писали базовые функции и логику + выводили наружу хвосты чтобы всё можно было согласно спецификациям дёргать, а Вендор на этой основе несколько разных UI прикручивал под совершенно разные задачи для разных своих Клиентов.

Если по другому не получается, то можно, конечно, вывести сразу функционал наружу. Суть была в том, что люди под автоматизированными тестами почему то сразу думают, что это кликанье тулами по кнопкам ... и побольше, чтобы получить ошибки ядра.
А под тестированием интерфейса я имею ввиду, что кнопочки правильно и удобно расположены, в нужном порядке.
Что нажатие на кнопочку вызовет именно то, что ожидается от неё... ну в общем тестирование именно того слоя, что лежит между готовым оттестированным "снизу" решением и "мордочкой".

[SALar]

Начну с цитат из другого источника.

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

ИТ — это путь обмана. Если решение стоит тысячу — покажи, что оно стоит десять. Если требуется срок в два месяца — покажи двадцать. Если требуется возить кирпичи — построй подводную лодку. Если нужен калькулятор — начни проект с блока искусственного интеллекта. Если заказчик хочет продавать воздух — построй ему компрессорную станцию на термоядерном синтезе..
Горе тому, кто обманулся.

Автор: WildHare

1-й Закон Автоматизации:
Автоматизация не цель в себе, а средство существования.

2-й Закон Автоматизации
Автоматизация понятие условное, неоднозначное, непрозрачное и непонятное, но величественное.

3-й Закон Автоматизации
Автоматизация процесс непрерывный, постоянный, а поэтому вялотекущий.

4-й Закон Автоматизации
Зарплата разработчика от объема и количества выполненных работ не зависит и является величиной номинальной и неизменной.

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

6-й Закон Автоматизации
Разработчик проекта самый главный человек на момент пуска и до его окончания, после чего снова превращается в ничто и может быть ошельмован, независимо от работоспособности системы.

7-й Закон Автоматизации
Самый незначительный и дешевый этап автоматизации разработка программного обеспечения.

8-й Закон Автоматизации
Цена проекта никак не связана с его технической сложностью

9-й Закон Автоматизации
Дешевизна системы приравнивается заказчиком к качеству системы.

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

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

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

Мне этот текст достался в изложении Ruslan Petrenko

Внедрении автоматизированного тестирование через GUI, как правило, приводит к увеличению времени и стоимости проекта и к ухудшению качества конечного продукта. Не пытайтесь найти здесь нелогичность. Помните, что работа в IT это кооперативная игра, у участников которой разные интересы. Ну, например:
* У вендора - интерес продать
* У тестировщика - интерес увеличить свою стоимость на рынке
* У менедчера по закупкам - получить откат
* У генерального - чтоб от него отвязались (смотри "Записки доброго автоматизатора")
Как видим, у всех участников есть интерес во внедрении автоматизации. А то, что продукт получится дороже и хуже, интересует только конечного заказчика. Но он никакого влияния на внедрение автоматизации оказать не может.

Конечно бывает и по другому. Но для того, чтобы сделать это по-другому нужно пройти еще несколько этапов (не считая внедрения других видов автоматизированного тестирования). В хорошей фирме это займет 3-5 лет. В плохой фирме внедрение QTP, Robot, TestComplet и иже с ними почти всегда будут убыточны.

Автоматизация функционалки как минимум просто ускоряет выполнение тестирования. Как минимум здесь выгода.

Это неверно. Это реклама производителей инструментов.

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

Это неважно, что разные отделы. Важно что ети задачи "немного" взаимосвязаны.

А вы реально видели, чтобы интерфейс писался параллельно ядру? Я пока ещё нет.
Другое дело, что с определённого момента можно начинать писать требования на интерфейс и по требованиям писать тест-кейсы.
И когда более менее "устаканится" ядро, то можно писать тесты по тест-кейсам на интерфейс.
Это очень гуд, когда несколько отделов и отдел тестирования интерфейса есть, как самостоятельная единица (туда же юзабилити).
Но реалии таковы, что вначале вылизываем функциональность, а потом думаем о "мордочке".
...
В общем хотел уточнить, что под автоматизированными тестами не нужно понимать только и в первую очередь тестирование GUI.

В принципе, я был свидетелем написания кода по хелпу. Скажу больше, известны случаи, когда сначала клали рельсы, потом клали шпалы и только потом делали насыпь (книга "Злые песни Гийома Дю Вентре"). Но это не очень хорошо .

[KaNoN]

Внедрении автоматизированного тестирование через GUI, как правило, приводит к увеличению времени и стоимости проекта и к ухудшению качества конечного продукта. Не пытайтесь найти здесь нелогичность. Помните, что работа в IT это кооперативная игра, у участников которой разные интересы. Ну, например:
* У вендора - интерес продать
* У тестировщика - интерес увеличить свою стоимость на рынке
* У менедчера по закупкам - получить откат
* У генерального - чтоб от него отвязались (смотри "Записки доброго автоматизатора")
Как видим, у всех участников есть интерес во внедрении автоматизации. А то, что продукт получится дороже и хуже, интересует только конечного заказчика. Но он никакого влияния на внедрение автоматизации оказать не может.

А в чем проявляется ухудшение качества за счет автоматизации некоторых процессов? Вы это просто продекларировали и ничем не подкрепили.
Затраты - да, возрастут. Особенно на раннем этапе, но чем качество-то снизится?

Конечно бывает и по другому. Но для того, чтобы сделать это по-другому нужно пройти еще несколько этапов (не считая внедрения других видов автоматизированного тестирования). В хорошей фирме это займет 3-5 лет. В плохой фирме внедрение QTP, Robot, TestComplet и иже с ними почти всегда будут убыточны.

Естественно, что внедрение любого средства нужно делать с умом.

Автоматизация функционалки как минимум просто ускоряет выполнение тестирования. Как минимум здесь выгода.

Это неверно. Это реклама производителей инструментов.

Если время на тестирование снизилось с 14 дней до 2-х (реальные цифры с одного из наших проектов), то ускорения выполнения тестирования не произошло? И по расчетам, автоматизация окупила затраты по внедрению за 6-9 месяцев (если сравнивать, что все это время проводить ручное тестирование), а продукт сам уже порядка 10 лет на рынке. И все вроде бы зашибись, а тут узнаю, что мне на самом деле это производители тулов прорекламировали. Прям Матрица какая-то.
А как же быть с такими видами тестирования, которые никак, кроме как програмными средствами и не провести? Тут сравнение даже с бесконечностью.

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

Это неважно, что разные отделы. Важно что ети задачи "немного" взаимосвязаны.

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

[Luceus]

Если время на тестирование снизилось с 14 дней до 2-х (реальные цифры с одного из наших проектов), то ускорения выполнения тестирования не произошло? И по расчетам, автоматизация окупила затраты по внедрению за 6-9 месяцев (если сравнивать, что все это время проводить ручное тестирование), а продукт сам уже порядка 10 лет на рынке. И все вроде бы зашибись, а тут узнаю, что мне на самом деле это производители тулов прорекламировали. Прям Матрица какая-то.

KaNoN, вы привели оценки времени, которые вы выиграли при прогоне тестов. Вы подсчитывали само время на проведение автоматизации некоторого функционала?

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

[KaNoN]

Если время на тестирование снизилось с 14 дней до 2-х (реальные цифры с одного из наших проектов), то ускорения выполнения тестирования не произошло? И по расчетам, автоматизация окупила затраты по внедрению за 6-9 месяцев (если сравнивать, что все это время проводить ручное тестирование), а продукт сам уже порядка 10 лет на рынке. И все вроде бы зашибись, а тут узнаю, что мне на самом деле это производители тулов прорекламировали. Прям Матрица какая-то.

KaNoN, вы привели оценки времени, которые вы выиграли при прогоне тестов. Вы подсчитывали само время на проведение автоматизации некоторого функционала?

А что не так с оценкой на время тестирования? Именно ради преимущества во время выполнения тестов и задумывается автоматизация подобного рода. А сама разработка скриптов с фреймворком заняла 3 месяца работы 3-х человек. Имея превосходство во времени выполнения 12 дней, затраты на постановку автоматизации окупаются достаточно быстро. Но изначальной посылкой было высказывание, что якобы автоматически тестирование осуществляется дольше, чем вручную. Вот я привел реальные цифры с одного из наших проектов, чтобы можно было сопоставить, что же реально быстрее. Если на то пошло, то и на постановку ручного тестирования тоже время надо. Конкретно для того проекта, для которого я привел цифры, на написание всех тест кейсов потребовалось полтора месяца (то есть в 2 раза меньше, чем на автоматизацию). То есть написание ручных тестов заняло в 2 раза меньше времени, но выполнение - в 7 раз больше. По-моему, в данном случае автоматизация куда более выигрышна.

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

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

[Luceus]

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

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

К тому же, как я понял, вы применили автоматизацию на продукте, который уже порядка 10 лет на рынке. Это очень правильно с вашей стороны. И фреймворк к месту.

[KaNoN]

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

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

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

К тому же, как я понял, вы применили автоматизацию на продукте, который уже порядка 10 лет на рынке. Это очень правильно с вашей стороны. И фреймворк к месту.

Фреймворк - он всегда к месту, особенно, когда проект уже не первый с данным средством автоматизации. Все равно найдутся участки кода да и просто решения, которые используются независимо от проекта. А конкретно по целесообразности применения автоматизации я бы скорее выделил такую величину, как период окупаемости автоматизации. То есть, например, у нас уже есть поставленное ручное тестирование, мы хотим его автоматизировать. Так вот, период окупаемости - это время, за которое затраты на внедрение и проведение автоматизированного тестирования сравняются с затратами на ручное тестирование, учитывая, что на этапе внедрения автоматизации ручное тестирование проводится. То есть, фактически сравниваются затраты при внедрении и использовании автоматизации и затраты на обычный процесс ручного тестирования. Это, собственно и позволяет решить, а выгодно ли нам автоматизировать. Если данный период окупаемости слишком велик (либо составляет значительную часть времени жизни продукта, либо не окупается за время жизни продукта), то автоматизация отбрасывается изначально.

У нас для таких расчетов есть определенная формула, она сыровата, но для создания оценок вполне может пригодиться

[Green]

Коллеги,

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


Иногда, некоторые представители нашего форума напоминают мне этих бухгалтеров.



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

Все!

Автоматизация позволяет решить только ТРЕТЬЮ задачу и частично ВТОРУЮ (но это экономически не оправдано - писать автотест для проведения разовой проверки).

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

Например,
запланировано 20 итераций. В каждой из них будет выполнен тест А. На его выполнение в среднем тратится 10 минут. Итого 200 минут. Если его автоматизация потребует менее 200 минут, то автоматизация ЭКОНОМИЧЕСКИ ОПРАВДАНА - значит автоматизация выгодна. Если же время на автоматизацию потребуется больше 200 минут, то необходимо выявить ДРУГИЕ выгоды. К примеру,
- создание пакета приемочных тестов, который будут передан заказчику (кстати, это может быть отдельным пунктом контракта со своим ресурсом - одним выстрелом двух зайцев),
- или планируемый объем регрессионных тестов "съест" все время, выделяемое на тестирование (сегодня - 100 тестов за 2 дня, через год - 5000 тестов, а есть всего лишь 10 дней),
- или автоматизация регрессионного тестирования позволит больше времени выделять на поиск новых дефектов (прогон регрессионного пакета из 1000 автотестов за 4 часа),
- или еще что-то другое...


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

Если суммарное время на запуск и анализ автотестов превышает время, необходимое на создание среды, то затраты ЭКОНОМИЧЕСКИ оправданы. Причем, в данном случае можно учитывать временные затраты по всем проектам компании и бюджет для этой задачи формировать на корпоративном уровне (а не на уровне проекта).

[KaNoN]

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

Все!

Автоматизация позволяет решить только ТРЕТЬЮ задачу и частично ВТОРУЮ (но это экономически не оправдано - писать автотест для проведения разовой проверки).

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

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

Если суммарное время на запуск и анализ автотестов превышает время, необходимое на создание среды, то затраты ЭКОНОМИЧЕСКИ оправданы. Причем, в данном случае можно учитывать временные затраты по всем проектам компании и бюджет для этой задачи формировать на корпоративном уровне (а не на уровне проекта).

Я под фреймворком подразумевал скорее совокупность API, которое будет использовано при разработке скриптов автоматизированного тестирования, частью которого также являются компоненты по выводу и предварительному анализу результатов. Такая вещь как раз очень важна, особенно учитывая, что автоматические скрипты расчитаны на многоразовое использование и maintenance просто неизбежен. В этом случае создание фреймворка экономически настолько же оправдано, насколько и сама автоматизация в целом. Хороший фреймворк сокращает время на maintenance кода. А если учесть, что стадия разработки фреймворка, на которой собственно говоря выполняется только эта задача, занимает 1-2 недели при нормальном подходе и наличии наработок, то необходимость создания фреймворка не стоит рассматривать отдельно от автоматизации.

[Green]

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

Все!

Автоматизация позволяет решить только ТРЕТЬЮ задачу и частично ВТОРУЮ (но это экономически не оправдано - писать автотест для проведения разовой проверки).

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

Вполне закономерный вопрос -
Что первично и что вторично в автоматизации?

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

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

Так что, для меня, в качестве главной задачи автоматизации тестирования - это проверка того, что "при устранении известных дефектов не были внесены новые баги (проверка целостности)." Цель номер 3.

Но!
Если при этом автотесты могут быть использованы для проверки профикшенных дефектов, то почему бы нет? Давайте их использовать и для этого.
Ничего не имею против.

[SALar]

Автоматизация функционалки как минимум просто ускоряет выполнение тестирования. Как минимум здесь выгода.

Это неверно. Это реклама производителей инструментов.

Если время на тестирование снизилось с 14 дней до 2-х (реальные цифры с одного из наших проектов), то ускорения выполнения тестирования не произошло?

Понятно. Вы имели время ввиду время одного прогона. Я же имел ввиду общее время тестирования.

[Green]

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

Если суммарное время на запуск и анализ автотестов превышает время, необходимое на создание среды, то затраты ЭКОНОМИЧЕСКИ оправданы. Причем, в данном случае можно учитывать временные затраты по всем проектам компании и бюджет для этой задачи формировать на корпоративном уровне (а не на уровне проекта).

Я под фреймворком подразумевал скорее совокупность API, которое будет использовано при разработке скриптов автоматизированного тестирования, частью которого также являются компоненты по выводу и предварительному анализу результатов. Такая вещь как раз очень важна, особенно учитывая, что автоматические скрипты расчитаны на многоразовое использование и maintenance просто неизбежен. В этом случае создание фреймворка экономически настолько же оправдано, насколько и сама автоматизация в целом. Хороший фреймворк сокращает время на maintenance кода. А если учесть, что стадия разработки фреймворка, на которой собственно говоря выполняется только эта задача, занимает 1-2 недели при нормальном подходе и наличии наработок, то необходимость создания фреймворка не стоит рассматривать отдельно от автоматизации.

Отличное дополнение! Полностью согласен.

Есть только одно замечание. Все, что требует финансирования и может быть решено отдельно - является отдельной задачей. Но, если в проекте используется автоматизация тестирования, то создание фреймворка - закономерная и логичная задача. В этом случае, ее можно рассматривать как следующую ступень автоматизации. (О чем я и говорил в своем докладе на РИТ2007. )

[SALar]

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

Например,
запланировано 20 итераций. В каждой из них будет выполнен тест А. На его выполнение в среднем тратится 10 минут. Итого 200 минут. Если его автоматизация потребует менее 200 минут, то автоматизация ЭКОНОМИЧЕСКИ ОПРАВДАНА - значит автоматизация выгодна.

Сергей, я с тобой почти согласен. В этот расчет нужно "всего лишь" добавить стоимость лицензий (очень недешевых), увеличение зарплаты тестеру занимающемуся автоматизацией

Бред естественно, но таковы перекося текущего рынка. Интересно, и почему это программистам, занимающимся генерацией кода из UML схем не платят больше, чем тем, кто пишет руками?

и прочие накладные расходы. Поправочный коэффициент будет 1.5-2. Ну и, естественно, добавить расходы на поддержание и/или расходы на тщательное проектирование.

Как говорил Mike: "в принципе в проектах бывает до 10% функциональных тестов которые можно автоматизировать". Я думаю, что эта цифра завышена.

Если же время на автоматизацию потребуется больше 200 минут, то необходимо выявить ДРУГИЕ выгоды. К примеру,
- создание пакета приемочных тестов, который будут передан заказчику (кстати, это может быть отдельным пунктом контракта со своим ресурсом - одним выстрелом двух зайцев),
- или планируемый объем регрессионных тестов "съест" все время, выделяемое на тестирование (сегодня - 100 тестов за 2 дня, через год - 5000 тестов, а есть всего лишь 10 дней),
- или автоматизация регрессионного тестирования позволит больше времени выделять на поиск новых дефектов (прогон регрессионного пакета из 1000 автотестов за 4 часа),
- или еще что-то другое...

А вот это в самую точку. И причины эти могут быть самыми разнообразными. Изредка обусловленные потребностями проекта. Но чаще всего, те, которые я указывал в предыдущих постах.