Здравствуйте, cyber2003, Вы писали:

C>Тестируем вручную Windows приложения с обширным GUI. Никаких средств автоматизации в конторе пока нет. Попробовали QTP, понравилось, теперь хотим убедить начальство его купить. Кроме удобства, QTP привлекает еще и своей популярностью. Для будущего опыта тоже лишним не будет. Вопрос: какие аргументы есть в пользу QTP по сравнению например c TestComplete? Цена QTP довольно высока, надо чем-то ее оправдать и показать, что QTP нам подходит более всего, даже за такие деньги. Что посоветуете?

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

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

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

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

Это тоже можно указать. Но начните с разговора о финансовой выгоде , если таковая есть или может иметь место