QA Tools...

[Logan]

На питоне сурьёзные люди пишут вёб сайты. А тут - тесты...Куда проще освоить C#. Сейчас некоторые девелоперы переквалифициуются в test autoimation (сам такой). Сколько народу в Ване знает/применяет Питон? А сколько С#?
А представте - девелоперы одной и той же канторы пишут на дот-нете, а тестеры на Питоне? Круто.

Но главное Coded UI Test итнегрирован в VS, Еcли кантора применяет TFS и .Net, то лучше придумать сложно в смысле "системы тестирования": написание, хранение, запуск, результаты тестов - всё уже заточено работать вместе. Мощь С#, VS и ваще MS позволяет наваять всё что душе угодно,любой степени сложности.

Возможно, это вопрос относительности в плане сложности изучения, но как мне кажется, питон как раз гораздо легче в освоении, нежели любой из си. Вы изначально дев, поэтому, возможно, вам кажется си шарп легким. У меня дорога обратная вашей, поэтому мне лично как раз все наоборот. У питона очень удобное для начинающих в кодинге и ООП реализация, и синтаксис. Си, любой в целом си, это гимор и не для новичков. А уж если в си серьезней копнуть, то все эти работы с памятью и пойнтеры и т.д. это вообще целая песня.
Сколько что знают в Ване это не особо показатель того, что для чего подходит. Номер 1 язык в Ване Джава без вариантов, но тесты в селениум на ней меня убили, вот уж точно из пушки по комарам.
Вы наверное не слишком сталкивались с питоном, если считаете, что это для серьезных людей, пишущих сайты. Веб-сайты, в особенности фреймворки типа джанго - это лишь малая толика того, где используют питон. Основная его цель, как языка без компиляции, как раз скриптинг. Я знаю множество контор по северной америке, которые его для скриптов, тестов и автоматизации используют. Да тот же гугл. Он, к примеру, очень удобен для скриптов в линуксе на уровне ос, я его использовал вместо bash и был доволен. Знаю многие 3д конторы, которые пишут скрипты автоматизации эффектов в Ване именно на питоне.
Как по мне, так лучше вообще как можно меньше дел иметь со всем, что связано с Майкрософт, в том числе си шарп, .нет и т.д., все у них через жопу.

[Meadie]

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

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

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

[Gatchinskiy]

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

неточное выполнения и порядок операций любую систему положит, почему продукцию МС в этом случае лучше не предлагать? Работал с MS Test Manager 2012 (Visual Studio 2010), понравилось, но дорогое удовольствие, он идет только с Ultimate edition, а это порядка 5K, только крупные вендоры могут себе позволить

[Meadie]

неточное выполнения и порядок операций любую систему положит, почему продукцию МС в этом случае лучше не предлагать? Работал с MS Test Manager 2012 (Visual Studio 2010), понравилось, но дорогое удовольствие, он идет только с Ultimate edition, а это порядка 5K, только крупные вендоры могут себе позволить

Эффективность автоматизации функционального тестирования зависит от того, насколько отделены друг от друга люди формулирующие требования к ПО и люди занимающиеся непосредственно автоматизацией. В идеальном мире люди определяющие ожидаемое поведение системы (бизнес аналитики) сами бы всегда писали автоматизированные функциональные тесты, запустив которые было бы сразу видно, выполняются ли требования к продукту или нет.

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

Более того, они и не должны быть программистами - иначе, они не смогут адекватно смотреть на продукт с точки зрения пользователей (без риска схлопотать раздвоение личности:). А что касается МС, то за многие годы сложилось устойчивое мнение, что его продукты как раз сделаны не для людей, а для программистов. И судя по всему, сделаны они программистами:)...

Кстати, о деньгах: 5К, которые, как вы говорите, только крупные вендоры могут себе позволить, - это всего лишь несколько % от годовых затрат на специалиста, который работает с этим тулом.

[Kiseta]

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

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

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

+1000 прям вот так же пыталась написать, но не шмогла, слишком погода была за бортом хорошая... совершенно согласна и спасибо, полезная информация...

[Gatchinskiy]

Эффективность автоматизации функционального тестирования зависит от того, насколько отделены друг от друга люди формулирующие требования к ПО и люди занимающиеся непосредственно автоматизацией. В идеальном мире люди определяющие ожидаемое поведение системы (бизнес аналитики) сами бы всегда писали автоматизированные функциональные тесты, запустив которые было бы сразу видно, выполняются ли требования к продукту или нет. .

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

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

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

А что касается МС, то за многие годы сложилось устойчивое мнение, что его продукты как раз сделаны не для людей, а для программистов. И судя по всему, сделаны они программистами:)...

о каких продуктах идет речь, примеры?

например MS Test Manager о котором уже говорил, заточен на обычного тестрера, знание языков приветствуется, но не обязательно, чтобы ранать и параметерезировать аутомейтед скриты

[Meadie]

Эффективность автоматизации функционального тестирования зависит от того, насколько отделены друг от друга люди формулирующие требования к ПО и люди занимающиеся непосредственно автоматизацией. В идеальном мире люди определяющие ожидаемое поведение системы (бизнес аналитики) сами бы всегда писали автоматизированные функциональные тесты, запустив которые было бы сразу видно, выполняются ли требования к продукту или нет. .

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

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

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

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