Имеет ли смысл автоматизировать все?
#1
Отправлено 01 сентября 2005 - 15:53
есть ли необходимость автоматизировать полностью тестирование определенного програмного продукта.
было принято решение об автоматизации, но действительно ли нужно автоматизировать абсолютно все модули?.
мне кажется, что все же надо обращать внимание на то, сколько тратится на реализацию скриптов и на сколько это окупится..
имеет ли смысл писать скрипт, для коректной работы которого в него прийдется вбивать всю логику приложения...
я в замешательстве...
подскажите, как правильно поступать с автоматизацией крупного проекта с большим количеством модулей?
QA manager
#2
Отправлено 01 сентября 2005 - 15:58
#3
Отправлено 02 сентября 2005 - 06:29
Такие вопросы любила русская интеллигенция 19-го века.
- Возможно ли пожертвовать жизнью младенца для достижения мира всеобщего благоденствия?
Переведите спор в объективное русло. Попробуйте прикинуть материальные затраты (хотя бы на пальцах), необходимые для достижения всеобщей автоматизации. Вопрос "рассосется"сам собой.
#4
Отправлено 02 сентября 2005 - 06:39
Если едет разработка, значит происходят доработки, в каждой сборке появлется нечто новое, что необходимо заново автоматизировать.
А может проще прогнать ручное тестирование этой функции вручную, если это отдельная фича, которая реализовалась в отдельно взятой сборке для конкретного заказчика.
И потом не забываем, что автоматизация тестирование это сам по себе отдельный проект, включающий: написание тестовых спецификаций, примеров, подготовки данных и окружения, непосредственно написания автотестов, их отладка, поддержание в актуальном состоянии.
Примерное отношение трудозатрат на написание автотестов 10:1 по отношению к ручному тестированию, отсюда и прыгайте.
Не забудьте учеть затраты на покупку инструмена автотетстирования, обучение, стоимость его владения и т.д.
#5
Отправлено 02 сентября 2005 - 09:30
я уж было начала сомниваться в своих соображениях по этому поводу. ребята, которые вроде более опытные уверяли, что я не права.. а верить наслово не хотелось
еще раз спасиба
QA manager
#6
Отправлено 02 сентября 2005 - 10:03
Смысл заключался в том, что в программе существует большой набор сложных расчетых алгоритмов и регрессионные тесты новых билдов занимали до 3х человеко-недель.
В этом случае мы надеемся получить большую выгоду от автоматизации.
Удачи!
#8
Отправлено 05 сентября 2005 - 06:25
Можно к примеру написать один конкрестый сценарий который всегда будет выполняться. Но если пробовать добавить хоть какой-то элемент случайности,
т.е. несколько типов ЕО то будет слишком трудно все это описать в скрипте...
а описать отдельно все возможные комбинации счетов и т.п. выйдет слишком долго и хлопотно.. я быстрее проверю ручками, чем придумаю как все это корректно описать в скрипте. и труднее будет определить где именно содержиться ошибка, в моем скрипте или в программе. по моему это наоборот усложнит работу.
QA manager
#9
Отправлено 05 сентября 2005 - 07:22
В любом случае, ручками прогонится конечное число конкретных сценариев, что мешает их загнать в скрипты?
Т.е. я бы тоже настаивал на 100% атоматизации в данном конкретном случае.
#10
Отправлено 05 сентября 2005 - 07:40
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#11
Отправлено 05 сентября 2005 - 07:43
С моей точки зрения, для такой задачи вопрос должен звучать "как правильно автоматизировать", а не "автоматизировать или нет".
В любом случае, ручками прогонится конечное число конкретных сценариев, что мешает их загнать в скрипты?
Т.е. я бы тоже настаивал на 100% атоматизации в данном конкретном случае.
Смело..а если это сценарии которые не поддаются автоматизации(автоматизируется с большими трудозатратами)?
#14
Отправлено 05 сентября 2005 - 10:04
Например, поддержка self-made контроллов, либо разработчиков сторонних фирм.
Еще конкретнее - была проблема поддержи Infragistics Controls средствами RRobot
Оригинальный пост был про затаскивание алгоритмов в тестовый скрипт, т.е. дублирования бизнес-логики тестируемого приложения в тестирующем, а не про контролы и выбор инструментария.
Проблема кастомных контролов при желании обходится (наши тоже большинством тулзов не понимаются).
#15
Отправлено 05 сентября 2005 - 10:13
[
Оригинальный пост был про затаскивание алгоритмов в тестовый скрипт, т.е. дублирования бизнес-логики тестируемого приложения в тестирующем, а не про контролы и выбор инструментария.
Надо делать мир лучше?
Надо..ок, проблема решена
Проблема кастомных контролов при желании обходится (наши тоже большинством тулзов не понимаются).
Ну и как успехи? Желание совпало с возможностями?
#16
Отправлено 05 сентября 2005 - 10:24
Если не секрет, а какое новое качество получается от дублирования в тесте логики реализации?
Еще в первом классе учат, что нужно "проверять сложение вычитанием", а не "сложить два раза подряд и сравнить результаты". При альтернативном способе проверки меньше вероятность повторить в тесте ошибку, сделанную в реализации.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
Количество пользователей, читающих эту тему: 3
0 пользователей, 3 гостей, 0 анонимных