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

[galogenIt]

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

Проблематика:
Один проект, но разные текущие ветки-релизы (обычно тестируются одновременно 4 ветки, последняя trunk) + некоторые особые тестовые ситуации.
Время выпуска релиза колеблется от 1 до 2 месяцев.
Есть 6 тестировщиков (общая численность команды разработки 35).
Тестовая группа делится на две условные подгруппы: тест-программисты (3) - разработчики автоматизированных тестовых процедур, и тест-аналитики аля дизайнеры + руководитель (3). Тест-программисты иногда усиливаются руководителем в качестве тест-программиста.
Количество тестовых процедур от релиза к релизу увеличивается. Например в настоящее время на trunk - около 300 тестов.

Одной из задач тестовой группы разбор логов после прогона тестов (т.е. практически исследуются 4 разных лога). Количество проблем на рекомендованных релизах в целом не велико (не более 5 %).
На trunk этот процент гораздо больше - до 40-50%. Причины падения тестов можно разделить на:
1 - некий глюк системы автоматизации тестов (используется TestComplete)
2 - реальная ошибка в тестируемом приложении
3 - изменение интерфеса и алгоритмов работы тестируемого приложения
4 - некий глюк всей платформы интеграции

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

Однако со временем количество тестов будет увеличиваться и проблема нехватки времени и ресурсов только усугубляться

В связи с этим вопрос:
возникают ли у вас подобные ситуации?
как вы из решаете?
каким образом можно решить проблему охвата меньшим числом и без потери качества контроля?

СПАСИБО

[KaNoN]

1) Начните с инфраструктуры. Прикрутите какую-то систему, позволяющую управлять запусками, как всего набора тестов, так и какой-то под-группы. Как выделить подгруппы и какие - это тема отдельного разговора. Под управляющей системой я подразумеваю что-то типа Cruise Control, Hudson, Bamboo.

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

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

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

[Pryanik]

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

Вижу несколько решений данной проблемы:
1) Увеличивать число ресурсов(путем привлечения дополнительных тестировщиков авт тестов, увеличить время на регресс)
2) Привлечение программистов для анализа причин падения теста(в этом случае им предоставляется описание тестового сценария с ожидаемыми результатами)
3) Если некая часть системы часто изменяется, в результате чего причина падения теса/тестов 3(из вашего списка), то стоит убрать этот тест/тесты из списка регресса и проверять вручную (если это будет быстрее).
4) В продолжении пункта 3. Автоматизировать те тесты, которые относятся к "устаканившимся" частям системы редко и дают постоянные результаты.

[galogenIt]

1) Начните с инфраструктуры. Прикрутите какую-то систему, позволяющую управлять запусками, как всего набора тестов, так и какой-то под-группы. Как выделить подгруппы и какие - это тема отдельного разговора. Под управляющей системой я подразумеваю что-то типа Cruise Control, Hudson, Bamboo.

Да проблема управляющей системой есть. Я уже публиковал вопрос подобного содержания здесь. Мне ответил ДмитрийН с предложением рассмотреть SpiraTest. Мы решили написать свой инструмент.
Однако я не думаю, что он решит вопрос кардинально. Посмотрю на продукты предложенные вами. Спасибо...

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

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

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

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

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

На изменения интерфейса мы реагируем достаточно быстро, на изменение логики или алгортима сложнее. Беда еще в том, что свзяка ТС и наше тестируемое приложение часто глючит.

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

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

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

Вижу несколько решений данной проблемы:
1) Увеличивать число ресурсов(путем привлечения дополнительных тестировщиков авт тестов, увеличить время на регресс)

Руковдитель пока не склонен увеличивать штат, полагает что нас достаточно. Можно конечно перепрофилировать одного из тест-аналитиков в программисты, но тогда пострадает написание тестовых сценариев, исследователькое тестирование и т.п.
В связи с этим, как вы считатет, вообще оправдано ли делать ставку исключительно на автотестирование?

2) Привлечение программистов для анализа причин падения теста(в этом случае им предоставляется описание тестового сценария с ожидаемыми результатами)

Вообще когда падает тест по причине ошибки в системе, мы пишим работы в специальной программе. передаем ее менеджеру, который изучает проблему и переправляет ее программисту. Работа описывается по спец шаблону, где мы указывааем как повторить ошибку, какой результат получился и какой должен быть. Если нужно даем ссылку на testlink где у нас описана тестовая ситуация. Ну и конечно лично помогаем разобраться, если что...

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

А не перенесет это проблему с тест-программистов на тест-дизайнеров, которые отвечают за как раз ручное тестирование?

4) В продолжении пункта 3. Автоматизировать те тесты, которые относятся к "устаканившимся" частям системы редко и дают постоянные результаты.

Это по-моему не так интересно. Идея с системой управления кажется мне почти оптимальной. Не понятно почему ТС не озаботился наличием оной.
По крайне мере можно было бы исключать устойчивые тесты из регресса или проводить их эпизодически, выключать гибко тесты которые пдают по причине ошибко программы до их устранения.

[rlabs]

Честно говоря, не нашел в теме свидетельств того, что проблема у вас в большом количестве тестов. Это скорее последствия.

Тут можно много всяких спорных вещей наговорить, но лучше подумайте вот над чем: а нужна ли вам такая автоматизация? Какую пользу она приносит вам как тестировщику и команде в целом?

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

[galogenIt]

Честно говоря, не нашел в теме свидетельств того, что проблема у вас в большом количестве тестов. Это скорее последствия.

А в чем, по-Вашему, у нас проблема? У меня не очень большой опыт, поэтому я вполне могу заблуждаться в данном вопросе

Тут можно много всяких спорных вещей наговорить, но лучше подумайте вот над чем: а нужна ли вам такая автоматизация? Какую пользу она приносит вам как тестировщику и команде в целом?

Задача автоматизации была поставлена руководителе проекта изначально. Мы с ним тоже долго спорили по этому вопросу. По его мнению мы решили ту задачу, которая на нас возлагалась в момент организации группы. Сейчас приоритеты меняются.
Какую пользу мне это приносит? Польза большая - вручную я бы это все так последовательно протестировать не смог. Простой пример. У нас есть так называемые схемы поставок, они задают очень сложный алгоритм. Мы написали процедуру, которая
1. создает счет на поставку по заданной схеме
2. подключает дистрибутив в счет
3. создает документ подключения дистрибутива
4. создает договор на поставку
5. создает расходные документы по схеме
6. создает приходные кассовые или банковские ордера

Все эти действия проходят по всем схемам поставки (их не менее 10)

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

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

А что же такое автоматизация? Что и каким образом следует автоматизировать? Я понимаю экстенсивный путь дает временные улучшения.

Каковы тогда могли бы быть Ваши рекомендации?

[DrVal]

Я правильно понимаю, что в первую очередь хочется разобраться с этим?

А сколько ошибок в коде приложения обычно дают эти 40-50% фейлов?

Если ошибок мало, например один баг в коде дает 10% фейлов, то нужно ранжировать тесты.
Сделать BVT (build validation test), который позволит выявить блокеры.
И дальше гнать только не тесты, которые не заблокированы.
Если тесты зависимы (например, в одном данные генерятся, а в другом анализируются), но нужно вводить fail-over (например, данные из формы не попали в базу - тест пофейлился, но нужные данные пишем в базу скриптом).

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

Если фейлов много (т.е. между 2-мя сборками вносится много багов), то нужно чаще делать сборки и гонять билды.

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

Результаты текущего прогона сравниваются с результатами предыдущего? Это тоже должно экономить время на анализ.

В общем, скорее всего здесь ошибка в подходе - гоним все тесты, анализируем все результаты.

На trunk этот процент гораздо больше - до 40-50%.

[galogenIt]

Простите уважаемый DrVal, ничего не понял. Вы на каком языке? :)

А сколько ошибок в коде приложения обычно дают эти 40-50% фейлов?

фейл, это от английского fail?
Все бывает по-разному. Однако статистика показывает, что тесты падают, в результате какой-то одной ошибки.
Пример - в счете не выставился субъект учета - т.е. ошибка в том, что не сработало определенное бизнес-правило.
В результате часть тестов, которые могут зависеть от счета созданного в другом тесте, поваляться.
Все эти зависимости установить сложно, они часто меняются

Если ошибок мало, например один баг в коде дает 10% фейлов, то нужно ранжировать тесты.
Сделать BVT (build validation test), который позволит выявить блокеры.

А каким образом это делается?

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

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

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

Подобные проблемы у нас редки и выявляются сразу

Вы будете тратить время на анализ каждого фейла?

Если проблемы системного уровня, уровня соединения и т.п. - тесты просто сразу прекращаются

Если фейлов много (т.е. между 2-мя сборками вносится много багов), то нужно чаще делать сборки и гонять билды.

По сути так у нас и идет. У нас ЕЖЕДНЕВНЫЕ сборки. Ночью делаются прогоны. Прогоны идут параллельно на трех машинах. Логи присылаются и анализируются на одной или распределяются между тестировщиками каждое утро.

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

И еще совет, если есть проблемы с нестабильной работой инструмента, то с этим нужно разбиратьс в первую очередь.

Именно с этим мы и постоянно разбираемся. Слуюбу поддержки я, наверное, просто достал. Постепенно эти нестабильности уходят. Но некоторые проблемы все-таки остаются.
Пример - была задача тестировать вывод документов на принтер. Пришлось создать имитацию печати в файл. Тест разработали, проверили неоднократно, все узкие места сняли (казалось), но тест почти регулярно падает в чем пичина так и не понятно. Такие тесты просто снимаем и периодически прогоняем вручную
Однако бывают случая, когда снять нельзя и проблему устойчивости полностью снять не удается. Приме - есть унас задача автоматического биллинга, т.е. в ходе прогона задачи на определенный месяц делается заполнение регистров разных и потом формируются счета и другие документы. Так вот в этой задаче из-за особенностей реализации тестовго приложения и работы TestComplete возникает сбой Improper Command, он совершенно не приводит к падению теста, тест проходит. Это видно по связанным с ним тестам - они зеленые. Если поставить событие прерывание всей группы последующих тестов из-за возникшей ошибке - значит почти никогда не тестировать биллинг :) Поскольку мы это знаем и понимаем, то вкупе с предваряющим тестом смотрим и тесты дочерние и делаем вывод

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

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

Результаты текущего прогона сравниваются с результатами предыдущего? Это тоже должно экономить время на анализ.

Сравниваются. Но вручную. Делаем попытку сравнивать автоматически

В общем, скорее всего здесь ошибка в подходе - гоним все тесты, анализируем все результаты.

А какие есть альтернативы?

[rlabs]

А в чем, по-Вашему, у нас проблема? У меня не очень большой опыт, поэтому я вполне могу заблуждаться в данном вопросе

Повторюсь - проблема в представлении автоматизации как способе ускорить ручные тесты. И еще - в автоматизации ради автоматизации. В смутном представлении о целях и процессе тестирования вообще.

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

[DrVal]

Извините за сленг, я на нем думаю :-)

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

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

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

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

Если установть зависимость между тестами действительно сложно, то самое простое решение - разбейте свои 300 тестов на N сценариев.
Перед прогоном каждого нового сценария базу с необходимыми данными восстанавливайте из бэкапа.
Это должно снизить зависимость последующих тестов от предыдущих.
И обязательно нужно добавлять проверки, что pre-requirements для теста обеспечены (например, есть все необходимые счета).

У Вас 3 тестовых системы, возьмите одну сборку и прогоните на всех 3-х (скажем на выходных).
Если результаты будут отличаться, то значит тесты нестабильны.
Вынесите нестабильные тесты в одельный сценарий... и гоняйте его руками - возможно будет дешевле.

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

Простите уважаемый DrVal, ничего не понял. Вы на каком языке? :)
...
А какие есть альтернативы?

[ShortLegged]

Есть несколько вопросов:
1. Из 40-50%, сколько процентов реальных дефектов Вы находите, сколько процентов ложных срабатываний тестов?
2. Из найденных дефектов, сколько процентов относятся к новой функциональности, а сколько к регрессии?
3. Рассматривали ли Вы возможность использования более стабильных инструментов для отдельных этапов автоматизации?
4. По каким причинам Вы не успеваете за изменением алгоритмов и логики приложения? Недостаток ресурсов у Вас или несвоевременное предоставление информации разработчиками?
5. На сколько меньше времени занимает автоматизированное тестирование (прогон + анализ логов) нового/измененного функционала по сравнению с ручным тестировнием?

[galogenIt]

Повторюсь - проблема в представлении автоматизации как способе ускорить ручные тесты. И еще - в автоматизации ради автоматизации. В смутном представлении о целях и процессе тестирования вообще.

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

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

за ссылку спасибо.

И Кстати, Алексей, я вовсе не игнорирую Ваши советы. Думаю Вы правы и поповоду погрешностей в организации и автоматизации не туда. Но с другой стороны, Вы не знаете полноты картины, может и не так все у нас убого :)

[galogenIt]

Извините за сленг, я на нем думаю :-)

Придется к Вам привыкнуть:)

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

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

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

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

Если установть зависимость между тестами действительно сложно, то самое простое решение - разбейте свои 300 тестов на N сценариев.

Что значит разбить 300 тестов на N сценариев. Мы скорее поступаем наоборот. Или может у нас разное представление о сценарии и тесте.

Перед прогоном каждого нового сценария базу с необходимыми данными восстанавливайте из бэкапа.

Так у нас собственно и делается, если возникает сбой в тесте или это определено предусловием мы приводим базу к эталону. Т.е. у нас есть обновленная эталонная база относительно которой мы делаем проверку. У нас это называется ревизия + версия сборки сервера и версия сборки клиента. В Итоге мы проверяем некую заданную сборку и ревизию пакетов

Это должно снизить зависимость последующих тестов от предыдущих.

Да именно так мы и думаем. Значит мыслим верно:)

И обязательно нужно добавлять проверки, что pre-requirements для теста обеспечены (например, есть все необходимые счета).

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

У Вас 3 тестовых системы, возьмите одну сборку и прогоните на всех 3-х (скажем на выходных).

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

Вынесите нестабильные тесты в одельный сценарий... и гоняйте его руками - возможно будет дешевле.

Да в определенных моментах мы так и делаем. Например мы совершенно не тестируем автоматически создания графиков для сервисных инженеров

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

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

[galogenIt]

Есть несколько вопросов:
1. Из 40-50%, сколько процентов реальных дефектов Вы находите, сколько процентов ложных срабатываний тестов?

Вообще ответить довольно сложно. Как Вы понимаете, если в систему не вносить никаких изменений, то можно ожидать от нее вполне устойчивой ситуации, а следовательно положительного прохода всех тестов. Эта ситуацияя у нас работает в рекомендованных релизах. Поскольку и в них происходит изменение, нам приходится контролировать регрессию этих изменений. В этом случае тесты запрограммированный на выявление проблемы процентов на 95 ее решают.

Совершенно иная ситуация для trunk, т.е. выпуска, который находится в интенсивной разработке. Руководство требует от нас постоянного контроля, чтобы на раннем этапе выявлять проблемы программистов. Как раз эта ситуация и создает проблему, из-за которой я начал тему. Моя оценка примерно такая 50 на 50. Все правда зависит от того, что планируется сделать. Иногда это изменения и улучшения алгоритмов, добавление новых правил и функциональности без переделки интерфейсов, в этом случае процент реальных ошибко в этих 40-50% высокий, не менее 75%.
Если же релиз связан с изменениями интерфейса, то практически ошибко нет, есть проблемы тестов, которые нужно в темпе изменять. Этот риск понятен, ожидаем. Вопрос как его снизить, наверное именно в этом главная моя цеь. когда я начинал тему...

2. Из найденных дефектов, сколько процентов относятся к новой функциональности, а сколько к регрессии?

Пока такую статистику не ведем явно. Может тогда Вы подскажите какие имеет смысл показатели сразу оценивать?

3. Рассматривали ли Вы возможность использования более стабильных инструментов для отдельных этапов автоматизации?

Нет, мы используем Test Complete, покольку все наши тесты так или иначе связаны с GUI. Попытка перейти к режиму Open applications преимуществ на наш взгляд не дал, а проблем устойчивости увеличил. Да предпалагалось, что использование OpenApps позволит резко снизить зависимость от изменения интерфейса. Действительно к контролам можно было обращаться по их уникальным именам, а не только по именам классов и индексам. Однако производительность сразу снизилась раза в 4, трудоемкость отладки тоже. Да и были и остались проблемы компиляции...

4. По каким причинам Вы не успеваете за изменением алгоритмов и логики приложения? Недостаток ресурсов у Вас или несвоевременное предоставление информации разработчиками?

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

5. На сколько меньше времени занимает автоматизированное тестирование (прогон + анализ логов) нового/измененного функционала по сравнению с ручным тестировнием?

Думаю тут считать сложнее. Мы часто просто не успеваем подготовить новые тесты к моменту приемки нового релиза. Возможно виной и наши огрехи организации процесса, но в большей степени это сами программисты, которые практически выкладывают эти изменения в самый последний момент.
Потому мы придерживаемся такой стратегии:
1. в самом начале когда начинается работа над новым релизом, мы составляем план будущих изменений и новой функциональности
2. ранжируем ее по приоритету
3. активно изучаем, что же там будет (не всегда правда это удается сделать)
4. подготавливаем тестовые случаи, если возможно. тестовые данные для проверки и эталоны
5. готовим сценарии и чеклисты для ручной прогонки при приемке
6. после этого передаем сценарии на разработку (для обеспечения регрессии)
Как то так...

[rlabs]

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

Всё очень просто. С какой-то стороны.

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

Например, появляется новая функциональность в продукте. Пока вы её изучаете, ставите перед собой вопросы - а что, если? а допустим вот так? а нет ли здесь проблемы? - это тестирование. Когда есть набор понятных точек и условий соответствия - это уже проверки. Типа, "после нажатия кнопки Сохранить документ должен оказаться в БД". Когда есть проверки, в случае падения для них не требуется описание шагов, условий и тд - есть просто название проверки и её статус. Это уже проблема разработчика: сделать проверку из красной - зеленой. В этом очень помогают четкие и понятные названия тестов, например ПриСохраненииДокументаТипаАвФормеТипаБДокументДолженОказатьсяВТаблицеГ. Здесь нужно приложить немного усилий и разъяснить команде разработки, что ни вы, ни они не являются тупыми набивателями теста багов. Поддержание качества продукта - общая задача, и должна решаться эффективно, а не "по процессу". Когда тест уже придуман, проверка написана и данных достаточно - участие тестировщика не требуется.

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

Проблема изменения интерфейса решается повышением тестируемости самого продукта, например - созданием API, до которого можно добраться снаружи без тесткомплита. Предположим, у вас есть диалог, делающий что-то с документом, например, переводящий его из статуса А в статус Б. Эти статусы характеризуются определенными изменениями в БД. В хорошо написанном приложении кнопка "Ок" в диалоге с кучей параметров будет вызывать одну функцию, ОбработатьДокумент, с кучей параметров, которые вводятся в диалоге. При наличии API все, что нужно сделать - сгенерировать документ исходного статуса, подготовить набор параметров (тестовый случай), вызвать эту функцию и посмотреть, что изменилось в данных. А вот сам диалог лучше посмотреть руками, потому что с ним будет работать человек, и то, что для тестового автомата будет Ок (наличие определенного текста в определенном поле) - для человека будет проблемой (текст есть, но съехал куда-то, и прочитать/изменить его нельзя).

Короче говоря. Как правило, почти любое приложение, работающее с какими-то данными, можно представить в виде конечного автомата с кучей статусов. И в большинстве случаев приведение объекта в статус Z не требует прохождения всех предыдущих, с A до Y - достаточно просто сказать объекту, что у него все уже было. Поэтому все ваши "последовательные" сценарии можно запросто разбить на микротесты, работающие между парой состояний. При этом самих "тестов" (а точнее проверок) будет очень мало, много будет их запусков с разными параметрами. Соответственно, при любом изменении логики приложения, добавлении новых типов объектов, еще чего-то - вы изменяете либо один-два теста, либо набор их параметров.

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

Это один из подходов. Его, разумеется, надо адаптировать под себя.

[galogenIt]

Алексей, спасибо за подробные разъяснения.

Все, что Вы говорите действительно верно. И над этим я изначально работал. Однако пока эта самая разработка API - дело весьма проблематичная.

Вы правы, говоря, что у нас не тестирование, а проверка. Эта мысль до меня дошла окончательно:) Да я вижу, мы автоматизируем не тестирование, а именно проверку. Интересно, а можно ли тогда автоматизировать тестирование?

К дополнению к нашей ситуации. Анализ самой базы, может быть важен только в определенных случаях. Но сама архитектура нашего приложения не дает это сделать, как Вы говорите. Наша база хранит данные не только по бизнесу, но и данные по структуре программы: метаинформацию о классах и методах, конкретную информацию по объектам. Да наверное я могу как-то обратится к кнопке OK, но мне все равно потребуется инициализировать диалог. Кроме того изменение одних контролов влияет на характер и содержание изменения других, а выбор в них влияет на третие и т.п. Т.е. просто вызвав метод OK и я могу и не знать какие в данный момент параметру ему стоит передать, их еще возможно нужно получить- создать в ходе работы с интерфейсом.
Как быть в такой ситуации?

[airguru]

Посмотрите мои наработки по организации автоматизированного тестирования. Тоже тесткомплит. Вероятно что-то будет полезным.
http://anairguru.blo...stcomplete.html

[Pryanik]

galogenIt, коллега rlabs видимо вас совсем запутал. Вам правильно говорят, что автоматизация применяется когда от нее есть выгода, в частности регрессионное тестирование. Написал именно регрессионное тестирование, потому что ни в одной литературе я не видел термина регрессионные проверки. Хотя по сути регресс это и есть конечный набор проверок(чеков). Автоматическое тестирование в понимании Майкла Болтона невозможно, т.к. требует человеческих мозгов, разума.

[KaNoN]

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

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

Имеется ввиду, что можно весь этот конвеер настроить так, чтобы он выполнялся постоянно, 24 часа в сутки 7 дней в неделю. В результате, вы будете получать актуальные результаты регулярно и это дает возможность заранее среагировать на появление систематических ошибок. Оперативная реакция на результаты и методичное исправление практически всех, пусть даже мелких ошибок, связанных с реализацией тестов, через время (вопрос пары месяцев) приведет к тому, что % ложных ошибок сведется к показателям 2-3% от всего объема тестов. По-крайней мере у меня так произошло, когда я подправлял тесты, даже, если там приложение просто протормаживало. В результате, После прогона порядка 300 тестов (это только на моем направлении столько) общей длительностью 48 часов, мне надо было по сути просмотреть 4-5 тестов, которые упали по неизвестным мне причинам.

[galogenIt]

Посмотрите мои наработки по организации автоматизированного тестирования. Тоже тесткомплит. Вероятно что-то будет полезным.
http://anairguru.blo...stcomplete.html

Спасибо большое. Очень интересный блог
Надо сказать, что мы во многом делаем также. Ясно, что тут действует нормальный здравый смысл. Единственно, не всегда удается сделать человеко-понятные сообщения о проблемах. Но в большинстве случаев мы стараемся их сделать. Правда иногда от этого мало проку. В частности, если возникает сообщение об ошибке в самой системе, мы его перехватываем и выводим в лог. Иногда это сообщение хотя оно написано и по-руски, не всегда сразу понятно.

galogenIt, коллега rlabs видимо вас совсем запутал. Вам правильно говорят, что автоматизация применяется когда от нее есть выгода, в частности регрессионное тестирование. Написал именно регрессионное тестирование, потому что ни в одной литературе я не видел термина регрессионные проверки. Хотя по сути регресс это и есть конечный набор проверок(чеков). Автоматическое тестирование в понимании Майкла Болтона невозможно, т.к. требует человеческих мозгов, разума.

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

Ну я понимаю что автоматизация применяется тогда, когда есть выгода. Эту выгоды мы понимаем и чувствуем. Проблема же во все возрастающем числе таких вот провероки как я ними справляться. Рекомендации я услышал, они не идеальны, но интересны. Будем работать

Имеется ввиду, что можно весь этот конвеер настроить так, чтобы он выполнялся постоянно, 24 часа в сутки 7 дней в неделю. В результате, вы будете получать актуальные результаты регулярно и это дает возможность заранее среагировать на появление систематических ошибок. Оперативная реакция на результаты и методичное исправление практически всех, пусть даже мелких ошибок, связанных с реализацией тестов, через время (вопрос пары месяцев) приведет к тому, что % ложных ошибок сведется к показателям 2-3% от всего объема тестов. По-крайней мере у меня так произошло, когда я подправлял тесты, даже, если там приложение просто протормаживало. В результате, После прогона порядка 300 тестов (это только на моем направлении столько) общей длительностью 48 часов, мне надо было по сути просмотреть 4-5 тестов, которые упали по неизвестным мне причинам.

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

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