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

[Yarilo]

Привет!

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

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

- затраты на тестирование, основанное на скриптах, при малейших изменениях функций системы будут расти в геометрической прогрессии => слишком дорого, чтобы применять в проектах с неводопадным жизненным циклом разработки;

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

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

В связи с этим у меня вопроы давно такие:

1.Для небольших проектов (4-5 разработчиков, 1-3 месяца работы) стоит ли автоматизировать тестирование, если стоит, то:

- какой тип тестирования нужно автоматизировать (модульное? системное?)?

- какой тип автоматизации использовать (скрипты для use cases? скрипты для функций имплементации самого нижнего уровня? тестирование на моделях - относительно use cases? тестирование на моделях - относительно функций имплементации самого нижнего уровня?)?

2.Какое должно быть соотношение тестировщиков по отношению к разработчикам чтобы можно было вообще думать о возможности автоматизации?

3.Обязательно ли начинать работы по подготовке и разработке автоматизированного тестирования с самого начало разработки самой системы? (если нет, то когда начинать)

4. Чего вы вообще автоматизируете?! (отчаянно) Имеется в виду, какие типы приложений (бизнес-приложения с клиент-серверной архитектурой, web-приложения с архитектурой клиент-web сервис..., сайты на PHP писанные и пр. виды).

Люди, пожалуйста, откликнетесь!!!!

[Dmitry_NJ]

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

Не уверен, что я понимаю что такое "автоматизированное тестирование, основанное на моделях системы". Окупаемость, на мой взгляд, не зависит от того насколько тестируемая система критична. Она зависит от того сколько денег вы сэкономите/заработаете, если тестирование проведете быстрее (в этом суть перевода тестирования с ручного на автоматизированное).

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

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

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

Соотношение разработчик/тестировщик роли не играет. Главное, чтобы у тестировщика было время именно на автоматизацию тестирования, а не как тут в одном объявлении было указано "без ущерба основным обязанностям". Естественно, что если тестировщиков мало, то они скорее погрязнут в рутине ручного тестирования. Им уже будет не до автоматизации. Для автоматизации все планирование заключается главным образом в создании документов, где будут детально (step-by-step) описаны действия пользователя с системой и контрольные точки, которые надо проверить.

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

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

Для небольших проектов (4-5 разработчиков, 1-3 месяца работы) стоит ли автоматизировать тестирование?

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

Какое должно быть соотношение тестировщиков по отношению к разработчикам чтобы можно было вообще думать о возможности автоматизации?

Любое, если у тестировщиков будет время заниматься автоматизацией. Лучше, конечно, иметь в штате людей, которые будут заниматься ТОЛЬКО автоматизированным тестированием.

Обязательно ли начинать работы по подготовке и  разработке автоматизированного тестирования с самого начало разработки самой системы? (если нет, то когда начинать)

Смотря что именно вы хотите автоматизировать. Я говорю только об автоматизации функционального тестирования на уровне GUI (как правило, когда говорят про автоматизацию тестирования, то имеется в виду именно этот тип тестирования). В данном случае на начальном этапе разработки системы можно расслабиться. Автоматизировать начнете, когда будет GUI и стабильно работающий функционал. Заранее озаботьтесь только step-by-step описанием шагов пользователя и контрольных точек. Много раз слышал умные слова про то, что начинать автоматизировать надо как можно раньше, уже на прототипах и пр. blah-blah-blah... Особенно любят про это большие боссы распространяться. Ерунда все это и пустая трата времени. Затраты на доработку/переделку будут таковы, что легче написать все заново, когда система начнет таки работать нормально (если, конечно, начнет :D )

Чего вы вообще автоматизируете?! (отчаянно) Имеется в виду, какие типы приложений (бизнес-приложения с клиент-серверной архитектурой, web-приложения с архитектурой клиент-web сервис..., сайты на PHP писанные и пр. виды).

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

Люди, пожалуйста, откликнетесь!!!!

Вроде откликнулся :)

[Yarilo]

Вот это да!!!
Вот так Dmitry_NJ!
Спасибо за ваш развернутый ответ!!!

Теперь у меня нету сомнений в том, что автоматизация тестирования GUI систем в нашей компании в текущей ситуации - несбыточная мечта (и можно спокойно принять этот факт :) )!

[Darkus]

Да уж! Кхе, кхе... :)
Первая мысль от поста уважаемого Dmitry_NJ возникает приблизительно следующая - А использовал ли он сам в полной мере автоматизированное тестирование??! Создалось впечатление, что ручное тестирование это рулез, а автоматизированное сакс. :)
...
Ну да ладно, попробую преподнести свою точку зрения.

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

Автоматизированное тестирование, к примеру, начинает окупаться при регрессионном тестировании системы с большим функционалом. Для примера могу привести пока что только собственный опыт ну и то, что пишут (бла-бла-бла, как выразились) в книжках.
Если у вас система, которая много чего умеет делать и вдобавок имеет тип клиент-серверной, то ручками шлёпать по кнопочкам и бегать от одной машины к другой при этом - есть убойный выход.
Вообще формула экономической эффективности автоматизированных тестов следующая:
E(n) = A1/A2 = (V1 + n*D1)/(V2 + n*D2)
Где A1, A2 - абсолютные затраты на автоматизацию и тестирование вручную соответсвенно.
V2, V1 - затраты на создание спецификацию ручного тестирования и создание спецификации и реализацию автомат. тестов.
D2, D1 - затраты на выполнение одного теста вручную и затраты на реализацию теста после перехода к автоматизированному тестированию.
n- количество тестов.

В моём случае проект достаточно большой по функциональности и тестировщики замучались уже отлавливать баги, которые поправляют в одном месте, а они вылазиют в другом. Спецификацию писать на ручное тестирование и следовать ей - себе дороже. Долго это получается в целом и от случайных ошибок в процессе тестирования не застрахован тестировщик.
К тому же нужно тесты организовать так, чтобы тестировалось параллельно 5 машин минимум в одном режиме и 2 машины в другом! Часто ли вы видете организацию у нас с 7 тестировщиками?
А если нужно синхронно что-то делать на нескольких машинах?
В этом случае мы переползаем на тестовые скрипты и разрабатываются они месяц, а может и два, а может и больше в зависимости от того когда переползаем.
(Сейчас мы рассматриваем пока случай, когда приложение уже на процентов 50 готово и мы решили переходить на автомат. тесты).
Поэтому нужно уже исходить из сроков проекта. Чем больше проект, тем больше скриптов нужно написать. Хотя это дело не такое и хлопотное, как его могут некоторые представить. Посудите сами.
Вы кликаете на кнопочки в любом случае. Если вы при этом поставили рекордер и записываете свои действия, то следующий ваш проход будет уже автоматизирован (я утрирую немного, т.к. нужно частенько подшаманивать получившийся скрипт и связывать его).
Но что мы имеем в итоге?
Очень высокую вероятность воспроизведения бага, если он случился при таком подходе.
Есть эталонные данные. Пляшем от них. И почти наверняка попадаем в ситуацию сбоя.

- затраты на тестирование, основанное на скриптах, при малейших изменениях функций системы будут расти в геометрической прогрессии => слишком дорого, чтобы применять в проектах с неводопадным жизненным циклом разработки;

Вовсе не факт. Если у вас поменялся GUI, то нужно подправить объекты вызовов, но функционал то сравнения остался прежним!
Если поменялся функционал, то достаточно подправить тесты именно для того случая, где он поменялся.
А вот если поменялась логика работы программы, то возможно этот участок прийдётся переписывать.
Но! Когда есть костяк основной, то ампутация или лечение тестов - это вовсе не написание их полностью с нуля. К тому же, как поведёт себя остальная часть системы, если изменится часть функционала? А тесты то уже написаны и они достоверно покажут где и что изменилось.
А ручками это 100% не проверишь, как правило.

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

В любой продвинутой фирме соотношение должно быть 1:1 - минимум.
К сожалению у нас бывает на 5-10 программеров 1 тестировщик. И это очень плохо, т.к. объём работ программистов большой , а тестов на него физически 1 тестировщик не успеет быстро сделать.
Но если игра стоит свеч и будет время дописать тесты к моменту, когда основной функционал уже завершён и начинается вылизывание и оптимизация, то стоит попробовать. Вообще это всё дело планируется приблизительно так.
Как пишут в классических методах разработки ПО, вначале делают ГУИ с минимумом функционала и потом его "замораживают". Нам для автомат. тестов нужно в первую очередь именно ГУИ, чтобы привязываться к нему в одном случае. Писать "затычки" точно также, как это делают программеры и тогда можно идти в ногу с разработкой проекта. В другом случае, если тестировать нужно СОМ программную часть, то пишется оболочка для неё и разрабатываются тесты так, как будто всё уже работает. Тесты естественно выдают ошибки, а программеры дописывают и подлаживаются под эти тесты, чтобы они не "краснели" от их кода :))

Я пока ещё не пробовал ни разу включаться в автомат. тесты с самого начала, но есть горячее желание. У меня самое раннее получалось где-то с середины проекта. И то, я очень жалел, что не начал раньше писать автомат. тесты. Многие ошибки были бы пофиксены ранее.

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

В книжках так приблизительно пишут. Если сроки тестирования уменьшатся, то вперёд на автомат.
Если же у вас 1-2 месяца, то основную часть функционала можно протестировать ручками, а сложные аспекты накидать скриптами. Получается смешанное тестирование. И всё равно впоследствии всё больше и больше ручного тестирования будет переходить в ручное, если при поддержки продукта начнут вылазить баги.
Принцип очень прост. Нашёл баг - напиши скрипт для его воспроизведения.
Много багов однотипных - объединяй их в общий модуль, который будет гонять и их, и другие данные на которых пока нет багов.

1.Для небольших проектов (4-5 разработчиков, 1-3 месяца работы) стоит ли автоматизировать тестирование, если стоит, то:

- какой тип тестирования нужно автоматизировать (модульное? системное?)?

- какой тип автоматизации использовать (скрипты для use cases? скрипты для функций имплементации самого нижнего уровня? тестирование на моделях - относительно use cases? тестирование на моделях - относительно функций имплементации самого нижнего уровня?)?

Лучше использовать вначале модульное, потом системное. Причём модульным тестированием должны заниматься сами программеры по принципу "белого" ящика. Т.е. пишут модуль. Ставят на него заглушки и прогоняют его сами, потом отдают тестировщику и он\она подставляют в него данные на входе, ловят на выходе и анализируют их ручками или с помощью автомат. средств...
А системное тестирование уже включать, когда куски программного кода готовы и более менее оттестированы и объединяются в законченную структуру.
Пример как это делается:
Вася программер(ВП) - я закончил пересчёт (скажем) банковских движений. Нужно проверить.
Петя тестер(ПТ) - давай сюда и сделай мне формочку(утилитку) для входных и выходных данных. Бум тестить.
Пишет скрипт, который вбивает кучу данных и анализирует их. Делает эталонные базы, конечные базы.
ВП пишет дальше и правит баги от ПТ.
...
Закончили и отладили основные куски. ВП сделал ГУИ для них и начинает объединять.
ПТ просит в студию ГУИ и пишет кляки на менюшки, "горячие" клавиши и т.п. Ждёт в конце от них скажем мессаджей или что наоборот никаких мессаджей нет. Что в контролах должны или не должны появляться данные. В общем каркас. (Кстати, ГУИ к столу нужно подавать не сразу, т.к. его то в начале, как показывает практика, тоже достаточно много меняют и привязываться к нему - себе дороже на ранних стадиях. Лучше после аператива, т.е. основного функционала.).
В этом время ВП начинает "подшивать" функционал на ГУИ и организует , скажем, клиент -серверную работу.
ПТ пишет скрипты, которые поднимают тестовые оболочки на машинах и завязывает их на функционал (в моём случае это был Test Complete).
Далее начинается системное тестирование(регрессионное, нагрузочное, на разных ОС...) на уже Готовых Скриптах и дописывание тестов.

Тут вдруг ВП говорит, что функция работала не правильно и затронет многие куски кода.
ПТ просит объяснить или написать небольшую доку. В соответствии с ней правит входные\ выходные результаты и анализ данных. При этом следующий прогон тестов выявит где ещё зацепилась программа от этих изменений.
Или типичный случай. Ошибок валом, всё валится. ВП точно видит где ошибки и знает что их нужно править. Когда есть тесты, которые это дело показывают после регулярного прогона, то нет такой иллюзиорной ситуации, когда ВП что-то пишет и убеждён, что большинство работает программы и только в 2-3 местах глючит.
В планировании должно быть чётко указано, что помимо разработки нового функционала - НУЖНО ПРАВИТЬ БАГИ! И делать это регулярно после и во время разработки модуля.
Даже более того, программер должен сам писать небольшие кусочки тестов, которые будут прогонять на нижнем уровне его программку, а только после этого отдавать её на тестирование.

3.Обязательно ли начинать работы по подготовке и разработке автоматизированного тестирования с самого начало разработки самой системы? (если нет, то когда начинать)

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

4. Чего вы вообще автоматизируете?! (отчаянно) Имеется в виду, какие типы приложений (бизнес-приложения с клиент-серверной архитектурой, web-приложения с архитектурой клиент-web сервис..., сайты на PHP писанные и пр. виды).

Лично у меня на опыте автоматизация работы с БД, сайты и клиент-серверные приложения. Особенно, когда количество виртуальных пользователей больше 3. Также тестирование программ с СОМ\DCOM оболочкой, т.е. тестирование программной части. Её тестирование, кстати, идёт почти вровень с разработкой программы.
Как я уже писал, вначале "сырые" программки быстренько гоняем ручками и пишем несколько скриптов. Как только устоялась программка и ГУИ - начинаем писать авто тесты и внедряем уже готовые скрипты, попутно дописывая новые.
-----------------------------------------------------------------------------------------------------------------------------------
P.S.
А вообще должен быть план тестирования и он должен тесно сотрудничать с планом разработок.
Т.к. оба они входят в ещё больший план - разработка проекта.
Нужен толковый менеджер , который будет общаться с делегацией программеров и тестеров(где есть тольковые менеджеры с обеих сторон), чтобы потом проанализировать и создать такой план со всеми сроками на непредвиденные разработки и правки багов.
Отнсительно полезности атоматизир. тестирования советую почитать книжку
"Автоматизированное тестирование программного обеспечения".Элфрид Дастин, Джефф Рэшка, Джон Пол.
Там очень хорошо всё расписано. Нужно с недельку, чтобы прочитать всё это дело и ещё с недельку, чтобы осмыслить и попытаться переложить на конкретный проект.
-------------------------
А в целом просто и без умностей - автоматизированное тестирование это просто следующий шаг компании после ручного тестирования.
Если с умностями, то смотри CMM и TMM - там как раз про это написано.

[Yarilo]

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

Спасибо, Darkus, за подробный ответ и, в особенности, за пример!

[Dmitry_NJ]

[quote]Первая мысль от поста уважаемого Dmitry_NJ возникает приблизительно следующая - А использовал ли он сам в полной мере автоматизированное тестирование??! Создалось впечатление, что ручное тестирование это рулез, а автоматизированное сакс. :)[/quote]

Странное у вас впечатление создалось после моего поста. Вроде в моих словах не было оды ручному тестированию. Скорее наоборот. Я всего лишь попытался обобщить свой опыт и предостеречь от эйфории что автоматизированное тестирование это легко и просто и решает все проблемы. Да, проблемы решаются, но при этом появляются новые, о которых стоит знать заранее. Что касается того использовал ли я сам автоматизированное тестирование, то таки да, использовал в течение 4-х лет практически ежедневно, а последние 2-3 года время от времени в зависимости от потребностей клиентов. И очень хорошо представляю себе этот процесс и с точки зрения разработчика автоматизированных тестов и с точки зрения руководителя группы таких разработчиков.

[quote]Спецификацию писать на ручное тестирование и следовать ей - себе дороже. [/quote]

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

[quote]В этом случае мы переползаем на тестовые скрипты и разрабатываются они месяц, а может и два, а может и больше в зависимости от того когда переползаем.[/quote]

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

[quote]Вы кликаете на кнопочки  в любом случае. Если вы при этом поставили рекордер и записываете свои действия, то следующий ваш проход будет уже автоматизирован (я утрирую немного, т.к. нужно частенько подшаманивать получившийся скрипт и связывать его).[/quote]

Вот приблизительно такие слова я слышал от одного большого босса. Он очень сильно удивлялся почему включив рекордер и записав "волшебные пассы руками на клавиатуре", мы должны потом делать с тестом что-то еще. :) Это работает, если приложение более или менее стабильно. Иначе следующий проход после сборки очередного билда очень вас расстроит.

[quote]Если у вас поменялся GUI, то нужно подправить объекты вызовов, но функционал то сравнения остался прежним;
Если поменялся функционал, то достаточно подправить тесты именно для того случая, где он поменялся.
А вот если поменялась логика работы программы, то возможно этот участок прийдётся переписывать.[/quote]

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

[quote]К тому же, как поведёт себя остальная часть системы, если изменится часть функционала? А тесты то уже написаны и они достоверно покажут где и что изменилось. [/quote]

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

[quote]Как пишут в классических методах разработки ПО, вначале делают ГУИ с минимумом функционала и потом его "замораживают". [/quote]

Вот именно, что это пишут в книжках. А в жизни GUI замораживают ближе к окончанию проекта. Впрочем, возможно у вас программеры работают, как в книжках написано.

[quote]Тесты естественно выдают ошибки, а программеры дописывают и подлаживаются под эти тесты...[/quote]

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

[quote]Я пока ещё не пробовал ни разу включаться в автомат. тесты с самого начала, но есть горячее желание. У меня самое раннее получалось где-то с середины проекта. И то, я очень жалел, что не начал раньше писать автомат. тесты. Многие ошибки были бы пофиксены ранее.[/quote]

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

[quote]Принцип очень прост. Нашёл баг - напиши скрипт для его воспроизведения.[/quote]
Напиши скрипт, подготовь для него исходные данные, оттестируй его, задокументируй, подключи в соответствующий test suite/test set. Все хорошо, только времени это занимает много. А ошибки, особенно на ранних стадиях проекта, когда все еще сырое, могут десятками вылетать. Надо кстати еще не забыть писать тесты "обычные" (не те, которые появляются из-за ошибок).

[quote]Когда есть тесты, которые это дело показывают после регулярного прогона, то нет такой иллюзиорной ситуации, когда ВП что-то пишет и убеждён, что большинство работает программы и только в 2-3 местах глючит. [/quote]

У вас какие-то идеальные тесты получаются. У вас никогда не падали тесты не по причине ошибок в тестируемой программе, а по другим причинам? Синхронизация не сработала - всегда окошко появлялось не дольше чем через 5 секунд, а тут вдруг появилось через 40 секунд. Окошко всегда имело заголовок "Information", а тут вдруг стало "Info". Коннект с базой порвался. Случайно кто-то клаву или мышь задел. Вылетело какое-нибудь popup окошко, типа предупреждения о low virtual memory. Да мало ли что еще? Таких вот помех в реальной жизни полно. А если у меня при этом сложная цепочка тестов шла, которые зависят один от другого?

[quote]Причём, если появляются уже на этой стадии трудно воспроизводимые баги, то нужно на них писать скриптик. Это не долго, но потом будет не так утомительно воспроизводить баг.[/quote]

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

[quote]Особенно, когда количество виртуальных пользователей больше 3. [/quote]

А при чем тут виртуальные пользователи и функциональное тестирование через GUI? :blink:
-----------------------------------------------------------------------------------------------------------------------------------

Как резюме. Автоматизированное тестирование вещь, конечно, классная. Заниматься им интересно и полезно. Гораздо меньше шансов, что от вас уйдет хороший специалист, если у него есть возможность заниматься автоматизированным тестированием. Но, это совсем не так быстро и легко, как можно понять из слов уважаемого Darkus'а.

У меня сложилось впечатление, что подобный опыт получен главным образом тогда, когда автоматизированным тестированием занимаешься в одиночку и тесты не требуют большой и сложной подготовки исходных данных (иначе надо писать скрипт, который будет обслуживать основной тест, это опять-таки время на его создание/отладку/ поддержание в актуальном состоянии). Быстренько записали (без всяких спецификаций), прогнали, вроде работает. Через недельку вдруг перестал работать? В одном месте убрали лишнее, в другом добавили новое. Сам прогнал, сам понял где ошибка в тесте, опять поправил, опять прогнал. Все знания держим в голове (помните, Вася объяснил Пете что и где теперь не так работает, а Петя быстренько поправил тесты). Если человек заболевает/уходит в отпуск/увольняется, то такая автоматизация накрывается медным тазом. Все знают какова "эффективность" от копания в чужом коде, особенно когда нет спецификаций.

У меня просто несколько иной взгляд на автоматизированное тестирование, полученный в результате работы в компании, с отделом тестирования человек в 60 и выделенной группой разработчиков автоматизированных тестов (7-8 человек для функциональных тестов, 2-3 для нагрузочных). В моем понятии автоматизированное тестирование стоит тех денег, которые на него приходится тратить (я даже не про зарплату разработчиков тестов, а про стоимость самих инструментов), если я могу быть уверен, что автоматизация тестирования не загнется от человеческого фактора. Иными словами, я могу взять со стороны человека, который не будет знать приложения, но зато будет экспертом в используемом инструменте. И этот человек сможет поддерживать имеющиеся тесты и писать новые. Главное, чтобы были спецификации на эти тесты, включая и все изменения/дополнения в результате развития тестируемого приложения.

[Darkus]

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

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

Единственное что хотелось бы расшифровать - вот этот пост:

Тесты естественно выдают ошибки, а программеры дописывают и подлаживаются под эти тесты...


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

Уже существует набор тестов, который проходит или практически проходит полностью.
Программисты видят отчёт последний о процессе тестирования и разбирают чей код "виновен" в отвалившемся тесте. Я имею ввиду, что тесты закончены полностью (не в смысле больше тестировать нечего, а в смысле что набор тестов принят, как эталонный для прохождения заданного функционала). И пока тесты не будут 100% пройдены, то программеры будут дописывать код и подлаживаться под эти тесты.

Никто и не утверждает, что авто-тесты это легко и всё будет легко работать.
Но поддержка автотестов гораздо нужнее и важнее, чем попытка оставить всё на "ручки".
Касательно же спецификации на автотесты - то она несколько иная, чем на ручное тестирование. Там уже учитываются такие аспекты, как использование стандартных\нестандартных контролов, среда разворачивания тестовой студии и т.д. Поэтому я писал , что спецификацию на ручное тестирование и описывать все тестовые случаи дороже получается, чем разработать более абстрактную спецификацию на авто-тесты и всё то, что писалось на бумаге для ручных тестов просто реализовать в авто тестах (так, например, нам нужно было писать -клякни туда, вызови сюда, а теперь мы просто говорим - обрабока Меню1. ) Это всё равно , что сравнивать статическое тестирование и динамическое. (надеюсь не дал очередного повода для длинных пояснений :))

Не поленюсь ещё пожалуй на вот эту реплику ответить

Особенно, когда количество виртуальных пользователей больше 3. 


А при чем тут виртуальные пользователи и функциональное тестирование через GUI?

Ну если вам нужно на 3-х машинах сделать одно и то же. То вы делаете это через GUI (к примеру).
И как вы будете это делать вручную да ещё и синхронно?
Это как раз одно из тех укзих мест, что уже сложно или практически невыполнимо сделать вручную.

Пишите, надеюсь, что побеседуем. У меня как раз сейчас тесты надолго зарядились :)

[Mike]

Darkus, отвечу за Диму: виртуальными пользователями обычно называют скрипты для нагрузочного тестирования (и, соответствено, экземпляры процесса/треда их исполняющего).

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

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

Это я всё к тому, что меньшие затраты на документацию (как тестов, так и системы) - сомнительный аргумент ЗА автоматизацию...

[Darkus]

Нет, нет, уважаемый Mike.
Опять таки , попытаюсь уточнить пределельно возможно.
Я не говорю, что не нужно писать документацию на авто тесты.
Хорошо, напишу очень доходчивый пример 2 документаций. Надеюсь, что из них вы сможете понять (ааа.. вот он что имел ввиду :) )
Покрытие тестом функции сливки данных.

Тест 1. Ручное тестирование.
- Тестирование функции сливки данных.
Вызвать приложение.
Залогиниться.
Нажать Команду 1 в Меню 1.
В открышемся диалоге нажать клавишу загрузить.
Ввести в поле1 данные1. Нажать ОК.
Закрыть окно.
Нажать Команду 2 в Меню 2.
В открывшемся окне нажать кнопку Слить данные.

...
Данная комбинация нужна всегда Именно в спецификации ручного тестирования ибо без неё тест невозможен для нового человека.


Тест1. Автоматизированное тестирование.
- Тестирование функции сливки данных.
Загрузить тестовую студию.
Загрузить Скрипт1. (тестирование функции сливки данных)
Нажать Пуск.

ВСЁ!
..
И новому человеку не нужно будет читать что-то ещё.
========================================
Уже слышу возгласы - ну а с как же ты будешь собственно говоря скрипт то писать?
Так вот - мне не нужна документация о ручном тестировании, потому что она пишется для сторонних людей. Да, я сделаю те же самые или практически те же самые действия, но мне их документировать не нужно. Для написания авто теста мне нужна только спецификация на собственно продукт.
Если тебе нужно посмотреть как это всё делалось - плиз в код с комментариями, т.к. код это и есть документация. Добавлю -граммотный и понятный код.

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

Только интересно, как вы определяете "coverage" (покрытие тестами функционала системы или требований) и как планируете из разработку (или это делается "от балды"  ?).

Ну так и будет выглядить. Делаем матрицу покрытий.
Слева что нужно сделать.
Сверху тестовые скрипты.
На пересечении 1.
А что вы имели ввиду?
.....
Привет Дмитрию.
А можно поинтересоваться в какой компании вы работаете, что там так много хороших тестировщиков? Есть предположение, что в AutomatedQA )

[Mike]

Мы работаем в разных компаниях (хотя действительно раньше работали в одной -в ЛАНИТе). Дима - в Mercury Interactive (думаю, знаете такую ;-)) в Штатах, а я - в одной очень крупной аутсорсинговой компании в Москве.

Тест1. Автоматизированное тестирование.
- Тестирование функции сливки данных.
Загрузить тестовую студию.
Загрузить Скрипт1. (тестирование функции сливки данных)
Нажать Пуск.

Ну-ну. Это как в той программисткой шутке, о том что программа прекрасно документирована: на C++. Мне казалось, что те времена немножко прошли, и девелоперы (и тестеры) научились думать по-другому. Жаль, если ошибался. Это ровно то, о чём я писал в предудущем посте: качество системы прямо пропорционально качеству документации и качеству планирования процесса. С таким подходом как описан у Вас, и то и другое страдают, IMHO.

[Darkus]

Тогда уважаемый Mike, не затруднит ли вас показать пример документирования автоматизированного тестирования?
А то видимо то ли пример тупой для нашей темы, то ли я чего-то недопонимаю.
Хотя, я уже начал жалеть, что развел пост.
Хотелось наглядно и по -деревенски просто показать, а тут с такими "акулами" тестирования столкнулся ;)

[Mike]

Я вовсе не претендую на особую "окулистость" :).

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

[Darkus]

Погодиде-ка! :unsure:
Ну про логи вообще вроде бы разговор не шёл. Естественно, что то, что мы называем "комментарии" в частности рассматривается как ЛОГи.
Млин, опять недостаток общения виртуального.
Я думал, что вы имели ввиду отдельное написание ручками документирования и потом следование ему автотестов... Поэтому я заменил эту часть на банальное - "выбрали скрипт и запустили его".

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

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

[Green]

Честно говоря, стало сложно следить за логикой дискуссии. :P
Предлагаю вернуться к сути вопроса.

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

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

В настоящее время при тестированнии программ общего пользования ("ширпотреба" по классификации Joel Spolsky - Joel on Software - Джоэл о программном обеспечении) наиболее типичным подходом является автоматизация только двух типов тестов: регрессионных и нагрузочных.

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

Регрессионное тестирование...
При тестированнии программы необходимо решить три задачи.
1. Убедиться, что созданная ранее часть программы работает и она не "пострадала" при внесении новой функциональности.
2. Проверить, что найденные ранее деффекты устранены.
3. Проверить новую функциональность на соответствие требованиям и на наличие программных деффектов.

Каждую из этих задач можно разбить на три группы, исходя из их важности.
1. Smoke test - набор тестов, назначение которых - проверить тестопригодность приложения. Они, как правило, занимают от 4 до 8 часов. Посли их прохождения принимается решение о передаче приложения в тестирование или возврат программистам на доработку.
2. Critical Path tests - оснавной набор тестов, которые обязательно должны быть выполнены.
3. Extended tests - тесты, которые выполняются при наличие времени.

Итак, получаем матрицу 3х3.
Какую из ячеек стоит автоматизировать в первую очедедь?

Ответ очевиден. Автоматизируется Smoke test для проверки работоспособности написанной ранее части приложения. Этот скрипт может и не найти ни одного бага, но он будет использоваться каждый раз, когда очередной билд будет сдаваться на тестирование. При добавлении новой функциональности автоматизировать стоит тесты, призванные решать именно эту задачу. Благодаря такому подходу промежуточное состояние между тем как программисты сдали билд на тестирование, а тестировщики приняли, будет минимизироваться, возможный простой (в работе и в мыслях :P ) будет сводиться к минимуму.

Далее следует приступать ко второму типу тестов - Critical Path tests. Автоматизировать лучше всего наиболее часто повторяющиеся пути с целью проверки найденных при их прохождении багов.

Третий тип тестов - по мере сил и возможностей.

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

Как определить, стоит ли автоматизировать тот или иной тест? Я использую следующую методику.
1. Каждый тест кейс таймируется (указывается минимальное, максимальное количество времени на его выполнение и вычисляется среднее, которое используется для планирования временных затрат).
2. Прогнозируется возможное количество прохождений данного теста за весь период тестирования.
3. Вычисляются временные затраты на автоматизацию.
4. Сравниваются полученные результаты.

Как правило, при таком подходе ни у кого вопросов уже не возникает.

B)

[Dmitry_NJ]

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

Что касается того, где я работаю, то Миша уже ответил. Есть такая компания Mercury Interactive. Может даже слышали о такой :) Но я, естественно, не работаю в QA и ежедневное автоматизированное тестирование осталось в прошлом. В моем предыдущем посте речь шла о компании, в которой я работал в Москве в 2000 - 2002 годах.

[Yarilo]

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

Да уж, точно не играют!

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

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

Хочу поблагодарить всех участников этой дискуссии за столь полное освещение вопросов автоматизированного тестирования, этот тред точно кому-нибудь поможет разобраться что к чему, и мне, может быть тоже в будущем :)

[barancev]

А теперь и вообще, отмирает тестирование :( - говорят и без него жить можно.

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

Дело в том, что обойтись без него нельзя! Но можно его "как-бы не делать", объявив, что такой деятельности нет и никто ею не занимается. В результате (так как тестировать всё равно надо) этим занимаются а) непрофессионалы, б) в "свободное от основной работы" время, и что самое страшное - в) БЕЗ ВСЯКОГО КОНТРОЛЯ!

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

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

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

[Yarilo]

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

[barancev]

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

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

1. Надо снизить затраты, потому что клиенты платят всё меньше и меньше, а конкуренция возрастает (увы, это объективная правда, посылка абсолютно верная).
2. Снизить затраты на производство нельзя. На управление тоже, как же они без нас, менеждеров, обойдутся?
3. Тестирование - непроизводительная деятельность, тестировщики не производят продукта (value), поэтому эту деятельность можно сократить.
4. Да, но как-то обеспечивать качество необходимо? Возложим эту обязанность на самих разработчиков.
5. Может быть это потребует дополнительных затрат, увеличится срок разработки? Нет, все книжки и консультанты говорят, что TDD (test-driven development) снижает затраты, уменьшает срок и повышает качество разработки.
6. А как же приёмочное тестирование? Всё равно оно дублируется бета-тестированием, поэтому оно тоже не нужно.
7. Ура! Нам больше не нужно тестировать наши продукты, а качество всё равно будет высоким.

Это несколько упрощённая схема вполне реального моего общения с вполне реальным клиентом.
Попробуйте самостоятельно обнаружить, какие провалы есть в этой логике.

[Darkus]

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

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

И видно, что данная компания пытается сейчас выжить либо у неё не настолько серъёзный заказчик, который не прощает серъёзных сбоев в работе... может другое что-то. Несостоятельность этой компании в том, что они не могут принять как факт и ПОНЯТЬ что тестирование давно уже стало частью разработки ПО.