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

[Ira]

Привет всем!
Проблема в следующем: у нас "устоявшийся" процесс тестирования. Только ручной тестинг для функционального тестирования. Пока что никаких жалоб на качество сдаваемого продукта клинету не было, как и на сроки. Компания решила перейти на автоматизированное тестирование. Необходимо предьявить список benefits -ов клиету, чем улудшит процесс тестирования внедрение автоматизации. Например если надо прибавить ресурси то это будет компенсироваться сроками....Вообщем как убедить клиента на автоматизированное тестирование... предполагается внедрение WatiN-а, как тула для функционального тестирования...
Люди имеющие опыт, помогитеееееееееееееееееее....какие плюсы и какие минусы...какой опыт?
Заранее благодарю.

[Luceus]

Добрый день!

WatiN, это всего лишь навсего библиотека, которую Вам придется прежде всего изучить, и только лишь потом использовать. Что бы сделать на базе WatiN'a хороший фреймворк для проведения автоматизированного тестирования, вы потратите уйму человеческих и временных ресурсов.

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

Убьете двух зайцев.

[APC]

ИМХО - если жалоб нет, то убедить можно лишь анализом тенденций. К примеру, если есть тенденция к увеличению объемов тестирования, то наступит момент, когда начнете вылазить за сроки в чисто ручном. Вот и аргумент для начала автоматизации.

[Ira]

А что если ету библиотеку использовать с Visual Studio environmet- ом без создания фреймворка, для автоматозации скриптов?
И еще предположим проблема с тулом решена, все-таки какие плюсы можно предъявить клиенту, что бы заинтересовать его в автоматозации?
Типа обеспечение регресивного теста (хотя это и сейчас обеспечивается за счет "добропорядочности" тестировщика)
Имидж компании
.....

Что нибудь весомое....!!!!!!!!!

[ArtemRudenko]

Вот, что по этому поводу говорят на sqaforums: http://www.sqaforums...amp;Search=true
Так же русскоязычный рессурс(может чем пригодится):http://edu.setlab.net/?view=IBM_Rational_Testing_RUPBenefits

[Luceus]

Преимущества автотестирования:
- сокращение человеческих ресурсов на регрессионку;
- независимое приемо-здаточное тестирование;
- проведение тестирования лично заказчиком и его инженерами.
- и др.

[Ira]

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

[Nadya Kochetova]

Автоматизация тестирования - это прежде всего поиск выгоды (т.е. экономии затрат).

Прежде чем убеждать клиентов, подумайте и убедите себя. сейчас вам надо 200 рублей на ручной тест низкой сложности, автоматизировать его вам будет стоить 2000 рублей. плюс на переделку и отдалку понадобится еще 2000 рублей, так как первые тесты никогда не бывают удачными.
итого, 4000 рублей на автоматизацию одного простого теста. т.е. 20 тестов ручных за это время можно было бы прогнать. автоматизация одного теста стоит пропущенных 19 тестов и багов вместе с ними?

посчитайте свои потери, перед тем как начнете все автоматизировать.

автоматизировать надо так, чтобы тесты находили баги. на дизайн такого теста и его автоматизацию требуется больше ресурсов, чем 1:10.
действительно ли это выгодно вам и вашим клиентам?

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

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

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

удачи вам в любом случае!

[Luceus]

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

Второе, очень важное, это сам подход в автоматизации. Можно, как этим занимался я вначале, скриптовать с помощью метода записи и воспроизведения, что показало ОЧЕНЬ плохой опыт. Потом автоматизация тест кейсов шла по принципу: нам дают тест кейс, мы должны выдать автоматизированный скрипт. Когда приложение находится в постоянном изменении, и текстовые тест кейсы требуют постоянной актуализации, автоматизированные скрипты приходилось переписывать. Это было похоже, что мы не проводим регрессионку, а просто догоняем текстовые тест кейсы. Тестирования как такового не происходило. Сейчас для себя нахожу оптимальным вариантом следующий подход, когда QA инженеры составляют тест кейсы в соответствии с предложениями, и эти кейсы используются, как входными данными для автоматизированного скрипта, который их интерпретирует и выполняет. Логика изменилась, тест кейс актуализировали, как это и должно быть, и его можно сразу прогонять в автоматическом режиме.

Почему заказчик так сильно заинтересован в автоматизированном тестировании? Главное, это что бы продукт был качественный и не содержал ошибок.

[Ira]

В принципе не сам заказчик заинтересован в автоматизации сколько сам QA Team, все-таки не благодарное ето дело manual testing, в любом случае благодарю за ответы. Думаю может стоит начать с меньшего, т.е. сперва автоматизировать смок тест, или логику не поддающуюся изменениям...хотя как я понимаю нам за это сроки и ресурсы не прибавят, будем делать для себя :)

[Nadya Kochetova]

не благодарное ето дело manual testing

Ира, да что вы такое говорите? вы уверены, что выжимаете из ручного тестирования все, что можно? может, мы понимаем разные вещи под ручным тестирование??

Ваша фраза напомнила фразу о том, что многие считают black box testing бесполезным занятием. Глупость. и только.

Все выше сказанное - моя точка зрения.

[BaAbaKa]

Надя абсолютно верно выделила основное, над чем вам стоит хорошо подумать - деньги. Внедрение автоматического тестирования достаточно затратная вещь и на первых этапах растут как сроки тестирования, так и его стоимость. Важно так же рассчитать окупаемость подобных работ.
Мы к этому делу подошли аккуратно (в хорошем смысле), все просчитали, спроектировали архитектуру и реализовали (дешевле и лучше всего было написать именно свое средство в силу специфики).
В итоге сейчас каждую ночь выполняется сборка и проходят все функциональные регрессионные тесты.
Перед началом работ над разработкой и внедрением автоматизации достаточно много полезной информации взяли вот из этой книги:
Автоматизированное тестирование программного обеспечения
Automated Software Testing
Издательство: Лори, 2003 г.
Мягкая обложка, 592 стр.
ISBN 5-85582-186-2
Тираж: 3200 экз.
Формат: 70x100/16
Успехов ;)

[Ira]

Нет black box testing не бесполезным занятие, а наоборот необходимое ...а не благодарное дело это потому как нечего показать кроме как результата (нормально работающего продукта), а главное что меня беспокоит что все-таки чтоб команда ..как бы правильнее высказаться .. прогрессировала хотелось бы внедрить хотя бы "чуточку" автоматизации..не не во вред срокам, дополнительным деньгам, и ресурсам...
Спасибо.

[Nadya Kochetova]

Нет black box testing не бесполезным занятие, а наоборот необходимое ...а не благодарное дело это потому как нечего показать кроме как результата (нормально работающего продукта), а главное что меня беспокоит что все-таки чтоб команда ..как бы правильнее высказаться .. прогрессировала хотелось бы внедрить хотя бы "чуточку" автоматизации..не не во вред срокам, дополнительным деньгам, и ресурсам...
Спасибо.

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

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

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

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

про black box testing это совсем было не к вам :) no personal offence.
сам факт, что вы думаете о развитии тестеров - уже большое дело. удачи вам!

[slat]

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

[Luceus]

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

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

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

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

[Luceus]

Вы <-> Автоматизированный скрипт <-> Тестируемое приложение

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

[slat]

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

+1

Да такое бывает )

[SALar]

Начать автоматизацию тестирования вы должны с ответов на два вопроса:
* У вас есть ежедневная сборка?
* Если нет, то почему?
Если ежедневной сборки нет и вы не можете ответить, почему ее нет - начинайте ее делать.
На этом первый этап автоматизации тестирования завершается.
Примечание. Иногда ежедневная сборка вредна. Поэтому на второй вопрос обязательно нужно ответить.

Второй этап.
* У вас есть юнит тесты?
* Если нет, то почему?
Если юнит тестов нет и вы не можете ответить, почему их нет - начинайте их делать. Но только после того, как пройдете первый этап.

Третий этап.
* У вас есть компонентные тесты?
* Если нет, то почему?
Если компонентных тестов нет и вы не можете ответить, почему их нет - начинайте их делать. Но только после того, как пройдете первый этап (а лучше и второй).

И только после этого можно, нет, не внедрять, а просто задуматься об автоматизации тестировании через GUI. В противном случае все ваши метания, скорее всего, будут просто попилкой бюджета проекта.
Т.е. если у вашей фирму денег как у дурака махорки, то вперед - покупайте QTP или что там еще подороже есть, съездите на месяцок в Лас Вегас на "тренинги", ну и что нибудь сделайте. Качество продукта конечно упадет, но ведь главное бюджет попилить, правда?

[KaNoN]

....
Если юнит тестов нет и вы не можете ответить, почему их нет - начинайте их делать. Но только после того, как пройдете первый этап.
.......
Если компонентных тестов нет и вы не можете ответить, почему их нет - начинайте их делать. Но только после того, как пройдете первый этап (а лучше и второй).

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

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

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

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

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