Not really.  You include the test libs at runtime or at compile time, so you 
don't have to have it compiled specifically.  All of the base objects are 
recognized by the plugin, and most subclasses get all the automation they need 
from the base class.  Occasionally you might need to write a delegate but that 
is rare, esp with flex 4.

The slowness is caused by too many controls to sort through.  It is solved by 
having the dev turn on the showInAutomation flag for some containers. That sped 
up our tests considerably.

I agree with you on a.  However, I disagree on b.  I have seen projects get 
burned by this approach, because the code functions, but the application did 
not because they never tested the ui.  And with a lot of code moving to the ui 
via either JavaScript or Flex, writing unit tests on the back end won't catch a 
lot of errors.  I am not saying the unit tests are not valuable, but the devs 
should write their own unit tests, and the testers acceptance tests.

With these big integrated systems I see QA going more toward integration 
testing, business rule validation, and risk based testing, instead of verifying 
that boundaries work.  Unit testing in my experience hasn't been able to handle 
these types of tests which are really more valuable to the business.


On May 11, 2011, at 10:00 PM, Mason Foley <[email protected]> wrote:

> Doesn't Flex code require instrumentation and specific compilation 
> requirements prior to QTP being able to interface with it?  And in my 
> experience, QTP driving a Flex RIA was extremely slow (for example, it took 
> seconds between each field when attempting to setText).  Maybe this got 
> better in Flex4.
> 
> If QTP opened up to other languages and was truly object oriented, (the IDE 
> is terrible relative to Eclipse, etc.) it would definitely be king of the 
> hill.  
> 
> The evolution of QA is a) OO programming skills and b) unit testing directly 
> in the code.  Apply the testing expertise earlier in the development 
> lifecycle, not on the back end.  That model is old and slowly but surely 
> becoming irrelevant and unsustainable.
> 
> My 2 cents,
> MWF
> 
> On Wed, May 11, 2011 at 8:46 PM, Christopher Davis 
> <[email protected]> wrote:
> I use both Selenium and Qtp every day, I would have to disagree.  
> 
> We use qtp in a agile environment and it works great.  I get a report in 
> email every morning from the tests, that tell me what broke.
> 
> Qtp most certainly can be integrated into Hudson or another CI tool.  Just 
> call it from the command line or, even easier control it through the com 
> libraries.  You can even spawn it on remote machines this way, and run the 
> tests in parallel as another poster pointed out.  Take a look at the 
> automation model docs and you will see you can do a ton of stuff.
> 
> If you find something lacking in vbscript just use the dotNet interface and 
> create classes and such in .net.  We do this for data classes.  It's mostly 
> automated, pulls the descriptions from the database and builds the data class 
> dll each test run, then pulls in the test data.  You edit the data in a web 
> interface that everyone has access to.  It sure beats editing excel sheets, 
> everything stays in sync, and doesn't require BPT.
> 
> If all you are doing is web Selenium isn't bad, but try automating a flex 
> front end with it and it gets painful.  What was easy in qtp becomes 
> difficult in selenium. 
> 
> I had to look up bdd.  I don't quite understand why you say qtp cannot 
> support it.  It wouldn't take much to have driver script handle something 
> like that.
> 
> I agree about the IDE, its bad.  So bad I write classes in .net and use them 
> in qtp instead of using vbscript classes.  With a com wrapper you actually 
> get intellisense.  I have been looking at Test Design Studio to augment the 
> qtp interface. It's closer to visual studio and has some nice features like a 
> test documenter.
> 
> I really don't get the knowledge sharing point.  I have worked on both dev 
> and test and you are performing two different tasks.  We are not writing unit 
> tests, we are testing an application so you shouldn't need the same codebase. 
>  If it's how the app works, I have never had a problem with talking to our 
> devs, or BAs.
> 
> Qtp has some things that the other tools just don't even come close in.  
> Visual object recognition in qtp 11, is really nice.  
> 
> 
> On May 10, 2011, at 11:17 PM, Leonardo Ribeiro Oliveira 
> <[email protected]> wrote:
> 
>> Hi guys,
>> 
>> After a long time, I'm back! As I told here some months ago, I was going to 
>> start working on a new project where I would automate tests with Selenium 
>> and other tools, but this project didn't happened and I decided to quit the 
>> company and joined ThoughtWorks.
>> I've doing real agile development and learning about BDD, TDD, continuous 
>> integration and about other automation tools like Selenium/Webdriver, Watir, 
>> Cucumber and others. That's the reason I started to think that QTP have to 
>> change a lot or it will lose a lot of market share.
>> 
>> These are my main points why I believe QTP have to change:
>> 
>> 
>> - Agile development is getting bigger and bigger.
>> - QTP can't handle continuous deployment, the tests takes to much time to 
>> run and can't be easily integrated with Hudson, CruiseControl or other CI 
>> tools.
>> - QTP can't handle BDD (it's possible with BPT but it's really expensive and 
>> doesn't work very well).
>> - VBScript is and old language and doesn't support a lot of features 
>> supported by newer languages like Python and Ruby.
>> - VBScript is not used for development, so DEVs and QAs can't code on the 
>> same language and improve knowledge sharing.
>> 
>> What do you think about that? I really interested in your views.
>> 
>> *** I will think about new points and add here later ***
>> 
>> 
>> Regards,
>> Leonardo Ribeiro Oliveira
>> -- 
>> You received this message because you are subscribed to the Google
>> "QTP - HP Quick Test Professional - Automated Software Testing"
>> group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/MercuryQTP?hl=en
> 
> -- 
> You received this message because you are subscribed to the Google
> "QTP - HP Quick Test Professional - Automated Software Testing"
> group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/MercuryQTP?hl=en
> 
> -- 
> You received this message because you are subscribed to the Google
> "QTP - HP Quick Test Professional - Automated Software Testing"
> group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/MercuryQTP?hl=en

-- 
You received this message because you are subscribed to the Google
"QTP - HP Quick Test Professional - Automated Software Testing"
group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/MercuryQTP?hl=en

Reply via email to