QTP (Keyword Driven) Vs. Twist (Page object pattern)

Previous two posts Web Application Testing (QTP Vs. Twist) and Test Creation (QTP Vs. Twist) talks more about the features in the tool and ease of use.  Following my two blog posts where I have compared QTP with Twist, this blog post is next  in the series which will talk about  Test framework and maintenance in both the tools.

When you launch QTP, you will notice that the Process Guidance pane shows you a path to achieve what QTP has popularized in the Testing community as “Keyword-Driven Testing”.

QTPFrameworkConcept

[Keyword Driven Testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly]
-QTP Help File on “Keyword Driven Testing”

This technique relies on 3 pillars:
  • Test Steps
  • Keywords
  • Object Repository
So a tester generally writes Test steps using the keywords, tester with technical knowledge creates function library using built-in keywords or their own user-defined keywords and maintain Object Repository. So a slight change in application would require changes in Object Repository and then the functions.

[The keyword-driven methodology is especially useful for organizations that have both technical and less technical users because it offers a clear division of automation tasks. This enables a few experts to maintain the resource framework while less technical users design and maintain automated test steps. Additionally, after the basic infrastructure is in place, both types of users can often do their jobs simultaneously. ]
-QTP Help File on “Keyword Driven Testing”

So QTP Keyword Driven Testing approach actually requires a significant manpower to create a Test Suite and maintain it. Also if you are following this testing technique (Keyword Driven), you need to put a significant effort in creating the infrastructure and then start writing the test cases. So it takes up considerable amount of time before you see the benefit out of QTP.

On the other hand if you are using Twist, it’s like you download it, install it and start automating your tests right from the day-1. You see an immediate benefit from the tool unlike QTP (Where in you will have to wait for quite some time may be a month, 2 months or 15 days till the basic infrastructure is built). Twist do provide a user some guide line to use the tool but you don’t need such heavy infrastructure to write test. All you need is the domain knowledge or the application under test.

[Writing your scenarios at the right level of abstraction is critical to building an effective test suite. Here are a few guidelines that can help you get there.
  • Tests should be independent of the user interface of the application.
  • Tests should strive to be at the highest level of abstraction possible, without sacrificing readability.
  • Don't repeat yourself: Repeating a series of steps at any level -- at a scenario, or in the implementation can increase the maintenance overhead.
  • Use Extract Concept and Push to Implementation to achieve granularity that reflects your domain and also promotes reuse
  • Your test should ideally be an illustration of the functionality as opposed to some UI mechanics. For instance, if a test reads:
    shopping cart
    • enter "5" in units and "10.0" in price and select "air shipping" in shipping dropdown
    Description of the UI clutters the intent here. Instead the test:
    shopping cart
    • create order for "5" units at price "10.0" for "air shipping"
helps clarify the intent.]
-Twist Help File on “Guidelines for your Test Suite”

Following a Page Object pattern is a nice way to group all the actions that are possible on a given screen.
Again Twist provides you more benefits than QTP when it comes to Test Suite Creation and maintaining them.

Comments

Popular posts from this blog

The 3 qualities that will always help you become better at almost anything…

How to install Android Emulator on Windows

Test Case Paths : Happy, Sad & Bad