Search This Blog

Thursday, September 22, 2011

QTP 11.0 and QC 11.0 Certifications

If anybody want QTP 11.0 and QC 11.0 Certification Dumps mail me at ch.girish.ch@gmail.com

In QTP 10.0 and earlier versions you need to take both QC exam(HP0-M31) AND QTP exam(HP0-M39) to get AIS certificate from HP. Starting with QTP 11/ALM 11, you just need to take one core exam that is HP AIS – Functional Testing v11 (Code HP0-M47) OR HP Application Lifecycle Management 11.x Software (Code HP0-M46).



Since you are reading a QTP blog, I assume you would want to take HP AIS – Functional Testing v11 (Code HP0-M47) exam. (Informally known as QTP 11 certification exam)



What to expect in HP0-M47: HP QuickTest Professional 11.0 exam?

Number of items: 72


Item types: multiple choice, drag-and-drop, and point and click


Exam time: 105 minutes


Passing score: 75%





Friday, January 21, 2011

Ruby on Rails Pros and Cons:

Good, somewhat objective summaries of the pros and cons surrounding the Ruby on Rails platform are rare. What you do find is plenty of buzz. What is Ruby on Rails all about? Why do people love it? Why do people hate it (yes, these people really do exist)? And why does it make some people very, very afraid?


 
Due to the nature of my employment, I’ve had the opportunity to work extensively with several web application frameworks, including Ruby on Rails. I’ve outlined my first-hand experiences below. Fat-free, but loaded with sugar.

Ruby on Rails: Development


 
Pros:
  • Very good OR/M – This is the best part of Rails. Saves a ton of work, and there is very little setup to be up and running (no nasty XML files, etc.)  
  • You feel like you are a hippie, rebelling against the system. J  
  • MVC, filters, etc. very useful  
  • Ruby is a terse language (compared to more tradition c-style languages), well thought-out, and very readable  
  • Lots of useful code generators  
  • Deployment is a snap with Capistrano  
  • Lots of interesting plug-ins and gems you can use to save time.  
  • Active, friendly, helpful community.  
  • Lots of good documentation  
  • Built-in testing framework  
  • Encourages good programming patterns  
  • Built-in support for AJAX

 
Cons:

 
  • Scaffolding is too basic to be very useful other than for learning and basic testing  
  • Easy to do things the “wrong way” if you rely too much on your experience with older web app models. I highly recommend getting some Ruby and RoR books and immersing yourself in the culture  
  • Hard to prove correctness of your code. Requires mounds of unit testing (which can easily take more time than coding the app itself).  
  • Large web apps become rather unwieldy. Rails is better suited to smaller, tighter code bases. Because it uses a dynamically typed, interpreted language, risk of regression bugs in your app increases exponentially with the size of the code base. Recent advancements in VMs (JRuby, Rubinius) and IDEs (Komodo, IntelliJ, Ruby in Steel), may help alleviate some of these problems.  
  • Hard to debug, step through code, etc. Again, new IDE support may help some with this, but it will be some time before it is on par with, say, ASP.NET.  
  • Rails development in a Windows environment is not as well supported as on a Mac.  
  • Development philosophy relies heavily on “magic” and “assumptions”. Coming back to a code base after a month or two will leave you confused until you remember everything that is going on behind the scenes.
Ruby on Rails: Deployment


 
Pros: 
  • Capistrano makes deployment to multiple machines straightforward  
  • Runs on inexpensive *nix boxes  
  • Multiple DBMS’s supported

 
Cons:

 
  • Have to keep gems, plugins, rails library all up to date and deployed along with your web app  
  • Capistrano’s SSH tunnel doesn’t always work the best when deploying from a Windows box  
  • You will be needing multiple servers earlier than you might expect. This obviously complicates deployment, but Capistrano is a big help there.  
  • When the app or server crashes, Mongrel & co. doesn’t (reliably) automatically restart (mod_rails AKA Passenger may be more reliable, but it is still fairly new and not as well tested).

 Ruby on Rails: Scaling


 
Pros

 
  • Runs on inexpensive *nix boxes or you can use a VPS cluster  
  • Capistrano designed with clusters in mind

 
Cons

 
  • You have to use clusters to handle even moderate traffic.  
  • Database can quickly become the bottleneck (this is what happened to twitter). No built-in support for multiple DB backends (shards, etc). ORM is not threadsafe.  
  • Eats up tons of RAM.  
  • Lots of CPU time spent, esp. in the OR/M layer. Much of this is due to heavy use of reflection. Rails 2.0 uses caching to improve this considerably, but can still be slow  
  • Rendering XML for REST/SOAP is very slow if you go through the old web services layer. In my tests, C#/WCF was at least 5x faster. Using the integrated 2.x REST features is much faster – on par with .NET when using a properly-tuned stack (not taking database access into account).  
  • Ruby is one of the slowest dynamic languages known to man. Ruby 1.9 is doing a lot to improve this, but statically-typed languages will always be faster. Depending on your workload, this may not matter.  
  • Page and partials caching can speed things up a lot, but is a pain to maintain when you make changes to your code  
  • Serious problems with piping files greater than a couple MB (i.e., PDFs, downloading a purchased product). I had to use PHP because Rails would crash every time.  
  • You have to use something else for serving static files, such as images and CSS. I highly recommend Nginx. Also makes a great proxy to Mongrel. 

 Ruby on Rails: The Bottom Line


Rails is a fun framework that takes a lot of the drudgery out of web programming. However, it’s lack of really great IDE support and static code analysis makes large apps difficult to maintain. There are also some serious scaling issues, even after recent developments speeding up rails 2x or so. I would recommend this for smaller projects with low to medium traffic loads. For very small projects, lighter MVC frameworks also based on Ruby would probably be more appropriate. If you are creating a web service that has to be SOAP or has to do a lot of computations or extensive data manipulation, I would stay away from Ruby altogether.

That being said, the critical weaknesses of the language and the framework (e.g., performance) are actively being addressed. So, even if you don’t choose to use Rails today, you would be quite foolish not to keep it on your radar.








 

Thursday, January 20, 2011

Enhancements in VSTS

The enhancements in VSTS are
1)      Find – You can now do a search in playback UI which will search request headers/bodies, response headers/bodies and the web test context.
2)      Add Extraction Rule – In the playback UI, you can now highlight some text in the response and select “Add Extraction Rule”.  This will automatically add a rule the web test.
3)      Goto webtest – This option will jump you from the request you are on in the playback UI to the same request in the web test.  Also if you are on a query string or form post parameter, it will jump you to that parameter in the web test editor.
4)      Show Recorded Result – This option will load a playback session with what was recorded.  During recording, we now create a web test result of what was recorded.  This will help when you want to try and figure out what is different between your current playback session and the recorded session.

VSTS supports five key types of tests

  1. Unit testing, in which you call a class and verify that it is behaving as expected
  2. Manual testing
  3. Generic testing that uses an existing test application that run as part of the biggest test
  4. Web testing to ensure the html apps function correctly
  5. Load testing to ensure the app is scalable.